Author: Amy Marion

Blog
Access Management

Why Cross-Cloud Federation for Workload Access Is So Hard

Micha Rave's avatar
Micha Rave CEO and Co-Founder

Table of Contents

Most workloads no longer live in one cloud. A service runs in AWS, calls a database in GCP, and pulls a secret from an Azure vault. Each of those hops needs access. And access means identity.

For humans, we solved this. Single sign-on, one IdP, federated trust. For workloads and AI agents, the tools now exist too, but using them across clouds is hard enough that most teams still fall back on long-lived secrets. Cross-cloud workload access is still stitched together by hand, and it breaks in predictable ways.

Here is why it is hard.

Every cloud is its own trust island

AWS has IAM roles and STS. GCP has service accounts. Azure has managed identities and Entra. Each was built to establish trust inside its own boundary. None was built to trust the others.

So the moment a workload needs to reach across clouds, there is no shared notion of who it is. The identity that AWS understands is meaningless to GCP.

Tokens do not translate

Federation on paper means exchanging trust through OIDC or SAML. In practice, token formats and claim semantics differ across providers. An identity assertion that satisfies one cloud’s authorizer maps poorly, or not at all, onto another’s policy engine.

You end up writing custom claim mapping for every pair. It is brittle, and it drifts.

What it actually takes to federate

Take a concrete case: Kubernetes pods that need to reach all three major clouds. Pods run in EKS, AKS, or GKE, and each has to authenticate to the other two providers. That alone is a three by three matrix, and every off-diagonal cell is its own build.

Each cloud speaks a different dialect:

  • AWS. An OIDC provider plus a role trust policy pinning subject and audience, assumed via AssumeRoleWithWebIdentity — that covers inbound trust. Outbound just got easier too: the new IAM Outbound Identity Federation issues a short-lived JWT via GetWebIdentityToken, no stored key needed.
  • Azure. An app registration with a federated identity credential mapping issuer and subject, plus RBAC roles.
  • GCP. A workload identity pool with attribute mappings, feeding a two-hop exchange: STS, then service account impersonation.

Same goal, three mental models, and the details bite: a separate token per target cloud, each with its own audience; claim matching that has to be exact; token lifetimes that disagree across clouds; and failures that surface as a bare 403 with no real signal.

None of this ships out of the box. AWS’s outbound federation closes its half of the gap, but the other five directions in the matrix, and every receiving side, still have to be built by hand.

And then you maintain it forever

Building it once is not the real cost. Keeping it alive is.

  • Teardown mirrors setup. Roles, providers, pools, and credentials all need undoing, across all three clouds. Cleanup takes as long as the build.
  • Recreate a cluster and trust breaks. The OIDC issuer changes, and every federated credential pointing at the old one has to be re-registered.
  • Config drifts in three dialects. Trust lives in separate IaC per cloud, and drift stays invisible until access silently breaks.
  • Hardening never ends. Tighter subject matching, scoped roles, dedicated pools per cluster: every improvement is more config to own.

Multiply that across every workload, cluster, and cloud pair, and cross-cloud identity quietly becomes a full-time job for a platform or security team.

Workloads are ephemeral

Containers scale up and down. Functions spin up for milliseconds. Autoscaling groups churn constantly. Static, long-lived credentials do not fit this world, but that is exactly what most cross-cloud setups fall back on.

The identity has to be issued at runtime, scoped to the moment, and gone when the work is done. Very few federation schemes do this cleanly across boundaries.

Secrets creep back in

When federation gets too painful, teams take the shortcut. They drop a long-lived key or a service account JSON into an environment variable and move on. Now you have a static secret crossing cloud boundaries, and it is the single most common root cause of breach.

The hard path gets abandoned, and the insecure path wins by default. Even where native federation now exists, migrating an existing estate is a project, not a switch: hundreds of integrations, each with its own owner, deadline, and risk tolerance. Under pressure, teams keep the old long-lived key running as a fallback, or never get around to retiring it, and the legacy secret quietly persists alongside the new setup.

No unified audit, no unified policy

Even when access works, visibility does not. Each cloud logs its own events in its own format. There is no single answer to “which workload accessed what, in which cloud, and why.” Policy is just as fragmented. Every provider speaks a different IAM dialect, so intent has to be re-expressed everywhere and stays consistent nowhere.

At the scale of modern NHIs and AI agents, which dwarf the number of humans, none of this can be managed by hand.

How Hush solves this

Hush puts one identity-based access layer across every cloud. Workloads and agents get a single identity, not a pile of per-cloud credentials.

  • One trust plane, not n by n. Hush brokers access across clouds through standards-based token exchange, so you stop hand-building trust between every pair.
  • JIT by default, no static secrets. Access is issued at runtime, scoped, and short-lived. Nothing long-lived crosses a boundary.
  • One inventory, one audit trail. Every agent and workload is accounted for, and every access is logged in one place, across every cloud.
  • Policy, not keys. Express intent once. Enforce it everywhere.

Cross-cloud federation is hard because the clouds were never built to trust each other. Hush gives them a common layer that was.

Let’s look deeper into how it’s done.

Hush, cloud federation done right

Hush becomes the one issuer every cloud trusts, instead of every cloud having to trust every other cloud. You register Hush’s OIDC issuer with AWS, Azure, and GCP once each, using the same federation primitives as before:

  • an IAM OIDC provider and trust policy in AWS
  • a federated identity credential in Azure
  • a workload identity pool in GCP

Three registrations instead of six.

That registration happens once, from the Hush console. Adding a connector for a given cloud walks through the application type and then surfaces the exact OIDC parameters, issuer URL and audience, to paste into that cloud’s identity provider setup:

