AI agent hardening: a checklist for switching an agent on at work

Hardening an AI agent means cutting down what it can do and what can go wrong before it starts work on real systems. The idea is the same as hardening a server: switch off what is not needed, give the least access that still does the job, and watch what is left. For agents there is a reason to be strict. OWASP, the open security project, says it is unclear whether there are fool-proof ways to prevent prompt injection (OWASP LLM01:2025 Prompt Injection). So the aim is not an agent that can never be tricked. It is an agent that cannot do much harm when it is.

This checklist follows two public sources: OWASP's 2025 entries on prompt injection and excessive agency, and the Guidelines for secure AI system development published on 27 November 2023 by the UK National Cyber Security Centre, the US Cybersecurity and Infrastructure Security Agency and agencies from many other countries (NCSC, guidelines collection). For the risks themselves, see our overview of AI agent security.

1. Give it fewer tools

• Only the tools the task needs: if the agent does not need to fetch web pages, do not offer it a web-fetch tool (OWASP LLM06:2025, mitigation 1).
• Only the functions a tool needs: a tool that summarizes a mailbox needs to read mail, not send or delete it (mitigation 2).
• No open-ended tools where a narrow one will do: "run any shell command" or "fetch any URL" leaves a huge range of possible actions. A tool that only writes one kind of file does not (mitigation 3).

2. Give it the least access

• Least privilege in the systems it touches: an agent that recommends products from a database may only need read access to the products table, enforced by the database permissions of the account it uses, not by its instructions (mitigation 4).
• Act as the user, not as an all-powerful service account: actions taken for a person should run with that person's rights and the smallest scope needed (mitigation 5).
• Its own keys, kept out of the model: give the application its own API tokens and handle them in code rather than handing them to the model (OWASP LLM01:2025, mitigation 4). Never put passwords or keys in the agent's instructions: OWASP lists system prompt leakage among its top ten risks (OWASP Top 10 for LLM applications 2025).
• Control what data it can reach: the NCSC/CISA guidelines call for processes and controls that manage what data AI systems can access (Guidelines, section 2, Identify, track and protect your assets).

3. Put a person in front of high-impact actions

• Human approval: require a person to approve high-impact actions, such as posting, paying, deleting or sending to outsiders, before they happen (OWASP LLM06, mitigation 6; LLM01, mitigation 5).
• Checks in the system, not in the prompt: the downstream system decides whether an action is allowed and checks every request against its policies. Do not rely on the model to decide (mitigation 7, complete mediation).

Our reading: an approval step that the agent can talk its way past is not an approval step. It should be a button or a setting in the system the agent calls, owned by someone who is not the agent.

4. Treat what it reads as untrusted

• Mark outside content: keep web pages, emails and uploaded files separate from instructions and clearly labeled as untrusted (LLM01, mitigation 6).
• Set a narrow role: state the agent's role, capabilities and limits in its instructions and keep it to its task (LLM01, mitigation 1).
• Check its output with ordinary code: define the expected format of its output and validate it with deterministic code before anything acts on it (LLM01, mitigation 2). Filter inputs and outputs for content that should not pass (mitigation 3).

5. Log it, limit it, watch it

• Log tool calls and downstream activity: OWASP notes this does not prevent excessive agency but limits the damage, because you can see undesirable actions and respond (OWASP LLM06).
• Rate limits: cap how many actions it can take in a period, so a bad run is caught before it does much (OWASP LLM06).
• Monitor behavior and inputs: the guidelines ask operators to watch outputs and performance for sudden or gradual changes, and to log inputs such as prompts, in line with privacy and data protection rules (Guidelines, section 4). Logs are themselves sensitive data and need protecting (section 2).

Logging prompts can mean logging what staff and customers typed. Tell people, and keep it within your data protection duties. See AI agents and personal data.

6. Plan for the bad day

• Incident plan: have response, escalation and fix plans that cover AI incidents, train the people who respond, and keep offline backups of critical resources (Guidelines, section 3, Develop incident management procedures).
• A known good state: keep track of models, prompts, data and settings under version control so you can roll back after a compromise (section 2).
• A stop switch: decide who can pause the agent at once and how. Our reading is that this follows from the incident and approval controls above; neither source names it as a separate item.

7. Test it, then retest after changes

• Attack it yourself: run regular penetration tests and attack simulations, treating the model as an untrusted user, to test trust boundaries and access controls (LLM01, mitigation 7).
• Release after evaluation: the guidelines call for security evaluation such as red teaming before release (Guidelines, section 3, Release AI responsibly).
• Treat updates as new versions: changes to models, data or prompts can change behavior, so test them like a new release (section 4, Follow a secure by design approach to updates).
• Check suppliers: hold AI vendors and components to the same security standards as other software (section 2, Secure your supply chain).

The checklist on one screen

• Tools: only those needed, narrow functions, no open-ended commands.
• Access: least privilege, user's own rights, keys out of the prompt, data access managed.
• Approvals: high-impact actions need a person, enforced in the system.
• Inputs: outside content marked untrusted, output validated by code.
• Watching: logs, rate limits, behavior monitoring, logs protected.
• Bad day: incident plan, rollback, someone who can stop it.
• Testing: attack it before release and after each change; check suppliers.

Who owns this list is a staffing question as much as an IT one. The person who writes an agent's brief and chooses its tools decides most of it; see the AI agent manager job description and introducing AI agents at work.

This page is general information based on the OWASP 2025 entries and the NCSC/CISA guidelines as published when checked on 6 November 2026. It is not a full security standard or professional advice.