Executive summary
Agentic AI - systems that plan, browse, execute code and take real action with limited human involvement at each step - has moved from pilot project to production dependency faster than the governance frameworks meant to contain it have matured. On 1 May 2026, CISA, the NSA and their counterparts in Australia, Canada, New Zealand and the UK jointly published Careful Adoption of Agentic AI Services, the first coordinated Five Eyes guidance addressing a single AI attack surface. It is detailed, technically grounded, and explicitly non-binding. HiddenLayer's 2026 AI Threat Landscape Report, published the same year, found that one in eight reported AI security breaches is now linked to agentic systems, and that nearly a third of organisations could not say with confidence whether they had experienced an AI-related breach at all. This paper sets out a governance framework built around five risk categories drawn from that Five Eyes guidance - privilege, design and configuration, behavioural, structural and accountability risk - and situates it inside the regulatory environment enterprises are actually operating in during 2026: EU AI Act enforcement powers taking effect, a contested US federal preemption debate, and a growing body of real incidents that make every one of these categories concrete rather than theoretical.
The central argument is that "voluntary" guidance from this particular set of agencies has a track record of becoming the de facto standard regulators, auditors, insurers and enterprise customers measure against, well before any legal mandate catches up to it. Enterprises that treat this guidance as a compliance footnote to revisit once something becomes mandatory are choosing to build agentic AI systems now, under commercial pressure, without the architecture that the people who study AI-specific attacks are telling them they will need. This paper is written for the enterprises that would rather not find that out the hard way.
1. Why agentic AI needs its own governance category
Conventional application security assumes a fixed, auditable set of code paths: the same input broadly produces the same behaviour, and a security review can reason about what the system can and cannot do. Agentic AI breaks that assumption by design. The same agent, given the same instruction, can take a different sequence of actions depending on what it encounters along the way, which means the review question shifts from "what can this system do" to "what is this system capable of deciding to do," a question conventional security tooling was never built to answer. Recent incidents make the gap concrete: a prompt injection flaw in an AI code editor that required no click from the victim to escape its intended sandbox, and a data-processing pipeline compromise where an autonomous agent, not a human operator, ran thousands of actions across disposable environments to harvest credentials and move laterally. Neither incident involved a stolen password. Both involved an agent doing exactly what it was manipulated into believing was its job.
2. Privilege risk
The Five Eyes guidance identifies privilege risk as agents granted access broader than any single task requires, creating disproportionate damage potential when an agent is compromised or manipulated, often executing at machine speed before a human has any realistic chance to intervene. The practical failure mode is familiar to anyone who has reviewed a service account: an agent provisioned once, broadly, for convenience, that ends up with standing access to systems and data far beyond what its current task set actually needs. We recommend scoping agent credentials per task class rather than per agent, issuing narrowly time-bound access for a specific action rather than a persistent broad grant, and treating any agent with standing access to sensitive systems as a tier-0 asset requiring the same scrutiny as a human administrator account.
3. Design and configuration risk
This category covers the security gaps introduced by how an agentic system is built rather than how it is used: weak authentication between agent components, poor scoping of third-party integrations, and architectural patterns that concentrate trust in a single high-value component without anyone deciding to do so deliberately. A multi-agent system where every agent shares one credential, or where a planning component and an execution component trust each other implicitly, is a design and configuration risk regardless of how carefully any individual agent's prompts are written. We recommend architectural review of agentic systems as a distinct discipline from prompt or model evaluation, specifically examining trust boundaries between components and third-party integrations before deployment, not after an incident reveals where they were missing.
4. Behavioural risk and the prompt injection problem
The Five Eyes guidance is unusually direct in naming prompt injection as the most persistent and difficult-to-fix threat facing agentic systems, for a structural reason: large language models cannot reliably distinguish a legitimate system instruction from an adversarial one embedded inside a document, email or web page the agent is asked to process. An agent pursuing its assigned goal through an unintended method, because the input it processed redirected it, is behavioural risk in its purest form, and no amount of capability testing catches it if the test set doesn't include an adversarial document. The recommended defence-in-depth approach separates planning from execution architecturally, so a manipulated plan cannot directly trigger a high-impact action; adds anomaly detection tuned to agent behaviour specifically rather than conventional network signatures; and treats human approval for high-impact action classes as a hard architectural gate rather than a configurable setting a deadline can quietly disable.
5. Structural risk in multi-agent systems
As agentic deployments mature, single agents increasingly hand off to other agents, creating multi-agent systems where a single compromised or manipulated component can propagate tainted output downstream through the whole chain. This is structural risk: the failure doesn't stay contained to the agent that was originally compromised, it cascades through every agent that trusted its output without independent verification. We recommend treating inter-agent trust the same way a mature organisation treats inter-service trust in a microservices architecture - explicit, verified, and never assumed by default because two components happen to be part of the same product.
6. Accountability risk
The final category is the hardest to design around after the fact: probabilistic reasoning chains are difficult to inspect, and in several documented incidents, altered or deleted logs have been the first available evidence that something went wrong at all, rather than a clear record of what happened and why. An agent that behaved correctly but cannot demonstrate why is, from a governance standpoint, indistinguishable from one that got lucky. We recommend per-step action logging that captures what an agent considered and chose, not merely its final outcome, and independent log integrity controls that do not rely solely on the agentic system's own audit trail, since a sufficiently capable compromise can tamper with exactly that trail on the way out.
Practical governance checklist
The following translates the five risk categories into decisions an enterprise can action now, independent of when any of this becomes legally mandatory.
- Scope agent credentials per task class with time-bound access, and treat any agent with standing access to sensitive systems as a tier-0 asset under the same scrutiny as a privileged human account.
- Review agentic system architecture as its own discipline, specifically examining trust boundaries between components and third-party integrations before deployment.
- Architecturally separate an agent's planning and reasoning step from its execution permissions, so a manipulated plan cannot directly trigger a high-impact action.
- Define which action classes require mandatory human approval at the design stage and enforce it in code, not as an overridable policy setting.
- Build anomaly detection tuned to agent-specific behaviour patterns, not repurposed conventional network security signatures.
- Log what an agent considered and chose at each step, not just its final outcome, and protect that log independently of the agentic system's own controls.
- Map every agentic AI deployment against all five risk categories individually rather than scoring "agentic AI risk" as one undifferentiated line item.
Risks and how to manage them
The most common failure mode is treating this guidance as aspirational because it carries no legal force, and deferring the architectural work until a binding standard arrives. Voluntary frameworks from this particular set of agencies have historically become the practical baseline that regulators, cyber insurers and enterprise customers measure against well ahead of formal enforcement, so the "we'll wait" posture tends to cost more in retrofit work than it saves in delay. A second failure mode is applying human-approval gating uniformly rather than by actual blast radius, which either slows every agent interaction to the point of defeating the purpose of automation, or gets quietly disabled under delivery pressure because it was never differentiated by risk in the first place. A third is treating prompt injection as a model-quality problem that better training will eventually solve, when the guidance is explicit that this is a structural limitation of how language models process instructions, requiring architectural mitigation rather than a wait for a smarter model. The last is assuming regulatory clarity will arrive in time to guide today's design decisions, when the US federal picture remains genuinely unsettled and even the EU's more mature framework has just had major elements deferred.
The regulatory backdrop enterprises are actually operating in
The governance work above does not happen in a vacuum, and the 2026 regulatory landscape is less settled than many enterprise AI programmes are currently assuming. In the EU, the European Parliament's Digital Omnibus vote on 16 June deferred the AI Act's high-risk system obligations by twelve to sixteen months, but left the Article 50 transparency duties and the Commission's general-purpose AI model supervision and enforcement powers untouched, both taking effect on 2 August 2026 with fines reaching the greater of €15 million or 3% of global turnover. In the US, a bipartisan discussion draft for a Great American AI Act, released in June, proposes a three-year preemption of state laws specifically regulating AI model development, but remains a draft under active negotiation rather than settled law, leaving US enterprises without a single stable federal reference point to build against even as state-level obligations continue to accumulate. The practical implication is the same in both jurisdictions: the technical governance framework in this paper is not contingent on any of these regulatory questions resolving first, because the underlying risks it addresses, privilege, injection, structural cascade and accountability, exist and are being exploited regardless of which legal framework eventually governs them.
Executive summary of actions
For boards and executive teams, the headline is that the technical guidance for securing agentic AI has arrived well ahead of any binding requirement to follow it, and the enterprises that treat that gap as an opportunity rather than a deferral will be materially better positioned whenever enforcement does catch up. Begin by inventorying every agentic AI deployment, including the pilots and internal tools nobody has formally classified as production, and score each against the five risk categories in this paper.
Resolve ownership explicitly: agentic AI governance currently sits unclaimed between security, the AI platform function and individual product teams in most organisations we work with, mirroring exactly the ownership gap that has caused AI vendor risk incidents elsewhere. Build human-approval architecture, per-step logging and credential scoping into agentic systems now, at design time, rather than retrofitting them once an agent already has unmediated production access, a change our own delivery work consistently finds far more expensive after the fact than before it. For a facilitated review of your own agentic AI estate against this framework, contact sales@halfteck.com.