← Back to the journal

GenAI & LLMs · August 2026

Agent identity and authorization: give agents authority they can prove

A practical guide to workload identity, delegated authority, policy, approvals, auditability, and revocation for AI agents.

RAG retrieval augmented generation overview

When an AI agent calls a tool, the most important question is not only what it wants to do. It is: who is acting, on whose behalf, with which authority, against which resource, under which conditions? As agents move from drafting text to accessing data and changing systems, identity and authorization become core product capabilities rather than infrastructure details.

The One+i Agent Identity repository is a practical course for building agents that can prove who they are, act only within delegated authority, and leave an evidence trail. It connects identity concepts to labs, notebooks, policy gates, and production readiness decisions.

Identity and authorization are different decisions

Identity answers which human, workload, or delegated agent is acting. Authorization independently decides which action that principal may perform on which resource and under which conditions. Keeping those decisions separate prevents a common failure mode: treating a model’s statement of intent as proof of permission.

The principal model for agentic systems

A production agent may involve a user, an application, an orchestrator, a specialist agent, a tool gateway, and a downstream service. Each hop should preserve enough identity context to make the authorization decision explicit. Avoid a single broad service credential that hides the original actor and makes revocation or investigation difficult.

Delegated agent identity chain from user through application and agent to a protected tool with policy and audit boundary
Delegation should narrow authority while preserving identity context and evidence.

Beginner foundations: identity context and safe tools

The beginner path introduces principals, identity context, RBAC, safe tools, and deterministic policy gates. A useful first lab is deliberately narrow: define the principal, resource, action, and policy decision; then test allowed, denied, missing-context, and expired-credential cases. The goal is to make authorization behavior predictable before adding model-driven flexibility.

Intermediate controls: exchange, down-scoping, and risk

Agents often need to call services that should not receive the user’s full token. OAuth token exchange and down-scoping can create a short-lived credential for one specialist task, with only the scopes and audience required. Attribute-based and relationship-based access add context such as tenant, ownership, sensitivity, time, location, approval state, or the relationship between a principal and a resource.

Risk should influence the policy decision. A read-only search may be allowed automatically, while sending an external message, changing permissions, moving money, or publishing code may require stronger evidence and human approval. Authorization is not a static role label; it is a decision at the trust boundary.

Authorization decision flow evaluating principal, action, resource, context, and risk before allow, approval, or deny
The application policy engine decides whether an agent request is allowed, requires approval, or is denied.

Capabilities and policy-as-code

Capability-style design gives an agent only the authority it needs for a specific operation. Policy-as-code makes those rules reviewable, testable, and versioned alongside the application. Keep model prompts out of the authority decision: prompts can describe the task, but application code must enforce identity, scope, resource ownership, conditions, and approval.

Delegation chains need a clear boundary

A user may delegate to an application, which delegates to an orchestrator, which delegates to a specialist. Every delegation should answer what authority is transferred, for how long, for which audience, with which constraints, and whether the action can be further delegated. Downstream services should be able to distinguish an original user from an agent acting on the user’s behalf.

Auditability and revocation are part of the user experience

People need to understand what an agent did and how to stop it. Record the principal, delegated authority, policy decision, tool call, resource, approval, result, and correlation identifier. Make credentials short-lived where possible, support rapid revocation, and test the kill path. A system that can grant access but cannot explain or revoke it is not ready for consequential work.

Advanced readiness: threat modeling and operations

The advanced path examines delegation chains, operations, threat modeling, and production readiness. Test confused-deputy attacks, privilege escalation, token replay, stale policy, cross-tenant access, prompt injection that attempts to change authority, tool misuse, and partial failure during a multi-step action. Include safe fallback, incident response, reconciliation, and evidence preservation in the release decision.

A practical course loop

The Learning Hub is organized into Beginner, Intermediate, and Advanced levels. Each lesson uses Learn → Lab → Checkpoint tabs, so learners move from theory to an executable example and then test their judgment. The repository includes a full interactive quiz for cumulative review, making it useful for self-study, team workshops, or an engineering design review.

Explore the Agent Identity repository ↗

Open the Agent Identity Learning Hub ↗

Take the Agent Identity Knowledge Check ↗

NIST AI Agent Standards Initiative ↗

OAuth 2.0 Token Exchange (RFC 8693) ↗

SPIFFE workload identity ↗

OpenFGA relationship-based authorization ↗

OWASP Authorization Cheat Sheet ↗

MCP security best practices ↗