The Identity Orchestration Layer for Hybrid AI

I can tell you how many employees almost any company has. Ask how many machine identities it runs, and the security team goes quiet. The honest answer is usually “a lot more than we track.”

The numbers back that up. CyberArk’s 2025 report found machine identities outnumber humans by more than 80 to 1. Rubrik puts a typical enterprise nearer 45 to 1. Entro Labs measured 144 to 1 in cloud-native and DevOps environments, up from 92 to 1 a year earlier, roughly 44% growth in twelve months. AI agents push this higher still: every agent needs its own identity, and multi-agent systems spawn more of them by the hour.

After scaling LoginRadius to over a billion users, I watched this fragmentation quietly wreck security postures. Human logins live in Azure AD or Okta. Service accounts scatter across AWS and GCP. Kubernetes workloads run on SPIFFE. AI agents get hand-rolled auth. Edge devices sit on certificates. Each system runs on its own, with its own policy language and its own logs.

Fragmentation is not just messy. It compounds risk. In the 1990s, one compromised human account exposed one attack surface. Today one compromised developer laptop can expose dozens: a cached Azure AD session, a GitHub token with write access, an AWS CLI role, a Kubernetes config, a SPIFFE agent socket, and whatever API keys the local AI agents hold. Every machine identity is an authentication endpoint, a set of permissions, a lifecycle to manage, and an audit trail to keep. Multiply that by 80, and the blast radius of a single mistake gets very large.

The result: nobody can answer “what can this AI agent actually reach?” or “who authorized this cross-cloud transfer?” without hours of log-diving. That gap is exactly what an identity orchestration layer closes. This is a plain-language guide to what it is and how to build one.

What an identity orchestration layer actually is

Plain version: it is a control plane that sits above all your identity providers and gives you one place to write policy, make access decisions, and read the audit trail. It does not replace Azure AD, Okta, AWS IAM, or SPIFFE. It coordinates them.

Think of it as a conductor. The identity providers are still the musicians. The orchestration layer decides who plays when, and keeps one score everyone follows.

People confuse this with identity federation, so it is worth drawing the line. Federation connects identity providers so a human logs in once and reaches many apps (“sign in with Google”). It is mostly about humans and single sign-on. Orchestration is broader: it covers humans, service accounts, and AI agents; it makes the authorization decision itself instead of handing it off; and it produces a single audit trail across every provider.

Federation answers “let this person log in.” Orchestration answers “let this agent, acting for this person, read one specific table in another cloud for the next fifteen minutes, and log the whole chain.”

The five jobs it does

• One policy engine. One policy language for every identity type. Most teams use Open Policy Agent (OPA) and its Rego language because it is provider-neutral and lives in Git. You write a rule once, and it applies whether the requester is a person, a workload, or an agent.
• Identity translation. A single identity is mapped into whatever each target expects: an Azure AD user becomes an assumed AWS role here, an impersonated GCP service account there, a SPIFFE identity for a Kubernetes workload. The requester never juggles five credential formats.
• Unified audit. Every action carries a trace ID, so you can follow one human authorization through the service account it triggered to the agent that finally touched the database.
• Dynamic authorization. Decisions factor in context: resource sensitivity, time, location, a risk score, and how deep a delegation chain runs. The answer can be allow, deny, or require human approval.
• Lifecycle. When someone joins or leaves, provisioning and deprovisioning fan out to every system at once, so you stop leaving orphaned accounts and stale keys behind.

Here is a single OPA rule set covering both people and agents:

# One rule set, applied to people and agents alike
default allow = false

allow if {                       # a person, in work hours, on a managed device
    input.identity.type == "human"
    input.resource.sensitivity == "high"
    has_mfa(input.identity.id)
    device_compliant(input.context.device_id)
}

allow if {                       # an agent, only via a valid human-rooted delegation
    input.identity.type == "ai_agent"
    valid_delegation_chain(input.identity.delegation_chain)
    human_in_chain(input.identity.delegation_chain)
}

deny if {                        # never let an agent touch PII without a human sign-off
    input.identity.type == "ai_agent"
    input.resource.contains_pii
    not has_human_approval(input.context.request_id)
}

That one file is what you would otherwise rewrite as Azure Conditional Access rules, AWS IAM JSON, GCP bindings, and Kubernetes RBAC, four separate times, by hand, and then pray they stay in sync.

Why AI agents break the old model

Human IAM is largely solved. Federation, SSO, and MFA are mature. AI agents are where the old design cracks.

An agent is neither a person nor a plain service account. It acts on behalf of a person, often chains to other agents, and appears and disappears in minutes. It needs three things legacy IAM was never built to give it.

Short-lived, scoped credentials. An agent should never hold a long-lived key. The pattern that works is a token that lasts minutes, scoped to exactly one resource and action. SPIFFE and SPIRE do this well for workloads. SPIRE runs as a certificate authority, verifies a workload through kernel-level attestation rather than a shared secret, and issues a short-lived SVID (an X.509 or JWT identity document). Because SPIRE can expose an OIDC endpoint, a workload can trade its JWT-SVID for a short-lived AWS or GCP token with no static credential stored anywhere.

