Zero Trust for AI Agents: The Control That Stops It Going In Is Not the Control That Stops It Coming Back Out
On 8 September 2026 the Cloud Security Alliance published its Zero Trust Microsegmentation Guidance. One sentence in it does more work than the title suggests.
"Unlike traditional workloads," the guidance states, agentic systems dynamically choose tools, invoke APIs and retrieve data as they run, and they "create outbound egress paths at runtime."
Read the last clause twice. Create outbound egress paths at runtime. Not use pre-approved ones. Not route through a configured gateway. Create them, while running, as a consequence of doing the job they were deployed to do.
The guidance then does something most architecture documents do not. It writes down two requirements and keeps them apart. On one side, an organisation must maintain an approved inventory of tools, APIs, models, data sources and services agents are permitted to access, and the guidance is explicit that this is "a managed lifecycle surface, not a static list." On the other side, and separately, it requires governed egress.
Two requirements. Two owners, in most organisations. Two tools. Two reporting lines.
If your AI security posture is a single number, you are reporting on one of them.
The taxonomy already knew
This is not one consortium's framing. The industry's own risk taxonomy has been split along the same seam for three years and almost nobody reads it that way.
OWASP published its GenAI LLM Top 10 for 2026 on 3 August 2026. Prompt Injection ranks first, for the third consecutive year. Sensitive Information Disclosure ranks second. Trade coverage of the release notes that the top two "remained constant." Excessive Agency climbed from sixth in 2025 to third in 2026.
A note on precision, because this chapter is about not conflating two things: the first three positions are what this pipeline verified directly, from the OWASP resource page and from independent trade coverage of it. The remaining seven positions are not claimed here. If you need the full order, go to the document.
The first three are enough. Prompt Injection is the ingress-side risk: untrusted content reaching a privileged agent. Sensitive Information Disclosure is the egress-side risk: data leaving that agent once it holds it. Excessive Agency, now third, is the capability that turns the first into the second.
These are not one risk described twice. They are separately named, separately ranked, and they fail separately. OWASP has been telling you that on the front page of its own list.
The exfiltration that never crossed a perimeter
This series has already found this once, and wrote the finding down without noticing it was general.
Chapter 29, "The Trust Boundary Is the CI Runner," covered a credential-theft chain across three vendors' coding agents. One sentence in it does the work this chapter is built on: the exfiltration loop stayed inside GitHub the entire time, which is exactly why no ordinary network-egress control would have caught it.
Read as a fact about that case, it explains one incident. Read as a claim about control architecture, it says something much larger, and the rest of this chapter is that reading.
In April 2026, researchers Aonan Guan, Zhengyu Liu and Gavin Zhong published "Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent." Three coding-agent products from three different vendors could each be induced, through a pull-request title, an issue body or a hidden HTML comment, to print their own repository secrets back into a PR comment, an issue comment or a commit.
Each agent held production continuous integration secrets. Each processed content from anyone able to open a pull request. Each could post output back to a page an attacker was already watching. All three legs, one unsupervised session, three vendors independently.
No traffic crossed a corporate network boundary at any point. A control watching that boundary, correctly configured, fully funded and working exactly as designed, would have reported nothing, because nothing it was built to watch happened.
That is the whole argument in one case. The ingress-side control and the egress-side control were not two settings on one product. They were two different things, and only one of them existed.
CoSnitch: one disclosure, two vulnerabilities
The pattern recurs inside a single vulnerability chain, which is the sharpest version of it.
Varonis Threat Labs disclosed CoSnitch, tracked as CVE-2026-24301, against Microsoft Copilot Personal. Reported to Microsoft in December 2025 and patched on 18 August 2026, roughly an eight-month remediation window. Varonis states it found no evidence of exploitation in the wild.
The chain has two distinct components, and both Varonis and independent trade coverage treat them as two.
The first is an undocumented autorun=1 URL parameter, paired with the existing q= parameter, which triggers automatic prompt execution on page load with no further user interaction beyond an initial click. That is the ingress side: a way to get an instruction in front of a privileged assistant without asking anyone.
The second is a separate exfiltration path. The injected prompt queries data from services the user had already authorised by OAuth, Gmail, Calendar and Drive among them, encodes it, and uses Copilot's own built-in URL-fetch capability to send it to an attacker-controlled endpoint, indistinguishable from ordinary web-summarisation traffic. That is the egress side, and it is not a bug in the ordinary sense. It is a documented product feature doing exactly what it was built to do, for someone else.
Patching autorun=1 closes the first. It says nothing whatsoever about the second. The URL-fetch capability was not the vulnerability; it was the exit. If your control estate treats the patch as having closed CoSnitch, it has closed half of it.
One further detail is worth recording because it changes the risk profile: the attack could plant persistent memory rules that survived password resets, session revocation and device re-enrolment. An egress path that outlives credential rotation is not an incident with an end date.
On the score, stated rather than omitted. A CVSS 3.1 base score of 8.8 circulates for this CVE. Neither of the two sources this pipeline fetched directly carries it. Varonis calls the flaw critical without a number, and the independent coverage gives none either. This chapter cites no CVSS score for CoSnitch, and readers who find one in circulation should treat it as untraced until they see it on a page that publishes it.
The scale evidence, corrected
Neither case above is an outlier. Two independently governed measurements, corrected here rather than taken from the headline figures circulating this month, point the same way.
Netskope's Threat Labs Report: Australia and New Zealand 2026, published 9 September 2026, finds downstream data policy violations, an AI system returning sensitive data to a user or agent not authorised to see it, occurring in approximately 89 per cent of ANZ organisations, a figure stated verbatim in the report body. Upstream violations, staff pasting sensitive data into AI tools, run far higher again. Neither number is New Zealand-specific: the report is a combined Australia and New Zealand aggregate dominated by the larger Australian customer base, and no split between the two countries is published anywhere in it.
A separate, independently fielded Cloud Security Alliance and Aembit survey of 228 IT and security professionals, released in March 2026, found 68 per cent of organisations cannot clearly distinguish AI agent activity from human activity in their own logs, and 82 per cent report unknown AI agents already active in their environment. It is a survey of practitioner perception, not measured telemetry, and it says so about itself.
Both details, the ANZ aggregation and the survey methodology, matter and neither undermines the direction. An estate that cannot reliably tell an agent's traffic from a person's is not well placed to say what that traffic is permitted to send onward, and a reported prevalence of downstream violations in nine out of ten organisations describes exactly the control gap this chapter has already found twice by name, in two vendors' products, six months apart.
The leg that was doing two jobs
The construct this book has used since Part Two needs sharpening, not replacing.
The lethal trifecta is the term Simon Willison coined on 16 June 2025 for the combination of private data access, untrusted content exposure and external communication capability. An agent holding all three is structurally capable of acting as an insider threat without tripping conventional access controls. Chapter 5, "The Three Capabilities That Turn Your AI Into an Insider Threat," applied it as this book's governing threat model, and it has held up under every production incident this series has examined since.
What the three cases above show is that the third leg has been carrying two control problems under one name.
External communication capability, read as a single property, invites a single control: watch the boundary. That reading survives right up until the communication does not cross a boundary. In "Comment and Control" it never left GitHub. In CoSnitch it left as a web fetch that the product performs a thousand times a day for legitimate reasons. In both, a boundary control was either absent or irrelevant, and in both the ingress side and the egress side were separately fixable.
So the refinement, stated as precisely as this chapter can put it. The trifecta's third leg is not one capability. It is the point at which two independent control problems meet: what may reach this agent, and what may leave it. They share a leg in the threat model. They do not share a control, a tool, an owner or a metric.
This is a refinement of Willison's third property, not a fourth property. The trifecta still has three legs. One of them needs two assurance answers instead of one.
Identity tells you who is asking. It does not tell you what may leave.
Chapter 12, "The Sixth Pillar: Agent Identity and the New Perimeter," argued that agent identity is the sixth Zero Trust pillar, and Chapter 9, "The Identity Layer: When Every Agent Needs a Badge," set out what issuing those identities requires. Both arguments hold. This chapter draws a boundary on them rather than disputing them.
Cryptographic agent identity answers an ingress-adjacent question: is this request coming from a principal I authorised. It is necessary. It does not, on its own, answer the egress question: given an authorised principal legitimately holding data, what may it send, and where.
Look at what that means against the two cases. In "Comment and Control," the identity of the acting agent was never in doubt. In CoSnitch, the OAuth grants were real, current and the user's own. Neither failure involved any identity ambiguity at all. Perfect identity architecture would have prevented neither.
The CSA guidance treats these as two policy dimensions, and it is worth quoting its own words for the access side, because they are more demanding than most segmentation policies in production. Segmentation must define "which agents may access which tools, APIs, data sources, model endpoints" and under what conditions of identity, posture, delegation, task and approval. That is the access half. Governed egress is the other half, and the guidance names it separately.
One caution before anyone writes this into a business case. NIST SP 800-207 remains the August 2020 final and names no AI agents. Any claim that an agentic egress control is "NIST-compliant Zero Trust" is an interpretation by reading, not a standard NIST has issued. This chapter's argument stands on what CSA, OWASP and two disclosed cases actually say. It does not need a borrowed authority, and neither does your paper.
A control-coverage declaration
Part Six is meant to hand over something deployable, so here is the smallest artefact that makes the gap visible. It is not a control. It is a statement of what your controls cover, written per agent, and its only job is to stop a single number standing in for two.
# agent-control-coverage.yml# One block per agent with any privileged access. Reviewed when scope changes.agent-id: claims-triage-assistantowner-team: claims-platformprivate-data-access: trueuntrusted-content-exposure: trueexternal-communication: trueingress-control:mechanism: content-filtering-gatewaycovers: prompt-content-on-inbound-api-callsdoes-not-cover: retrieved-document-content-and-tool-responsesmetric-reported: blocked-injection-attempts-per-quarterowner-team: ai-platformegress-control:mechanism: none-deployedcovers: nothingdoes-not-cover: all-outbound-paths-including-in-product-fetchmetric-reported: noneowner-team: unassignedknown-blind-spots:- in-product-url-fetch-is-not-treated-as-an-egress-path- responses-written-back-to-the-source-system-never-cross-a-network-boundarynote: "An unassigned egress owner is a finding, not an empty field."Three things about this artefact, stated plainly so nobody mistakes it for more than it is.
It is a starting shape, not a finished control. It records coverage; it enforces nothing. And it deliberately does not make two governance decisions for you: who owns egress control when the platform team owns ingress, and what an acceptable egress metric even looks like when nobody in the market publishes one. Those are yours.
What it does do is make mechanism: none-deployed a thing somebody has to write down.
| What it watches | What it misses | |
|---|---|---|
| Network-boundary control | Traffic leaving the corporate perimeter | Anything that stays inside a trusted platform |
| Ingress content filter | Untrusted content on the way in | Everything after the agent holds the data |
| Egress path governance | What an authorised agent sends, and where | Nothing, if it is deployed. Everything, if it is not |
Aotearoa New Zealand: an honest gap, again
This is the fourth consecutive chapter in this series to look for a New Zealand publication on its topic and find none.
NCSC-NZ's published AI guidance takes a governance and compliance posture: confirm executive accountability, remediate gaps against NZISM and the NCSC Cyber Security Framework. That is a reasonable posture and it is not a technical-controls posture. It does not name ingress-side content controls and egress-side data-loss controls as separate assurance obligations, because it does not operate at that layer.
NZISM v3.9, released 9 May 2025, remains the current version. This chapter did not read its text to check whether any chapter separates input-content controls from output data-loss controls for agentic systems specifically. That is a targeted read this series has now flagged and left three times, and it is stated here as an open question rather than answered by assertion.
So the honest position: there is no New Zealand regulatory hook for this chapter's distinction. Every mechanism-level case in it belongs to international vendors, researchers or an international industry consortium. A New Zealand architect asking what the guidance says about this will find the question competently unaddressed rather than answered badly, and closing that gap is enterprise work before it is anybody's policy work.
The number that was not on the slide
An enterprise architect at a New Zealand insurer is presenting the quarterly security posture update to the risk committee. She opens with a chart she is pleased with. The organisation's prompt-injection detection rate has trended down for three consecutive quarters, since the platform team put a content-filtering layer in front of every agent holding tool access.
A committee member, an actuary rather than a security specialist, asks a question that is not on the slide. If something did get past that filter, what stops the agent sending our data somewhere it should not go?
She starts to answer with the same slide, because the injection-detection number is the only AI security metric her team produces. Then she stops, because the honest answer is that she does not know what the equivalent number is. The gateway logs what it blocked on the way in. Nothing in her stack logs, in any comparable way, what an already-authorised agent sent onward and to where. The two would be built by different teams, on different tooling, reporting on different cycles, and until this moment nobody had asked her to put them on the same page.
She is not hiding anything. She has been reporting a real number, accurately, for three quarters. Nobody had asked whether it was the number that answered the question.
Which is the finding worth carrying out of all of this. A falling prompt-injection count is evidence that your ingress control is working on its own terms. It is not evidence about the other half, and reading it as though it were is the substitution this chapter exists to interrupt. OWASP's own methodology note on the 2026 list makes the trap concrete: ranked by raw incident count alone, Prompt Injection would fall out of the top ten entirely, which OWASP attributes to defences working well enough that fewer attacks reach public incident databases. A quieter dashboard can mean the ingress side is holding. It cannot mean the egress side is covered, because on most estates nothing is measuring it.
Go and look at your own AI security reporting. If every metric on it counts something that was stopped on the way in, you have half a control estate and a full-looking slide.
The distinction this chapter draws did not come from a single vendor's product team. OWASP's GenAI Security Project builds its Top 10 through an open, versioned community process: a working group operating in public, rankings set by community vote weighted against real-world incident data, the document itself published under an open licence and revised in the open. The Cloud Security Alliance's guidance sits in the same open-consortium tradition, developed through member working groups rather than issued by a single company with a stake in the answer. The open-source dimension worth naming here is not a codebase; it is a governance model, decisions about what counts as a top risk made by a community that must defend its ranking in public rather than behind a vendor's marketing copy. That is also part of why two independently governed bodies converged on the same split without coordinating with each other.
The defence-doctrine reading has a specific document behind it, not only a habit of mind. The US National Security Agency's own zero trust guidance treats data as one of seven distinct pillars, and its data-pillar cybersecurity information sheet is explicit that maturing this pillar means governing not only who may reach data but what may leave with it once access is granted, through data tagging, rights management and monitored egress rather than perimeter assumptions carried over from an earlier architecture. That is the same seam this chapter has traced through a consortium guidance document and two disclosed cases: access and egress are distinct assurance obligations, stated separately because collapsing them into one control has repeatedly failed the same way. Segmentation doctrine did not invent this distinction. It inherited it from an agency that spent decades assuming the network was already compromised.
What is your egress-side number, and who owns it?
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
References
[1] Cloud Security Alliance. "Zero Trust Microsegmentation Guidance." 8 September 2026. https://cloudsecurityalliance.org/artifacts/zero-trust-microsegmentation-guidance
[2] OWASP GenAI Security Project. "OWASP GenAI LLM Top 10 2026." Published 3 August 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
[3] Help Net Security. "OWASP 2026 LLM Top 10: 'The model will be fooled.'" 6 August 2026. https://www.helpnetsecurity.com/2026/08/06/owasp-2026-llm-top-10-released/
[4] Varonis Threat Labs. "CoSnitch." https://www.varonis.com/blog/cosnitch
[5] The Hacker News. "Microsoft Copilot Personal Flaws Could Let One Click Exfiltrate Data From Connected Apps." https://thehackernews.com/2026/08/microsoft-copilot-personal-flaws-could.html
[6] Guan, A., Liu, Z. and Zhong, G. "Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent." April 2026.
[7] Willison, S. "The lethal trifecta for AI agents: private data, untrusted content, and external communication." simonwillison.net. 16 June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[8] National Institute of Standards and Technology. SP 800-207, Zero Trust Architecture. Final, August 2020.
[9] National Cyber Security Centre New Zealand. New Zealand Information Security Manual, v3.9. Released 9 May 2025.
[10] Hamberger, A. "The Trust Boundary Is the CI Runner." Zero Trust Architecture for the Agentic Enterprise, Chapter 29. EA Thursday, 27 August 2026.
[11] Netskope Threat Labs. "Threat Labs Report: Australia and New Zealand 2026." Published 9 September 2026.
[12] Cloud Security Alliance and Aembit. "Identity and Access Gaps in the Age of Autonomous AI." Press release. 24 March 2026.
[13] National Security Agency. "Advancing Zero Trust Maturity Throughout the Data Pillar." Cybersecurity Information Sheet. 9 April 2024. https://media.defense.gov/2024/Apr/09/2003434442/-1/-1/0/CSI_DATA_PILLAR_ZT.PDF