Who owns the authority behind an AI agent?
Every significant action should have an identifiable actor, an understandable reason, and a human who remains answerable for the outcome.
When I see an AI agent complete a task, I want to understand the authority behind the outcome. Which identity did it use? Who approved its access? And who is responsible if the action turns out to be wrong?
My colleague Roopika captures the issue in “Your agents already have identities. You just did not issue them.”
That observation deserves attention. An agent may enter an enterprise through a small experiment, using a developer’s credentials, a service account, or an existing API key. Once it begins acting through those credentials, it already has access and authority—even if nobody has deliberately decided what its identity should represent.
What concerns me is the gap between that technical access and the business responsibility behind it.
An agent that can create a ticket has one level of responsibility. An agent that can close the ticket, change a user’s access, or approve the next step in a workflow has another. I would expect each expansion to trigger a fresh decision about its authority.
Success at the first task should earn a review before the next permission is granted.
For me, that review starts with a named human owner. Someone should be able to explain why the agent exists, which outcomes it is meant to support, and where its authority ends. That responsibility needs to remain clear after the original developer moves to another project.
I would also want the permissions to reflect the task. An agent helping investigate an access issue may need to read identity information. Whether it should modify an account is a separate decision. Whether it should make that change without human approval is another.
Those decisions belong in the design of the workflow.
There is an important distinction here: an action can be technically permitted and still fall outside the purpose for which the agent was deployed. A valid credential alone cannot tell us whether the business intended that particular action in that particular situation.
That is why I want evidence connecting the action to its purpose, the authority used, and any approval required. A record that says “the agent changed the account” leaves too much unexplained.
I would ask teams to demonstrate how they suspend an agent’s access, too. If its purpose changes or its owner leaves, there should be a clear way to review or withdraw its authority without disrupting unrelated work.
Roopika’s article is a useful starting point for looking at the credentials agents are already using. My next step would be to connect each of those identities to an owner, a defined purpose, and a decision about acceptable autonomy.
That is the standard I would want before an experiment becomes an enterprise capability: every significant action should have an identifiable actor, an understandable reason, and a human who remains answerable for the outcome.