Five Eyes guidance on AI agent deploymentWhat the agencies say. What engineers build.

In November 2023, NCSC UK published "Guidelines for secure AI system development" with joint endorsement from CISA, ASD, CCCS, and NCSC-NZ. The document covers how to build AI systems that do not fail badly. In 2024, ASD added "Engaging with Artificial Intelligence." In 2025, NCSC UK issued an agentic AI addendum addressing autonomous agents specifically. CISA published its own "AI Cybersecurity Guidelines" in 2024.

That is four coordinated documents from five agencies across three years. The scope grew from general AI system design to something much closer to what engineering teams are actually shipping: agents that read files, run commands, call external APIs, and make decisions without human approval at each step.

The consensus is real. The agencies agree on the threat categories. What they do not provide is a runbook. Engineers reading the guidance for the first time often finish it knowing what to worry about and still unsure what to build.

This guide translates the recurring themes into controls you can scope to a sprint.

What to know in 60 seconds

• CISA, NCSC UK, ASD, CCCS, and NCSC-NZ have issued coordinated AI deployment guidance since 2023, updated through 2025 to cover agentic systems.
• Four themes appear across all documents: secure-by-design defaults, ML supply chain integrity, operator monitoring of agent actions, and input/output validation as a control boundary.
• For coding agents specifically, these themes translate to: sandboxed execution, credentials scoped to session and task, signed or vetted MCP servers, and tamper-evident audit logs.
• The guidance describes what to protect. It does not describe how to build the protection. That translation is on your team.
• Joint guidance carries weight in compliance conversations with customers, auditors, and insurance underwriters. Use it as a shared vocabulary for your security posture documentation.

What the agencies actually published

The November 2023 NCSC document is the anchor. Titled "Guidelines for secure AI system development," it organizes around the four phases of an AI system's life: design, development, deployment, and maintenance. It names the ML supply chain as an explicit attack surface, covers training data poisoning, and flags model weight integrity as a hardening target. All five agencies signed it.

CISA's 2024 "AI Cybersecurity Guidelines" extends the supply chain section with more specific guidance on model provenance: know where your weights came from, know what data trained them, know who fine-tuned them and under what conditions. The document does not endorse any verification standard but points to existing SBOM frameworks as an analogy.

ASD's "Engaging with Artificial Intelligence" (2024-25) adds practical deployment context for organizations using commercial AI APIs. It addresses the operator layer directly: the organization deploying an AI system is responsible for what that system does, even when the underlying model is third-party.

The NCSC UK agentic AI addendum from 2025 is the most direct treatment of the problem most teams face in 2026. It covers agents that plan, execute, and take external actions. It names prompt injection as an input vector. It flags unvalidated tool outputs as an exposure point. It asks operators to define the scope of agent authority before deployment, not after an incident.

None of these documents name MCP, Claude Code, Cursor, Codex, or any specific tool. They are technology-neutral by design. That is appropriate for guidance at this level. It also means the translation work falls to you.

Recurring themes across the guidance

Read the four documents together and four themes appear consistently.

Secure-by-design defaults. Every document opens with some version of this. AI systems should fail safely. Default configurations should not expose capabilities that most deployments do not need. For coding agents, the analogous control is starting with no permissions and adding what the task requires, rather than inheriting whatever the developer's shell environment exposes.

ML supply chain integrity. The guidance frames training data, base model weights, fine-tunes, and third-party plugins as supply chain components, each with its own integrity requirements. For teams using coding agents, the supply chain extends to MCP servers. OX Security reported approximately 7,000 MCP servers in the wild with around 150 million downloads as of early 2026, with no signature requirement. That is a software supply chain without a lock on the door.

Operator monitoring of agent actions. The agentic AI addendum is explicit: the operator must be able to observe what the agent did, at what time, with what authority. This is harder than it sounds. Most coding agent sessions produce logs that capture model output, not actions taken. An agent that runs a shell command, reads a file, and calls an external API generates three distinct audit events, and most teams capture zero of them in a structured, queryable form.

Input/output validation as a control boundary. Prompt injection gets significant treatment in the 2025 addendum. Input validation means checking what reaches the agent context window. Output validation means checking what the agent produces before it hits a tool call or a downstream system. Both the NCSC and CISA documents frame these as control points, not nice-to-haves.

Translating guidance into agent runtime controls

The gap between "implement operator monitoring" and a system that actually does it is wide. Here is a concrete translation for each theme.

Secure-by-design defaults for coding agents: start each agent session with a credential set scoped to what that session requires. A coding agent reviewing a pull request does not need write access to the production database, access to the CI/CD signing key, or any long-lived token that persists after the session ends. Scoping happens before the session opens, not as a cleanup step afterward.

ML supply chain for the MCP layer: before adding an MCP server to your agent configuration, verify its source. Pin to a specific commit hash or digest. Treat unsigned MCP packages the same way you treat unsigned npm packages in a security-sensitive context: with suspicion until proven otherwise. CISA's supply chain framing applies directly here, even though the documents predate MCP as a standard.

