TL;DR: On August 20, 2026, NCSC published 7 safeguards for agentic AI, prompted by unsanctioned agent activity incidents. It follows a May 1, 2026 joint guidance from six Five Eyes agencies (CISA, NSA, ASD's ACSC, Canada's Cyber Centre, NCSC-NZ, NCSC-UK). Neither comes with a template. Here is a copy-paste audit that turns all 7 points into checks a small team without a SOC can actually run.
On August 20, 2026, the UK's National Cyber Security Centre published a blog post with a title that undersells it: "Managing the cyber risk of agentic AI." Written by Toby W, NCSC's Principal Security Architect, it opens with a line worth sitting with: "Recently, there have been several incidents involving AI models and agentic AI systems carrying out unsanctioned or unintended activity."
NCSC does not name the incidents. It does not need to. Seven weeks earlier, Sysdig had disclosed JADEPUFFER, the first documented end-to-end AI-agent ransomware attack, in which an LLM agent exploited an unpatched Langflow instance, harvested credentials, moved laterally, and encrypted a production database, correcting its own failed login attempt in 31 seconds, without a human directing a single step. If you run AI agents and have not read our breakdown of that attack, start there. This article picks up where NCSC's response to that climate leaves off.
Here is the part that should get your attention if you are a five-person startup and not a bank: NCSC's guidance was not written for enterprises with a 24/7 security operations center. It was written for anyone deploying an AI agent with real access to real systems. That includes a two-person ops team wiring a coding agent into production, a support team letting a chatbot touch customer records, or a solo founder giving an agent an API key to a payments system. The guidance does not check your headcount before it applies to you.
What NCSC actually published, and why it carries weight
This did not start with NCSC acting alone. On May 1, 2026, six national cybersecurity agencies, NCSC-UK, the US Cybersecurity and Infrastructure Security Agency (CISA), the US National Security Agency (NSA), Australia's ASD Australian Cyber Security Centre (ASD's ACSC), the Canadian Centre for Cyber Security, and New Zealand's NCSC-NZ, jointly published "Careful Adoption of Agentic AI Services." That document set the strategic frame: start small, restrict agents to low-risk tasks first, and apply the access-control and monitoring discipline your team already uses for human employees before you extend it to autonomous ones. It organized its advice around four areas: designing and developing secure agents, deploying them securely, operating them securely, and defending against risks that have not surfaced yet.
The August 20 NCSC blog is the operational follow-up, aimed specifically at teams that are past the "should we" question and into the "how do we not get burned" question. NCSC is explicit that this is interim: it says it is "working with partners to develop formal guidance which will build upon, and ultimately supersede, this blog." Translation: this is the floor, not the ceiling, and the bar is going up from here, not down. Treat the 7 points below as the minimum viable version of controls you will eventually need in more detail.
None of the six agencies published a fill-in-the-blank checklist alongside the guidance. That gap is what this article closes.
Copy-paste audit: NCSC's 7 safeguards, small-team edition
Copy this into whatever tracker you already use, a spreadsheet, Notion, a shared doc. Run one column per AI agent your team operates. If you cannot check a box, that is your backlog, in priority order.
1. Identify what could go wrong before you deploy
- Have you written down, in one page, exactly what this agent is allowed to touch: which systems, which data, which actions?
- Have you documented the "red lines," the specific actions the agent must never take, even if a user or a prompt asks for them?
- Has one named person threat-modeled this deployment, even informally, and dated the document?
You do not need a formal risk committee. You need a person, a date, and a page. Teams skip this step because it feels like paperwork; it is the difference between an incident you can explain to a customer and one you cannot.
2. Prompt carefully, and do not rely on prompting alone
- Does the system prompt explicitly state what the agent should and should not do, in plain language, not just implied by task framing?
- For long-running or multi-step tasks, are critical constraints repeated, not stated once and assumed to persist?
- Have you tested what the agent does when a user or a document explicitly tries to override those constraints?
NCSC's point here is blunt: a system prompt is a control, not the control. If your only safeguard is "the agent was told not to," you have a policy, not a security measure.
3. Set the right level of oversight for what the agent can actually do
- For each agent, have you picked one of: human-in-the-loop (approves every action), human-on-the-loop (monitors and can interrupt), or human-out-of-the-loop (fully autonomous, highest risk)?
- Is there a named, individual person responsible for this agent, not "the team"?
- For any agent with financial, production, or customer-data access, is there real-time monitoring with the ability to intervene mid-task?
Small teams default to human-out-of-the-loop by accident, because nobody assigned oversight explicitly. Naming an owner costs nothing and closes most of the gap.
4. Control the agent's environment with a real sandbox
- Does the agent run in an isolated environment with network access denied by default, not open by default?
- Are the agent's credentials scoped to only what this specific task requires, not a shared service account with broad access?
- Are agent credentials short-lived where your tooling supports it, rather than long-lived keys sitting in an environment file?
- Is the agent's execution environment separated from the infrastructure that runs your actual product?
This is the single most important item on the list, and it is the one JADEPUFFER exploited directly: an AI orchestration tool with broad network access and long-lived credentials sitting next to a production database.
5. Log, audit, and monitor everything the agent does
- Does every action the agent takes get logged, including what it decided and why, not just what API call it made?
- Are those logs protected from modification by the agent itself?
- Does someone actually review those logs on a schedule, weekly at minimum for lower-risk agents, and do you have alerting for anomalous patterns for higher-risk ones?
You do not need a SOC for this. You need a log destination the agent cannot write to, and a calendar reminder that someone honors.
6. Make your AI agent's activity easy to attribute
- If your agent makes outbound network requests, is there an identifying header or reverse-DNS record that lets a third party trace that traffic back to your organization?
- Would an external security team, seeing traffic from your agent, be able to identify it as yours quickly rather than mistaking it for an attack?
This one gets skipped because it sounds like it protects other people, not you. It also protects you: attributable traffic is what turns "we think we were compromised" into "we can prove exactly what our agent did and when."
7. Maintain the ability to shut it down immediately
- Is there a single action, a switch, a script, a revoked credential, that stops this agent's activity across all its access points, not just one integration?
- Has someone actually tested that kill switch, not just assumed it exists?
- Does the person with oversight from item 3 know how to trigger it without needing to page someone else first?
An untested kill switch is a belief, not a control. Test it before you need it.
Why this applies to you even without an incident
The instinct for a small team is to read guidance like this and file it under "we'll deal with it if something happens." NCSC's own framing argues against that. The blog exists because incidents already happened, at organizations that presumably also thought they were too small or too careful to be a target. Agentic AI failure modes are not gated by company size; they are gated by what access you gave the agent. A five-person team that wires an autonomous coding agent into a production deploy pipeline has, for that specific agent, the same blast radius as a five-hundred-person team doing the same thing.
The other reason to act now rather than later: NCSC has told you the bar is moving. Formal guidance is coming that will "build upon, and ultimately supersede" this interim blog. Whatever additional detail lands in that formal version will be measured against organizations that already implemented the seven points above. If you run the audit now, formal guidance is a refinement. If you wait, it is a retrofit, and retrofits happen under worse conditions, usually after an incident report is already being written.
Running this in a day, not a quarter
You do not need new tooling to start. Most of the seven items above are documentation and configuration changes, not engineering projects:
- Block an hour to write the one-page scope document for your highest-access agent first. Start with whichever agent can touch money, customer data, or production infrastructure.
- Pull the credentials that agent uses and check whether they are scoped narrowly or borrowed from a broader service account. Narrow them.
- Confirm someone, by name, owns oversight of that agent. If the answer is "the team," that is a gap, not an answer.
- Test the kill switch for that one agent before moving to the next.
Do this for your highest-risk agent this week, and work down the list. A partial audit finished this week beats a complete audit that never starts because it looked like a quarter-long project.
Related Reading
- JadePuffer Ransomware: 8 Gaps in Your AI Vendor Security Checklist
- Unattended AI Coding Agents Governance Policy 2026
- AI Browser Agents Governance Policy for Small Teams 2026
- AI Agent Governance Policy for Small Teams 2026
- TypeScript AI Agent Security Incident Response Playbook 2026
- TypeScript AI Agent Observability and Tracing Patterns 2026
- MCP Server Security Governance Checklist 2026
- Agentic AI Vendor Contract Clauses 2026
Sources: NCSC, "Managing the cyber risk of agentic AI" (August 20, 2026), NCSC, "Thinking carefully before adopting agentic AI", CISA, "Careful Adoption of Agentic AI Services", Canadian Centre for Cyber Security, joint guidance announcement (May 1, 2026), New Zealand NCSC, "Careful Adoption of Agentic AI Services", Sysdig, "JADEPUFFER: Agentic ransomware for automated database extortion" (July 1, 2026).
