line·Jun 17, 2026·4 min readCurated summary

ID-JAG The Hard Way: Learning AI Agent Security Through Failure, Hands-On

ID-JAG provides a structured way for AI agents to access protected APIs on behalf of users without granting them permanent, broad permissions. The hands-on environment demonstrates how authentication, enterprise authorization policies, delegation, and token exchange work together across Keycloak, Athenz, MCP, and resource servers. Its central conclusion is that AI-agent security requires explicit delegation boundaries and centralized policy enforcement, not just user authentication at the entry point. ## Why AI Agents Need a Different Authorization Model - AI agents continuously call internal APIs, SaaS tools, databases, and other services. - Requesting user consent for every automated action would create an unusable experience. - Granting agents permanent, broad access increases: - Blast radius during failures or compromise - Difficulty assigning responsibility - Exposure to prompt injection and shadow AI risks - The key question becomes whether an agent is authorized to access a specific resource, for a specific user, with a specific scope at a specific time. ## ID-JAG and Its Practical Role - ID-JAG is an emerging OAuth profile discussed by the IETF OAuth Working Group. - It combines: - OAuth 2.0 Token Exchange (RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) - It models delegated, cross-domain API access using explicit authorization grants. - The hands-on explores questions that architecture diagrams often leave unanswered: - What token payloads are issued? - Why should an ID token not be exchanged directly for an access token? - Where are enterprise policies evaluated? - How does an agent prove it is acting for a user? - How is trust established between the identity provider and authorization server? ## Separating Authentication from Enterprise Authorization - Keycloak acts as the upstream identity provider: - Authenticates the user - Issues the original identity assertion - Athenz, through `KeycloakTokenExchangePlugin`, acts as: - The authorization server - The ID-JAG issuer - The policy decision point (PDP) - The central resource authorization authority - Athenz validates the Keycloak assertion’s: - Issuer - Signature - Audience - Subject - Client binding - Enterprise policy requirements - Resource authorization servers trust only the Athenz-issued ID-JAG, rather than accepting Keycloak tokens directly. - Centralizing delegation policies in Athenz reduces duplicated or conflicting rules across identity providers, SaaS vendors, and applications. ## End-to-End Request Flow - The user logs in through Keycloak. - The user gives the AI agent a task through a prompt. - The agent requests an ID-JAG from Athenz. - Athenz evaluates enterprise policies and determines whether the delegation is allowed. - The agent requests an access token from Athenz. - The agent calls the protected MCP server with the issued token. - The MCP server exchanges the token with the authorization server. - The MCP server uses the exchanged token to call the final resource server. - The agent therefore operates within a policy-defined boundary instead of holding a long-lived master credential. ## Learning Through Deliberate Failures The tutorial emphasizes failure paths to show where each security control applies. - Calling a protected API without a token produces `401 Unauthorized`. - Defining an enterprise role without adding membership causes token exchange to fail. - Omitting the agent’s required delegation permission breaks the delegation chain. - These failures reveal whether the problem lies in authentication, grant validation, agent delegation, enterprise policy, or resource-token validation. ## Why ID Tokens Should Not Be Used Directly - An ID token proves that a user authenticated successfully to a client. - An authorization grant is an artifact submitted to request access to a particular resource and scope. - Directly exchanging an ID token can implicitly treat login evidence as permission to access resources. - Using an explicit ID-JAG grant creates clearer boundaries between: - Authentication failure - Grant validation failure - Delegation denial - Enterprise policy rejection - Resource authorization failure - ID-JAG is not technically required for the small local demo, but it makes authorization boundaries and audit paths much clearer. ## Hands-On Environment - The tutorial is available in `athenz-community/id-jag-the-hard-way`. - It guides users through a deliberate “fail, diagnose, and fix” workflow. - Users can later remove an agent’s delegation permission in the Athenz UI and observe exactly where execution is blocked. - This experimentation demonstrates the value of centralized policy control more effectively than a successful request alone. AI-agent ecosystems need more than front-door authentication. A practical deployment should use short-lived, explicitly scoped delegation, centralized enterprise policy evaluation, and observable token-exchange boundaries such as those demonstrated by ID-JAG.

Read original(opens in new tab)

Id JagAI AgentsModel Context ProtocolJwt+4

line·Apr 30, 2026·4 min readCurated summary

