One Chat, Three Specialists,
Zero Standing Privileges

00 The Setup

The user types one sentence into a chat box.

Three different systems. Three different identity domains. Three different places where something could go wrong. And the agent that fields this request is not running in your data center. Anthropic owns the model. Anthropic owns the inference layer. You own the agent loop, the tools, the secrets, and the authorization decisions. The model runs on someone else's infrastructure. Everything else lives in your tenant.

That last point is the one a lot of teams are about to learn the hard way. Hosted agents are showing up in enterprise architectures faster than the identity controls around them. Microsoft's Copilot Studio agents, AWS Bedrock agents, IBM watsonx Orchestrate, and Anthropic's own managed agents all share the same risk shape. The model is somebody else's. The actions are yours.

In 2024, this usually would not have been one engineer writing a script and calling it done. It would have been a line-of-business request turned into an integration project across application developers, IAM engineers, security architects, compliance reviewers, and the system owners for Verify, Entra ID, and the banking stack. Somewhere in that build, the path of least resistance would win: a few service principals, a couple of long-lived client secrets, maybe an automation account for the database, and broad API permissions justified as “temporary” so the workflow could ship. Those credentials would end up in CI, vaults, runbooks, containers, or environment files, and over time the standing privilege would become the architecture. Once that happens, the real authority no longer belongs to the user who asked for the action. It belongs to whatever non-human identity the system was allowed to keep.

In 2026 we can do this differently. This post walks you through exactly how.

01 Meet Charlie

Charlie, our AI concierge, is a Claude-hosted agent running on Anthropic's infrastructure. Charlie speaks English. Charlie has three tools:

Each of those three specialists is itself a Claude-hosted agent with its own tools pointed at its own API. Charlie is a supervisor. When the user types one sentence, the model inside Charlie decides which specialists to call, in which order, and Charlie dispatches.

The interesting bit is not the routing. Anthropic has had tool use for a while, every agent SDK can draw this picture. The interesting bit is what flows through each hop, and what stops the hop cold when policy says no.

02 Following One Hop From Start to Finish

Pick the hardest case. The user asked Charlie to create an account in Microsoft Entra ID. Most enterprises will recognize this one because most enterprises live in Entra. Here is what happens between Charlie and the actual Microsoft Graph call.

That is two nested token exchanges per specialist, three specialists, six total. The two specialists that hit databases or sensitive APIs add a Vault authorization on top of that. Every one of these is audited. Every one of them can be independently denied. And every OBO token carries an act.act claim that looks like this:

{
  "sub": "rgraham@us.ibm.com",
  "act": {
    "sub": "spiffe://ibm-verify-lab.com/copilot-agent",
    "act": {
      "sub": "spiffe://ibm-verify-lab.com/concierge-agent"
    }
  },
  "scope": "entra:users:write",
  "authorization_details": [
    { "type": "urn:smt:agent:copilot",
      "operationDetails": {
        "action": "graph_user_create",
        "upn": "sarah.smith@example.com" } }
  ]
}

Read it as nested wrappers around the user. The sub at the top of the JWT is the user, the original delegator. The first act wraps that with the most recent actor (Copilot). The deeper act.act is the prior actor in the chain (Concierge). So the delegation reads: Copilot acts on behalf of Concierge, which acts on behalf of the user. Every link is traceable. Every link had a policy decision. This is not a flow diagram. This is a working implementation, live. You can decode the token at jwt.io and see it. - If you follow me on linkedin, come find me at a conference or message me for a live demo! 

03 What Happens When Charlie Oversteps

Type: "Delete sarah.smith@example.com permanently."

Claude inside Charlie picks up on "delete". Tool use fires. Concierge does the first token exchange with its chain scope and a RAR shaped like { target: "iia", op: "delete" }. Verify's access policy sees the scope and the RAR and matches a Tier 4 rule: deletion is blocked for this tenant.

The token exchange returns denied. No OBO token is ever issued. IIA's /api/a2a is never called. The SCIM endpoint is never touched.

That is the difference.

Without the policy decision at the token exchange endpoint, your only enforcement is whatever your agent code remembered to do. With it, the authorization logic lives in a separate system that you can change without redeploying the agent, that an attacker with code execution in the agent cannot bypass, and that produces an audit record regardless of what the agent intended.

04 Why All This Work Is Worth It

The world is full of "just plug your agent into the endpoint" stories. Pick your favorite agent SDK, point it at the API, it works. Then a month later a customer asks who authorized the agent to delete that customer record at 3 AM. Then the answer is "the service account." Then the answer is "I rotated the key." Then the answer is "I think we have logs somewhere." Then you move to something like this.

The architecture in this post answers three questions by construction:

An Audit Property You Cannot Forge

One thing falls out of this architecture that you do not get when you bolt agents onto an API: a write trail that three independent systems agree on, written by three independent processes, joined by IDs that none of them invented locally.

Take banking's transfer_funds as the canonical case. The committed row stamps three things at commit time: the IBM Verify jti from the OBO that authorized the call, the OAuth grant_id that ties this OBO back to the user's original session, and the ephemeral Postgres username that ran the SQL. Those same three IDs appear independently in IBM Verify's SSO event log (the original token issuance), in HashiCorp Vault's audit log (the lease that produced the Postgres user, with the full RAR claims), and in Postgres's log_statement=mod output (the SQL run AS that user). The IIA SCIM writes have an analogous three way correlation against IBM Verify's tenant audit. Different destination, same property.

Three independent writers. Three independent stores. The same three IDs. To forge a record after the fact, you would have to convince all three log stores to lie in agreement. That is the audit posture a CISO actually wants, and you do not get it by writing more application code. It falls out of building on identity primitives that already cooperate.

05 What's Next: A2A on the Envelope

The wire format we use for Concierge to specialist is bespoke: Bearer token in Authorization, chain context in X-Chain-* headers, JSON body. Works fine.

The industry is converging on an A2A protocol that standardizes the envelope: JSON-RPC 2.0, task lifecycle, signed agent cards, and so on. None of that changes the security model. The token exchange, the RAR, the SPIFFE attestation, and the JWKS-validated Vault path all live below the envelope.

Adopting A2A would let a Microsoft Semantic Kernel agent, a watsonx Orchestrate agent, or any future protocol compliant client drive the Identity Agent or the Copilot specialist with no custom client code. Point it at /.well-known/agent-card.json and it works, governed identically. The hosted agent vendor changes. The trust fabric does not.

06 The Headline

The hard part of an AI agent is not the agent. It is making sure that when the agent is wrong, confused, compromised, or manipulated, the damage it can do is bounded by a system outside of its control.

Charlie did not just onboard sarah.smith@example.com across IBM Verify and Microsoft Entra ID and move money into her trading account. Charlie proved that, in 2026, you can give a hosted AI supervisor real authority over your identity tenant, watch it chain across three target systems, approve every privileged write on your phone (sometimes via a Verify access policy that fires step-up, sometimes via the agent's own HITL gate), mint database credentials that exist for five minutes and gate the actual SQL, and have an auditable, revocable, bounded, policy enforced record of every single step.