Access Graphs: A Working Model for AI Agent Permissions
A practical explanation de agent access graphs.
TL;DR
TL;DR: AI agents don't fail because they lack intelligence — they fail because organizations grant them permissions in the shape built for humans: one login, one static role, one implicit trust boundary. Agents need a different shape: a graph that separately tracks who an agent is, how it proved that, what it's allowed to touch, who authorized it to act on their behalf, and what it actually did. Netics' position is that teams should model this as an access graph now, in parallel with — not waiting for — the standards work currently underway at NIST and in protocols like MCP. The article separates the permission problem, five access concepts, the practical graph model, the standards boundary, and Netics' position. The article also explains where Netics fits.
The problem isn't the agent. It's the permission model underneath it.
Most companies deploying AI agents today reuse infrastructure built for humans clicking buttons: an OAuth login, a role in an IAM system, a session token with a long expiry. That model assumes a human is present to notice when something looks wrong, and it assumes one identity acts, roughly, one way.
Agents break both assumptions. A single agent might act under its own service identity, on behalf of a user who delegated a task, through a chain of sub-agents it spawned, calling tools that were scoped for a completely different use case. When something goes wrong — an agent deletes the wrong record, calls a paid API in a loop, or leaks data across a tenant boundary — the postmortem question is rarely "was the model good enough." It's "who or what authorized this action, and why did the system let it happen." Most teams can't answer that cleanly, because their permission model never separated the concepts that would let them.
That gap is now a recognized, active area of standards work, not just a Netics observation. NIST's AI Agent Standards Initiative names agent identity and authentication infrastructure as a priority for secure human-agent and multi-agent interaction (NIST AI Agent Standards Initiative [1]). The NIST National Cybersecurity Center of Excellence is running a dedicated project on software and AI agent identity, authorization, delegated access, and accountability, explicitly because existing identity standards weren't built with autonomous, non-human actors in mind (NCCoE: Software and AI Agent Identity and Authorization [1]). Neither of these establishes a finalized universal standard for agent identity — they establish that the industry agrees the current model is insufficient and is actively working the problem. That distinction matters: build your architecture on the problem being real, not on a standard that doesn't exist yet.
Five concepts your access model needs to keep separate
Most incidents we see trace back to two or more of these being collapsed into one field, usually "the API key" or "the role."
Identity — the durable answer to "which agent is this." Not a session, not a token — a persistent record that survives key rotation, redeployment, and version upgrades. If your agent's identity is indistinguishable from its credential, you can't investigate an incident after the credential is rotated.
Authentication — the proof that a given request actually came from that identity, right now. For agents this increasingly means machine-to-machine credentials with short lifetimes, not a password a human typed once. Authentication answers "is this really the agent it claims to be," nothing more.
Authorization — what that authenticated identity is permitted to do, on which resources, under which constraints. This is where least-privilege scoping lives. MCP's authorization specification is a concrete, current example of this layer in practice: it documents protected resource metadata, least-privilege scope design, resource indicators to bind a token to a specific resource, and audience validation so a token issued for one server can't be replayed against another (MCP Authorization Specification [2]). Authorization is not "the agent has access to the CRM" — it's "this agent, with this token, can read these three fields on these record types, and nothing else."
Delegation — the chain of "on whose behalf." A human delegates a task to an agent; that agent may delegate a sub-task to another agent or tool. Delegation needs to be explicit and boundable — an agent should not be able to act with more authority than the party who delegated to it possessed in the first place, and each hop in the chain should be a distinct, inspectable record, not an assumption baked into a shared credential.
Audit — the record of what actually happened, tied back to identity, the authorization that permitted it, and the delegation chain that authorized the intent. Audit is not logging for its own sake; it's the thing that makes the other four layers falsifiable after the fact. If you can't reconstruct, from logs alone, which identity acted, what it was authorized to do, and who delegated the task, you don't have an audit trail — you have a debug log.
Collapsing these into a single "API key with a role attached" is exactly why agent incidents are hard to investigate: there's no seam between the layers, so there's nothing to inspect independently when one of them fails.
A practical access-graph model
Instead of a flat permission list, model agent access as a graph with four node types and typed edges between them:
- Principal nodes — humans, service accounts, and agents, each with a durable identity record independent of any credential.
- Credential nodes — the specific authentication material (a token, a key, a certificate) bound to exactly one principal, with its own lifecycle and expiry, separate from the principal's identity.
- Resource nodes — the systems, data objects, or tools an agent can reach, scoped as granularly as the underlying system allows (a field, a record type, an endpoint — not "the database").
- Grant edges — directed, typed edges connecting a principal to a resource, carrying the authorization scope, the delegation chain that produced it (which principal delegated to which, and under what original authority), and a validity window.
Every action an agent takes should be traceable as a walk across this graph: principal → credential used → grant edge invoked → resource touched, with the delegation chain on that edge showing whether the action stayed inside the authority that was actually handed down. Audit logs then record which edge was walked and when, rather than free-text descriptions of what an agent "did."
The practical payoff: when an agent misbehaves, you don't start from the code — you start from the graph. You isolate the credential, walk its grant edges, and see exactly which resources were reachable and under whose delegated authority, before you ever have to reason about model behavior at all. That's a fundamentally faster and more defensible incident response than reading through agent transcripts.
This also makes least-privilege enforceable rather than aspirational. A grant edge with a narrow resource scope and a short validity window bounds the blast radius of a compromised credential automatically — you don't need the agent's judgment, or your monitoring, to catch it in time.
What this means before the standards land
Waiting for a finalized cross-industry standard before building this is the wrong trade. The standards bodies are converging on the same five-layer distinction described above — that's visible directly in what NIST and NCCoE have scoped their work around — but convergence and ratification are different things, and neither has happened yet. Building an access graph now doesn't lock you into a doomed architecture; it builds the exact primitives — separated identity, scoped authorization, explicit delegation chains, walkable audit trails — that any eventual standard will need to sit on top of.
The teams that will adapt fastest when a standard does land are the ones who already have identity, authentication, authorization, delegation, and audit as distinct, inspectable concepts in their systems — not the ones with a single role field to unwind five different concerns from.
Where Netics fits
Netics designs and reviews access architecture for teams putting AI agents into production — specifically the identity, authorization, and delegation layer that most agent incidents trace back to. We don't sell a standard; we help you build the graph so that when one does land, you're extending an architecture, not replacing one.
Learn more about our approach at Netics or book a session to walk through your current agent access model.
For a practical architecture review, visit the Netics homepage or book a free 30-minute audit.