AI agents are being reviewed with the wrong mental model.
A team brings security an agent. It has a model. It has a vendor. It has a system prompt. It has a short list of tools. Someone asks whether the agent is approved.
That sounds reasonable. It is also too broad to be useful.
The risk is not only that an agent exists. The risk is what the agent can do in a specific moment, using specific data, against a specific system, with a specific permission. That is where the control has to live.
If an agent can call tools, change records, send messages, create tickets, query customer data, update workflows, or trigger downstream automation, then governance cannot stop at launch approval. It needs a transaction boundary.
Approval is not an execution control
Approving an agent tells you that someone accepted a design under known assumptions. It does not prove that every future action is appropriate.
The agent may receive a messy user request. It may retrieve stale context. It may summarize hostile content. It may follow instructions embedded in a web page, document, ticket, email, or knowledge base article. It may call a tool that was originally meant for humans who understood the business context.
That does not mean agents should be blocked. It means approval is not enough.
The common mistake is treating the agent like a normal SaaS feature. Enable it, restrict it to a group, add a policy note, and move on. But an agent with tool access is closer to delegated operational authority. It acts through an identity. It touches systems. It can create facts the business has to unwind later.
Zero Drama Security has covered this from the identity angle before: AI agents are now an identity and access problem. The next layer is execution control.
The transaction is the unit of risk
For agent tool access, the useful review question is not just: can this agent use the CRM?
It is:
Can this agent perform this class of action, on this type of record, using this data, under this condition, with this approval path, and with this evidence?
That sounds heavier. It is actually more precise.
There is a meaningful difference between an agent that drafts a customer note and one that sends it. Between an agent that summarizes a support ticket and one that closes it. Between one that looks up an account owner and one that exports an account list. Between one that creates an engineering ticket and one that changes access groups.
The tool name does not tell you enough. The transaction does.
A transaction boundary should describe:
- Who or what requested the action
- What data the agent used to decide
- Which tool was called
- Which system was affected
- What permission or service identity was used
- Whether the action was reversible
- Whether human approval was required
- What evidence was captured
- How the action can be stopped or rolled back
That is the operating model. Not a prettier policy.
Give agents narrow tools, not broad trust
The cleanest architecture is often boring: do not hand the agent a powerful generic tool if a narrow purpose built function will do.
Instead of giving an agent broad write access to a SaaS API, expose a smaller action surface. Let it create a draft, not send the message. Let it propose a change, not apply the change. Let it update a low risk field, not modify account ownership or entitlements. Let it read one approved data set, not search across everything the service identity can see.
This has a tradeoff. Narrow tools require more engineering and product thought. Broad tools are faster to ship and easier to demo.
That tradeoff should be named instead of hidden. If the business wants autonomy, it should also accept the control obligations that come with autonomy: scoped identity, approval paths, evidence, monitoring, recovery, and a real stop button.
A good agent architecture separates read actions from write actions. It separates reversible actions from irreversible ones. It separates low impact workflow updates from actions that affect customers, money, access, legal commitments, or regulated data.
The point is not to make the agent timid. The point is to stop pretending every action has the same blast radius.
Evidence should prove the decision, not hoard the prompt
Agent logging is easy to get wrong.
Some teams collect everything because it feels safer. Full prompts. Full outputs. Retrieved documents. Tool payloads. Intermediate reasoning traces. User context. System instructions. Screenshots. Copies of records. The result can become a privacy and security problem of its own.
Other teams collect almost nothing because logging feels sensitive. Then, when something odd happens, nobody can reconstruct what the agent saw, why it acted, or which system accepted the change.
Neither extreme is mature.
The evidence should support accountability without creating a new warehouse of sensitive material. Capture the transaction record. Capture the tool call. Capture the authority used. Capture the approval decision where needed. Capture enough context to review the action without storing every sensitive input forever.
If prompts and outputs are being logged, retention and access rules need to be explicit. This is especially important for copilots and model powered workflows, where prompt logs can quietly become a second copy of sensitive business data. The same issue shows up in AI logging policy work.
Design the stop button before the launch
An agent with tool access needs a containment plan.
Not someday. Before release.
Can security disable the agent without breaking the whole platform? Can the service identity be revoked quickly? Can specific tools be turned off while read only functions continue? Can queued actions be paused? Can downstream workflows be stopped before they amplify the mistake? Can the team preserve evidence without copying sensitive data into another uncontrolled workspace?
This is where many cyber playbooks are too generic. They know how to handle compromised accounts, malware alerts, and suspicious network activity. They often do not handle an agent making plausible but wrong business changes at machine speed.
That gap is close to the first hour problem in AI incident response planning: the first signal may not look like a traditional security incident. It may look like bad output, strange workflow behavior, unexpected tool use, or a business process quietly drifting off course.
Questions to ask before granting tool access
Before an AI agent gets write access, architecture review should answer a few concrete questions.
What action classes are allowed?
Which actions require human approval?
Which actions are blocked entirely?
What identity does the agent use, and who owns it?
Can the agent act across tenants, customers, business units, or environments?
What data can influence the agent before it calls a tool?
What happens if retrieved content contains instructions?
What evidence proves the action was authorized?
Who can shut the agent down?
Who owns cleanup if the agent does the wrong thing?
These are not theoretical AI ethics questions. They are ordinary security architecture questions with a new execution pattern.
If your team is trying to turn AI governance into workable operating decisions instead of approval theater, Zero Drama Security services can help structure the controls, ownership, and evidence model.
The goal is not dramatic AI lockdown. It is simple: approve the agent if you want, but control the transaction where the business consequence actually happens.