Identity and cloud access

An agent doing real work often has to reach one of your own cloud resources: a database, a storage account, a managed service. The question your identity team asks is the exact one this page answers: how does that agent prove it is allowed in, and what credential is sitting in the sandbox to make that possible?

The answer is that nothing is sitting there. A sandbox proves its identity with a short-lived token your cloud projects at the moment of use, against a trust you set up in your own cloud and can pull at any time. No standing cloud secret is ever placed in the sandbox, so there is nothing in there to copy, print, or leave behind. This page is the governance view of that mechanism: what it protects and what you can attest. For the hands-on setup, the Kubernetes host and Local Docker host pages walk it through field by field.

An identity, not a stored secret

The familiar way to let a process reach a cloud resource is a service-account key in its environment: a long-lived secret that works until someone rotates it, and that anyone who can read the environment can copy. A workload identity replaces that with something that has nothing to harvest. Your cloud grants a managed identity the access you choose, and a sandbox is allowed to act as that identity for the moment it needs to, by presenting a token your cloud issues fresh and that expires in minutes. There is no key in the sandbox to steal or to find on a disposed disk, because the credential is a short-lived assertion, not a value at rest.

The platform never holds your cloud credential. The managed identity, the role it carries, and the trust that lets a sandbox use it all live in your cloud, under your control; the platform gives the sandbox the standard hooks your cloud already understands and projects the short-lived token in, and the decision about what that identity can reach, and whether it exists at all, stays yours. The cloud side is Azure Workload Identity, the federation model Azure already provides, so the trust rests on primitives your own cloud team governs rather than anything the platform invents.

On Kubernetes, the pod proves it is yours

On a Kubernetes host, the platform uses the standard Azure Workload Identity model, the same one your own workloads use. When a sandbox should run as a managed identity, the operator gives its pod a dedicated service account, named deterministically for that identity, annotated with the identity's client id and tenant, and labeled so your cluster's identity webhook projects a token into the pod. Each managed identity gets its own service account, derived from that identity, so two agents running as different identities on the same host are isolated from each other's cloud access rather than sharing one.

Two properties make this safe to hand an agent. The pod's service account has no role binding and mounts no Kubernetes API token at all, so the identity that lets a sandbox reach a cloud resource gives it no reach into your cluster: it cannot call the Kubernetes API, list anything, or touch a neighbor. And the token it does get is the projected workload-identity token, minted by your cluster, scoped to the standard token-exchange audience (api://AzureADTokenExchange), and good for minutes rather than indefinitely.

