Cyber authorities warn prompt injection can steer agents to unauthorised actions

If an email, web result or document makes an AI agent ignore an internal policy rule and carry out an unauthorised action, the liability question shifts from the model to the organisation. What matters is whether authority, policy enforcement, monitoring and evidence sat apart from the agent, so it can be shown afterwards who granted and could bound the authority.

On 30 April 2026, multinational cyber-security authorities, including Australia’s ASD ACSC, the United States’ CISA and NSA, the Canadian Centre for Cyber Security, New Zealand’s NCSC and the UK’s NCSC, published the guidance Careful adoption of agentic AI services. In it they address prompt injection, privilege compromise and so-called confused-deputy attacks, in which an agent uses its legitimate authority to carry out an instruction it should not in fact have carried out, and discuss their implications for accountability.

What exactly did the multinational cyber authorities establish about prompt injection in agents?

The guidance explains that autonomous agents use tools, memory and external data to act with limited human intervention, and that malicious instructions hidden in, for example, emails or retrieved data can steer an agent. It discusses scope creep, unauthorised actions that may look legitimate in audit logs, and accountability gaps, and recommends independent monitoring, human approval for high-impact actions, authentication during execution and clearly assigned risk ownership. Prompt injection has long topped broader AI security discussions, such as the list of top risks for applications using large language models maintained by the OWASP Foundation.

That technical attack route is underpinned by recent peer-reviewed research. In the Proceedings of MM '26 of the Association for Computing Machinery, the paper INSURE describes that agents can be hijacked by malicious instructions in retrieved web content and in cross-modal input, so not only through a user's direct prompt. The paper provides a defence method during execution, but says nothing about legal liability; it offers technical corroboration for the possibility of agent hijacking.

Why does liability shift from the model to the organisation?

The malicious instruction misleads a probabilistic model, but the extent of the damage is determined by the organisation's choices: how much authority the agent was given, whether that authority was temporary or permanent, and whether there was an independent authorisation check per action. In our assessment that is the pivot point: the existence of a prompt injection in itself says little about culpability, but the absence of a pre-arranged authority boundary says a great deal.

UNESCO's Global AI Ethics and Governance Observatory develops that reasoning in the article Who answers for the machine?. It argues that responsibility should not dissolve into a chain of model developers, integrators and customers, but should remain traceable to a natural or legal person; it links that accountability to operational control, verifiable audit logs and traceable handovers. UNESCO also warns that human oversight can erode into the signing of a signature without real assessment.

Which controls must sit apart from the agent to carry liability?

The National Institute of Standards and Technology (NIST) translates this into concrete design principles. In the blog Design Tenets for Agent Identity Management Systems NIST states that guardrails within the model alone are not enough and that architectural separation is needed to limit prompt injection, privilege escalation and unintended actions. The core of NIST's design guidance is that the layer deciding what is allowed should be architecturally separate from the layer reasoning about what is requested.

• Dedicated agent identity: a cryptographically verifiable identity for each agent, combined with independent logging so actions can be traced to the relevant agent and mandate.
• Limited, short-lived authority: least privilege and zero standing privilege, task-specific and with a short validity.
• Policy enforcement outside the model: deterministic authorisation decisions for sensitive resources, apart from the reasoning layer.
• Human escalation: mandatory approval for actions with high impact or irreversible consequences.
• Independent monitoring: monitoring separated from the agent's control and designed to provide ongoing oversight of its actions.
• Immutable evidence: append-only or otherwise tamper-resistant recording of the delegated mandate, the action taken and the authorisation decision, stored independently of the agent so the agent cannot alter the record.

Our reading of NIST and UNESCO together is that failing to separate these functions effectively leaves the agent to determine the practical reach of its own authority, and can deprive the organisation of the evidence needed to show that it drew and enforced the boundary. See also the elaboration on NIST on separation of duties between agent, policy layer and human approver and on blind spots in monitoring agent tool calls.

What does this mean for directors, lawyers and CISOs deploying an agent?

Our analysis: In our analysis, because the authorities describe unauthorised actions that can look legitimate in audit logs, organisations risk reconstructing incidents only afterwards and incompletely. A CISO should therefore record before deployment which actions require independent authorisation and test whether that control runs outside the agent. In our analysis, because NIST states that guardrails within the model are not enough, a supplier claim about a "safe" agent is not by itself a defensible basis for procurement. A procurement lawyer should therefore require the supplier to demonstrate where policy enforcement sits and what tamper-resistant evidence is retained. In our analysis, because UNESCO links responsibility to operational control, the board should assign the agent's mandate to an identifiable risk owner and test the withdrawal procedure before the first production deployment. For organisations in the EU, this governance analysis may also intersect with the EU AI Act (Regulation (EU) 2024/1689) and other applicable legal and regulatory requirements; the specific obligations depend on the system, its use and the applicable regime and should be assessed separately.

As a summary of that analysis, as a minimal set of questions a board wants answered before deployment:

1. Who approved the agent's mandate and is that recorded?
2. Which internal rules bounded each individual action?
3. Which independent control released the request or refused it?
4. What evidence is retained and can the agent not alter it?
5. When could the authority be withdrawn or the system be stopped?

These guidelines and principles, including the EU AI Act framing above, are not binding Dutch law and do not constitute a judgement on liability in a specific case. They do, however, together sketch a defensible line. More context can be found in the topic hub on agentic AI and AI agents, in defending against prompt injection before an agent acts and in why an AI explanation is not yet a decision record.

Sources: The article draws on the joint guidance from ASD ACSC, CISA, NSA and partners, on NIST's design tenets for agent identity, on a UNESCO analysis of accountability and on an ACM paper on agent hijacking.