Securing AI Agents: Six Controls Drawn From NIST

Six months ago it was a chatbot that answered policy questions. Today it has a service account, a read connection to the customer database, permission to raise tickets in the service desk, and an integration that lets it send email on a colleague's behalf. Nobody approved that as a system. It grew one integration at a time, each one individually sensible, and the person who could describe the whole thing has left. This is what an AI agent usually looks like inside a mid-size organisation: not a research project, but an accumulation of permissions attached to a non-deterministic component.

The security question changes at that point. For a chatbot, the question was what the model said. For an agent, the question is what the system did — on whose authority, against which data, and whether you can reconstruct it afterwards. Most existing security controls were designed around two assumptions that agents break: that an actor is either a person or a predictable piece of software, and that instructions come from inside the trust boundary. An agent is neither, and it reads its instructions from whatever content it happens to process.

What actually changes when a model becomes an agent

Three things break at once. First, privilege meets non-determinism. A traditional integration does the same thing every time; an agent chooses its next tool call, so the blast radius of its permissions is the full set of things it could decide to do, not the set of things you saw it do in testing.

Second, untrusted content becomes an instruction channel. Prompt injection is not a content-moderation problem. When an agent reads a supplier email, a web page or a PDF and that text redirects its behaviour, the attacker has effectively borrowed the agent's privileges without ever authenticating. OWASP's work on LLM and agentic application risks describes this and the related pattern of excessive agency in detail, and it is the failure mode most likely to affect you first.

Third, attribution collapses. Agents are commonly deployed under a shared service account or, worse, under a human user's own credentials. When that happens your logs say a person did something they did not do, and every control that depends on identity — access review, segregation of duties, incident response — degrades quietly.

The six control areas

A useful way to organise the response is around six control areas. It is worth being precise about provenance: NIST does not publish a single document headed "six controls for AI agents". What it publishes is the AI Risk Management Framework (AI RMF 1.0), with its GOVERN, MAP, MEASURE and MANAGE functions and its Generative AI Profile, alongside the long-established SP 800-53 control catalogue, and ongoing work on control overlays that apply that catalogue to AI systems. The six areas below are the practical distillation, and each maps to controls your security team already knows.

Control area	What it means for an agent	Where it already lives
Identity and authentication	Every agent holds its own credentialed identity with short-lived tokens; never a shared service account or a borrowed human login	IAM; SP 800-53 IA and AC families
Continuous monitoring	Telemetry on tool calls and outbound actions, not just prompts; alerting on unusual action sequences and volume	SIEM; SP 800-53 CA and SI families
Data governance	Retrieval scoped to a defined corpus; access mediated by the requesting user's own entitlements; defined retention for prompts, outputs and memory	Records management; UK GDPR Art. 5 and 32
Testing and validation	Adversarial testing before deployment, including injection through every content source the agent reads, and re-testing whenever the model, prompt or tool set changes	Change management; SP 800-53 CM and RA
Accountability	A named owner, a tamper-evident action log, and the ability to reconstruct why a specific action was taken	Risk register; SP 800-53 AU; EU AI Act Art. 12
Transparency	Documented purpose and limits, disclosure to affected people, and an explainable basis for consequential outputs	AI RMF MAP/MEASURE; UK GDPR Art. 13 and 22

The pattern worth noticing is that five of the six are not new capabilities. They are existing controls that stop at the boundary of the AI system because nobody extended them across it.

Where these controls meet UK and EU obligations

None of the NIST material is law in the UK or the EU. It is voluntary guidance, and its value is that it gives you a defensible structure. The binding obligations come from elsewhere.

Under the EU AI Act, deployers of high-risk systems carry duties in their own right: assigning human oversight to people with the competence and authority to intervene, using the system in line with the provider's instructions, and retaining automatically generated logs where those are under their control. Penalties are tiered — up to 7% of global annual turnover for prohibited practices, and up to 3% for most other obligations. UK organisations are not exempt by geography; the Act reaches systems placed on the EU market or whose output is used in the EU.

In the UK there is no equivalent statute. Existing law does the work: UK GDPR accountability under Article 5(2), security of processing under Article 32, a DPIA under Article 35 where processing is likely to result in high risk, and the restrictions on solely automated decisions with legal or similarly significant effects under Article 22. Maximum exposure is 4% of global annual turnover. The ICO's guidance on AI and data protection is the practical reference. Regulated firms should also expect their sector regulator's operational resilience and outsourcing expectations to apply unchanged to an agent that sits in a customer-facing process.

Readiness checklist

• Every agent in production has a distinct machine identity, and no agent authenticates as a named human.
• Credentials are short-lived and scoped to the minimum tool set the agent needs for its stated purpose.
• Tool calls, arguments and outcomes are logged — not only the conversation transcript.
• Logs are held outside the agent's own write access and retained for a period you have consciously chosen.
• Retrieval is bounded to an approved corpus, and the agent cannot return data the requesting user could not access directly.
• Every content source the agent reads has been treated as untrusted input in testing.
• Actions with external effect — payment, publication, sending, deletion, contract commitment — require a human confirmation step or sit behind a hard policy block.
• A named individual owns each agent, and the ownership survives that person's absence.
• A change to the model version, system prompt or available tools triggers re-testing before release.
• People materially affected by the agent's output are told an AI system is involved.
• There is a documented way to stop the agent quickly, and someone has actually tried it.

Limits of this guidance

This is a security and governance structure, not a legal assessment. It does not tell you whether a specific system is high-risk under the EU AI Act, whether you are acting as a provider or a deployer, or whether a particular use engages Article 22 of the UK GDPR — and those classifications change your obligations substantially. Get legal advice on classification before you rely on your own reading, particularly where an agent affects access to employment, credit, insurance, education or essential services.

It also does not cover the model supply chain in any depth: provenance of weights, licence terms, subprocessor arrangements, or where inference physically happens. Those matter for international transfer analysis and for contractual liability, and they need separate attention. Nor does it substitute for technical assurance work — adversarial testing of a consequential agent is a specialist exercise, and an internal team running it for the first time should expect to miss things.

Finally, this is a fast-moving area. NIST's AI-specific material continues to develop, EU AI Act obligations phase in over time, and UK regulator guidance is still being issued. Treat any control set, including this one, as something to re-check against current published text rather than something to adopt once and file.