The standard way to give an AI agent access to a system is to give it access to the system. You create an account, issue it a credential, hand that to the agent, and then you spend your time trying to observe what it does with it.
Every product in this space is built on that assumption. Log the calls. Detect the anomalies. Alert on the unusual. Review it afterwards. All of it is downstream of a decision made in the first five minutes: the agent holds the key.
It is worth sitting with how unusual that is. We do not do it for people. A new employee does not receive the company's payment credentials on their first day so that we can review their usage later. They get an identity, and each action they take is authorised at the moment they take it. Authority is not a thing they possess. It is a thing they are granted, per action, and it can be refused.
Agents got the other arrangement, and mostly because it was the fastest thing to build.
The consequence nobody plans for
An agent holding a credential has capability it has not been asked to use yet, and that capability does not expire when the task ends.
So the interesting question is not what the agent did. It is what it could have done. And with a credential in hand the answer is everything that credential can reach, which is almost never scoped to the task, because scoping it properly would have meant a different credential per task and nobody has ever managed that.
Then it gets worse, because the agent is not a program with fixed behaviour. It takes instructions from its input. An agent that holds a credential and reads untrusted content is a system where the boundary between data and command is a matter of hope. Watching it closely does not fix that. It just means you find out sooner.
Broker it instead
The agent asks. Something else holds. The action is completed with access the agent never possessed. Squidder brokers that exchange.
What the application ends up with only means anything in one place, for one purpose, and cannot be used anywhere else. If it is stolen, it is worthless. If it leaks in a log, nothing happens. If the agent is persuaded by a malicious instruction to do something with it, it has nothing to do it with.
That is not a better lock on the same door. It is a different arrangement, and it changes the question your security review is asking. You stop asking "how do we detect misuse" and start asking "what was this agent actually authorised to do, once".
The same move works on ordinary software that was never an agent, and there it is mostly a hygiene exercise: getting keys out of applications you cannot edit. With an agent it is not hygiene. It is the difference between a system whose worst case is bounded and one whose worst case is whatever it was talked into.
What this asks of you
Something has to hold what the agent no longer holds. That moves the sensitive part somewhere deliberate, which is the point, and it means that place matters. Anyone offering you this arrangement should be able to tell you exactly where the value goes and who can reach it. If the answer is vague, the problem has been moved rather than solved.
Not every system cooperates. Access that can be brokered depends on the destination supporting it. Plenty of internal systems have one credential and no concept of delegation, and those need a different approach.
A brokered action is still an action. Removing the credential does not decide whether the action should happen. It decides that the agent cannot decide alone. Those are two controls and you want both.
The question to take to your next review
Not "what did the agent do", which your logs already answer.
Ask what it could have done. Then ask why it was able to.
If the answer is that it holds a credential because that was the shortest path to shipping, that is a fair answer and it was true for all of us. It is just no longer the only option.