Delegation you can trace. When Alice asks an agent to run a report, the agent should carry a signed delegation that says “acting for Alice, these permissions only, expires in one hour, at most two hops deep.” The orchestration layer verifies that chain on every request, and can only ever grant a subset of what Alice herself holds.

Standard agent auth. This part is finally standardizing. The Model Context Protocol (MCP), the emerging standard for how agents connect to tools and data, revised its authorization spec in 2025 to treat MCP servers as OAuth 2.1 resource servers. Agents authenticate with the Authorization Code flow plus PKCE, and Resource Indicators (RFC 8707) let a client request a token scoped to one specific server instead of a broad “access everything” grant. The November 2025 revision added step-up authorization, so a server can demand more scopes mid-session. The point: you no longer have to invent agent auth. Build on OAuth 2.1 and MCP.

A short audit trace shows the payoff:

trace-abc-123
  alice@company.com    authorized the workflow    10:00:00
  workflow-engine-sa   started the agents          10:00:05   (for alice)
  agent-research-01    queried the database        10:00:15   (for alice, via workflow-engine-sa)

When someone asks “who authorized this agent to read customer data,” you answer in seconds, with the full chain, instead of stitching three log sources together by hand. For a deeper treatment of agent-era identity design, see my piece on building identity infrastructure for the autonomous enterprise.

One request, many clouds

Identity translation is the piece that sounds abstract until you watch it run. Say an analyst named Alice kicks off a job that needs an object in AWS S3, a query against GCP BigQuery, and a file in Azure Blob Storage. Without orchestration, Alice (or her agent) needs three separate credentials in three formats, each provisioned and rotated by a different team.

With an orchestration layer, one identity goes in and the layer does the rest. It validates Alice against her home provider, works out which resources the job touches, then translates her identity for each one: an assumed role with short-lived STS credentials for AWS, an impersonated service account with a five-minute token for GCP, a managed identity for Azure. It grants only the intersection of what Alice holds and what the job actually needs, then logs the full chain under one trace ID. Alice sees a single request. Security sees one clean record instead of three.

The same mechanics apply when the requester is an agent rather than a person. The only differences are shorter token lifetimes and a delegation chain that has to trace back to a human.

One policy, many systems

The hardest part in practice is that every provider speaks a different policy dialect: Azure Conditional Access in a UI, AWS IAM in JSON, GCP in bindings and conditions, Kubernetes in RBAC YAML, OPA in Rego.

The move that keeps this sane: write policy once in an abstract, readable form, store it in Git, and compile it down to each provider’s format. Some rules, like an agent behavioral check, have no equivalent in Azure Conditional Access, so the orchestration layer enforces those itself. You get one source of truth, version history, and the ability to test a policy before it ships.

You do not build all of this from scratch. OPA, SPIFFE/SPIRE, and your existing identity providers are the load-bearing pieces. The orchestration layer is the glue, plus the single policy and audit surface on top.

The joiner and leaver problem, solved once

Lifecycle is the least glamorous of the five jobs and the one that fails most often. When an employee is hired, someone provisions an Azure AD account, an Okta assignment, an AWS user, a GCP service account, a Kubernetes token, and an entry in the agent registry. When they leave, all of that is supposed to be revoked the same day. In fragmented environments it rarely is. Orphaned service accounts and stale keys are how attackers get a quiet foothold months after the person who created them is gone.

Because the orchestration layer already knows every downstream system a person maps to, deprovisioning becomes one action that fans out everywhere at once: disable the directory account, kill the sessions, delete the access keys, revoke the agent delegations. No system is left holding a live credential for someone who walked out the door. The same fan-out applies to a retired agent, which matters more as agents become the majority of what you provision.

Making it work in production

Three honest tradeoffs before you commit.

It adds latency. Every request now passes through one more layer. Keep it under roughly 50 milliseconds by caching aggressively: decisions for seconds, resolved identities for a minute, compiled policy for a few minutes.

It is a new single point of failure. If the orchestration layer is down, access breaks. Run it multi-region, fall back to cached policy when a provider is unreachable, and never block a request on writing an audit log.

It is easy to over-scope. Do not onboard every system at once. A sane order: stand up the policy engine against your main human IdP first, add AI agent delegation next (the part that actually hurts today), then extend to a second cloud, then everything else. Each stage pays off on its own.

The takeaway

The machine-to-human ratio is not going back down. It sits somewhere between 45 and 144 to 1 depending on how cloud-native you are, and every agent you deploy pushes it up.

You cannot govern that with a pile of disconnected identity systems and a promise to check the logs later. An orchestration layer gives you one policy language, short-lived and scoped credentials for agents, and a single audit trail that follows a human authorization all the way to the machine action it set off.

Start where it hurts most: AI agent authorization. If you cannot answer “who let this agent do that” today, fix that first, before a breach makes you answer it under pressure.