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
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
what you learn in operation goes back into design
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.
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.
Training, system prompts, classifiers and spotlighting make the model less likely to follow planted instructions.
Grants, filters, approvals and sandboxes decide what any model output can actually do.
Every agent works for a known person or team, and acts within their authority; critical actions need their confirmation.
An agent’s reach matches its task. Reading outside email and holding privileged tools do not mix.
What the agent planned, called and changed can be seen, reviewed and replayed.
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.
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.
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.
If this agent action were wrong, what would it cost?
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.
Threat-model the agent: its inputs, tools, data and the people it acts for. Decide grants and approvals before choosing a model.
Vet every model, tool, connector and dataset you depend on; record where each came from and what it is for.
Verify artifacts with signatures and checksums, keep keys in a vault, isolate the agent’s network, release deliberately.
Log inputs, outputs and every tool call; watch for anomalies; patch, re-test and share what you learn.
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.
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.
Twelve questions to ask of any agent before it goes live, and again whenever it changes.
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.
| Practice | On Botminds |
|---|---|
| Identity | SSO-locked workspaces, two-factor, credential ceilings and suspension that takes effect on the next request |
| Least privilege | Tools granted by name; no grants, or unreadable settings, fall back to read-only basics |
| Data per person | Every search filtered by the person’s read rules, the assistant’s own search included |
| Tenancy | A tenant on every block of context; anything that cannot prove where it belongs is dropped |
| Approvals | The run pauses in the conversation until a person approves, rejects or edits the call |
| Containment | Document conversion with no network, no secrets and no identity; archives and code checked first |
| Supply chain | Signed images, signature-checked packages, secrets stripped from every package |
| Record and response | A 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.
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.
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.
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.
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.
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.
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.
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.
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.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.