Agent Security › Deploy safely
A practical step-by-step guide. Not what happens if the agent goes rogue, but what happens when it gets something ordinary wrong, and the sequence for setting it up safely before you switch it on.
You've built an AI agent. It works. It can use the tools it needs. You've tested the prompt. You're ready to switch it on. Before you do, there is another question: what happens when it gets something wrong?
Not what happens if it becomes rogue. Not what happens if it becomes superintelligent. Something much more ordinary. What happens if it misunderstands a task, uses the wrong tool, receives a malicious instruction, retries something it shouldn't, misses part of its job, acts on incomplete information, sends something incorrectly, or confidently believes it has finished when it hasn't? Once an AI can act, those questions become part of deployment. Here's how to work through them. The sequence also matches the direction of current standards work on agent identity, authorisation, least privilege and lifecycle controls from NIST and OWASP.
Start with one sentence: this agent exists to... Be specific. Not "help with marketing", but "monitor 20 named competitor websites every weekday by 8am, record whether every site was successfully checked, and prepare an internal summary when material changes are detected". You cannot properly define permissions, authority, success, failure or monitoring until you know exactly what the job is.
Secure the job, not the idea of an agent.
Don't let important agents disappear into generic accounts and shared credentials. Record agent name, agent ID, purpose, human owner, platform, model/provider, environment, trigger, status, created date and review date. Where possible, give the agent its own technical identity too. You want to be able to answer "which agent did this?", not "something using the automation account did it". Identity creates the foundation for everything that follows.
Every deployed agent should have someone responsible for it. Not necessarily someone watching every action, but someone accountable for why it exists, whether it should still exist, what authority it has, what happens when it fails, when permissions change, and whether it should be retired. Avoid orphan agents: an agent shouldn't continue running simply because nobody remembered who created it.
Map access: public web, Google Drive, CRM, email, CMS, database, GitHub, payments, analytics, customer support, internal APIs, other agents. Don't just document what you intended to connect; check what the agent can actually reach. Then ask whether it needs every one of these systems to perform its current job. If not, remove access.
An agent may need access to email without needing authority to read every mailbox, send email, delete messages, change settings or create forwarding rules. It may need access to your CMS without needing to publish. It may need access to a payment platform without needing to execute payments. Access tells us where the agent can go. Authority tells us what it is allowed to do when it gets there. Define both.
Start with the job, then grant the smallest amount of authority required to complete it, using the Authority Ladder: READ (retrieve information), RECOMMEND (analyse and suggest), PREPARE (create something ready for action), CHANGE (modify a business system), SEND (communicate externally), SPEND (create financial consequences), PUBLISH (make something public), DELETE (remove something). An agent doesn't become better because it moves higher up this list. A highly capable agent may only require READ + RECOMMEND. Intelligence does not create entitlement.
Avoid "agent can access CRM"; prefer "agent can read assigned customer records". Avoid "agent can send email"; prefer "agent can reply inside existing authenticated support conversations". Avoid "agent can issue refunds"; prefer "agent can refund up to £20 to the original payment method for an existing customer". Authority can be constrained by system, action, amount, recipient, destination, data, time, volume, environment, task and duration. The narrower the permission, the smaller the consequence when something goes wrong.
Define hard boundaries. For example, the agent cannot change its own permissions, create new credentials, disable monitoring, access payroll, export the customer database, send data to unknown domains, change supplier bank details, deploy directly to production, spend above £500, permanently delete records, publish without approval, or create higher-authority agents. Then ask the important question: what actually prevents it? If the answer is "the prompt tells it not to", you have an instruction, not necessarily a security boundary. Where an action matters, enforce the restriction outside the model wherever practical.
Agents increasingly operate on information they didn't create: websites, emails, documents, support tickets, calendar invitations, database content, messages from other agents. Some of that content may contain instructions intended to manipulate the agent. So separate trusted instructions from untrusted content, and don't rely entirely on the agent recognising the difference every time. Instead ask what a manipulated agent could actually do, then reduce that blast radius through permissions, boundaries and approvals. (More on prompt injection.)
Don't require approval for every tiny action; that destroys useful autonomy and encourages approval fatigue. Identify consequential boundaries instead. Human approval may be appropriate before large payments, public publication, destructive changes, sensitive external communication, production deployment, permission escalation, high-impact customer changes and irreversible actions. Let the agent research, analyse, prepare, test and recommend, then stop at the appropriate boundary. Put humans where consequences begin.
Don't show a human "agent wants permission, approve/deny". Show which agent, what it wants to do, why, which system, what will change, who is affected, the financial consequence, whether it can be reversed, what authority the agent currently has, and how long approval will last. An approval should be meaningful. (Work out where approval belongs.)
If approval is required and nobody responds, what happens? Choose deliberately: wait, cancel, expire or escalate. Don't allow "no response equals yes", particularly for consequential actions.
Some agents need elevated authority occasionally without needing it permanently. A coding agent might require production access for one deployment. A finance agent might require authority for one approved payment. A data agent might need a sensitive dataset for one task. Where possible, grant authority for a task, a session, a transaction or a time window, then remove it. Temporary need doesn't require permanent authority.
This deserves its own deployment test. Can the agent create API credentials, request broader OAuth scopes, change permissions, add tools, install integrations, modify its own configuration, disable monitoring, spawn another agent, or call another agent with greater authority? If yes, understand exactly what that creates. The normal response to ACCESS DENIED should be REQUEST AUTHORITY, not CREATE AUTHORITY.
Agent A cannot access Finance. Good. But Agent A can call Agent B, and Agent B can access Finance. Can Agent A simply ask "get this finance information for me"? If yes, Agent A may have more effective authority than its direct permissions suggest. So document who can call whom, what they can request, what data can move and what authority can be delegated. Delegation should never create authority.
Don't wait until the agent finishes and then ask "did that look successful?" Define success first. For a Backup Agent: expected, a backup every day by 03:00; success evidence, a backup object exists, with today's timestamp, including the expected database, above a minimum file size, and verification passes. Now success has an external definition.
For each important task, ask what should exist in reality if this agent succeeds: a sent email, a database row, an updated CRM field, a backup file, a published URL, a git commit, a payment transaction, a generated report, a completed test, an API response, an analytics event. Where possible, verify that evidence directly. Don't simply ask the agent "did you do it?"
Your agent may say SUCCESS while your evidence says INCOMPLETE. Keep those separate. Agent reported SUCCESS, expected 25 websites checked, observed 21, verified INCOMPLETE. Or agent reported BLOCKED, expected control "payment above £500 must stop for approval", observed "agent stopped and requested approval", verified BLOCKED CORRECTLY. A block isn't necessarily a failure. Sometimes it's evidence that your controls worked.
Some of the hardest failures produce no error. The agent simply doesn't run. So define expected activity. If an agent should run at 07:00 every weekday and by 07:30 there is no execution and no expected evidence, raise a MISSED RUN. Silence shouldn't leave you wondering what happened.
Don't only monitor successful actions. Watch denied actions, approval requests, repeated retries, attempts to access unexpected systems, attempts to use prohibited tools, new destinations, unusual data movement, permission changes, unexpected agent-to-agent calls, spending changes and activity outside expected times. These events tell you where the agent is pushing against its boundaries. Watch what happens at the edge of the agent's authority.
Before deployment, answer: how do I pause this agent? How do I stop scheduled runs? How do I revoke its credentials? How do I stop related agents? Where are its logs? What systems could it have changed? How do I recover? Who needs to know? Who decides when it can restart? Don't invent the incident process during the incident.
Having a kill switch isn't enough. Test it. Run the agent, pause it, and confirm new tasks stop, scheduled tasks don't start, credentials are revoked where expected, in-flight actions behave as expected, and the event is recorded.
A kill switch nobody has tested is an assumption.
Normal testing asks "can the agent complete its job?" Agent deployment testing should also ask: what happens when the API fails, when a website is unavailable, when credentials expire, when the agent receives malicious instructions, when a tool returns incomplete data, when approval doesn't arrive, when another agent fails, when verification fails, and when the agent itself doesn't run? Test ugly conditions before production creates them for you.
Don't begin by giving the agent every system, every tool, every customer, every action and permanent authority. Start with limited systems, data, actions, destinations, amounts and time. Observe. Verify. Then expand deliberately.
Start narrow. Expand deliberately.
Deployment isn't the end of authorisation. Review when the model changes, the prompt changes materially, tools change, systems change, the agent's purpose changes, its owner changes, another agent is connected, permissions increase, a significant incident occurs, or the review date arrives. Capability can change without anyone deliberately changing authority. Keep the two separate. (More on governance and review.)
Before switching the agent on, you should be able to produce something like this:
| Field | Example (Invoice Agent) |
|---|---|
| Purpose | Process incoming supplier invoices and prepare approved payments |
| Owner | Finance Manager |
| Systems | Accounts payable, supplier database, payment platform |
| Authority | READ, RECOMMEND, PREPARE |
| Conditional authority | SPEND up to £100 for approved recurring suppliers |
| Human approval | Payments above £100, new supplier, changed bank details, unusual invoice |
| Denied | Create supplier, change bank details, create credentials, change permissions, disable monitoring |
| Expected | Process new invoice queue every weekday at 09:00 |
| Evidence | Every invoice assigned a processing status; prepared payments recorded; exceptions recorded |
| Verification | Invoice count compared with processed + exception count |
| Failure | Incomplete coverage generates an alert |
| Containment | Pause agent, revoke payment access, preserve task log |
| Review | 90 days |
Now you know considerably more than "we've tested the prompt and it seems good".
If you don't have time for all 25 steps, answer these ten questions before deployment:
If you can't answer one, don't ignore the gap. Investigate it.
The prompt matters. The model matters. The tools matter. But once an agent can act inside real systems, security needs to exist around the model too: identity, authority, permissions, boundaries, approval, monitoring, verification, containment and review. Together, those controls allow something important: useful autonomy. You don't have to remove the agent's ability to reason, and you don't have to supervise every step. You define the environment in which it is allowed to work.
Give the agent freedom to work. Not freedom to do anything.
As the number of agents grows, remembering all of this becomes its own job. Which agents ran? Which didn't? Which crossed a boundary? Which need approval? Which reported success? Which outcomes were actually verified? The human shouldn't have to hold all of that in their head. That's the problem we're working on with Agent Control.