Before you give an AI agent access to your systems: a security checklist

A chatbot answers questions. An agent takes actions: it reads your inbox, updates records, calls APIs and sends messages. That makes it useful, and it means a wrong answer can become a wrong action. Most agent incidents come from too much access, not from a clever attack.

1. Write down what it must never do

Before listing what the agent should do, list what it must not do: move money, delete records, email customers, change prices, touch production servers. That list decides every setting below.

2. Give it the least access that does the job

• Read and write are separate decisions, made tool by tool. An agent that summarises tickets needs to read them, not close them.
• Limit the scope inside each tool: one mailbox, not the whole domain; one database table or a read-only view, not the admin account.
• No open internet unless the task needs it. Web pages are a common way to slip instructions into an agent.
• No production access from a test agent, and no test data mixed with real customer data.

3. Give it its own keys

• One key per agent and per service, never a person's own login. You can then switch the agent off without locking out a person, and every action is attributable.
• Keys live in a secret store on the server, not in a prompt, a config file in the repository, or an instruction file the agent can read.
• Set a spending limit and an alert at every AI and API provider the agent uses.

4. Put a person between "suggested" and "done"

For anything that moves money, sends a message outside the company, submits a form or deletes data, the agent should prepare the action and a named person should approve it. Remove the approval step only for actions that are cheap to undo, and only after the agent has a track record.

5. Log every action, and make failure visible

• Record each action: what the agent did, with which key, on which record, and why it decided to.
• Honest failure: if an action did not finish, the agent must say so, not report success.
• Review the log weekly at the start. Patterns of near-misses appear long before an incident.

6. Treat everything it reads as untrusted

An email, a web page, a PDF or a support ticket can contain text written to look like instructions. This is called prompt injection. The agent should treat what it reads as data, never as orders, and the strongest protection is the access limits above: an injected instruction cannot make an agent do something it has no permission to do.

7. Know how to switch it off

1. One place to disable the agent immediately.
2. A list of every key it holds, so each can be revoked.
3. Backups of anything it can change, tested by actually restoring one.
4. A named owner who is told when it fails.