Govern natively, federate outward, and what breaks across trust domains
By now the agent has its own identity and you can carry that identity through a chain of calls. The next question is where the rules live. Who decides what an agent is allowed to do, and where does that decision get made?
Two answers, and they are load-bearing for everything above them.
The authorization server is the control plane
The authorization server is the strategic control plane for agent identity. It is the thing that issues identities, exchanges tokens along the delegation chain, and decides what each token is good for. Everything in the first three posts routes through it. Treat it as core infrastructure, not as a library you import into one service.
Fine-grained authorization belongs in an externalized policy layer, the category of policy engines, not scattered through application code. The reason is the non-determinism from Part 1. When an actor picks its actions at runtime, the question “is this specific call allowed” has to be answered at runtime, against current context, by something that can see the whole picture. Bury that logic inside each service and you get inconsistent decisions, no central place to change a rule, and no way to reason about what your agents can collectively do.
You will not get everyone on one identity provider
Here is the constraint every large enterprise hits. You will not get every identity provider in the org to converge on one system. There is a directory for employees, a workload identity system in the platform team, a different one in the cloud account a business unit spun up, and three more from acquisitions. Telling all of them to standardize is a multi-year project that never finishes.
So do not try. Govern agent identity natively in one place, and federate outward to the identity providers and workload identity systems that already exist.
Figure 1. Govern agent identity in one control plane, federate trust to the IdPs, OIDC providers, and workload identity systems already running. The boundary on the right is where this stops working.
This is not a vendor invention. It mirrors the compose-existing-standards approach in the public IETF draft authored by contributors from AWS, Zscaler, Ping, OpenAI, and others (draft-klrc-aiagent-auth). That draft composes SPIFFE, WIMSE, OAuth, and OIDC rather than inventing a replacement protocol. The bet is the same one you should make: the substrates already exist, so the job is to govern on top of them, not to relitigate them.
Concretely, federation leans on open substrates. SPIFFE and SPIRE attest workloads so an agent’s underlying compute can prove what it is. WIMSE carries workload identity across systems. OIDC federates trust between identity providers so a token from one is honored by another. None of this is new. The work is composing it under a single governance plane.
Now name the frontier
Every single-control-plane model from Part 2 works for one reason. Entra Agent ID, Bedrock AgentCore, and the open-source patterns in the same shape all maintain identity continuity inside one trust domain. One platform issues the identity, governs it, and can see every hop, because every hop happens on home turf.
The hard problem starts the moment an agent has to act somewhere its issuing platform does not reach. Across organizations. Across clouds. In an open ecosystem of discoverable tools and agents that no single platform owns. The control plane that made everything tractable has no authority on the other side of that boundary. The token it issued may mean nothing there. The registry that was the source of truth does not span the gap.
That cross-trust-domain case is where the field is genuinely unsolved. The standards being composed today are the most credible path toward it, but no one has shipped a clean answer to “my agent, with my identity, acting under my governance, in a domain I do not control.” Anyone who tells you this is solved is selling inside a single trust domain and calling it the world.
Controls should scale with blast radius
One more lens before you leave this. Do not apply the same controls to every agent. Controls should scale with an agent’s capability and blast radius. CoSAI’s capability-impact framing runs from a low-risk FAQ lookup bot at one end to a high-risk agent executing financial operations at the other. Same identity foundation underneath both. Very different control surface on top.
The FAQ bot can run on coarse scoping and light review. The agent that moves money needs tight task scoping, a short-lived grant, human-in-the-loop on sensitive operations, and an audit trail you would show a regulator. Uniform controls either strangle the harmless agents or under-protect the dangerous ones. Tier them by what they can break.
Figure 2. Controls scale with blast radius. A low-risk FAQ bot needs coarse scoping and light review. A high-risk agent that moves money needs tight scoping, short-lived grants, human review on writes, and a regulator-grade audit trail.
The take-away
Centralize governance of agent identity in one control plane. Federate trust outward to the identity providers and workload identity systems your org already runs, because they are not going to converge. Push fine-grained authorization into an externalized policy layer that decides at runtime. And size your controls to each agent’s blast radius, not to a single org-wide default.
Then be honest about the edge. The single-control-plane model holds inside one trust domain. Crossing domains is the open problem, and it is where the next few years of this field will be decided.
There is one dimension left, and it runs underneath all of this. An identity is not a static record you write once. It is something you provision, scope, revoke, and re-evaluate over the agent’s whole life. The last post is about treating identity as a lifecycle, and why that is what finally answers the non-determinism problem this series opened on.
The post Govern natively, federate outward, and what breaks across trust domains appeared first on DataRobot.