Operator monitoring in practice: structured audit logs that record agent action type, target resource, credential used, and timestamp. Append-only storage with a tamper-evident structure (HMAC chaining works; the specific algorithm matters less than the append-only property). The question "did the agent access the production token between 14:00 and 16:00 on Tuesday" should return an answer in seconds. If it takes a log grep across multiple systems, the audit capability is insufficient.

Input/output validation for coding agents: on the input side, treat any text that enters the agent context from an external source (a GitHub issue, a Jira ticket, a web page fetched by a tool) as potentially adversarial. The MCP GitHub prompt injection incident documented by Snyk in early 2026 showed what happens when content from external sources reaches the agent context without inspection. On the output side, validate tool call arguments before execution. An agent asked to read a file should not be able to issue a shell command. Both controls require you to define the boundary: what counts as external input, what counts as a valid tool call. That definition does not exist in most coding agent setups today, because nobody required it until the first incident.

What the guidance gets wrong, or at least incomplete

The agencies are right that these threat categories matter. They are less right about the ordering of risk.

The documents treat prompt injection as the central risk for agentic AI. Check Point's CVE-2025-59536 in Claude Code involved command injection through project files, which fits the prompt injection frame. The NCSC's agentic AI addendum leans into this category. But GitGuardian's 2026 State of Secrets Sprawl data shows AI-service token leaks up 81% year over year, with AI-assisted commits leaking around twice as often as the baseline. Credential harvesting from agent state files and leaked environment variables is producing more incidents than prompt injection in the wild.

The five-eyes framing emphasizes model integrity and training data provenance. Both matter. But for most engineering teams deploying commercial coding agents against third-party APIs, the practical risk is much more mundane: an agent reads a credential from the shell environment, persists something to disk, and that thing ends up somewhere it should not. Knostic's February 2026 disclosure found Claude Code's settings.local.json in roughly 1 in 13 npm packages. No prompt injection required.

Read the agency guidance for the threat taxonomy. Do not read it for the risk prioritization. The agencies are writing for a broad audience that includes critical infrastructure operators, enterprise AI vendors, and government system integrators. Your risk profile as a team shipping a coding agent against a cloud API is narrower and, in some dimensions, more acute. Use the documents to anchor security conversations with customers and auditors. Do not let them anchor your sprint backlog.

A checklist for your next sprint

## Five Eyes compliance alignment: coding agent runtime

Supply chain
- [ ] MCP servers pinned to commit hash or digest (not floating @latest)
- [ ] MCP server source reviewed: origin, maintainer, last commit date
- [ ] Model weights and fine-tunes documented with provenance (base model, training data source, fine-tune author)
- [ ] Agent dependencies in lockfile with integrity hashes

Credentials and access scope
- [ ] Agent sessions start with minimum required credential set
- [ ] No long-lived tokens passed through shell environment to agent process
- [ ] Session credentials expire or are revoked at session end
- [ ] Separate credentials per agent role (read-only review vs. write-capable code generation)

Operator monitoring
- [ ] Agent actions logged: action type, target, credential used, timestamp
- [ ] Logs stored in append-only format with tamper-evident structure
- [ ] Log query tested: "what did the agent do between T1 and T2?" returns structured result
- [ ] Incident response runbook covers AI-specific events (credential exposure, prompt injection, data exfiltration)

Input/output validation
- [ ] External content (issues, tickets, fetched pages) flagged before entering agent context
- [ ] Tool call arguments validated before execution
- [ ] Agent output filtered for credential patterns before reaching downstream systems or logs
- [ ] Prompt injection test cases in CI (at minimum: instruction injection via issue body, injection via fetched URL content)

Documentation for auditors and underwriters
- [ ] Written description of agent authority scope and how it is enforced
- [ ] NCSC/CISA guidance referenced in security posture docs as shared vocabulary
- [ ] Incident response contact designated for AI-specific incidents

What this means for your stack

The gap the agencies do not close is the one between the principle level ("monitor agent actions") and the implementation level ("here is a credential-scoped, audit-logged process wrapper for your coding agent sessions"). Closing that gap is engineering work. The guidance gives you a defensible framework for explaining to a customer, auditor, or underwriter what you are protecting against. It does not give you the runtime.

A runtime that closes the gap needs four properties: credentials scoped to each session and injected at exec time rather than inherited from the shell; an append-only audit log with tamper-evident structure; automatic redaction of credential patterns from agent output streams; and a clean revocation path when a session ends abnormally.

hasp is one working implementation of that runtime. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent session gets scoped credentials for the duration of the window, an HMAC-chained audit log, and 11 redactor encodings on the output stream. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The agency guidance will not tell you what tool to use. It will tell you, in a compliance conversation, exactly why you needed one.