SailPoint's fifth annual Horizons of Identity Security report, a survey of 340 senior identity, IT, security and risk leaders, found that 79% of enterprises run AI agents in production, while 2% have deployed identity-security tools built to govern those agents. Seventy-nine to two: SailPoint calls it a 40x gap between adoption and readiness.
In his QCon AI Boston talk "Zero Trust Agent Systems that Pass Audits and Still Ship", Advait Patel, a senior site reliability engineer at Broadcom, starts from a premise most enterprise teams know but rarely say out loud: prompts are not a dependable security boundary. The blast radius of an agent sits at the tool layer, where it calls APIs, reads databases and triggers actions, so that is where authentication, authorization and narrowly scoped permissions have to be enforced.
Patel's framing is useful because it is specific. He names four production risks: prompt injection through tool outputs, privilege creep as an agent collects tools nobody reviews, unsafe retrieval that crosses tenant and sensitivity boundaries, and action amplification, where one vague request triggers many consequential tool calls. Two more follow from them: actions nobody can trace, and incident response that is too slow.
None of this is theoretical. Salt Security surveyed more than 380 organizations and found that 49.8% confirmed or suspected that an agent took an unintended or unauthorized action in the past year. Only 12.5% can consistently trace a complete agent path, and only 17.5% can automatically stop an agent that starts behaving unexpectedly.
Those numbers should concern anyone responsible for integration architecture in a regulated environment. If you cannot trace what an agent did and cannot stop it when it misbehaves, you do not have a production system. You have a liability with an API key.
- Identity. Each agent, and where needed each session, gets its own identity (workload identity on GCP, IAM roles on AWS) instead of shared credentials, so every action can be tied to one agent and one user.
- Tools. Every tool has its own identity, authorization, rate limits and input and output controls, and is called with short-lived tokens scoped to the task.
- Context and retrieval. Access rules are enforced per document at query time, not by asking the model to behave.
- Policy and decision. A separate engine (OPA, Cedar or your own rules) sits between what the agent intends and what gets executed, and logs each decision.
- Audit and evidence. Structured traces per action, tied to identity and session, show what the agent accessed and did.
This is a control plane, not a diagram for the wall. For those of us who have spent years arguing that the integration layer is the enterprise control plane, the parallel is hard to miss. Agent systems inherit the structural problems of any integration estate: routing, fallback, observability, ownership at 02:00. The difference is that agents can outrun human review, which is why the check has to sit outside the model. We looked at that separately in deterministic gates against silent policy violations.
Much of the effort that goes into securing agents is spent on prompt engineering, guardrails around model behaviour and input validation. Patel argues those are not enough. Prompts can be injected through tool outputs. Permissions accumulate silently. Data crosses tenant boundaries during retrieval. Enforcement has to live where the agent acts.
This matches a principle integration architects know well: point-to-point trust is cheap exactly once. After that, you pay interest in incidents, exceptions and awkward steering committees. Scoped tokens, least privilege at the tool layer and allowlists for destructive actions are the agent equivalent of the governance we already apply to APIs and service contracts, and a gateway in front of the model and its tools is a natural place to enforce them (see our look at an AI gateway as a control point). What changes is velocity: an agent can chain dozens of tool calls in seconds, so privilege creep and action amplification happen faster than any human approval loop can catch.
Patel's controls are concrete. Treat tool outputs as untrusted and sanitize them. Enforce ACLs at query time. Tier destructive actions by blast radius, with a dry run or an explicit confirmation for the highest tier. And build the kill switch before the incident, which in practice means being able to revoke an agent's token at once. A kill switch is not paranoia; it is operational hygiene.
The common objection is that governance slows delivery. Patel inverts it: audit readiness built in from day one, through structured traces and decision logs, reduces friction over time. Without traces, incident investigation becomes archaeology. With them, you can show an auditor what the agent accessed, which policy governed each action and how far the damage could have gone. That is the evidence that lets you ship the next iteration without a three-week review. How to carry one trace across APIs, queues, workflow engines and model calls is the subject of our guide to trace IDs.
The stakes are already visible. On 21 October 2026 Microsoft attributed the ConnectWise Cloud Backup compromise to the actor it tracks as Storm-0940 and reported that the actor used ARTEX, an open-source penetration testing framework that can be driven by any AI model, to speed up reconnaissance, password spraying and the abuse of OAuth application access, including attempted sign-ins to more than 2,250 tenants. The root cause was still compromised credentials and trusted integrations; the agentic tooling made the attack chain faster. When adversaries automate their way through your integration surface, least privilege, strong application identities and monitoring around integrations stop being a theoretical business case.
Patel's practical advice: pick a valuable use case with a small blast radius; start with logging before any policy engine, because you cannot control what you cannot observe; run the agent in shadow mode for at least two weeks before you rely on it; and bring the SOC in early, because they will be paged first. Keep human approval for destructive actions only. Approval for everything is a control nobody sustains.
The survey data, the threat report and the architecture point the same way: agent identity, tool-layer authorization, short-lived credentials and end-to-end traces are the minimum for production, not extras for mature organizations.
Take one agent that is in production and answer three questions. Which identity does it run under, and is that identity its own? Which tools can it call, with which permissions, and for how long is its token valid? Can you produce the trace of its last ten actions, and stop it within minutes? Each question you cannot answer is the next item on the backlog.
If the agent acts on enterprise systems, this is the work we do in AI agent development: agents that act through your integration layer, with scoped permissions, audited tool access and a person at the checkpoints that matter.
