Guide · AI agent security

AI agent security best practices, from design to the day after an incident.

An agent reads text it cannot fully trust and holds permissions that matter. Good practice assumes the first and limits the second.

Government cyber agencies, OWASP and the large model vendors now agree on the shape of the answer: assume the model can be manipulated, and put deterministic controls around it. This guide turns that into practices you can apply — who the agent acts for, what it may touch, which actions wait for a person, how hostile content is contained, and what you record — with a checklist at the end.

Updated · 14 sources

Secure AI system development, as a cycle
  1. Designthreat-model the agent; decide what it may do before it reads anything
  2. Developvet models, tools and data; document what each is for
  3. Deployverify signed artifacts; protect keys and weights; release on purpose
  4. Operatelog every tool call; watch for anomalies; update and respond

what you learn in operation goes back into design

What are AI agent security best practices?

AI agent security best practices are the controls that keep an AI agent safe even when its model is manipulated: give it an identity and a responsible human, grant it the fewest tools and data it needs, treat everything it reads as untrusted, require human approval for high-impact actions, contain the files and code it touches, and log every step. They follow the joint NCSC and CISA guidance — secure design, development, deployment and operation.

Where to start

The principle behind AI agent security best practices: assume the model can be steered.

The UK NCSC calls a language model an “inherently confusable deputy”. Google’s approach for secure agents answers with a hybrid: defenses inside the model to make manipulation harder, and deterministic controls outside it that hold when manipulation succeeds.

inside the model

Reasoning-based defenses

Training, system prompts, classifiers and spotlighting make the model less likely to follow planted instructions.

  • Adapt to new phrasings
  • Lower attack success rates
  • Can be bypassed by a new attack
  • Hard to prove
outside the model

Deterministic controls

Grants, filters, approvals and sandboxes decide what any model output can actually do.

  • Hold whatever the model says
  • Testable and auditable
  • Need design work up front
  • Can block a legitimate task
How likely is manipulation?AnswersHow bad can manipulation get?
Prompt classifiers, adversarial trainingExamplesTool grants, approvals, egress rules
A new attack gets throughFailure modeA control was never configured
BothYou needBoth
Google · principle 1

Agents must have well-defined human controllers

Every agent works for a known person or team, and acts within their authority; critical actions need their confirmation.

Google · principle 2

Agent powers must have limitations

An agent’s reach matches its task. Reading outside email and holding privileged tools do not mix.

Google · principle 3

Agent actions and planning must be observable

What the agent planned, called and changed can be seen, reviewed and replayed.

Least privilege for AI agents

Identity and least privilege: who the agent acts for, and what it may touch.

Several published agent attacks stole no credential at all. In Invariant Labs’ GitHub case the agent leaked private repository data using a token that was allowed to read it. The practice that answers this is to stack narrow permissions, each checked on every call.

Five checks between a request and an action
01
The personsigned in through your identity provider, with two-factor where it matters
SSO
02
The agenta named identity of its own, owned by a person or team
owner
03
Tool grantseach tool granted by name; no grant, no call
grants
04
Data rulesevery search and read filtered by what the person may see
filters
05
Action approvalhigh-impact calls wait for a person who sees the exact change
approval

The privilege-reduction rule. The NCSC puts it in one line: a model processing input from a party should have no more privilege than that party. An agent that reads email from strangers should not hold tools only an administrator should use.

Input and actions

Treat everything an agent reads as untrusted, and gate what it does.

Documents, emails, web pages, tool results and other agents’ messages are all data. Model-level defenses help, and the figures show how much — but none reaches zero, so the decision about approvals has to be made on impact.

>50% → <2%
indirect injection success before and after spotlighting untrusted input
Hines et al., 2024
77%
of AgentDojo tasks completed with provable security when the plan is fixed before data is read, against 84% with no defence
Debenedetti et al., 2025 (v2)
3
legs of the lethal trifecta — private data, untrusted content, outbound channel; remove one
Simon Willison, 2025

If this agent action were wrong, what would it cost?

Nothing lasting — a read, a draft, a searchLet the agent run it. Log the call with its arguments.
Something you can undo — an internal update, a status changeRun it, record it, and keep a restore point; alert on unusual volume.
Something you cannot undo — a payment, an external email, a delete, a permission changeRequire a person to approve, reject or edit the exact call before it runs.
Design to operation

AI agent security best practices across the system lifecycle.

