A Deputy CISO asked me the question every identity team should be asking. The answer lives inside your existing identity ecosystem — if it has the depth to support it.
Last week I was presenting IBM’s Agentic Runtime Security approach to a customer — walking through how we secure non-human identities, how Token Exchange and RAR fit into multi-agent pipelines, and how Identity Protection discovers agents that aren’t in policy. Midway through, the Deputy CISO stopped me and asked the question:
“Can we actually secure our AI agents
without spending more money
or buying yet another product?”
It’s the right question. Every enterprise security leader is staring at the same budget pressure: agentic AI is arriving faster than procurement cycles, and the last thing anyone wants is another point solution bolted onto an already overstretched stack.
My honest answer? It depends — on your identity ecosystem. Not just your IDP, but the full stack around it: your secrets management, your workload identity infrastructure, your threat detection. The answer lives inside your existing ecosystem — if it has the depth to support what agentic AI demands.
The ability to secure agentic AI — to control delegation, scope credentials, enforce granular policies, and maintain audit trails across multi-agent pipelines — is fundamentally an identity problem. Not a network problem. Not an endpoint problem. An identity problem.
Which means the answer to “can I do this without buying more?” hinges on your full identity ecosystem: who is your IDP, what secrets management do you have, what workload identity infrastructure is in place, and can your stack discover and govern agents you didn’t provision?
If your ecosystem was built with deep open standards support — Token Exchange, Rich Authorization Requests, workload identity, continuous evaluation — then yes, you likely already own the infrastructure to secure agentic AI. With IBM Verify, HashiCorp Vault, SPIFFE/SPIRE, and IBM Verify Identity Protection, enterprises have a full solution stack — not a patchwork of point products, but an integrated ecosystem built on open standards. If your ecosystem doesn’t have that depth, you have a gap that no amount of configuration will close.
The Core Question
This isn’t about buying more. It’s about whether what you already own has the depth to handle what’s coming. IBM Verify + Vault + Identity Protection gives you the full pattern: secrets management, delegated authorization, agent discovery, and continuous enforcement. Most enterprises don’t know whether their ecosystem can do this — because they’ve never had to ask.
If you’re an IBM Verify customer, the honest answer is: you likely already have what you need.
IBM’s lineage with Token Exchange (RFC 8693) runs deep. This isn’t a feature we bolted on when agentic AI became the conversation. The pattern — take one token, validate it, mint a new scoped token for a downstream service or agent — has been core to IBM’s identity platform through multiple generations:
The Lineage
TFIM (Tivoli Federated Identity Manager) → Verify Access Federation → Verify Access OIDC Provider (cloud-native containerized OP) → IBM Verify SaaS. Token exchange, delegated authorization, and act-on-behalf-of patterns have been operationalized in enterprise environments across this platform lineage for over a decade. Each iteration deepened the standards support — from SAML federation through OAuth/OIDC API protection to the full RFC 8693 and RFC 9396 implementation in today’s SaaS platform.
That matters enormously when you’re talking about multi-agent pipelines. An orchestrator agent needs to delegate a constrained, scoped credential to a sub-agent — without passing secrets, without over-permissioning, and with a full audit trail. This is exactly the pattern Token Exchange was designed for. And IBM Verify has been doing it at scale since before anyone was talking about agentic AI.
Here’s where the Deputy CISO’s question gets uncomfortable — not for IBM Verify customers, but for everyone else.
When you evaluate what’s actually required to secure agentic AI at the identity layer, most identity providers fall short. Not because they’re bad products — but because the agentic AI use case demands capabilities that were never part of their original design.
| Capability | What Agentic AI Demands | Industry Reality |
|---|---|---|
| Token Exchange (RFC 8693) | Native, mature implementation for secure delegation across agent chains | Most IDPs offer limited or preview-only support — not production-hardened |
| Rich Authorization Requests (RFC 9396) | Structured, machine-readable authorization context in every token | Rarely supported. Most IDPs still rely on flat scope strings |
| Context-Aware Authorization Policies | Dynamic policy evaluation based on agent behavior, risk signals, and business context | Typically rule-based and static — not adaptive to agent behavior |
| Granular Token Scoping per Agent | Each agent in a chain receives only the permissions it needs for its specific task | Most IDPs scope at the application level, not the agent level |
| Shadow Agent Discovery | Continuous discovery of agents operating without registered identities or policy bindings | Typically absent. Network monitoring doesn’t catch agents the way it catches users |
| Open Standards Depth | RFC 8693, RFC 9396, SPIFFE, CAEP/SSF, HILT/OBO flows — implemented together, not selectively | Most IDPs support some standards selectively — few implement the full stack |
The depth of open standards implementation is where the gap becomes a chasm. Most competitors have made tactical bets on proprietary agent frameworks — walled gardens that lock customers in and lock interoperability out. The RFCs will outlast every vendor framework. And the IDPs that built on them early have a structural advantage that can’t be replicated overnight.
Ask Your IDP
If you’re not on IBM Verify, ask your identity provider three questions: Do you support RFC 8693 Token Exchange natively? Do you support RFC 9396 Rich Authorization Requests? Can you discover and bind policy to agents you didn’t provision? If the answer to any of those is no — you have a gap.
Token Exchange gives you the mechanism for secure delegation. Rich Authorization Requests (RFC 9396) give you the intelligence layer on top of it.
With RAR, your authorization tokens aren’t just carrying scope strings — they’re carrying structured, machine-readable authorization context. What data the agent is allowed to access. Under what business conditions. For what purpose. Expiring when. This transforms a generic access token into a purpose-bound credential that a downstream API or agent can actually reason about.
read:data but structured authorization_details that encode purpose, constraints, and conditions.When you combine Token Exchange + RAR + IBM Verify’s policy engine, you get the last mile of agentic AI security — making sure that by the time a token reaches a tool call, a database query, or an API invocation, it carries exactly the rights needed and nothing more.
This is where conversations get quiet.
“How many AI agents are running in your environment right now
that aren’t in policy, aren’t using granular controls,
and weren’t sanctioned by your security team?”
Most CISOs don’t have a clean answer. Shadow IT was bad enough with SaaS apps. Shadow agents are the next frontier — and they move faster, have API access baked in, and don’t surface in traditional network monitoring the way a user would.
IBM Verify Identity Protection is purpose-built for this. It surfaces agents operating on your network that don’t have registered identities, aren’t bound to policy, and represent uncontrolled exposure points. It’s the discovery layer that makes everything else possible — because before you can secure your agents, you have to know your agents.
The Hard Truth
You cannot enforce policy on agents you don’t know exist. Discovery isn’t a nice-to-have — it’s the prerequisite for every other control in the chain.
Put it all together and there’s a clear operational sequence. Each step depends on the one before it:
Discovery → Policy Binding → Token Scoping → Continuous Enforcement.
That’s the full pattern. And for IBM Verify customers? Most of the infrastructure to execute it is already there. Not as a future roadmap item. Not as a preview feature. As production-ready capability built on open standards that have been hardened across enterprise deployments for over a decade.
Can you secure agentic AI without buying another product?
If you’re on IBM Verify — yes. And here’s the playbook: discover every agent on your network with Identity Protection, bind them to policy, scope every delegated token through Token Exchange and RAR, manage secrets dynamically through Vault, and enforce continuously through CAEP. The infrastructure is already in your ecosystem.
If you’re on something else — ask hard questions about RFC 8693 and RFC 9396 support before you assume you’re covered. Ask about agent discovery. Ask about secrets management integration. The gap between “we support OAuth” and “we support secure agent delegation with structured authorization context, dynamic secrets, and continuous enforcement” is enormous. And it’s the gap your agents are currently running through.
The answer isn’t buying more.
It’s using what you already own
to its full depth.