TL;DR: SpiceDB models authorization as a typed relationship graph with consistency controls, caveats, and delegated permissions so applications can make the correct decision every time an actor accesses a resource, according to Authzed. The key issue is not connecting agents to identity, but enforcing authorization at the point of action with current state.
At a glance
What this is: Authzed argues that AI agent security depends on consistent, point-in-time authorization decisions over a relationship graph, not on simply attaching agents to identity or tokens.
Why it matters: IAM, PAM, and NHI teams need to treat authorization as the control plane for agent actions, because stale decisions, overbroad delegation, and missing context can expose resources even when identity checks pass.
Context
The core problem is authorization drift: an identity or token may be valid, but the decision made from stale relationships, incomplete context, or a copied bearer credential can still be wrong. For AI agents, that matters because the actor, the request context, and the resource path can change faster than traditional access-review cycles can observe.
Authzed's article positions SpiceDB as a relationship-based authorization system that separates access logic from application data and evaluates each request against the current graph. The important governance point is broader than the product itself: security for agents, services, and delegated workflows depends on decision freshness as much as on identity proofing.
In practice, this is an IAM and NHI control issue as much as an application design issue. When permissions are inherited, delegated, or conditionally scoped, the enforcement point has to understand both relationship state and request context at the moment of action.
Key questions
Q: How should teams design authorization for AI agents and delegated workloads?
A: Use a central authorization model that stores relationships separately from application data, then evaluate each request against the current graph at the point of enforcement. That approach works better than scattering role checks across services because it can represent inheritance, delegation, exclusions, and context in one policy layer.
Q: Why do stale authorization decisions create risk in dynamic environments?
A: Because a correct policy can still produce the wrong outcome if the system evaluates it against old relationship data. In fast-moving environments, revocation, reassignment, and object creation can happen close together, and stale reads may preserve access that should already be gone. Consistency is therefore part of access control.
Q: What are the signs that agent handoffs are too broad or poorly scoped in a multi-agent workflow?
A: The common signs are bloated prompts, redundant tool calls, agents acting on irrelevant history, and outputs that reflect unnecessary context rather than the task at hand. Teams may also notice harder debugging, slower orchestration, and inconsistent responses when the receiving agent is forced to process more information than it needs to complete the job.
Q: What is the difference between authentication and authorization in enterprise AI systems?
A: Authentication proves who or what the identity is, while authorization decides what that identity can do after it is verified. In enterprise AI systems, both layers matter. Authentication establishes the user, agent, or service account, and authorization must then constrain data access, tool use, and action scope.
Technical breakdown
Relationship graphs as the authorization source of truth
SpiceDB models authorization as objects, relations, and permissions rather than as static role tables. That lets the application derive access through graph traversal, set operations, and exclusions, so a subject can inherit rights through teams, tasks, projects, or delegated relationships. This is materially different from embedding permission logic in each service, because the graph becomes the canonical source of who can do what. For agent workflows, that means access can be expressed as a policy path instead of a copied token scope. The control value is in making authorization explicit, queryable, and reusable across systems.
Practical implication: Model agent and workload access as durable relationships, not as scattered application-specific rules.
Consistency controls prevent stale authorization decisions
A permission check can be logically correct and still be insecure if it uses outdated state. SpiceDB addresses this with revision-aware consistency, including ZedTokens and freshness options such as At Least as Fresh. That matters when access is revoked, delegated, or re-scoped while requests are still in flight. Without revision control, a user or agent can keep passing checks against an older view of membership or ownership, which creates a New Enemy Problem window. The key mechanism is that the authorization decision is tied to a specific state of the graph, not just to the latest cached answer.
Practical implication: Tie enforcement to the correct revision whenever revocation, delegation, or inheritance changes during active requests.
Caveats and expiring relationships constrain delegated access
Relationships describe who is connected to what, but caveats add request-time conditions and expiration adds time-bound validity. In practical terms, an agent may hold access only when the current environment, customer context, or numeric threshold matches the rule attached to the relationship. This avoids turning every condition into a permanent permission. For delegation-heavy systems, that distinction matters because a bearer token can overstate authority, while a relationship with a caveat can narrow it to a specific task and context. The result is more precise enforcement of time, purpose, and scope.
Practical implication: Use context-bound and expiring permissions when delegated access should only exist for a narrow task.
Threat narrative
Attacker objective: Obtain access to protected resources through a decision path that still authorizes action after the intended scope has changed.
- entry: An actor presents a valid identity or delegation path, but the real security question is whether the application checks the current authorization state before allowing access.
- escalation: If the system evaluates an older relationship set or a copied token scope, access can persist after revocation or exceed the intended task boundary.
- impact: The result is unauthorized access to resources through stale, inherited, or overbroad permission decisions rather than through broken authentication.
Breaches seen in the wild
- Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Decision freshness is now an identity governance requirement, not an implementation detail. Agentic and delegated systems fail when access is evaluated against yesterday's relationship state. That makes point-in-time authorization part of the governance boundary, because identity proofing alone does not answer whether the current action should be allowed. Practitioners need to treat consistency as a control objective whenever privilege can change mid-workflow.
Bearer credentials are too blunt for task-scoped delegation. When authority is copied into a token, the receiving actor inherits more than the task needs and far more than the oversight model can explain. Relationship-based delegation makes the authority path visible and testable, which is what IAM and NHI programmes need when multiple services or agents participate in one workflow. The conclusion is straightforward: delegated access has to be represented, not implied.
Current-state authorization closes the gap between human-paced governance and machine-paced execution. Access review, recertification, and offboarding all assume there is a stable state to review. In systems where requests, inheritance, and delegation can change quickly, that assumption weakens. The governance implication is that authorization must move closer to the request boundary, where relationships, conditions, and freshness can actually be enforced.
Context-bound permissions are the right answer when scope is dynamic. Caveats and expiring relationships let teams express purpose, environment, and time without inflating standing privilege. That matters for AI agents, but also for service accounts and workflows that inherit access only for a narrow operation. The broader lesson for the field is that authorization models must describe why access is valid, not only that a subject once had it.
Consistent authorization is a control plane for AI agent governance. The field will keep confusing authentication, tooling, and authorization unless it separates those functions cleanly. AI agents can be authenticated and still be dangerous if the enforcement layer cannot make the same decision every time against the right revision. Practitioners should anchor agent governance in deterministic authorization, because that is what survives runtime variation.
What this signals
AI agent governance needs decision freshness, not just identity proofing. When access can change during a task, the decisive control is whether the policy engine evaluates the current relationship state before every sensitive action. That shifts governance from static entitlement review toward point-in-time enforcement.
Delegation must be explicit if agents are allowed to act on behalf of others. If authority is not modeled as a visible relationship, the receiving actor can inherit more access than the task requires and the audit trail becomes ambiguous. A relationship graph gives security teams a way to scope, inspect, and expire delegated rights without relying on token reuse.
Consistent authorization is the missing layer between agent runtime and IAM policy. Identity providers can establish who the actor is, but they do not resolve whether the current request still matches the intended privilege boundary. Programmes that support agents or other NHIs need an enforcement design that can react to revocation, inheritance, and context in the same decision.
For practitioners
- Define authorization as a first-class policy graph Separate access relationships from application data so permissions can be evaluated centrally across users, agents, tools, and services.
- Require revision-aware enforcement for changing access Use freshness controls for revocation, delegation, and inherited permissions so checks cannot succeed against stale state.
- Replace token copying with explicit delegation rules Represent delegated authority as relationships with narrow scope, expiry, and conditions instead of passing bearer tokens between actors.
- Attach context to high-risk permission checks Use request attributes such as environment, customer, or transaction context when a permission should only hold under specific conditions.
- Audit whether your review model matches runtime decision speed Check where access review and recertification still assume privileges persist long enough to be reviewed after the fact.
Key takeaways
- The article's central point is that security for AI agents depends on consistent authorization decisions, not on identity attachment alone.
- Relationship graphs, freshness controls, and context-aware conditions address the governance problem of access changing while requests are still in flight.
- IAM and NHI teams should treat authorization as the point where delegated access, current state, and runtime context are enforced together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article focuses on agent permissions, delegation, and point-in-time authorization. |
| Recommendation — Constrain agent authority to explicit relationships and verify privilege at each sensitive action. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows that valid identity alone does not guarantee a safe authorization decision. |
| NHI-05 — Overprivileged NHI | Delegated agents and copied tokens can carry more authority than a task requires. | |
| Recommendation — Separate authentication from authorization and enforce access against current relationship state. Reduce standing authority by modeling narrow, task-scoped access paths for non-human actors. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about enforcing permissions and entitlements at decision time. |
| Recommendation — Review entitlements so authorization checks always reflect the current access state. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Bearer tokens and delegated credentials must be managed as authenticators with lifecycle controls. |
| Recommendation — Manage authenticators so delegated credentials are issued, constrained, and revoked deliberately. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stale tokens and inherited permissions can enable access beyond the intended boundary. |
| Recommendation — Map stale access paths to credential abuse and lateral movement risks in detection and review. | ||
Key terms
- Relationship Graph Authorization: A model that derives permissions from explicit relationships between objects instead of from hard-coded application rules. It lets teams express who can do what, to which resource, and through which delegation path, which is especially useful when access changes frequently or spans agents, users, and services.
- Revision-Aware Consistency: A control pattern that ties an authorization decision to a specific point in the state of the permission data. It matters when access can change while requests are still active, because stale reads can approve actions that no longer match current governance intent.
- Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
- Caveated Authorization: Caveated authorization is an access-control approach that adds runtime conditions to a permission check. Instead of granting access only by relationship or role, the policy also evaluates context such as IP range, session claims, or time window. That makes authorization more precise without hardcoding business logic into the application.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 28, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org