Editorial explainer · official sourcesmedium
An agent that acts on its own: six agencies on how not to hand over the keys
On 1 May 2026 six national cyber security agencies published joint guidance on adopting AI agents: systems that do not merely answer but take actions — open tickets, send emails, modify records, initiate payments. The central recommendation is blunt and should be read before everything else: never grant broad or unrestricted access, and use agents only for low-risk tasks on non-sensitive data. The document organises risks into five categories and good practice across four lifecycle phases, from design to operation. The idea holding it all together: an agent should be treated as a subject with an identity of its own, not as a feature of an application.
The difference that changes everything
An assistant that answers a question produces text. If it is wrong, you have wrong text. An agent does something: opens a ticket, sends a message, modifies a record, approves a request, calls another system. If it is wrong, you have an action taken.
That distinction underpins the joint guidance published on 1 May 2026 by six agencies: Australia's ACSC, the United States' CISA and NSA, the Canadian Centre for Cyber Security, and the New Zealand and UK centres. They describe themselves in the document as the «authoring agencies», and the recommendation they place at the centre is unusually direct for a text of this kind: never grant an agent «broad or unrestricted access, especially to sensitive data or critical systems», and use it «only for low-risk and non-sensitive tasks».
Read it for what it is: not a call to avoid agents, but a call not to start with the most delicate use case.
The five ways an agent becomes a problem
The document organises risks into five categories, and the split is more useful than it looks because it separates problems that usually get conflated:
- privilege risks — the agent can do more than it should;
- design and configuration risks — it was built or set up badly;
- behaviour risks — it does something unexpected while staying within the limits you set;
- structural risks — arising from the interaction of multiple agents and systems, not from any single component;
- accountability risks — when something goes wrong, it is unclear who answers for it.
The first two are addressed with technology. The third with monitoring. The last two, which are also the most neglected, are addressed only by decisions taken in advance.
- 01The confused deputythe agent has access to finance, email and contracts «to do its job»
- 02The abusesomeone induces it to take an action: the agent has the permissions, so it acts
- 03The damagethe records look legitimate, because the action was taken by a party entitled to take it
The confused deputy scenario in the guidance is exactly this: a procurement agent with broad access to financial systems, email and contract repositories produces «audit logs that appear legitimate and delay detection». It is not that the logs are missing. It is that the logs tell the truth, and the truth is that the operation was authorised.
The core idea: give the agent its own identity
The most concrete piece of advice in the document, and the one with the most practical consequences, concerns identity. Developers should build each agent «as a distinct principal, a cryptographically anchored identity with its own unique keys or certificates». And on the controls side: «Deny access for any agent or cryptographic key that is not present in the trusted registry».
This means no longer running agents under a generic service credential or, worse, under a person's. An agent with its own identity is observable: it can be revoked without touching anything else, what it did can be seen separately from who started it, and it can be limited to a set of operations. An agent speaking with a user's credentials inherits everything that user can do, and disappears into their logs.
Then there is propagation. The guidance notes that some systems can autonomously create sub-agents — «spawning» — to handle secondary tasks. This is where structural risk becomes real: if agent A can create agent B, and B inherits A's permissions, the permission boundary has stopped being your decision.
Three operational rules worth copying
Consensus proportionate to risk. «Implement consensus controls for actions based on risk; use multi-agent approval for moderate-stakes actions and human-in-the-loop approval in addition to multi-agent consensus for high-stakes actions». In plain terms: for medium-consequence actions, more than one agent has to agree; for serious ones, a person must be involved too. Not «a human approves everything» — which does not scale — but a threshold.
The logs do not belong to the agent. Two verbatim instructions: «Quarantine requests to delete logs or audit records until reviewed and approved by a human» and «Isolate agents into enclaves with no write access to logs». It is security's oldest principle applied to a new kind of subject: whoever takes the action does not keep the record of the action.
Permissions are not self-granted. «Prohibit agents from modifying their own privileges or initiating unapproved delegation without explicit expiry timers and recorded grant chains». An agent must not be able to widen its own boundary or delegate to another without that delegation having an expiry and a trace.
To these, two starting-posture instructions: phased rollout, «with progressively increasing access and autonomy», and a conservative default — «Set system configurations to fail-safe by default requiring agents to stop and escalate issues to human reviewers in uncertain scenarios». When in doubt, the agent stops. It does not try.
What the agencies themselves admit
The most honest part of the document is the limits it declares, and they deserve quoting without softening.
On tooling: «Gaps in agentic AI cyber security tooling and the immaturity of relevant standards further amplify these risks. Governance mechanisms designed for human actors do not always translate effectively to autonomous AI agents». On testing: «Many existing evaluation methods for agentic AI security are still evolving. They may be sensitive to minor semantic changes, vary by scenario and only partially capture real-world deployment conditions». And the conclusion that follows: «organisations should assume that agentic AI systems may behave unexpectedly».
One scope limit should be added: the guidance «primarily focuses on large language model (LLM)-based agentic AI systems». It therefore does not cover deterministic automation, which raises different problems.
The UK centre's blog condenses everything into a line that works as an admission criterion: «If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment».
Where to start, if you are starting
The guidance's appendix lists the prerequisites to have in place before introducing agents — and they are almost entirely non-AI things: identity management, segmentation, event logging, vulnerability management. It is the least eye-catching message and perhaps the most useful: an autonomous agent does not add security to a disorderly environment, it amplifies the disorder, because it acts faster than you can watch.
Three questions for a first round of discussion, before any technical choice: what can this agent do that I cannot undo? Under whose identity does it do it? Who answers if it does it at the wrong moment? If the first two have no answer, the third one is you.