The 2023 Guidelines for secure AI system development, published by the UK NCSC and US CISA and co-sealed by 23 cybersecurity organisations, sort practice into four stages. The 2024 joint guidance on deploying AI systems securely, led by the NSA’s AI Security Center with six partner agencies, adds detail for organisations running AI systems built elsewhere.

  1. Secure design

    Threat-model the agent: its inputs, tools, data and the people it acts for. Decide grants and approvals before choosing a model.

    threat model
  2. Secure development

    Vet every model, tool, connector and dataset you depend on; record where each came from and what it is for.

    supply chain
  3. Secure deployment

    Verify artifacts with signatures and checksums, keep keys in a vault, isolate the agent’s network, release deliberately.

    integrity
  4. Secure operation

    Log inputs, outputs and every tool call; watch for anomalies; patch, re-test and share what you learn.

    monitoring

Contain files and code

Agents open office files, unpack archives and run code steps. Convert files in an isolated service, check archives before they open, and run code in a sandbox with no secrets and no network.

Re-test on every change

A new tool, prompt or model changes the risk. Score the changed agent against a golden dataset and an attack set before it reaches people.

Checklist

An AI agent security best practices checklist.

Twelve questions to ask of any agent before it goes live, and again whenever it changes.

Before an agent goes live
  • Owner namedA person or team answers for the agent and its actions.
  • Tools granted by nameThe agent holds the tools its task needs, and a missing setting falls back to less.
  • Runs as the personCalls carry the user’s permission, not a shared service account.
  • Data filtered per personSearch and retrieval respect each person’s read rules.
  • Tenants kept apartContext from another customer or workspace is dropped, never blended.
  • Untrusted input markedDocuments and tool results are labelled as data and screened by a classifier.
  • Approvals on irreversible actionsPayments, external sends, deletes and permission changes wait for a person.
  • Outbound paths controlledUnknown links and auto-loaded images are blocked; destinations are allow-listed.
  • Files and code containedConversion, archives and code run isolated, without secrets or network.
  • Artifacts verifiedImages, packages and models are signed and checked before they run.
  • Every step recordedRequest, tool calls with arguments, approvals and answer — tamper-evident and replayable.
  • A way to stop and roll backYou can freeze an agent, see what changed and restore a known-good state.
On Botminds

How Botminds applies these practices to every agent.

Botminds agents start closed: no tools until they are granted, no data beyond the collections they are given and the rows each person may read, and no change without the approvals you choose.

PracticeOn Botminds
IdentitySSO-locked workspaces, two-factor, credential ceilings and suspension that takes effect on the next request
Least privilegeTools granted by name; no grants, or unreadable settings, fall back to read-only basics
Data per personEvery search filtered by the person’s read rules, the assistant’s own search included
TenancyA tenant on every block of context; anything that cannot prove where it belongs is dropped
ApprovalsThe run pauses in the conversation until a person approves, rejects or edits the call
ContainmentDocument conversion with no network, no secrets and no identity; archives and code checked first
Supply chainSigned images, signature-checked packages, secrets stripped from every package
Record and responseA hash-chained audit trail, run replay, detectors, freeze, snapshots and rollback

The nine layers behind this table are in AI agent security. To set them up, see the Academy lessons on access and roles, approvals inside a flow and observability.

Questions people ask

AI agent security best practices: common questions.

The technology behind itAI agent securityClosed by default, at every layer
What are the most important AI agent security best practices?

The AI agent security best practices that matter most: grant each agent only the tools and data its job needs, run it under the user’s permissions, treat everything it reads as untrusted, require human approval for irreversible actions, contain files and code, and record every tool call.

How do you secure AI agents?

Assume the model can be manipulated and build deterministic controls around it — tool grants, per-person data rules, approvals, sandboxes and an audit trail — then add model-level defenses such as classifiers and marking of untrusted input to make manipulation rarer.

What is least privilege for AI agents?

Giving an agent exactly the tools, data and permissions its task requires and nothing more. OWASP’s excessive agency entry names the three ways it fails: too much functionality, too many permissions and too much autonomy.

Should an AI agent have its own identity?

Yes. An agent should be a named identity owned by a person or team, and its calls should carry the permission of the user it acts for. Shared service keys hide who did what and give every user the agent’s full reach.

Which AI agent actions need human approval?

Those you cannot undo or that leave your organisation: payments, external emails, deletes, permission changes and anything that commits you to a customer. Reads and drafts usually only need to be logged.

How do you monitor AI agents for security?

Log every input, output and tool call with its arguments; watch for failed or unusual calls, which the NCSC notes can reveal an attack early; alert the owner; and keep a tamper-evident record you can replay after an incident.

Which frameworks cover AI agent security?

The NCSC and CISA Guidelines for secure AI system development, the joint guidance on deploying AI systems securely, Google’s three principles for secure agents, the OWASP Top 10 for LLM and for Agentic Applications, MITRE ATLAS for attacker techniques, and the NIST AI Risk Management Framework for governance.

How does Botminds apply AI agent security best practices?

Agents reach only tools granted by name, search under each person’s read rules, pause for the approvals you set, run hostile files and code inside walls, and leave every change on a hash-chained audit trail with run replay.

See it on
your own work.

Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.