Key takeaways
Start from least privilege and add access on purpose.
Log the action, the source and the approval every time.
Bring security in during design, not at the end.
Most AI agent projects stall at the same meeting, the one with security. It usually goes better when the controls exist before anyone asks for them.
Scope what agents can touch
Give each agent its own identity and the smallest set of permissions it needs. Shared service accounts make it impossible to answer the first question an auditor will ask: who did this?
Log every action
Record the input, the reasoning, the tool calls and the result. Logs should be readable by a person and exportable to the tools your team already uses for compliance.
Plan for the bad day
Decide in advance how to pause an agent, how to reverse its actions and who gets notified. A rollback plan that has been tested is worth more than a policy that has only been written.
Protect data by default
Encrypt data in transit and at rest, keep customer content out of shared training, and redact sensitive fields before they reach a model. These are table stakes, and they are far cheaper to build in from the start.
Bring security in early
Most review pain comes from timing. When a finished agent lands on a security team’s desk, every question feels like a blocker. Invite them in at the design stage, and the same questions become requirements you can build for.
A one page brief is enough to start: what the agent does, which systems it touches, what data it sees and who owns it. That single page answers most of the first meeting.
Treat prompts and tools as change
A new prompt can change behaviour as much as a code release, so it deserves the same discipline. Version it, review it and test it before it ships. The same applies to adding a tool or widening a permission.
Every change has an author and a reviewer
Tests run before anything reaches production
New tools start with read access only
Rollback takes minutes, not a meeting
Answer the questions before they are asked
Security reviews tend to repeat the same questions. Where does the data go? Who can change the agent? What stops it from acting outside its scope? How would you know if it did? Write the answers once, with evidence, and keep them next to the agent’s documentation.
This turns a long review into a short conversation. It also keeps your team honest, because a claim on paper has to match what the system really does on the day an auditor asks to see it.
Plan the incident before it happens
Security teams relax when they can see the off switch. Show them how to pause one agent, revoke one credential and pull the history of every action it took. Then run the exercise together once, with real people and a stopwatch.
Guardrails do not slow agents down. They are what lets a careful organisation say yes, and keep saying yes as the scope grows.
About the author
Theo Rask
Theo leads engineering at Falak and builds the permission, logging and evaluation systems behind every agent.
