My IAM thoughts about Agentic AI – Part 1

The noise around Agentic AI security is hard to ignore. I’ve been watching identity challenges evolve for over 10 years, and what’s happening today feels different. We went from managing hundreds or thousands of Active Directory accounts to federating millions of consumer identities, to wrestling with the explosion of service accounts, API keys, and certificates that DevOps and cloud-native architectures threw at us. Each wave pushed us to rethink what “IDENTITY” actually means.

And just when Non-Human Identity (NHI) was starting to feel like a solved problem, Agentic AI walked in and completely broke the mental model.

This post is the first in a two-part series based on my recent research, hands-on experimentation, and conversations in the field. Part one is theoretical and it’s about how we should think about IAM for Agentic AI? Part two is practical, a demo application that brings these concepts to life, covering OAuth 2 token exchange, Security Token Service (STS), Workload Identity Federation and more.

Let’s dig in…

Consider what’s already happening in enterprises today (Gov sector – fictitious scenario): An applicant submits a housing benefit claim through a government portal. An orchestration agent receives the request and hands off to a verification agent, which checks identity against the national ID database, cross-references income records with the tax authority, and validates residency through municipal registries. Once it returns a consolidated eligibility verdict, a third agent reviews the outcome, approves the claim, and triggers the payment. The applicant receives their benefit.

No human reviewed the decision!

Here’s what that broken state looks like, visually:

Every arrow hides the original identity or actor. By the time the action reaches its destination, Adam is gone.

What Makes Agentic AI Different from Other NHI

We all spend a lot of time talking about Non-Human Identity. Service accounts, RPA, API tokens, workload credentials, these are all entities we’ve learned (sometimes painfully) to manage. But AI agents are a different beast.

Traditional NHI is mostly deterministic. A service account runs a scheduled job. An API key calls a specific endpoint. You can define what it does, scope it tightly, and monitor for deviations. It’s not “SMART” it just executes.

An AI agent is autonomous and compositional. It plans. It delegates. It adapts its steps based on intermediate results. It can spawn other agents, call multiple tools, interact with sensitive systems, all in pursuit of a goal that a human set at the start of a session. By the time it reaches the fifth hop of a multi-agent workflow, that original human context may be completely invisible to the downstream systems receiving the requests.

This creates what I’d call the three core identity problems with Agentic AI:

Problem 1: Agents don’t have a native identity concept. Today’s IAM infrastructure was built for two kinds of principals: humans and machines executing defined workloads. An agent that “acts on behalf of a human” sits in an uncomfortable middle ground that our systems don’t know how to represent.

Problem 2: Delegation chains collapse. When Agent A calls Agent B which calls API C, the downstream system sees only the immediate caller. The human who initiated the session, and every intermediate agent, disappears. We lose provenance and accountability.

Problem 3: Static credentials don’t fit dynamic behavior. An agent might need read access to logs at one moment, write access to a config at the next, and query access to a database after that, within a single session. Long-lived, broad credentials are a security disaster waiting to happen.

The Protocol Foundation: Let’s Talk About the RFC 8693

When I dug into how forward-thinking engineering teams are solving the agentic AI identity challenges, I kept coming back to a relatively old RFC: RFC 8693, OAuth 2.0 Token Exchange.

This protocol, published in 2020, was originally designed for scenarios where a resource server needed to trade an access token for a different token to call a backend service. The classic microservices delegation pattern. But its core concept, a Security Token Service (STS) that can validate an existing credential and issue a new, scoped token for a specific purpose, turns out to be exactly the right foundation for agent identity.

Here’s why it matters for agentic workflows:

RFC 8693 introduces two key concepts that map directly onto the agent problem. First, delegation semantics: the idea that Principal A can act on behalf of Principal B, while still maintaining its own separate identity. The issued token carries information about both the subject (who authorized the action) and the actor (who is performing it). Second, the “act” claim in JWTs: a structured way to express and chain delegation in a token, creating a verifiable history of who delegated to whom.

Think of it like a chain of authorization letters. When the citizen submits their claim, it’s like signing a letter saying, “I authorize the Orchestration Agent to process this benefit request on my behalf.” When the Orchestration Agent delegates to the Verification Agent, that agent gets a new letter that says “Authorized by the Verification Agent, acting on behalf of the Orchestration Agent, who was authorized by citizen Adam.” Every hop in the chain is recorded, cryptographically.

The RFC 8693 token exchange flow with full provenance preserved at every step:

The practical implementation of this looks like what organisations should build/adopt: a Security Token Service that issues short-lived, single-hop JWTs. Each agent, before calling another agent or system, presents its current token and its target audience to the STS, which validates the chain and mints a fresh token scoped only for that next hop. A token issued for Agent A to call Agent B is useless if intercepted; it can’t be replayed against any other service.

What the act claim looks like inside a JWT at the final hop:

The sub claim always stays as the citizen. The nested act claims form a verifiable history of every delegation step. Downstream systems can enforce policies against the full chain not just the immediate caller.

A proposition of what “Secure Agentic AI Identity” should looks Like

If we were to map all this out, a basic version of the architecture would probably look something like this:

1. Give Every Agent a Verifiable Identity, Not Just a Service Account

