Skip to main content
Replicas agents can authenticate to cloud providers and internal services with OpenID Connect (OIDC). Every workspace can mint a short-lived, signed identity token for any service it needs to call. The service verifies the token against Replicas’ public keys and exchanges it for its own credentials, so no AWS keys, service-account files, or API tokens live in the workspace.
Workspace identity requires a Team or Enterprise plan or an active trial.

How it works

  1. The agent requests a token and names the service it is for, the audience. Replicas does not allowlist audiences: any printable ASCII string without spaces, up to 255 characters, works, and replicas:workspace is used when none is given.
  2. Replicas signs an RS256 JWT that identifies the organization, environment, workspace, and creator. It is valid for 15 minutes.
  3. The service verifies the signature with the issuer’s public keys, checks that the audience is its own, and applies its trust policy to the claims.
You configure trust once on the service side. After that, agents obtain and use tokens on their own; nothing is stored, refreshed, or rotated in the workspace. For Replicas Cloud, use https://api.replicas.dev as the issuer URL. Dedicated and self-hosted deployments use their configured issuer, returned by GET /v1/environments/{id}/workload-identity on the API. The AWS and Google Cloud examples below also use your organization ID; copy it from Organization → Settings → Basic Info. Copy an environment ID from its app URL or replicas env list. Copy a workspace ID from its app URL, or run replicas whoami inside that workspace.

AWS

Once, in AWS. Create an IAM OIDC identity provider for your Replicas issuer with audience sts.amazonaws.com, then a role that trusts it. IAM can only match aud and sub, so scope the role with a sub condition: Grant what the agent may do, such as reading an S3 bucket, as ordinary permissions policies on the role. Then ask the agent.
The agent configures an AWS profile whose credential_process runs replicas identity aws-credentials, which obtains a token and calls AssumeRoleWithWebIdentity. The AWS CLI and SDKs use it with AWS_PROFILE=replicas. The helper caches the one-hour credentials and exchanges a new token only when fewer than 15 minutes remain, so most AWS commands add no exchange. To have every workspace ready without asking, put the profile in the environment’s start hook:
Workspace in CloudTrail. Off by default. To have AWS record the workspace ID as the session’s source identity on every action, including chained roles:
  1. Allow sts:SetSourceIdentity in the role’s trust policy. AWS rejects the exchange for a role without it. The Null condition makes the source identity required, so exchanges without it fail. Replicas sets the value server-side, so agents can omit it but not change it. The example uses the Replicas Cloud issuer; dedicated and self-hosted deployments replace all three api.replicas.dev references (the provider ARN and both condition keys) with their configured issuer host.
  2. Add --source-identity to the command. The token then carries the workspace ID in its https://aws.amazon.com/source_identity claim.

Google Cloud

Once, in Google Cloud. Configure Workload Identity Federation to trust your Replicas issuer, map google.subject=assertion.workspace_id (Google caps the subject at 127 bytes, one short of sub), restrict it with an attribute condition such as assertion.organization_id == '<organization_id>' or assertion.creator_email.endsWith('@example.com'), and grant the needed roles. The audience is https://iam.googleapis.com/<provider-resource-name>, Google’s default. Then ask the agent.
The agent writes a credential configuration whose executable command is replicas identity token --format gcp, points GOOGLE_APPLICATION_CREDENTIALS at it, and signs in with gcloud auth login --cred-file. Google client libraries call the helper whenever they need a new token. For a permanent setup, put the same commands in a start hook:
Add --service-account=<email> to create-cred-config when your setup impersonates a service account.

MCP servers

An http or sse environment MCP can present the workspace token instead of a stored header. When adding the MCP, choose Workspace identity token and enter the audience the server verifies, usually its URL. The equivalent config is:
The URL must be HTTPS without query parameters, and no static headers are allowed. Agents call the MCP as usual and Replicas attaches a current token to every request, reusing one per audience while it has more than five minutes left. The server verifies it as described below. Adding MCPs requires environment Write, so agents inside a workspace cannot do this part.

Your own APIs

Ask the agent to call the service with a workspace token:
The agent uses the CLI:
Tools that cannot run the CLI can call the loopback helper directly:
Your service verifies the token with the issuer’s documents:
  • Discovery: <issuer>/.well-known/openid-configuration
  • Keys: <issuer>/.well-known/jwks.json
Check the RS256 signature against the key matching kid, the issuer, that aud equals your audience exactly, and the time window with at most 30 seconds of skew, then authorize on the claims below. The workload identity API returns these complete document URLs alongside the configured issuer. examples/workspace-identity in the repository holds a dependency-free verifier plus HTTP and MCP servers built on it. Services that support OIDC federation can trust the discovery URL directly.

Token claims

Security properties

  • No long-lived credentials. Tokens last 15 minutes and are minted when requested. Workspaces cache one per audience in memory while it has at least 5 minutes left and do not persist it as a credential. The AWS helper briefly writes the token to a protected temporary file for the STS exchange and deletes it afterwards, then caches the resulting AWS credentials in a user-only file under ~/.replicas/aws-credentials until shortly before they expire.
  • Scoped access. Each token is valid for one audience, and trust policies scope by organization, environment, workspace, or creator.
  • Auditable identity. Every token names the organization, environment, and workspace. When a person created the workspace, it also names them, so downstream logs can attribute actions to both.
  • Bounded by the workspace. Replicas stops issuing tokens when a workspace sleeps, is archived or deleted, when its creator loses access to the environment, or when plan or feature access goes away. An issued token stays valid until exp; there is no revocation.
  • Rate limited. Up to 120 mints per workspace per minute.