Prompt injection can steer agents to unauthorised

You must now demonstrate that authority boundaries for AI agents sit outside the agent itself, that policy enforcement is independently verifiable, and that you can show afterwards who granted each permission and what triggered each action. Prompt injection alone does not determine liability; the absence of architectural separation between the agent and the policy layer does.

An analysis of 11 November 2026 of prompt injection, excessive privileges and inadequate logging in AI agents argues that malicious instructions hidden in emails, web results or documents can steer autonomous agents to carry out unauthorised actions, and that liability turns on whether authority, policy enforcement, monitoring and evidence sat apart from the agent itself. The analysis draws on joint guidance from 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 in April 2026. In our assessment, the development means that a CISO or board cannot treat prompt injection as a model problem alone; it is an operational control problem, and the organisation's choices about agent authority, approval workflows and audit trails now determine whether an incident can be reconstructed and who bears responsibility.

What makes an agent vulnerable to unauthorised action?

Autonomous agents use tools, memory and external data to act with limited human intervention. That operational model creates two distinct failure modes. First, malicious instructions can be embedded not only in a user's direct prompt but also in retrieved web content, emails or cross-modal input, so the attack surface extends beyond what the organisation can see at the moment of deployment. Second, an unauthorised action can look legitimate in audit logs if the agent's authority was never clearly bounded in the first place. The agent may use its legitimate access rights to carry out an instruction it should not have received, a pattern known as a confused-deputy attack.

Which failure modes does inadequate separation create?

• Prompt injection via external data — malicious instructions embedded in retrieved web content, emails or documents steer the agent without appearing in direct user input.
• Scope creep and privilege escalation — an agent granted broad authority can use legitimate access rights to carry out unauthorised actions that appear legitimate in logs.
• Confused-deputy attacks — an agent acts on a malicious instruction using its own legitimate authority, obscuring the boundary between what it was permitted to do and what it was instructed to do.
• Audit trail gaps — unauthorised actions may be indistinguishable from authorised ones if the organisation did not record which actions require independent approval before deployment.
• Erosion of human oversight — human approval can become a signature without real assessment if the approval workflow is not architecturally separate from the agent.

Where should policy enforcement sit?

The core principle is architectural separation: the layer deciding what is allowed must be separate from the layer reasoning about what is requested. Guardrails within the model alone are not sufficient. If policy enforcement sits inside the agent, the agent can determine the practical reach of its own authority, and the organisation loses the evidence needed to show that it drew and enforced a boundary. If policy enforcement sits outside the agent, in an independent layer, then the organisation can demonstrate which actions required approval, whether that approval was granted, and what triggered each permission.

What controls must you be able to demonstrate before deployment?

1. Record which actions require independent authorisation — document which agent actions are high-impact or sensitive and require human approval outside the agent itself.
2. Test that policy enforcement runs outside the agent — verify that the approval layer is architecturally separate and that the agent cannot override or bypass it.
3. Establish tamper-resistant audit evidence — ensure that logs record not only what the agent did but also what approval was sought, who granted it and what external input triggered the action.
4. Assign risk ownership to an identifiable person — make one individual accountable for the agent's mandate and the scope of its authority.
5. Test the withdrawal procedure — before the first production deployment, verify that you can revoke the agent's authority and that the revocation takes effect immediately.

What can tooling carry and what remains your own judgement?

Architectural separation and audit logging can be engineered and tested before deployment. Supplier claims about a "safe" agent are not by themselves a defensible basis for procurement; you should require the supplier to demonstrate where policy enforcement sits and what evidence is retained. What cannot be automated is the assignment of risk ownership, the definition of which actions are high-impact enough to require independent approval, or the decision to deploy at all. Those remain your own professional judgement, informed by the operational control framework but not determined by it.