On 1 May 2026, five global intelligence agencies stopped what they were doing to warn the world about agentic AI. The signatories were the Australian Signals Directorate's ACSC, the United States' CISA and NSA, the Canadian Centre for Cyber Security, the UK's NCSC, and New Zealand's own National Cyber Security Centre. This is not a forecast. It is a siren.
The document covers the security risks specific to agentic AI systems and provides best practices for organisations designing, deploying, and operating them. It is thorough and technically grounded. It is also written almost entirely for developers and system architects.
If you are an NZ organisation evaluating an agentic AI deployment, that is not you. That does not mean the content does not apply. It means you will need to read it differently.
Most of the risk in agentic AI is not in the model itself. It is in what the model is allowed to do.
What makes agentic AI different from a chatbot?
Most people get this wrong.
Generative AI produces content: text, images, code, analysis. The output is intended for a human to review and act on. A chatbot that drafts a reply, a tool that generates a report summary, an assistant that proposes a contract clause — all of these put a human between the AI output and any real-world consequence.
Agentic AI is different. An agent does not produce output for review. It takes action.
| Feature | Standard Chatbot | Agentic AI |
|---|---|---|
| Output | Text, images, code | Actions and API calls |
| Human role | Approver / editor | Orchestrator / supervisor |
| System access | Read-only | Read and write |
| Consequence | A bad draft | A breached database |
The technical building blocks that distinguish agentic AI from a basic chatbot:
- Actions and execution privileges: the agent does things in external systems, not just describes them
- Tool access: real integrations to CRMs, email, calendars, databases, file systems
- Memory: context persists across steps; the agent knows what it did two steps ago
- Planning: multi-step reasoning toward a goal, not a single prompt-response cycle
- Sub-agent spawning: a parent agent creates and directs child agents for specific sub-tasks
Capabilities create liabilities. The attack surface of an agentic AI system is not the model's text output. It is every system the agent can touch, every credential it holds, every action it can take without a human in the loop.
A chatbot that drafts a phishing email is a nuisance. An agent with write access to your email that sends it is a breach.
The "confused deputy" problem
The most consequential risk in the guidance is one most NZ organisations have never heard of: the confused deputy problem.
An agent is granted privileges to do its job. An email management agent gets write access to inboxes. A procurement agent gets access to financial systems, contracts, and vendor communication channels. These permissions are appropriate for the agent's function and are granted by a legitimate administrator.
The agent is then trusted by other components in the system: the tools it calls, the APIs it integrates with, the data sources it reads. That trust is the point of failure.
A malicious actor does not need to compromise the agent directly. They need to compromise something the agent trusts. If that input can be crafted to look like a legitimate instruction, the agent will act on it — using its full set of privileges — on behalf of someone who was never authorised to direct it.
The poisoned input
A malicious actor crafts a document, webhook, or tool response designed to look like a legitimate instruction. It targets a low-privilege component the agent trusts.
The agent reads and trusts
The AI agent reads the compromised input as part of its normal workflow. It has no way to distinguish injected instructions from legitimate ones — it was not designed to.
High-privilege execution
Using its full access, the agent executes the malicious instruction. Logs look clean. The agent acted under its own legitimate identity throughout.
The agent is not the villain. It is the highly-privileged deputy being lied to.
The Five Eyes guidance uses a procurement agent as its illustration. A malicious actor compromises a low-risk scheduling tool integrated into the agent's workflow. That tool sends crafted instructions back to the agent. The agent executes, modifying contracts and approving payments, while generating audit logs that look entirely legitimate throughout. Detection is delayed until the financial discrepancy surfaces.
The NZ business equivalent: giving a new contractor a master key, signing authority, and access to your CRM, then leaving for two weeks with instructions to handle things. If someone can manipulate what that contractor believes they have been asked to do — through a poisoned document, a malicious tool response, or a crafted message — you have no defence. The contractor is doing exactly what they were asked. The problem is who is doing the asking.
Three failure modes amplify the confused deputy risk:
Privilege scope creep. Permissions granted broadly at deployment because granular configuration is slow. The calendar agent with read access to every meeting across the organisation. The email assistant with write access to every inbox. Once granted, these permissions are rarely revisited.
Identity spoofing. Agents authenticate using tokens or keys. If those credentials are static and shared across agents, a malicious actor who obtains them can impersonate a trusted agent while appearing entirely legitimate to downstream systems and audit logs.
Chain compromise. In multi-agent systems, agents trust each other. Compromising Agent B gives access to everything Agent A can reach, if A trusts B unconditionally. The blast radius of a single compromise scales with the depth of the trust chain.
Detection is hard in all three cases. The agent operates under a legitimate identity. Logs reflect its authorised actions. Anomalies emerge, if they surface at all, only after impact.
The five risk categories
The guidance organises agentic AI security risks into five categories. Each one has a plausible NZ deployment scenario behind it. Click into the ones that apply to your situation.
What the guidance doesn't tell you
The document is thorough. It is also written for the person building the system.
The design and development sections address developers. The deployment and operations sections address vendors and operators running the infrastructure. The guidance assumes the reader can make architectural decisions, configure access controls, and instrument monitoring.
Most NZ organisations adopting agentic AI are not in that position. They are commissioning a system from a vendor or consultant — approving a proposal, signing a contract, trusting that the technical implementation is sound. The guidance offers them almost nothing directly.
That gap is where deployments fail. Not because the risks are undocumented, but because the person signing off on the deployment never read the documentation, and the vendor never volunteered it.
Three things the guidance implies but does not state for commissioners:
Vendor competence is not self-certifying. A vendor who does not mention privilege minimisation, human-in-the-loop controls, or audit logging in their proposal either does not implement them or does not expect you to ask. Both are problems. Security architecture should be in the proposal, not something you have to extract by interrogation.
"AI did it" is not a compliance defence. The guidance is explicit: accountability for agentic AI actions sits with the organisation that deployed and operated the system, not the model provider. If your agent sends an unauthorised communication, modifies a record it should not have touched, or acts on injected instructions, that is your liability exposure.
The time to ask is before, not after. Once an agentic system is embedded in operations, renegotiating its permission model or improving its audit architecture is expensive and disruptive. The questions below are far easier to answer before a contract is signed than after a deployment is live.
The commissioning checklist
These seven questions should appear in every NZ organisation's due diligence process before commissioning an agentic AI system. A vendor who cannot answer them clearly is not ready to build one for you.
Seven questions to ask before signing
1. What permissions does the agent require, and what is the justification for each?
Good answer: a specific list of permissions mapped to functions, with a rationale for each scope. "Read access to calendar for scheduling; write access limited to the requesting user's events."
Red flag: "broad access to keep the integration simple," or permissions described as something to sort out during setup.
2. How are permissions evaluated — once at startup or at each action?
Good answer: per-action authorisation with contextual checks. Permissions are not cached from initial configuration.
Red flag: static permissions set at launch and re-evaluated only on request or incident.
3. What happens when the agent encounters an ambiguous or high-impact situation?
Good answer: a defined escalation path. Human-in-the-loop checkpoints for uncertain situations or irreversible actions. The agent stops and requests approval rather than proceeding.
Red flag: "it handles it automatically," with no description of what that means or when a human becomes involved.
4. How are third-party tools and components vetted?
Good answer: a maintained allow list, version pinning, source verification, and a software bill of materials. Tools are not loaded dynamically at runtime.
Red flag: dynamic package loading, no registry of approved tools, or a suggestion that the tools are whatever the framework provides by default.
5. What does the audit trail look like, and can you show us an example?
Good answer: unified logs covering inter-agent interactions, tool calls, decisions, and the reasoning behind them. Human-readable. Searchable. Retained for a defined period.
Red flag: logs exist but are not reviewed. No unified view across agents. "You can query the raw model output" is not an audit trail.
6. How would you detect if the agent was compromised or behaving unexpectedly?
Good answer: runtime anomaly detection against behavioural baselines. Alerting when guardrails are triggered or unusual patterns emerge. A defined response procedure.
Red flag: "we'd notice if something went wrong," or reliance on periodic manual review as the primary detection mechanism.
7. Who is legally accountable if the agent causes harm?
Good answer: explicit contractual allocation of risk, documented governance policies, and a defined incident response procedure that includes the deploying organisation's obligations.
Red flag: silence, or an implication that the model provider or the framework bears responsibility. They do not.
The Five Eyes guidance represents a meaningful step in the public documentation of agentic AI risk. The fact that NZ's NCSC co-authored it signals that agentic AI security is on the government's radar for NZ organisations — not just large infrastructure operators abroad.
The document will not protect you on its own. Neither will reading it. The value is in using it to raise the standard of the conversations you have with vendors before you sign anything.
For context on how NZ businesses are approaching AI adoption more broadly, see NZ's AI Strategy Gap: 87% Adopt, 12% Scale and The State of AI in NZ Business 2025-2026. If you are at the stage of evaluating consultants or vendors, Choosing an AI consultant: what NZ businesses need to know covers what to look for in a partner. For a structured approach to AI integration that manages risk at each phase, see How NZ Businesses Reduce AI Risk with a Three-Phase Model.
We design agentic AI systems where these questions are answered before build begins, not after something goes wrong. If you are reviewing a vendor proposal and want an independent assessment of what is actually being proposed — or if you are starting from scratch and want an architecture that holds up to this level of scrutiny — get in touch.