ID-JAG, a next-generation standard candidate for solving authentication challenges in the AI era

ID-JAG extends enterprise SSO trust to API access between AI agents, applications, and services. It uses an enterprise IdP to centrally evaluate permissions and issue a signed JWT that can be exchanged for a resource-specific access token. This can reduce consent prompts, improve auditing, and limit token sprawl, but organizations should adopt it cautiously while the specification remains an Internet-Draft. ## The Authentication Challenge in the AI Era - AI agents increasingly perform real work, including: - Searching systems - Querying databases - Sending messages - Creating tickets - As the number of connected services grows, authentication and authorization become more complex. - Poorly coordinated integrations can turn AI from a productivity tool into an operational bottleneck. - ID-JAG is being discussed by the IETF OAuth Working Group as a potential solution. ## What ID-JAG Is - ID-JAG, or Identity Assertion JWT Authorization Grant, extends the enterprise IdP’s SSO trust relationship to API access. - The IdP centrally determines: - Which application or agent may access an API - Which user or identity it acts for - Which scopes or permissions are allowed - It combines: - OAuth 2.0 Token Exchange (RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) - The IdP issues a cryptographically verifiable JWT as an “introduction” or authorization assertion. - The target authorization server validates that assertion and issues the final access token. ## The ID-JAG Participants and Flow The model involves four main parties: - **Requesting Agent:** An AI agent or application calling another service’s API - **Enterprise IdP:** Provides SSO and enforces centralized organizational policies - **Authorization Server:** Issues tokens for the target application - **Resource Server:** Hosts the API being accessed The basic five-step flow is: 1. The user signs in to the requesting agent, which obtains an ID token from the IdP. 2. The agent presents the ID token to the IdP and requests an ID-JAG through token exchange. 3. The IdP evaluates organizational policy and issues the ID-JAG if access is allowed. 4. The agent presents the ID-JAG to the target authorization server and receives an access token. 5. The agent uses the access token to call the resource server. The key architectural shift is that authorization decisions move from isolated agent-to-service relationships toward a centrally governed relationship between the enterprise IdP and target authorization servers. ## Benefits for User Experience and Auditing - Centralized IdP policies can reduce repeated consent screens. - This is especially useful when AI agents connect to many tools and services. - ID-JAG claims can record important context, such as: - The user whose authority is being delegated (`sub`) - The requesting agent (`client_id`) - The target authorization server (`aud`) - Approved scopes (`scp`) - Issuer, issue time, expiration, and unique token ID - Centralized issuance logs provide a clearer view of service-to-service relationships. - Security teams can more easily determine which agent accessed which service, on whose behalf, and with what permissions. - The same records can support incident investigation, compliance audits, and accountability. ## Centralized Control and Reduced Token Sprawl - The IdP can help detect and control unauthorized “shadow AI” integrations. - It can evaluate every token exchange using consistent organizational policies. - Requested scopes can be narrowed or overridden according to enterprise security requirements. - Blocking future access can be handled centrally instead of by changing policies across every endpoint. - ID-JAG may reduce token sprawl by avoiding additional long-lived refresh tokens. - The draft recommends that resource authorization servers generally not issue refresh tokens when an ID-JAG is exchanged. - Agents can instead submit a new ID-JAG to obtain another access token, replacing scattered API keys, service credentials, and refresh tokens with dynamic, policy-based trust. ## Adoption Requirements and Risks - ID-JAG is still an IETF Internet-Draft, not a finalized RFC. - Its behavior may change, so systems should avoid tightly coupling their core architecture to the current draft. - Before implementation, organizations need to verify that: - The requesting agent is registered as an OAuth client with both the enterprise IdP and the target authorization server. - Explicit trust relationships exist between the IdP and agent, and between the IdP and authorization server. - The IdP has pre-authorized the agent to act on users’ behalf for the relevant services and scopes. - Deployment also requires coordinated support from agents, enterprise IdPs, authorization servers, and resource servers. Organizations should treat ID-JAG as a promising architectural direction for governing AI-agent access, while isolating its implementation behind adaptable interfaces until the standard stabilizes. Pilot deployments should focus on centralized policy enforcement, detailed audit logging, strict scope control, and minimizing long-lived credentials.

Read original(opens in new tab)

Id JagDatabase DesignOauthJwt+4