Article
When AI acts on its own: what agentic AI changes about your controls
AI agents send, approve, change, and buy, not just suggest. That shifts the control model toward agent identity, action limits, traceable decisions, real human oversight, and a way to stop.
Most AI controls were designed for systems that suggest. A person reads the output, decides, and acts. Agentic AI removes that step for some tasks. The system sends the email, approves the request, changes the record, or places the order. When AI acts on its own, the control question moves from “is the output good?” to “what is this thing allowed to do, and how would we know if it did the wrong thing?”
From suggestion to action
The difference sounds small. It is not.
A generative assistant that drafts a customer reply carries risk, but a human usually stands between the draft and the customer. An agent that drafts the reply, decides it is good enough, and sends it has no such checkpoint unless someone builds one. The same is true for an agent that can reset passwords, issue refunds, update vendor bank details, or book purchases against a budget.
Consider a bank that deploys an agent to handle routine service requests. It reads the request, looks up the account, and takes one of several actions. On most days, that works. But the control environment now has to answer questions that never applied to a chatbot. Whose credentials does the agent use? What is the largest refund it can issue alone? If it acts on a fraudulent request, can anyone reconstruct why?
When I supervised teams that built AI solutions, the design conversations that mattered most were about the edges: what the system could touch, when it should stop and ask, and what record it left behind.
Watch for agent washing
Before redesigning controls, confirm what you are actually looking at. Some products labeled “agentic” are traditional automation with a new name: a fixed workflow, a set of rules, a scheduled script. Others are genuine agents that plan steps, choose tools, and act with some independence.
The distinction matters in both directions. Calling a simple rules engine “agentic” can trigger unnecessary review. More often, the reverse problem appears: a genuinely autonomous capability is described as “workflow automation,” so it passes through a lighter review than it deserves.
Ask three plain questions. Does the system decide which steps to take, or follow a fixed sequence? Can it choose among tools or actions at run time? Can its behavior change without a code change, for example through a new prompt or model version? If the answers are yes, treat it as an agent, whatever the brochure says.
Identity and least privilege for agents
Every agent needs its own identity. Not a shared service account. Not the credentials of the developer who built it. Not the user’s session, borrowed indefinitely.
A distinct identity makes three things possible: access can be scoped to the agent’s purpose, its actions can be attributed in logs, and it can be shut off without disrupting anything else. These are the same principles security teams apply to people and service accounts, and the NIST Cybersecurity Framework 2.0 treats identity management and access control as core protective outcomes. Agents should not be an exception.
Least privilege needs more care with agents, because they are built to be flexible. A developer may grant broad access so the agent “can handle anything that comes up.” That is the opposite of what you want. Grant access for the tasks the agent was approved to perform, review that access on a schedule, and treat any request for broader permission as a change that needs approval.
Action boundaries and approval thresholds
The most practical control for an agent is a clear boundary on what it may do alone, what it may do with approval, and what it may never do. I find it helpful to write these down as a table that the business owner signs.
| Action type | Illustrative example | Agent may act alone | Requires human approval |
|---|---|---|---|
| Read and summarize | Pull account history to answer a question | Yes, within data access limits | No |
| Low-value, reversible change | Update a mailing address after verification | Yes, with logging | Above a defined volume per day |
| Financial action | Issue a refund or fee waiver | Up to a set amount | Above the threshold, or for flagged accounts |
| Sensitive change | Change payee bank details or contact channels | No | Always, with independent verification |
| External communication | Send a message to a customer or vendor | Templated messages only | Any free-form or non-standard message |
| Irreversible or high-impact | Close an account, approve credit, delete records | No | Not delegated to the agent |
The specific lines will differ by organization. What matters is that they exist, that they are enforced in the system rather than described in a policy, and that someone tests whether the agent stays within them.
Logging and traceability
For a person, we accept a decision record that says who acted and when. For an agent, that is not enough. When something goes wrong, you need to know what the agent was asked to do, what information it used, which tools it called, what it decided, and what it changed.
That means logging at the level of the agent’s steps, not just the final outcome. Keep the instruction or trigger, the inputs it retrieved, the actions it took, and the version of the model and configuration in use at the time. Store those logs where the agent cannot alter them.
Traceability also supports the Measure and Manage functions of the NIST AI Risk Management Framework. You cannot measure whether an agent is performing as intended, or manage incidents when it is not, without a record of what it did.
Human oversight that is real
Many approval documents say a human is “in the loop.” I have learned to ask what that person can actually do. Oversight is real only when the reviewer has three things.
- Authority. The reviewer can reject, reverse, or halt the agent’s action without needing someone else’s permission.
- Knowledge. The reviewer understands what the agent is supposed to do, its known limits, and what errors look like.
- Information. The reviewer sees enough context to judge the action: the inputs, the proposed action, and why the agent chose it. Approving a one-line summary is not oversight.
Volume matters too. If one person is asked to approve hundreds of agent actions an hour, the approval becomes a click, not a judgment. The EU AI Act’s expectations for human oversight of high-risk systems point the same way: oversight has to be assigned to people with the competence and authority to exercise it.
A kill switch and a way back
Every agent should have a tested way to stop it quickly, and a plan to undo what it did. Stopping should be possible by the business owner or operations without a code release. Practically, that might mean disabling the agent’s identity, revoking its tokens, or switching the workflow to manual handling.
Rollback is harder. Some actions can be reversed, such as a record update. Others cannot, such as a sent message or a completed payment. That is a strong argument for keeping irreversible actions behind human approval in the first place. Where rollback is possible, document how, and rehearse it before you need it.
When the vendor or the model changes
Many agents run on models supplied by a vendor. When the vendor updates the model, the agent’s behavior can change even if your configuration does not. An agent that respected its boundaries last month may interpret instructions differently after an update.
Treat model changes as changes. Require notice from vendors in the contract where you can, re-test boundary behavior after updates, and record the model version in your logs. The 2023 Interagency Guidance on Third-Party Relationships expects banks to manage risk across the life of a vendor relationship, and a model update is exactly the kind of change ongoing monitoring should catch.
What auditors should ask
When I review an agentic AI deployment, these are the questions I start with.
- Is this a genuine agent, or relabeled automation? How was that determined?
- Does the agent have its own identity, separate from users and developers?
- Are its permissions limited to its approved tasks, and when were they last reviewed?
- Is there a signed table of action boundaries and approval thresholds?
- Are those boundaries enforced in the system? Show me a test.
- Can we reconstruct a sample of agent actions from the logs, step by step?
- Do human reviewers have the authority, knowledge, and information to make real decisions?
- Who can stop the agent, how fast, and when was that last tested?
- How are vendor model changes detected and re-tested?
- Is the agent recorded in the AI inventory with a named accountable owner?
Closing
Agents can take real work off people’s desks, and that is worth pursuing. But an organization should never give a system more authority than it would give a new employee on day one, and it should always be able to see what that system did. Set the boundaries first. Then let it act.
This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.