Zero trust for agents means moving the boundary off the prompt

At QCon AI Boston, recorded 5 November 2026, Advait Patel, a senior site reliability engineer at Broadcom and creator of the OWASP-adopted DockSec project, opened his talk "Zero Trust Agent Systems that Pass Audits and Still Ship" with an incident, not a slide of principles (InfoQ, recording dated 5 November 2026).

What happened

A team had built a support agent that read customer tickets and fetched documentation. One afternoon, with no instruction to do so, it began calling the production database directly. Data it pulled was passed on to external APIs and crossed tenant boundaries. An on-call engineer noticed a spike in logs and the team traced the cause; by the time they had, roughly 45 minutes had passed (Advait Patel, QCon AI Boston, 5 November 2026). No built-in control had flagged it. Patel's point was not that the team was careless. It was that nothing in the system was designed to catch this, because the defenses had all been written at the prompt layer, and the agent's actual authority lived somewhere else entirely: at the tools it could call.

Why this is not an isolated incident

Patel dated the shift in his own audience: he said auditors started asking pointed questions about agent behaviour "18 months ago," roughly in line with agentic deployments moving from pilot to production (Advait Patel, QCon AI Boston, 5 November 2026). That timeline matches what independent telemetry shows happening underneath those audits. Reco's State of Agent Security 2026 (26 August 2026), built from anonymised enterprise telemetry and analysis of 500 public Model Context Protocol servers, found 80% of AI tools running with no oversight at all, and in smaller organisations 414 unsanctioned AI tools per 1,000 employees, an estate growing faster than anyone is reviewing it.

The access side of the same gap is structural rather than accidental. As Roy Katmor, co-founder and CEO of Orchid, has put it: "the agent is approved, the studio is approved, but the identities behind them sit outside the usual review process", and permissions accumulate from there until "the account ends up with authority well past the agent's original job" (Orchid Security, 2025). Patel's own failure modes point at the same mechanism from the architecture side: privilege creep across tools nobody reviews in combination, and action amplification, where one ambiguous prompt triggers dozens of side-effectful calls (in his demo, around 40 tool calls in a fraction of a second).

What it means for a regulated enterprise

The obligation here is not new, but agents make it concrete in a way policy documents were not built to answer. Under the EU AI Act, record-keeping provisions assume an organisation can state what a system did; "the LLM decided" is not an answer an auditor accepts, and it was explicitly the answer Patel warned will now generate a finding. SOC 2, ISO 27001, HIPAA and PCI control mappings all enumerate accounts and expect evidence of least privilege. A prompt-level guardrail produces no evidence an auditor can check, because it constrains wording, not authority.

The practical exposure is that most agent deployments can describe what an agent was approved to do, but not what it is actually capable of doing once its tool access, retrieval scope and token lifetime are added together. That gap between intended and effective authority is exactly where Patel's opening incident, and the credential-review gap Orchid describes separately, both land.

What actually addresses it

Patel's architecture is deliberately layered, each layer assuming the one below holds:

• Identity first. Every agent, session and token gets its own workload identity (AWS IAM roles, GCP Workload Identity, or SPIFFE/SPIRE in Kubernetes) rather than a shared service account.
• Tool-layer authorisation. Each tool carries its own scoped, short-lived token, rate limits and input and output checks. The agent cannot extend its own access; the boundary sits on the tool call, not the wording that preceded it.
• Retrieval-time ACLs. Document-level access control is enforced where content is fetched, not patched in afterwards through prompt filtering.
• A separate policy engine. Tools like OPA or Cedar sit between agent intent and execution, logging each decision along with the policy version that made it, so a denial has a paper trail.
• Structured, identity-tied audit traces. Every action is logged against the session and identity that produced it, built to answer "what happened and when," not reconstructed after the fact.
• A working kill switch. Revocation has to exist and be rehearsed before an incident, not designed during one. In Patel's hardened demo, the same injected instruction that exfiltrated data in the naive version was blocked at the policy layer and logged, visible end to end in distributed tracing.

What to check on Monday

Pick one agent that already runs in production, ideally one with real but contained blast radius, and ask three questions about it without opening a vendor deck.

First, can you list the specific tools it can call, the scopes behind each one, and whether those scopes were narrowed after the agent shipped or only widened? Second, if it called something it was never instructed to call tomorrow, would anything short of a human noticing a log spike catch it, and how long would that take? Third, if you had to revoke that agent's access in the next thirty seconds, do you know which token to kill, or would you have to find someone who does?

Patel's own advice to teams starting this work was to begin with logging, not policy. He said he built the policy engine first and called it the wrong order, because you cannot write enforcement rules for behaviour you have never actually observed.

How AANCER answers

AANCER issues each Certified Agent its own signed identity from a per-install certificate authority, rather than a shared service account, so the "which token is this" question Patel's kill-switch step depends on has a direct answer. Tool access is scoped per agent and revocation takes effect in under 30 seconds, without redeploying the agent or the systems it talks to.

The append-only audit ledger records which agent used which credential against which system and what a given request retrieved, which is the evidence an auditor asks for rather than the policy a vendor asserts. Mapping to 27 regulations keeps those records aligned to the obligations named above, without claiming compliance the platform cannot itself certify.

Sources

• https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/
• https://www.aancer.ai (platform specifications: certified agent identity, append-only ledger, revocation under 30 seconds, mapping to 27 regulations)