--- title: "Prompts Are Not a Security Boundary: Zero Trust for AI Agents" description: "Zero trust for AI agents: why prompts are not a security boundary, and how tool-layer identity, short-lived tokens and audit traces close the gap." canonical: "https://www.kondevs.com/content-hub/prompts-not-security-boundary-zero-trust-ai-agents/" language: "en" type: "article" author: "https://www.kondevs.com/authors/stoyan-kondev/" published: "2026-11-11T20:42:52.800Z" modified: "2026-11-11T20:42:54.992Z" image: "https://www.kondevs.com/assets/images/content/prompts-not-security-boundary-zero-trust-ai-agents/og.jpeg" tags: ["ai-agents", "zero-trust", "agent-security", "least-privilege", "audit-trail", "integration-architecture", "AI Agent"] --- > For the complete index of this site, see [llms.txt](https://www.kondevs.com/llms.txt); the whole site in one file: [llms-full.txt](https://www.kondevs.com/llms-full.txt). # Prompts Are Not a Security Boundary: Zero Trust for AI Agents AI & Machine Learning 11 November 2026 6 min read By [Stoyan Kondev](https://www.kondevs.com/authors/stoyan-kondev/) ## Key takeaways - SailPoint's survey of 340 senior leaders found 79% of enterprises run AI agents in production while 2% have deployed identity-security tools built to govern them: a 40x gap between adoption and readiness. - Advait Patel's architecture enforces security at the tool layer, with an identity per agent, short-lived tokens scoped to the task and least privilege, instead of relying on prompts as a security boundary. - Four production failure modes to plan for: prompt injection through tool outputs, privilege creep, unsafe retrieval across tenant and sensitivity boundaries, and action amplification. - Five layers: identity, tools, context and retrieval, policy and decision, audit and evidence. Structured traces and decision logs from day one are the audit evidence that lets the next release ship faster. - Microsoft's report on Storm-0940 and the ConnectWise Cloud Backup compromise shows attackers already using AI-driven tooling to move faster through trusted integrations. - Where to start: a use case with a small blast radius, logging before policy, at least two weeks in shadow mode, the SOC involved early, human approval for destructive actions only. 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](https://www.sailpoint.com/press-releases/sailpoint-horizons-identity-security-ai-adoption-gap). 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"](https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/), 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. ## Four failure modes that matter in production 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](https://salt.security/blog/agents-are-acting-most-organizations-cannot-stop-them). 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. ## The five layers Patel proposes 1. **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. 2. **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. 3. **Context and retrieval.** Access rules are enforced per document at query time, not by asking the model to behave. 4. **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. 5. **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](https://www.kondevs.com/content-hub/deterministic-gates-silent-policy-violation-llm-agents/). ## Why the tool layer is the real trust boundary 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](https://www.kondevs.com/content-hub/cloudflare-ai-gateway-enterprise-control-plane/)). 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. ## Audit readiness as a shipping accelerator 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](https://www.kondevs.com/content-hub/trace-ids-correlation-apis-queues-bpm-ai-calls/). 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](https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/). 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. ## Where to start 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. ## Three questions for an agent you already run 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](https://www.kondevs.com/services/agent-development/): agents that act through your integration layer, with scoped permissions, audited tool access and a person at the checkpoints that matter. ## Frequently asked questions ### Why are prompts not a reliable security boundary for AI agents? A prompt can be overridden by text injected through tool outputs, and it cannot enforce authentication, authorization or permission scoping. Patel argues that security must live at the tool layer, where agents call APIs, read databases and trigger actions, using an identity per agent, short-lived scoped tokens and allowlists. ### What are the five layers of a zero trust architecture for AI agents? Identity (each agent and session has its own identity), tools (each tool has its own identity, authorization, rate limits and short-lived tokens), context and retrieval (access rules enforced per document at query time), policy and decision (a separate engine between intent and execution that logs each decision), and audit and evidence (structured traces per action tied to identity and session). ### What controls help prevent an agent from taking high-impact unauthorized actions? Least privilege at the tool layer, short-lived tokens scoped to the task, allowlists and tiers for destructive actions, a dry run or an explicit confirmation for the highest tier, and a kill switch built before the incident: in practice the ability to revoke an agent's token at once. ### How can organizations show auditors what an AI agent accessed and what actions it took? With the audit and evidence layer: structured traces that record every tool call, policy decision and data access per agent session, tied to the agent's identity. They serve as replayable evidence for incident investigation and compliance reviews. ### How large is the gap between AI agent adoption and agent governance? SailPoint's survey of 340 senior leaders found 79% of enterprises run AI agents in production, while 2% have deployed identity-security tools built for agents. Salt Security found that only 12.5% of organizations can consistently trace a complete agent path and only 17.5% can automatically stop an agent that behaves unexpectedly. ### What real-world threat shows why agent controls matter in integration-heavy environments? On 21 October 2026 Microsoft reported that the actor it tracks as Storm-0940 used ARTEX, an open-source penetration testing framework driven by AI models, to speed up reconnaissance, password spraying and OAuth abuse in the ConnectWise Cloud Backup compromise, with attempted sign-ins to more than 2,250 tenants. ## Sources 1. [Zero Trust Agent Systems that Pass Audits and Still Ship, infoq.com](https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/) 2. [The State of Agentic AI and API Security 2H 2026, salt.security](https://salt.security/blog/agents-are-acting-most-organizations-cannot-stop-them) 3. [AI-driven, large-scale nation-state campaign using ARTEX, microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/) ## Related concepts & services Key terms: [AI Agent](https://www.kondevs.com/glossary/#ai-agent) Explore our service: [Data Science & AI Consulting](https://www.kondevs.com/services/ai-consulting/) ai-agents zero-trust agent-security least-privilege audit-trail integration-architecture