'It was the agent' can't be the new corporate excuse

In a recent conversation with a colleague, a systems auditor, we discussed a concern I've seen growing among companies: the adoption of AI agents is advancing faster than the mechanisms to control them.

The conversation caught my attention because much of the discussion about agents still focuses on what they can do. But for auditing, the perspective is different: which identity executed the action, with what authority, over what data, using which tools, and how to later reconstruct what happened.

This distinction becomes important when we move from systems that only generate responses to systems connected to tools capable of querying corporate systems, altering data, calling APIs, sending messages, executing code, or initiating transactions.

At that point, AI stops being just a matter of response quality. It also becomes a matter of authority to act. NIST itself has put agent and software identity and authorization on its 2026 agenda, discussing identification, authentication, delegation of authority, least privilege, auditing, non-repudiation, and mechanisms to tie agent actions to human authorization.

One of the first problems we discussed was identity. If several agents use the same technical account or a generic credential, the log may show which account executed an operation, but not necessarily which agent acted, on whose behalf, for what purpose, and under what delegation.

That's why I increasingly think it's important to treat agents as governable machine identities, with a distinguishable identity, properly managed credentials, limited permissions, and delegation context when operating on someone's behalf.

The second problem is excessive privilege. An agent needs to look up orders, but is given a tool that also allows it to change them. Another should prepare a payment, but holds credentials capable of executing it.

OWASP calls this problem Excessive Agency: excessive functionality, permissions, or autonomy can turn an inadequate or manipulated model output into a real action on corporate systems.

The solution starts with an old security principle: least privilege. But now it also needs to reach the tools used by the agent. The ability to propose an action doesn't mean the authority to execute it.

Another point we considered critical is the audit trail. Logging only the input sent to the model and its final response is insufficient in agentic systems. We need to be able to reconstruct the execution: identity, objective, relevant context, tools invoked, requested actions, applied policies, authorization decisions, human approvals, results, and failures.

OWASP itself recommends logging and monitoring the activity of tools and target systems and, for agents, validating tool calls against permissions and session context.

There is also the problem of indirect prompt injection. An agent may process an email, document, or page containing malicious instructions and treat them as part of its task. If it has excessive tools and privileges, a manipulation of the model can go beyond generating a wrong response and produce consequences on data or systems.

That's why it has never seemed enough to me to try to solve this problem with just a more elaborate prompt.

Authorization needs to exist outside the model, in the systems and tools that actually execute the actions. OWASP explicitly recommends that target systems validate requests according to their own policies, rather than trusting the LLM itself to decide whether an action is allowed.

Finally, there is accountability. "It was the agent" can't become the modern version of "it was the system." Every agent in production must have an owner, a defined purpose, authorized tools and data, a risk classification, autonomy limits, and human escalation criteria.

I left that conversation even more convinced that agent auditing can't be something added after they go into production. Identity, least privilege, segregation of duties, independent authorization, observability, audit trails, human oversight proportional to risk, reversibility, and interruption mechanisms need to be part of the architecture.

Agents don't make traditional internal control principles obsolete. They do exactly the opposite. They turn these principles into part of the AI's architecture. When software stops merely recommending and starts executing actions, auditing only the outcome is no longer enough.

We need to audit not just what the agent did, but why it was authorized to do it, on whose behalf it acted, and whether we can reconstruct the entire chain that turned a probabilistic model output into a real action.