Watch: Context for Reliable Agents
Live demo · Sandbox identity

Test cloud access with Chalk sandbox identities

This demo shows an agent’s sandbox identity controlling its access to Google Cloud. Compare an allowed read with a denied read or impersonation attempt to see how cloud IAM decides access without a long-lived cloud key in the sandbox.

See the DemoTry Chalk

Compare an allowed request with a denied one

Chalk supplies the sandbox identity; cloud IAM decides what it may read or impersonate. Compare the two scenarios below. A denied request is the expected result when that identity lacks access.

Try this experiment · expected results

  1. 1Run the Release agent

    Start with the first scenario and follow its requests to BigQuery.

    Expected: Deployment metrics are readable; customer payments are denied.

  2. 2Try the Unvetted agent

    Select the scenario that tries to borrow the release agent’s service account.

    Expected: Impersonation is denied. A red step is the intended boundary working.

Fictional company and data · tokens shown as fingerprints onlyOpen in new tab

Compare an allowed agent with an untrusted identity. Chalk supplies a short-lived identity token; Google Cloud IAM decides which data the agent may read.

Inspect the identity exchanges step by step

  • Launch

    A sandbox started with chalk_identity=True carries the identity of whoever launched it: a person, or an agent's own Chalk service token. Nothing else is mounted.

  • Mint

    Inside the sandbox, the agent asks Chalk for a one-hour OIDC token for one audience. Its subject names the environment and the launcher, so your cloud knows exactly who is asking.

  • Exchange

    Your cloud's token service checks Chalk's signature, the audience and your pool condition, then hands back a federated token. A token minted for any other audience is refused.

  • Narrow

    The federated principal can act as one existing service account, or read what you granted it directly. Each hop is shorter-lived and narrower than the one before.

  • Decide

    Your IAM decides every read. In the demo, BigQuery refuses the customer table outright, and the unvetted agent is refused the release agent's service account.

  • Audit

    Cloud Audit Logs record the federated subject, environment and token id included, on every call it makes directly, and the service account on calls it makes as one.

Built on Chalk

Chalk supplies the sandbox identity and OIDC tokens. Google Cloud’s token services and IAM decide what that identity can access; the example supplies the scenarios and fictional data.

  • Mint short-lived identity tokens

    A sandbox launched with chalk_identity=True can request an OIDC token for an audience. Tokens identify the environment and launcher without mounting a cloud key.

  • Keep access in cloud IAM

    Google Cloud verifies the token and applies the workload identity pool conditions and IAM bindings. Chalk supplies the identity rather than a separate copy of the permissions.

  • Choose which identities to trust

    Bindings can trust a specific developer, an agent’s service token, or an environment. The chosen bindings determine who may use a service account or read data directly.

  • Inspect the identity chain

    The demo shows token fingerprints and the outcome of each exchange. Cloud audit records identify the federated subject or impersonated service account behind a call.

Deploy your own

One pool, a few bindings

Register Chalk as an OIDC provider in a workload identity pool, then bind the subjects you trust: a developer, an agent's service token, or a whole Chalk environment. Launch sandboxes with chalk_identity=True and they can reach exactly what those bindings allow.

Removing a binding or a token cuts access within the hour, the longest any token in the chain lives.

chalk-ai/sandbox-identity-federation
git clone https://github.com/chalk-ai/sandbox-identity-federation
cd sandbox-identity-federation

# One service token per agent (see the README), saved to agents.env.
# Then the subject each agent's sandbox federates as:
./print_subjects.py --agents-env agents.env

# Pool, provider, tables, service accounts and bindings in your GCP project.
./setup_gcp.sh my-gcp-project https://api.chalk.ai <release> <support> <scratch>

./deploy.py --agents-env agents.env --gcp-project my-gcp-project --gcp-project-number <number>

Give your agents an identity you can audit

Talk to an engineer about running sandboxes in your cloud with identities that map onto the IAM you already have.

Talk to an engineerExplore sandboxes