Notifications
Clear all
Topic starter
11/08/2026 3:12 pm
TL;DR: Runtime agent authorization is splitting between proxy-based gateways and standards-based short-lived tokens, with the trade-off centered on inspection depth versus data-path privacy, according to C1.ai. The real governance issue is not which model wins, but whether identity teams can choose per system, per agent, and per policy without forcing one pattern everywhere.
NHIMG editorial — based on content published by C1.ai: Agent Authorization: Gateway or Token? The Answer Is Both
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams choose between gateway and token authorization for AI agents?
A: Choose the model based on the system’s sensitivity and control objective.
Q: Why do AI agents complicate traditional IAM controls?
A: AI agents complicate traditional IAM controls because they do not behave like human users with short, predictable sessions.
Q: What do organisations get wrong when they standardise one authorization model for all agents?
A: They confuse consistency with control effectiveness.
Practitioner guidance
- Classify agents by sensitivity tier Assign each agent and application pair to a sensitivity tier before choosing an authorization pattern.
- Define when proxy mediation is mandatory Write policy that names the systems, data classes, and audit conditions that require a gateway in the path.
- Treat token scope as a governance boundary Limit token permissions to the smallest practical action set and shortest viable lifetime.
What's in the full article
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- A side-by-side explanation of how the gateway and token models behave in real deployments
- The article's specific reasoning for when proxy mediation creates unacceptable data-path exposure
- Practical examples of how teams can choose an authorization pattern per system and per agent
- The vendor's own framing of the enterprise managed authorization standard and its implementation context
👉 Read C1.ai's analysis of gateway and token authorization for AI agents →
Agent authorization models: gateway vs token, or both?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:26 pm
Agent authorization is now an NHI architecture decision, not just an API design choice. The article shows that runtime access for agents sits in the same governance family as service account and workload identity control, because the key question is where authority is expressed and how it is revoked. Once agents touch production systems, IAM teams have to treat authorisation as part of the identity lifecycle, not a one-off integration decision.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: How do teams govern runtime access for agents without creating standing privilege?
A: Issue access as short-lived, task-scoped credentials and tie each grant to a specific policy decision. Then review token scope, lifetime, and revocation paths as part of identity governance, not as an afterthought. That keeps the agent’s authority narrow enough to limit blast radius if the session is abused.
👉 Read our full editorial: Agent authorization needs both gateway and token models
