Most AI safety conversations in small firms start with a policy: what staff may paste into a chatbot, which tools are approved. That's a sensible start, but it stops being enough the moment an AI system can act: read a mailbox, update a record, call an API.
An agent that can act is a new kind of user with access to your systems. The controls that keep it safe are the same ones that keep any user safe, and they are engineering controls, not documents.
Five controls that do the work
- Identity: the agent has its own identity, never a shared service account or a person's credentials.
- Least privilege: it can reach only the data and systems its task needs, scoped to the user it acts for.
- Tool limits: an explicit allow-list of tools and APIs, with limits on what each call may do.
- Review: high-impact actions wait for a person; routine output is checked by a reviewer or an LLM judge.
- Logs: every prompt, tool call and result is recorded where your security team can see it.
Why policy alone fails
Policy describes intent. It can't revoke a token, block a tool call or tell you afterwards what happened. When something goes wrong at runtime, only the controls that were built in will act.
The practical test: if your security lead asked "what can this agent do, and what did it do yesterday?", could you answer from a system rather than from memory?
Where to start
Pick one agent or pilot. Give it its own identity in the directory you already run, cut its permissions to what the task needs, and turn on full tracing. Those three changes answer most of the questions a security review will ask.