--- title: "How to Secure AI Agents: Ten Controls in Build Order" description: "A short, ordered list for securing AI agents, grounded in NCSC and OWASP guidance. Each control comes with the proof worth keeping, and the order puts limits before detection." author: "Declan Osei" category: "Defensive Architecture & Security Controls" date: 2026-11-01T17:25:33.530Z canonical: "https://agenticcyber.co/blog/how-to-secure-ai-agents-ten-controls" --- # How to Secure AI Agents: Ten Controls in Build Order ![padlock, locked, secured](https://cdn.pixabay.com/photo/2014/08/26/21/29/padlock-428549_1280.jpg?w=1200&q=75) > A short, ordered list for securing AI agents, grounded in NCSC and OWASP guidance. Each control comes with the proof worth keeping, and the order puts limits before detection. Ask how to secure an AI agent and you tend to receive a long framework or a sales pitch. What helps on Monday is an ordered list covering what to build first, how to know it works and what can wait. This page gives ten controls in build order, each with the proof worth keeping. The list draws on public guidance: OWASP's prompt injection entry, the OWASP Top 10 for Agentic Applications, the UK National Cyber Security Centre, the MCP specification and the research cited in our deeper guides. Read it as engineering guidance. It is no audit, and no list can promise safety. ## Why the list starts with limits, not detection The NCSC argues that prompt injection is not like SQL injection. Current language models, it says, do not enforce any security boundary between instructions and data inside a prompt, so the flaw may never be fully mitigated the way SQL injection was. Its advice is to reduce risk and impact, to focus design protections on deterministic, non-LLM safeguards that constrain what the system can do, and to be wary of any product claiming it can stop the problem ([NCSC blog](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)). Every control below follows from that stance. Assume the model can be steered, then shrink what a steered model can reach. ## Phase one: know what exists and who it is ### 1. Take a census with named owners Write down each agent, model, tool server, plugin and extension, giving every row a responsible person and a reason to exist. Proof to keep: an export you could give an auditor today. Unapproved agents belong on the list too; [inventory before controls](/attack-surface-management-for-ai-agents-inventory-before-controls) shows the record. ### 2. Give every agent its own identity Stop sharing service accounts across agents. Each identity carries a responsible person, a reason and an end date. Proof: an identity listing in which no account serves two agents. The design choices are in the [identity guide](/ai-agent-identity-and-non-human-identity-security-guide). ### 3. Issue narrow credentials that expire Limit every token to a single task, and let it lapse within hours. Proof: token lifetimes and scopes visible in configuration, with no long-lived keys in agent config files. ## Phase two: shrink what a steered agent can do ### 4. Drop privileges to match the least-trusted input The NCSC quotes a simple rule from a discussion between Simon Willison and Baibhav Bista: when a model processes information from a party, its privileges drop to that party's level. An agent that reads mail from strangers should hold no privileged tools in that session ([NCSC blog](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)). Proof: for each agent, a table showing which inputs may influence which tools. ### 5. Treat every external word as data Pages, files, tool results and messages from other agents are material to process, not orders to follow. OWASP's wording for indirect injection is an LLM taking input from outside sources such as websites or files ([OWASP LLM01:2025](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)). Proof: a diagram of each agent's inputs and of the people able to write into them. ### 6. Put one checkpoint before every side effect Send state-changing calls past one gatekeeper that is told the agent, the job and the surrounding context. Proof: a test where the gatekeeper refuses a call. The pattern appears in [controls at the action layer](/execution-gap-controls-at-the-agent-action-layer). ### 7. Make approvals show what will really happen Build the approval screen from the actual call: command, target, destination. Proof: captured screens for three risky actions, each matching the log. ## Phase three: contain, verify, stop ### 8. Run tools in an isolated space Use a sandbox that holds no lasting credentials, allows only listed outbound hosts and keeps its rules out of the agent's reach. Proof: a logged escape attempt and what happened. ### 9. Vet and pin what you load Approve each tool server and plugin, freeze its version and check what actually gets installed. The MCP security best practices page, for example, calls for showing the exact command before a local server is launched and for sandboxing it with minimal privileges ([MCP security best practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices)). Proof: an approved list with versions frozen. See the [MCP security guide](/mcp-security-complete-guide). ### 10. Log, test and keep a way to stop Keep action records out of the agent's reach, alert on odd behaviour, run harmless canary tests regularly and practise the stop. Proof: a dated entry for each. The [runtime security guide](/ai-agent-runtime-security-complete-guide) shows how these fit together. ## What OWASP's agentic list adds OWASP published its Top 10 for Agentic Applications on 9 December 2025, describing it as peer reviewed with input from more than 100 practitioners ([OWASP](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)). Use it as a naming scheme, so that a finding in one team's report means the same as in another's. It does not replace the build order above; it labels the failures you are building against. ## How long each stage takes WhenControlsNature of the work First week1, plus a hunt for shared keys under 2 and 3Mostly discovery, measured in days First month2, 3, 4, 7Design changes that take weeks First quarter5, 6, 8, 9Platform work, weeks to months Continuing10, and a rerun of 1Routine Treat the timings as rough editorial guesses; real environments differ a lot. ## The same list on a support agent Take an agent that reads tickets, looks up orders and drafts refunds. The census names the support platform team as owner. It authenticates as its own OAuth client. Its tokens allow order lookup and refund drafting, not payment execution. Because it reads untrusted ticket text and touches customer data, it may not send external messages or execute refunds alone, which removes one leg of the lethal trifecta. Ticket bodies are passed as data. Refunds above a threshold go to a person, and the approval screen shows customer, amount and account as the platform wrote them. The container reaches only the order system and the ticket tool. Its two tool servers are on the pinned list. A canary ticket runs weekly. Each step is small, and together they cap a hostile ticket at a draft that a person checks. ## Privilege first, detection later Many teams buy a prompt injection detector first because it is easy to install and demo. My view is that this order inverts the risk. A detector lowers the odds of an attack landing. A privilege limit lowers the damage whatever lands. The NCSC says deny-list style filtering fails because there are endless ways to rephrase an attack, and that detection and training approaches overlay a distinction the technology does not make ([NCSC blog](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)). Put the early weeks into controls 2 to 4 and 8. Add detection afterwards, as one signal among several. Limits-first fails when you cannot cut privileges because the product requires them, such as an assistant whose whole value is acting broadly on a user's behalf. Then the NCSC's last line applies: if the system cannot tolerate the remaining risk, it may not suit an LLM at all. For narrow agents, limits first is usually cheaper and more durable. ## Self-test and gaps Score each control 0, 1 or 2, with 2 meaning proof exists. Below 8 means the basics are missing, 8 to 15 means a base with clear gaps, and 16 to 20 means you can begin adversarial testing at scale. The scale is ours, and it is not an audit. The list leaves out governance, privacy controls beyond what agents touch, and model-level training work that most buyers do not control. ## Questions about securing AI agents ## FAQ ### What is the first control to build? A census of agents with named owners. Every other control depends on knowing what exists. ### Can one product cover all ten controls? No product covers all ten. Several controls depend on your own identity, platform and logging setup. ### Is a prompt injection filter enough? No. The NCSC warns against relying on deny-listing and says to reduce impact with deterministic safeguards. Treat filters as one signal. ### How often should we revisit the list? At least quarterly, and whenever you add a tool, a data source or an agent. --- Source: https://agenticcyber.co/blog/how-to-secure-ai-agents-ten-controls