The first step is separating the workload identity from the agent identity. Just because Agent X runs inside a Kubernetes pod doesn’t mean it should inherit the pod’s service account as its identity. Each deployed agent should be registered in an Agent Registry and issued its own identity, cryptographically bound to the workload it runs on.

Tools like SPIFFE/SPIRE are excellent here, they give workloads cryptographically signed identity certificates (SVIDs) that can be used to bootstrap agent-specific tokens from an STS. The agent gets an identity it can prove, not just a credential that was handed.

2. Never Let Tokens Outlive Their Purpose

Long-lived API keys and service account tokens that never rotate are a gift to attackers. With AI Agents, the answer is clear: tokens should be short-lived and scoped to a single hop.

If a session involves five agent-to-agent calls, that’s five separate token exchanges, each producing a token valid for minutes and only for its intended recipient. The STS becomes a critical control plane, and every exchange is an opportunity to enforce policy: Does this agent have the right to delegate to that agent? Does the actor chain make sense for this request?

3. Preserve the Full Actor Chain

It’s not enough to give agents good credentials for calling downstream systems. We need to carry the full context: who initiated the session, through which agents, with what stated intent, all the way to the final API call or database query.

When the downstream system (payment system in our example) receives a request, it should be able to see a JWT claim chain that reads: [citizen → orchestration-agent → verification-agent → review-agent]. That’s not just nice-to-have. It’s what makes the process fully auditable. It’s what makes compliance audits defensible. It’s what lets us write policies that say “a payment can only be triggered when the chain originated from an authenticated citizen, not from a fully automated pipeline with no human touchpoint.”

4. Apply Least Privilege – Dynamically

AI agents are non-deterministic in their behavior, which means static permission sets are inherently over-privileged. The answer isn’t to give agents broad access and hope they behave, it’s Just-in-Time (JIT) access and Zero Standing Privileges combined with scope constraints in the token exchange flow.

When an agent requests a token to call a specific tool, the STS can evaluate: Is this the right agent for this tool? Is the human in the actor chain authorized to trigger this action? Does the current session context justify this scope? This is where the access control layer becomes adaptive rather than static.

5. Monitor the Actor Chain, Not Just the Endpoint

Security operations teams are used to monitoring API calls. With agentic AI, you need to monitor the full lineage of every call. Who initiated? What agents were in the chain? What tools were invoked, in what order, with what authorization decisions?

This turns your SIEM or observability platform into something more like a behavioral analysis engine for AI agents. Anomaly detection shifts from “this service account called an unusual API” to “this agent session deviated from expected patterns for this type of task.”

The Governance Layer

In my experience working with organizations on IAM, one thing tends to hold true across the board: security controls are only as effective as the governance and visibility layers supporting them.

From an identity security point of view, a useful way to think about agentic AI is as three stacked layers:

If your organisation try to jump straight to Layer 3 – governance dashboards, audit reports before Layer 1 is even in place. It rarely works out well. And the reason is straightforward: you can’t govern what you can’t identify.

To make a real difference, I beleive we shoudl start with a reliable source of truth, an Agent Registry (we can call it a Directory for Agent) that tells you which agents exist, what they’re authorized to do, where they’re deployed, and who owns them. Without that foundation, issuing meaningful identities becomes difficult, enforcing policies becomes inconsistent, and auditing becomes largely theoretical.

Let’s talk ownership: the security admin sets the policy, the Dev team builds the agent, but it’s the business owner who owns the “why” behind using it. Once it’s built, we need to talk about agent identity lifecycle management. Agents have their own version of JML, models get upgraded, vendors swap out, and purposes shift. If we aren’t careful, we get “zombie agents“: AI agents quietly running with live credentials long after their job is done. It’s essentially the AI version of the classic “orphan account” problem, but given the scale of agentic AI, it has the potential to become a much larger attack surface if we don’t take it seriously.

Perhaps the most important shift, though, is treating agent identity as a natural part of the software development lifecycle kind of “Identity By design“. If teams are spinning up agents outside of identity provisioning processes, the problem compounds quickly. The goal (and this is easier said than done) is to make the secure path, the path of least resistance for developers. That usually means integrating agent identity management directly into the platforms, SDKs, and deployment pipelines they’re already using.

My Practical Recommendations for Getting Started

You don’t have to solve all of this at once. Here’s how I’d prioritize:

Start with inventory Before you can secure agent identities, you need to know what agents exist. Do an audit. You will be surprised by what’s running.

Establish your identity foundation first Get workload identity (SPIFFE/SPIRE) in place. This is the cryptographic root everything else is built on.

Instrument your token exchange Even before you have full policy enforcement, getting every agent-to-agent call to go through an STS gives you visibility. Visibility is the prerequisite for control.

Build provenance into your audit logs Start logging the full actor chain on every significant action. This pays dividends immediately when something goes wrong.

Enforce least privilege iteratively Start with broad scopes, then tighten. It’s easier to relax a scope than to recover from an over-privileged agent incident.

Enjoy !

شكرًا / Thank you / Merci

Reference

• RFC 8693 – OAuth 2.0 Token Exchange
• RFC 7523 – JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
• Solving the Identity Crisis for AI Agents
• What is A2A
• How to Secure Agents using OAuth — Jared Hanson (Keycard, Passport.js)
• Can SPIFFE Solve the Secret Zero Problem?