The assignment usually arrives as one sentence in a staff meeting: you own AI agent security now. By then the agents are already in production. A product team shipped a support agent last spring. Finance has a reconciliation agent that writes to the ERP. Engineers run coding agents with shell access on their laptops. Business teams have switched on AI features in a dozen SaaS tools. Nobody did anything wrong, and nobody can say what all of these are allowed to do.
A few weeks later the audit committee asks two questions: how many agents do we have, and what is the worst thing one of them could do today? The reflex is to answer with a policy or a product evaluation. Both are premature. Spend the first quarter on authority instead: who holds which credentials, what each agent can do with them, and whether anything outside the model stops the worst of it. Choose depth over breadth. Two agents whose worst action is enforced and tested will survive the audit committee's second question; two hundred agents in a monitoring dashboard will not. What follows is six decisions, taken in order, with a test on a real agent at the end of each phase.
Decide that you own authority, not models
For this plan, an agent is software that uses a model to decide which actions to take with real credentials. What you are accountable for is its authority: the credentials it holds, the tools it can call, and the people and systems that can put text in front of it. Authority is knowable from configuration you already have, which is why it is the right place to start.
Name owners before anything else. NIST's Cybersecurity Framework 2.0 asks that roles, responsibilities and authorities for cybersecurity risk be “established, communicated, understood, and enforced” (GV.RR-02) [1], and the GOVERN function of the NIST AI Risk Management Framework calls for accountability structures that empower the appropriate teams and individuals [2]. In practice there are two kinds of owner. You own the program: the method, the controls and the reporting. Each agent has a business owner, a person rather than a team, who decides what the agent is for and accepts the risks it keeps. Teams do not sign exceptions or answer approvals at night; people do.
Days 1 to 30 find and assign every agent that can act, days 31 to 60 enforce controls outside the model, and days 61 to 90 prove the result. Move to the next phase when the exit test passes on a real agent, not when the documents exist.
Decide what to count: agents that can write, send, pay or delete
Find agents by their credentials, not by asking who built one. Agents leave traces you can read without changing anything: admin consoles and organization keys at your AI providers, OAuth grants to AI apps in your identity provider, AI services in your cloud accounts, SDK imports, MCP configuration files and committed keys in your repositories, and AI line items in procurement and expense data. CSF 2.0 already expects inventories of software and services you manage and of services suppliers provide (ID.AM-02, ID.AM-04) [1], and the AI RMF asks for mechanisms to inventory AI systems resourced according to risk priorities (GOVERN 1.6) [2].
Stop counting once you have every agent that can act. A list of three hundred AI assets with no owners is a backlog, not a program, and a meeting summarizer that can only read a transcript earns one line in the register. For every agent that can write, send, pay, delete or change access, fill in one authority record:
- Owner: one named person who can say what the agent is for and who accepts its risks in writing.
- Credentials: each key, token or service account, with the scope it was meant to have and the scope it actually has.
- Worst action: the most consequential thing one call can do, such as moving money, emailing outside the company, deleting records or granting access.
- Writers: everyone who can put text in front of the agent, including customers, suppliers, web pages, documents and other agents.
- Enforcement: whether anything outside the model stops the worst action, and whether the agent's traffic goes through a point you can mediate or directly to the provider.
The gap between intended and actual scope is usually the month's most useful finding. OWASP's Excessive Agency entry names its three causes: excessive functionality, excessive permissions and excessive autonomy [3]. Record anything enforced only by instructions to the model as unenforced.
Take Kittredge Supply, a fictional distributor with about 2,000 employees, whose security engineering manager inherits the program in September knowing of four agents. Her biggest day-30 finding: the reconciliation agent's service account could adjust invoice lines, edit supplier bank details and approve payment batches, and only its system prompt held it back.
| Agent | Owner | Worst action | Untrusted writers | Enforced outside the model? | Priority |
|---|---|---|---|---|---|
| Supplier-invoice reconciliation | Accounts payable systems lead | Change supplier bank details; approve payment batches | Suppliers, through invoice PDFs and email | No: one service account with full payables write | 1 |
| Support agent | Support operations director | Issue order credits | Any customer, through tickets | Partly: billing API caps each credit | 2 |
| Coding agents | Developer platform lead | Run shell commands; push code | Repository content, issues, web pages | Partly: branch protection on main only | 2 |
| Sales outreach | Sales operations manager | Send email as a rep to anyone | Prospect replies, web research | No | 3 |
| SaaS AI features (11 found) | Owners missing for 4 | Varies by product | Varies | Unknown | Assign owners first |
Decide where controls go first: consequence times exposure
Two properties decide it: how bad the worst action is, and how easily a stranger can write into the agent's context. An agent with consequential authority and no untrusted input needs its credentials fixed. An agent that reads the internet but can only summarize needs watching. Start with the agents that have both.
Kittredge's agents placed by the consequence of their worst action and their exposure to untrusted input. The four in the shaded quadrant get controls in days 31 to 60; the rest get an owner and a record.
Exit test for day 30: pick any agent from the register at random and, within ten minutes, say who owns it, what its worst action is, and whether anything outside the model stops that action. Every priority agent's owner has acknowledged the record in writing. If the test fails, stay in this phase. Controls on agents nobody owns produce exceptions nobody can approve.
Decide the order of controls: credentials, then mediation, then approvals
Make each priority agent's worst action depend on something other than the model's judgment. OWASP's AI Agent Security Cheat Sheet says to enforce authorization in the execution component, outside the agent's context, and to fail closed when an approval requirement or policy lookup is missing [4]. The order matters, because each step makes the next one smaller.
- Shrink the credentials. Split broad service accounts and remove capabilities the agent never needed. It is the cheapest control you will ever ship, and it holds when everything else fails. At Kittredge, bank-detail edits and batch approval moved to accounts only people use.
- Mediate, then close the direct path. Route the agent's model and tool traffic through a point where each call is seen and decided, and rotate the keys it used before. A mediated path with a working bypass is a monitoring tool, not a control.
- Set approvals by consequence. Reads and reversible changes run; irreversible changes, outbound messages, payments and access changes ask a person. Bind each approval to the exact action, including tool, target, parameters and expiry [4].
- Log every decision and tool call with its outcome [4], keyed to the agent, its owner and the input that triggered it. Month three measures from these records.
Do not record a prompt edit as a fix. A prompt change may make a failure rarer, but it cannot close a risk.
Approvals that ask forty times a day get switched off
Month two fails through approval fatigue. If an agent asks forty times a day and its owner approves each request in four seconds, those are not reviews, and soon someone more senior than you will ask for the control to be turned off. Track asks per day, the share approved and median time to decision for each agent, every week. A class of request approved every time for two weeks should become a scoped standing grant with a ceiling. At Kittredge (figures illustrative), routine invoice matches within tolerance became one grant capped at the tolerance, which left a handful of over-tolerance asks a week. A request that is sometimes denied is doing its job, so keep it.
Exit test for day 60: in staging, steer each priority agent toward its worst action, for example a supplier bank-detail change requested by text inside an invoice. The control stops it and the downstream system shows no change. A legitimate task still completes. The old credential no longer works. All three must hold; a control that blocks the attack and the work has not passed.
Decide what counts as proof
Month three turns three things you believe into things you have observed.
- A containment exercise. Run the injected-invoice scenario as a tabletop with the incident response lead, then for real in staging, and time how long it takes to stop the agent's authority on every path: its mediated traffic, its credentials, its queued jobs and any approvals still pending. CSF 2.0 expects improvements to be identified from tests and exercises (ID.IM-02) [1], so write down what slowed you down.
- A release gate. Changes to an agent's model, prompt, tools or policy run against attack cases, each paired with a similar legitimate task, before they ship. The AI RMF's MEASURE function says AI systems should be tested before deployment and regularly while in operation [2].
- A board update whose numbers trace to records rather than to a spreadsheet someone typed.
Exit test for day 90: someone outside your team can regenerate every number in the board update from the register and the decision logs, and at least one real change to a priority agent has passed through the release gate.
| Phase | Owners | Deliverables | Done when |
|---|---|---|---|
| Days 1 to 30: find and own | Security lead, with each agent's business owner | Register of agents that can act; one authority record per agent; ranked priority list | Any agent can be traced to owner, worst action and control in ten minutes; priority owners have signed their records |
| Days 31 to 60: enforce | Agent owners and platform engineering; security sets the controls | Scoped credentials; mediated path with the direct path closed; approvals by consequence; decision logs | A steered test action has no downstream effect, a legitimate task completes, and the old credential fails |
| Days 61 to 90: prove | Security lead, incident response lead, agent owners | Exercise report with containment time; regression set and release gate; board update | Board numbers are reproducible by someone else; one real change has passed the gate |
| After day 90: sustain | Security governance forum | Intake for new agents; quarterly review; re-review triggers such as a new tool or credential | New agents enter through intake rather than being found by the next scan |
Give the board authority and denominators, not blocked-prompt counts
A board can act on “four of our five highest-consequence agents now have their worst action enforced outside the model; the fifth is scheduled for November.” It cannot act on a risk score. Report these, each with its denominator:
- Agents that can act, and how many have a named owner and a signed authority record.
- Priority agents whose worst action is enforced outside the model, and whose direct path has been tested and found closed.
- Time to contain in the exercise, with the slowest path named.
- Approval load per priority agent: asks per day, share approved and median time to decision.
- Open exceptions, each with an owner and an expiry date, and the date of the next review.
Leave out counts of blocked prompts, which measure how often someone tried rather than whether anything was protected, and any coverage percentage whose denominator you cannot state. Leave the acceptable-use policy out of the first month, too. Written in week one, it will be wrong by week six; write it once you know what the agents do.
Where Intertrace fits in each phase
Intertrace's discovery runs read-only against cloud accounts, repositories, identity providers' AI-app grants and AI provider organization keys, opening findings as work items without storing key values. Its gateway sits inline between agents and the models, tools and MCP servers they call, reads each call's tool name and arguments, and allows, flags, asks or blocks by consequence tier; outbound messages, payments and admin changes always ask, and the enforcer fails closed when it cannot decide. Every decision is a structured event naming its rule and layer, and policy changes can be replayed against the last 30 days of decisions. Scoping credentials and naming owners stay with you.
On Monday, run the day-30 test early
Ask for read-only access to your AI provider admin consoles, your identity provider's app grants and your code search, and book thirty minutes with each team you already know runs an agent. Then run the day-30 exit test on the one agent you think you understand best: its owner, its worst action and what outside the model stops it, in ten minutes. If you cannot pass the test on the agent you know, you have found your first month's work.
