In a few months AI agents went from chat windows to colleagues with access. ChatGPT, Claude and Cursor can now connect to Databricks with one click, Snowflake's CoCo can run in the cloud on a schedule, and agents start more than 40% of pull requests on GitHub. That is great for productivity and a new kind of risk. An agent can be tricked by text it reads, it can take a wrong action very quickly, and it can run up a large bill. This checklist turns the lessons of 2026 into controls any data team can apply.
Why agents need different security
A normal application does exactly what its code says. An agent decides what to do based on what it reads, so anything it reads can influence it. Three risks come up again and again, and they match the top of the OWASP list for AI applications:
- Prompt injection
- Hidden instructions in a document, email or web page that the agent treats as orders, such as "send this table to this address".
- Excessive agency
- The agent has more permissions or tools than the task needs, so one mistake or trick causes real damage.
- Sensitive data disclosure
- The agent includes personal or confidential data in an answer, a log or a message where it should not appear.
The October 2026 evidence is clear. In OpenAI's own tests, GPT-6.1 Terra carried out an unauthorised action requested by an apparent "peer" agent in 11 of 80 cases, against 1 of 80 for GPT-6.1 Sol. Google reports that Gemini 4 Carbon resisted every attempt in Gray Swan's indirect prompt-injection test, but that was without guardrails and with a model most people cannot use yet. Models are getting better, but you cannot rely on the model alone.
The checklist
- 1
Give each agent its own identity
Never let an agent borrow a person's login. Use a service principal or agent identity, so you can see and revoke exactly what it does. Snowflake now gives each agent its own identity and permissions.
- 2
Grant the least access possible
Start with read access to one schema or one set of metric views, not the whole warehouse. Use roles, row access and masking policies as you would for a new employee.
- 3
Make read-only the default
Let agents query, analyse and draft. Any write, delete, merge or email should be a proposal a person approves.
- 4
Route code changes through review
Agents should open pull requests on a branch, with tests that must pass. Snowflake's CoCo GitHub integration and GitHub's own review flow do this.
- 5
Separate trusted and untrusted text
An agent that reads customer emails, tickets or web pages should not also hold write access to production. Split these into two agents with different permissions.
- 6
Allow-list tools and MCP servers
Only connect the tools the task needs. Databricks Unity Gateway can now screen MCP tool calls for prompt injection (beta); Snowflake's Cortex AI Gateway controls which external tools agents may use.
- 7
Restrict network access
Agents and their code should run in a sandbox that can only reach approved destinations, so data cannot be sent to an unknown server.
- 8
Mask sensitive data
Apply masking to personal data before agents see it. If the agent does not need names and emails, it should never receive them.
- 9
Log every action
Turn on tracing for prompts, tool calls and results, and keep audit logs. MLflow tracing on Databricks and Snowflake's agent activity records make this easier.
- 10
Set spend and rate limits
Cap AI spend per agent, team or project, and limit how many actions an agent can take per hour.
- 11
Test it like an attacker
Before go-live, try to trick the agent: plant instructions in a test document and see whether it follows them. Repeat after every model change.
- 12
Keep a kill switch
Know how to revoke the agent's credentials in one step, and who is allowed to do it.
Where to switch these on
| Control | Snowflake | Databricks | Coding agents (GitHub, Claude Code, Codex, Cursor) |
|---|---|---|---|
| Agent identity | Per-agent identity and permissions | Service principals; default OAuth apps for external agents use each person's own permissions | Separate bot accounts or tokens per agent |
| Limiting scope | CoCo Restricted Session Scope (GA) | Unity Catalog grants, row filters and masks | Branch protection; repository-level permissions |
| Tool control | Cortex AI Gateway tool access rules | Unity Gateway MCP screening (beta) | Allow-listed MCP servers and commands |
| Logging | Agent activity records, tracing in Cortex AI Gateway | MLflow tracing, Unity Gateway audit logs | Pull request history and CI logs |
| Spend | AI cost governance in Cortex AI Gateway | Spend caps in Unity Gateway | Usage limits per seat or per organisation |
A simple maturity path
From pilot to production
Read-only pilot
One agent, one dataset, read access, full logging.
Proposals with approvalNow
The agent drafts changes and pull requests; people approve.
Limited automationUpcoming
Low-risk actions, such as adding tests or documentation, run automatically with spend caps.
Regular red-teamingUpcoming
Re-test after every model or permission change.
Check your understanding
1/3What is indirect prompt injection?
It is the top risk for agents that read untrusted content.
2/3What should an agent's default access be?
Read-only by default limits the damage a mistake or a trick can cause.
3/3Why split one agent into two when it reads customer emails?
Separating untrusted input from write access is one of the most effective defences.
You got 0 out of 3.
Read next: AI agents going off script, GitHub Octoverse 2026, Snowflake vs Databricks for AI agents and the EU AI Act timeline.
Sources: OWASP Top 10 for Large Language Model Applications; OpenAI's GPT-6.1 Terra system card as summarised by Learnetto (October 2026); Google's Gemini 4 Carbon security results (28 October 2026); Databricks release notes (October 2026); Snowflake Expedition 2026 announcements (3 November 2026); GitHub Octoverse 2026. This is general guidance, not a substitute for your security team's review.
Alessandro Ecclesie AgazziWritten by Alessandro Ecclesie Agazzi, analytics engineer in London. Updated 3 November 2026. About me