Notifications
Clear all
Topic starter
10/06/2026 11:38 pm
TL;DR: AI agents are being modeled with access patterns that look more like people than scripts, and Authzed argues that relationship-based access control fits that reality better than static policy engines. The core issue is that authorization for agents depends on dynamic relationships and shared context, while policy-only models still assume the decision data can be assembled cleanly ahead of time.
NHIMG editorial — based on content published by Authzed: AI agent authorization and relationship-based access control
Questions worth separating out
Q: How should security teams authorize AI agents that need changing access over time?
A: Security teams should model AI agents as first-class identities with explicit relationships to resources, teams, and shared data.
Q: Why do policy engines struggle with AI agent authorization in real systems?
A: Policy engines struggle when the relevant decision context is not already present at evaluation time.
Q: What breaks when organisations treat AI agents like service accounts?
A: Treating AI agents like service accounts hides the fact that agents are expected to participate in dynamic relationships, not just run a fixed workload.
Practitioner guidance
- Map agents as first-class identities Represent AI agents as explicit objects in the authorization model so group membership, shared resources, and delegated access are visible in governance rather than hidden inside generic user records.
- Separate policy evaluation from context assembly Document which attributes and relationships must be fetched before an authorization decision is made, then measure where the pre-decision data gathering becomes the real bottleneck.
- Retire the user-shaped service account shortcut Review every non-human principal that was forced into a human identity pattern and decide whether it needs workload, agent, or delegated-actor treatment instead.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- The side-by-side Cedar and SpiceDB model examples, including the line-by-line schema and relationship structure.
- The specific photo-sharing access pattern used to show how policy data and relationship data differ in practice.
- The practical comparison of where policy engines make sense and where ReBAC becomes the cleaner authorization model.
- The discussion of how agent identity should be represented as shared, relationship-bearing access rather than as a user-shaped workaround.
👉 Read Authzed's analysis of AI agent authorization and ReBAC →
AI agent authorization and ReBAC: is your policy model ready?
Explore further
12/06/2026 5:55 am
Policy engines are a poor default for AI agent authorization because they assume the decision context can be assembled ahead of time. That assumption holds for simple allowlist-style checks, but it fails when access depends on relationships, shared resources, and context that changes during the session. The result is not just slower evaluation, but a governance model that hides where the real decision inputs live. Practitioners should treat this as a model-fit problem, not a tuning problem.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
A question worth separating out:
Q: When is a policy engine still the right tool for authorization?
A: A policy engine still fits cases where the decisive data is already available, such as IP allowlists, URL checks, or other simple pre-known conditions. It becomes a weaker fit when authorization depends on relationship graphs, shared documents, team membership, or other context that must be assembled from multiple identity systems before the decision can be made.
👉 Read our full editorial: AI agent authorization needs relationships, not static policy engines
