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

A run of 2026 research on AI agent accountability keeps finding the same gap from different angles. Access is being scoped and approval is being required. Neither one proves which agent actually acted.

> By Saad Bin Shafiq, Founder of Nodes · Aug 8, 2026
> Canonical: https://www.nodes.inc/blog/agent-identity-is-the-missing-governance-surface


---
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](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-governance-framework-gap-20260403/) 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](/platform) 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](/platform), 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.

A shared intelligence layer should make that record easier to inspect without pretending there is only one actor. In Nodes' intended architecture, specialist AI teams use permission-controlled company context while each agent retains an identifiable run and authority record. Buyers should ask to see those records in the proposed workflow. Nodes supports Nodes Cloud, a single-tenant customer VPC, and customer-managed on-premises deployment. The selected boundary does not substitute for evidence of identity, permissions, handoffs, and retention.

## 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](/blog/what-is-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](/blog/least-privilege-does-not-govern-ai-agents) 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.

Before accepting the identity design, ask the vendor to run a handoff in a test environment. The parent delegates a bounded task, the child proposes an action, and the owner changes the plan. Inspect whether the record distinguishes the parent, child, plan version, and authority used at execution. Then revoke the child's credential and attempt the same effect. The old approval must not make the revoked actor valid again. Ask who controls signing keys, how replacement identities are provisioned, and whether an exported record preserves those links. A readable agent name is useful for people; the underlying identity and execution checks still need their own evidence. Keep the failed attempt visible alongside the permitted one.

## The proof

This is an architecture requirement, not proof that the complete mechanism is deployed. Nodes' public production reference is candidate evaluation at one Fortune 500 insurance carrier, live since January 2025. A separate historical study covered four years of production data and 10,765 agents. [Decision Traces](https://arxiv.org/abs/2604.19819) documents the research logging protocol. It does not independently establish broad multi-agent execution, second-signer enforcement, or automatic outcome learning in production. Ask for a working demonstration of the specific control.

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](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-governance-framework-gap-20260403/)
- [Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring](https://arxiv.org/abs/2604.19819)


*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: [Decision Traces](https://arxiv.org/abs/2604.19819).*