Access is scoped. Approval is required. Nobody checked whether the agent was real.

Two governance projects are already running inside most enterprises that have moved AI agents past a pilot. One narrows what an agent can reach: scope every credential to the task, revoke standing access, treat an agent like a contractor instead of an employee who keeps a badge for years. The other puts a human between a proposed action and its execution, so nothing fires until someone reviews the evidence and signs off. Both projects are real progress, and both are worth finishing. Neither one answers a question that a run of 2026 research on AI agent accountability keeps raising from a different angle each time: when an action lands in a system of record, can anyone name which agent produced it, and tell the real one from a copy, a compromise, or a shadow deployment nobody provisioned. Access answers what an agent may touch. Approval answers whether a person saw the proposal first. Neither one answers whether the actor was who it claimed to be, and that gap sits underneath both projects rather than beside them.

The accountability question underneath the two projects

A wave of 2026 research on AI agent accountability lands on the same finding from different directions. Industry commentary this year keeps framing accountability as the differentiator ahead of model capability or feature count once agents move from pilot to live workflow, because the enterprises furthest along still cannot always say which agent took a given action once one goes wrong. A Cloud Security Alliance research note describes the same gap from the security side: most enterprises running agents cannot produce a reliable inventory of the agent identities operating inside their own environment, and fewer are confident they would notice if one of those identities had been copied, misused, or was never authorized to begin with.

Neither finding is about permission scope, and neither is about whether an approval step exists. An over-permissioned agent and a properly scoped one can both act under an identity nobody can verify after the fact. A workflow with a real human approval gate still depends on an assumption that the thing proposing the action is the agent the approver thinks it is, an assumption that holds by default in a single-vendor pilot and stops holding the moment an enterprise runs more than one agent framework, more than one model provider, or agents built by teams outside the group that provisioned the first one.

What identity means for something that is not a person

A person's identity inside an enterprise system is a login, a session, and an audit trail tied to a badge that already exists for other reasons. An agent has none of that by default. It does not clock in, it does not have a manager who would notice if someone else were using its credentials, and in most deployments it shares a service account with every other automated process a team has built this year. Ask which agent wrote a given record six weeks ago, and the honest answer in most environments is a shrug: several teams built agents against the same system this year, none of them log a distinguishable signature, and the service account tied to the change tells you which application called an interface. The reasoning process that decided to call it stays invisible.

A signed trace on every action closes that gap by making identity a property of the action rather than a property of the account that took it. A Decision Trace records what the system read, what it weighed, what it proposed, and what a specific human did with the proposal, all timestamped and queryable after the fact. That record names the actor because producing the record is a condition of acting at all, independent of whether anyone remembers to check a login later. A human approves, edits, or rejects the proposal before execution, and the trace ties that approval to the action it authorized, so the question of which agent did something and the question of who approved it resolve to the same record instead of two systems a team has to reconcile by hand.

The architecture underneath makes the answer simpler than it sounds, without pretending there is only one possible actor. Inside the customer's own environment, single tenant, with no data egress, thirteen agents share one calibrated model instead of each running its own point solution from its own vendor, with its own logging format and its own definition of what counts as an event worth keeping. Sharing the model does not collapse the actors into one. It means every one of the thirteen writes to the same trace format when it acts, so the record naming which agent invoked the model for a given action is a byproduct of the architecture rather than a reconciliation project bolted on afterward. The estates where the Cloud Security Alliance's finding bites hardest are the estates running the most agents from the most vendors, each with a partial log that does not speak to the others. Consolidating the logging surface, not the agent count, is most of the fix.

Where identity alone is not enough

None of this makes the other two projects optional. A well identified agent can still propose a wrong action if nothing pauses execution long enough for a person to look at it, which is the same gap an approval gate exists to close regardless of how confidently a system can name its own actor. A well identified agent with standing access to everything it might someday touch still carries the blast radius a scoping project is built to narrow, because knowing who acted does not shrink what it was able to reach while doing it. Identity, access, and approval answer three different questions, and an enterprise that solves one and calls the agent governed has closed a third of the problem while reporting the whole thing closed.

The order enterprises tend to fund these projects in runs backward from the order that matters on a bad day. Access scoping gets funded first because it maps onto a security review checklist. Approval gates get funded second because a near miss usually makes the case for one. Identity gets funded last, if at all, because nothing forces the question until an action shows up that nobody can trace to a source, and by then the enterprise is answering which agent did this during an incident instead of by design. The fix is cheaper before that day than after it, and it is the same fix either way: an architecture where every action already carries the answer, instead of a search for one.

The proof

The claim here is architectural rather than a result measured after the fact, because the question is whether the mechanism exists rather than whether it improved an outcome later. At a Fortune 500 insurance carrier running Nodes across four years of production data and 10,765 agents, every proposed workflow carries a signed Decision Trace before anything executes, and the workflows designated for it take a second signer on top of the standard approval. The trace names the reasoning process that produced the proposal and the person who approved it, in the same record, queryable months later without reconstructing anything from separate systems. The Decision Traces methodology documents the logging protocol behind that guarantee: an adversarial review process paired with decision-trace logging, built so the record still holds up when checked by someone who was not in the room when the decision was made.

That is what identity should mean for something that is not a person: attribution rather than authentication. A record that names which agent invoked the model, what it read and proposed, and which specific human approved it, logged at the moment of acting instead of reconstructed after the fact. It is a claim the system makes about itself, checkable against every other record left behind, not a cryptographic guarantee that no other process holding the same credential could have produced it.

Access answers what an agent may reach. Approval answers whether someone saw it first. Identity answers who the record says did it, and it is the question the current run of AI agent accountability research keeps circling without naming directly. An enterprise that finishes the first two projects and skips the third has built a system where the access list is short, the approval log is full, and the honest answer to which agent did this is still a shrug. Ask that question before an incident does.

Sources

• Cloud Security Alliance research note: the AI agent governance framework gap
• Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.