The trust that ties it together is a federated credential you create in your cloud, once per cluster, with three parts you control: the subject (the sandbox service account), the audience, and the issuer (your cluster's own OIDC issuer URL). Bind it to your issuer and that service account, and your cloud trusts exactly the pods this host launches and nothing else. The setup steps are on the Kubernetes host page; the point here is that the trust anchor is your cluster's issuer, in your cloud, on your terms.

The same guarantee without a cluster, on Local Docker

A Local Docker host has no cluster webhook to project a token, so the platform stands up an OIDC issuer your cloud can trust the same way it trusts a cluster issuer. The issuer signs short-lived assertions and publishes a public key set your cloud verifies against, and the operator projects the assertion into the container as a file at a fixed path (/var/run/secrets/disco-parrot/azure-identity/token), never an environment variable. Your cloud's federated credential trusts this issuer the same way a Kubernetes federated credential trusts a cluster issuer, and the managed identity, the role, and the decision to allow it are still yours. The assertions are short, on the order of fifteen minutes, so even the projected token is a small thing to lose.

This path stays off until it is deliberately turned on. A Local Docker host will not let you enable Azure Workload Identity until the issuer is configured for your workspace, so a half-wired identity never quietly looks ready. And the variable names your cloud uses to find that token, AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_AUTHORITY_HOST, and AZURE_FEDERATED_TOKEN_FILE, are reserved: an environment file you point the host at cannot set them, so a local config can never shadow the real identity wiring or stand a fake one up in its place.

The identity is yours to grant, and yours to pull

Every piece of this is a control you hold. You decide the managed identity exists. You decide the role it carries, and so what an agent acting as it can reach. The posture that holds up in a review is the narrow one: a managed identity that carries the single role for the single resource an agent needs, granted one per resource or team rather than as a broad identity shared across many, so the access you give is exactly the access you can describe. You create the federated credential that lets a sandbox use it. Removing that credential, or the role, or the identity ends the access at once, with nothing cached in a sandbox to keep using it, because there was never a stored secret, only a token that expires in minutes. There is no platform-held copy to revoke separately and no standing key to rotate under pressure.

What a sandbox never carries is a long-lived cloud secret. The workload-identity path injects no client secret; a sandbox authenticates with the projected token and nothing else. The name a static client secret would travel under is one the platform refuses outright, so there is no path by which one reaches a sandbox even by mistake.

What a reviewer can verify

None of this asks to be taken on faith. An identity owner can confirm the shape of it directly:

• The managed identity, the role it holds, and the federated credential live in your cloud, so you can show exactly what an agent identity can reach and who created it.
• The federated credential names your issuer and the sandbox service account, so the trust is scoped to the pods this host launches and not to anything else.
• On a Kubernetes host, the sandbox service account has no cluster role binding and mounts no Kubernetes API token, so a cloud identity grants no cluster reach.
• On a Local Docker host, the identity stays off until the issuer is configured for your workspace, and the reserved AZURE_ identity variables cannot be set by the host's environment file, so a local config can neither stand up a fake identity nor shadow the real one.
• The token an agent uses is short-lived and projected at the moment of use, and no standing cloud secret is configured in the sandbox: the name a static client secret would travel under is one the platform refuses, so there is no value at rest for a disposed sandbox to leave behind.
• In your cloud's own logs, an agent's action appears as the managed identity it assumed, and the platform's audit trail ties that same run back to the person who launched it, so the identity in your logs is never anonymous.

Each of those is a fact you can produce from your own cloud and your own host, which is the point of letting your identity do the work rather than a secret.

Granting an identity, end to end

Marcus owns the Insights service, and a review has drawn a line: an agent that touches the production data store has to authenticate as a governed identity, not with a key someone pasted into a config. The work already runs in the team's own Kubernetes cluster, so the identity is the last piece.

The platform engineer who runs the cluster creates a managed identity that can read the production store, registers the cluster's OIDC issuer with the cloud, and adds a federated credential that trusts that issuer and the sandbox service account. Marcus turns on Azure Workload Identity for the host and points the relevant profile at that identity by its client id and tenant. From then on, an agent working an Insights plan comes up as a pod that authenticates to the data store as the managed identity, holding a token that lives for minutes, with no secret on disk and no reach into the cluster. When the engagement ends, removing the federated credential ends that access cleanly, and Marcus can show the reviewer the identity, its single role, and the trust it rests on, all in the team's own cloud.

Why identity works this way

The tempting way to let an agent into a cloud resource is the fast one: drop a service-account key in the environment and move on. It works, and it is precisely the thing an identity team cannot live with, because a long-lived secret in a place an agent can read is a secret that can be printed, copied, or carried off, and rotating it is a fire drill across every place it was pasted. So the model refuses to put one there. The agent acts as an identity you granted, proves it with a token your cloud mints fresh and expires in minutes, and holds nothing in between.

From that one decision the rest follows. The trust lives in your cloud because the identity is yours to grant, not the platform's to hold. The sandbox gets no cluster reach because an identity for talking to a database is not an identity for talking to your cluster, and the two should never be the same grant. The token is projected at the moment of use and gone after, because a credential that exists only while a real operation runs is a credential there is almost nothing to steal. And the whole thing is something you can pull in one move, because access an agent holds should be access you can end, cleanly, the instant you decide to.

For the person who owns identity, an agent reaches exactly what one managed identity you granted allows, proves it with a short-lived token your cloud projects, and holds no standing secret in the sandbox at all. The trust is yours, scoped to your issuer and a known service account, and revocable in a single move: remove the federated credential or the role, and the access ends with nothing cached to keep using it.

For a platform engineer, this is the standard workload-identity wiring you already know: a federated credential bound to your issuer and a service account, a projected token, no client secret. The deterministic service account carries no role binding and no API token, so a sandbox that can reach a cloud resource still cannot reach your cluster.

For an engineer, none of this is in your way. You point a profile at an identity once, and from then on the agent comes up already able to authenticate, with no token to paste and nothing to rotate when it expires, because it expires on purpose.

For a prospect evaluating the platform, this is how agent autonomy and cloud access stop being in tension. The agent gets real access to do real work, and yet there is no long-lived cloud credential in its world to leak, because the access is an identity you grant and a token your cloud mints, not a key you store where an agent could find it.