From there, Hush signs a short-lived token for the workload’s identity and mounts it directly into the pod. The workload presents that token to whichever cloud it needs, and gets back a native, temporary credential from that cloud’s own STS. Hush never sees or holds the downstream credential, it only vouches for the workload that’s asking.

Hush also owns the token’s lifecycle end to end. It rotates the signed token before it expires, and refreshes it again if the workload outlives the cloud’s own credential 

lifetime, AWS session tokens cap at 12 hours, for instance. A long-running workload never has to detect an expiring credential or handle renewal itself.

The result: one identity, one trust relationship to configure per cloud instead of per pair, and access that is short-lived by construction rather than something a team has to remember to rotate.

Cross-cloud federation is hard because the clouds were never built to trust each other. Hush gives them a common layer that was.

Still Using Secrets?

Let's Fix That.

Get a Demo
Blog
Identity Security

Agentic AI Just Got an Enterprise Access Layer

Shmulik Ladkani's avatar
Shmulik Ladkani CTO and Co-Founder

Table of Contents

Anthropic recently shipped the Enterprise-Managed Authorization (EMA) extension for Claude’s MCP connectors, which lets IT admins configure tools such as Asana, Figma, and Linear once through their existing identity provider. Authorized employee end users can then inherit access at login without needing any additional individual OAuth approvals.

Under the hood, Anthropic’s EMA relies on a specific IETF draft spec called ID-JAG.

It’s worthwhile to take a deep dive into how it actually works, what makes it such an elegantly well-designed piece of plumbing, and to map out what it solves for and what gaps might still need to be solved for by its users.

The Problem ID-JAG Solves

An agent acting on your behalf touches a lot of apps in one task: the wiki, Slack, a Jira ticket, your calendar. Each is a separate vendor, usually reached through something like MCP.

Each of those apps needs to know who you are and what you’ve allowed the agent to do before handing over any data. The standard way to establish that is OAuth, which normally means a human in the loop: a redirect, a login screen, and an “Allow Access” click, once per app.

That works fine when a human is connecting one app, once. It doesn’t work when an agent needs ten services in the course of a single task and there’s nobody around to click “Allow” each time a new tool gets invoked. The actual complaint isn’t “too much security”; it’s that you already authenticated once, this morning, to SSO, and every downstream tool is making you prove it again.

Enter ID-JAG

ID-JAG, or Identity Assertion JWT Authorization Grant, is an IETF draft built to answer exactly that complaint, for one specific, well-bounded case: the apps involved already trust the same identity provider for login.

Instead of the agent asking you for permission app by app, it goes back to the IdP that handled this morning’s login and asks it to vouch for it. The IdP issues a short-lived token: this agent is acting for this user, and here’s what it should be allowed to do. The receiving app still decides whether to trust that and what to actually grant. The IdP is making an introduction, not issuing a blank check.

In practice:

You sign in to the agent via company SSO, as usual.

When the agent needs a new app, it goes to the IdP, not to you, and requests a token scoped to that app.

The agent hands that token to the app, which exchanges it for a normal access token under its own rules.

The agent calls the app’s API with that access token.

No second login, no per-app click. You authenticated once; everything downstream gets brokered through trust that already existed.

The Architectural Elegance of ID-JAG

ID-JAG doesn’t invent new cryptography or a new trust model. It combines two existing OAuth pieces, Token Exchange and the JWT Bearer grant, and defines exactly what goes inside the token: who’s vouching for the user, who’s acting on their behalf, what they’re allowed to do, and which app it’s for.

That specificity is what makes it useful. With those claims pinned down, an identity provider from one vendor and an app from another can implement the flow independently and still understand each other.

It’s also not really an “AI agent spec,” even though agents are why everyone’s suddenly paying attention. The worked example in the draft itself has nothing to do with agents: a company wiki embedding a live preview from a chat app, scoped to the viewing employee, with no consent prompt. Same mechanism, much older problem.

The boundary is also part of the design. ID-JAG only works between apps that already share an IdP for SSO. In most B2B and enterprise environments, that is already the norm. By staying inside that existing trust fabric, ID-JAG avoids turning agent authorization into a new identity system.

Why ID-JAG Is Necessary but Not Complete

ID-JAG decides whether an agent should be allowed to talk to a given app at all, and it does that job well, without making anyone click “Allow” repeatedly. That decision happens once, at grant time. It has no visibility into what the agent does five minutes later when it actually picks up a tool and uses it.

If a connected agent gets manipulated into taking an action it shouldn’t, ID-JAG isn’t the layer that catches it; that’s a different question than “can this agent reach this app.” You still need something that governs actions: per-action permissions instead of one broad standing scope, human-in-the-loop approval for anything sensitive enough to warrant it, centralized action-level audit, and credentials the agent itself never directly holds.

These two layers aren’t competing; they reinforce each other. Action-level governance needs to know who’s acting in order to apply per-user policy and produce a real audit trail, and a clean per-user grant is exactly what ID-JAG gives you, in place of the shared service accounts and static API keys that agents have mostly been running behind until now.

The Takeaway

ID-JAG is good infrastructure: two existing OAuth pieces, recombined precisely, removing the biggest piece of friction in connecting agents to apps inside an enterprise’s existing trust fabric, without inventing new trust assumptions. It’s already shipping, including Claude, VS Code, and a growing list of MCP servers, which tells you the industry agrees. Adopt it for the connection layer, and pair it with something that governs actions. Together, that’s the full picture.

Still Using Secrets?

Let's Fix That.

Get a Demo