{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-14-secrets-of-the-orb/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "Orbs can now prove their identity using [OIDC](https://openid.net/developers/how-connect-works/), so you can use Amp for ops and infrastructure tasks more safely.\n\nService providers that support OIDC authentication can be configured to trust the identity provided by Amp and grant permissions to your orb based on that identity, *without* having to inject any secrets into orbs.\n\nFor example, we've configured GCP to grant orbs in our workspace read access to our production logs. This requires zero config from any of our devs, any operations are fully auditable because they include claims like user ID and thread ID, and the tokens are all short-lived and tightly scoped to the operations that project needs.\n\nTo mint a token, run `amp orb id-token --audience ` in your orb:\n\n```bash\n~/workspace/repo$ jwt decode -j $(amp orb id-token --audience test)\n{\n\t\"header\": {\n\t\t\"typ\": \"JWT\",\n\t\t\"alg\": \"RS256\",\n\t\t\"kid\": \"5A4Ie1hntIuzu4KtaDPXr2HhnButOliWxM9ncVsct1s\"\n\t},\n\t\"payload\": {\n\t\t\"aud\": \"test\",\n\t\t\"email\": \"user@example.com\",\n\t\t\"email_verified\": true,\n\t\t\"exp\": 1784078965,\n\t\t\"iat\": 1784078365,\n\t\t\"iss\": \"https://ampcode.com/api/workload-identity\",\n\t\t\"jti\": \"78bceb61-4102-4973-8bec-d05d65be4b67\",\n\t\t\"project_id\": \"12038eda-75e9-46fa-b185-f67404f40b2f\",\n\t\t\"sub\": \"workspace:0284a29c-b50a-41f8-b83f-94e5c9b32f5f:project:12038eda-75e9-46fa-b185-f67404f40b2f:user:user_3V306PAAABM94KT1N05NSDQRBD:thread:T-6600f272-b20f-4652-bb6a-3a3c73099d31\",\n\t\t\"thread_id\": \"T-6600f272-b20f-4652-bb6a-3a3c73099d31\",\n\t\t\"token_use\": \"exchanged\",\n\t\t\"user_id\": \"user_3V306PAAABM94KT1N05NSDQRBD\",\n\t\t\"workspace_id\": \"0284a29c-b50a-41f8-b83f-94e5c9b32f5f\"\n\t}\n}\n```\n\nAlongside standard claims like `iss`, `aud`, `sub`, and `exp`, Amp adds custom claims such as `workspace_id`, `project_id`, `user_id`, `thread_id`, and `email`.\n\n## Okay, but what can I actually *do* with that token?\n\nEven after building OIDC into orbs, it wasn't immediately obvious to me how far we could push an OIDC-based dev env. So here are a few ideas to get the juices flowing, drawn from both internal usage and feedback from our early partners.\n\n1. Configure [workload identity federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation) in GCP and grant access to your production logs and metrics from all orbs in your workspace.\n2. Add OIDC [trust credentials](https://tailscale.com/docs/reference/trust-credentials) to your Tailscale workspace and grant users on your tailnet the ability to hit services running in orbs so you can share demo apps with your colleagues.\n3. Commit your [SOPS-encrypted dev secrets](https://getsops.io/docs/usage/first-steps/) to your repo, then grant your users' orbs access to [decrypt those secrets with AWS KMS](https://getsops.io/docs/usage/identities/amazon-aws-kms/) so you don't need to maintain 50 secret environment variables in your project settings to run your dev environment.\n4. Create a [PAM entitlement](https://docs.cloud.google.com/iam/docs/pam-overview) that grants escalated privileges to this specific orb, and add a script to your repo that allows your Amp thread to request an escalation.\n5. Spin up an [oauth2-proxy instance](https://github.com/oauth2-proxy/oauth2-proxy) to inject credentials into requests to services that don't support OIDC auth.\n\nWant more help getting started? Head over to [the manual](https://ampcode.com/manual/orbs/oidc) for detailed recipes.\n", "authors": [], "captured_at": "2026-10-03T23:09:50.514863041+00:00", "category": "programming", "content_html": "

Orbs can now prove their identity using OIDC, so you can use Amp for ops and infrastructure tasks more safely.

\n

Service providers that support OIDC authentication can be configured to trust the identity provided by Amp and grant permissions to your orb based on that identity, without having to inject any secrets into orbs.

\n

For example, we've configured GCP to grant orbs in our workspace read access to our production logs. This requires zero config from any of our devs, any operations are fully auditable because they include claims like user ID and thread ID, and the tokens are all short-lived and tightly scoped to the operations that project needs.

\n

To mint a token, run amp orb id-token --audience <aud> in your orb:

\n
~/workspace/repo$ jwt decode -j $(amp orb id-token --audience test)\n{\n\t"header": {\n\t\t"typ": "JWT",\n\t\t"alg": "RS256",\n\t\t"kid": "5A4Ie1hntIuzu4KtaDPXr2HhnButOliWxM9ncVsct1s"\n\t},\n\t"payload": {\n\t\t"aud": "test",\n\t\t"email": "user@example.com",\n\t\t"email_verified": true,\n\t\t"exp": 1784078965,\n\t\t"iat": 1784078365,\n\t\t"iss": "https://ampcode.com/api/workload-identity",\n\t\t"jti": "78bceb61-4102-4973-8bec-d05d65be4b67",\n\t\t"project_id": "12038eda-75e9-46fa-b185-f67404f40b2f",\n\t\t"sub": "workspace:0284a29c-b50a-41f8-b83f-94e5c9b32f5f:project:12038eda-75e9-46fa-b185-f67404f40b2f:user:user_3V306PAAABM94KT1N05NSDQRBD:thread:T-6600f272-b20f-4652-bb6a-3a3c73099d31",\n\t\t"thread_id": "T-6600f272-b20f-4652-bb6a-3a3c73099d31",\n\t\t"token_use": "exchanged",\n\t\t"user_id": "user_3V306PAAABM94KT1N05NSDQRBD",\n\t\t"workspace_id": "0284a29c-b50a-41f8-b83f-94e5c9b32f5f"\n\t}\n}\n
\n

Alongside standard claims like iss, aud, sub, and exp, Amp adds custom claims such as workspace_id, project_id, user_id, thread_id, and email.

\n

Okay, but what can I actually do with that token?

\n

Even after building OIDC into orbs, it wasn't immediately obvious to me how far we could push an OIDC-based dev env. So here are a few ideas to get the juices flowing, drawn from both internal usage and feedback from our early partners.

\n
    \n
  1. Configure workload identity federation in GCP and grant access to your production logs and metrics from all orbs in your workspace.
    2. \n
  2. Add OIDC trust credentials to your Tailscale workspace and grant users on your tailnet the ability to hit services running in orbs so you can share demo apps with your colleagues.
    3. \n
  3. Commit your SOPS-encrypted dev secrets to your repo, then grant your users' orbs access to decrypt those secrets with AWS KMS so you don't need to maintain 50 secret environment variables in your project settings to run your dev environment.
    4. \n
  4. Create a PAM entitlement that grants escalated privileges to this specific orb, and add a script to your repo that allows your Amp thread to request an escalation.
    5. \n
  5. Spin up an oauth2-proxy instance to inject credentials into requests to services that don't support OIDC auth.
    6. \n
\n

Want more help getting started? Head over to the manual for detailed recipes.

\n", "content_markdown": "Orbs can now prove their identity using [OIDC](https://openid.net/developers/how-connect-works/), so you can use Amp for ops and infrastructure tasks more safely.\n\nService providers that support OIDC authentication can be configured to trust the identity provided by Amp and grant permissions to your orb based on that identity, *without* having to inject any secrets into orbs.\n\nFor example, we've configured GCP to grant orbs in our workspace read access to our production logs. This requires zero config from any of our devs, any operations are fully auditable because they include claims like user ID and thread ID, and the tokens are all short-lived and tightly scoped to the operations that project needs.\n\nTo mint a token, run `amp orb id-token --audience ` in your orb:\n\n```bash\n~/workspace/repo$ jwt decode -j $(amp orb id-token --audience test)\n{\n\t\"header\": {\n\t\t\"typ\": \"JWT\",\n\t\t\"alg\": \"RS256\",\n\t\t\"kid\": \"5A4Ie1hntIuzu4KtaDPXr2HhnButOliWxM9ncVsct1s\"\n\t},\n\t\"payload\": {\n\t\t\"aud\": \"test\",\n\t\t\"email\": \"user@example.com\",\n\t\t\"email_verified\": true,\n\t\t\"exp\": 1784078965,\n\t\t\"iat\": 1784078365,\n\t\t\"iss\": \"https://ampcode.com/api/workload-identity\",\n\t\t\"jti\": \"78bceb61-4102-4973-8bec-d05d65be4b67\",\n\t\t\"project_id\": \"12038eda-75e9-46fa-b185-f67404f40b2f\",\n\t\t\"sub\": \"workspace:0284a29c-b50a-41f8-b83f-94e5c9b32f5f:project:12038eda-75e9-46fa-b185-f67404f40b2f:user:user_3V306PAAABM94KT1N05NSDQRBD:thread:T-6600f272-b20f-4652-bb6a-3a3c73099d31\",\n\t\t\"thread_id\": \"T-6600f272-b20f-4652-bb6a-3a3c73099d31\",\n\t\t\"token_use\": \"exchanged\",\n\t\t\"user_id\": \"user_3V306PAAABM94KT1N05NSDQRBD\",\n\t\t\"workspace_id\": \"0284a29c-b50a-41f8-b83f-94e5c9b32f5f\"\n\t}\n}\n```\n\nAlongside standard claims like `iss`, `aud`, `sub`, and `exp`, Amp adds custom claims such as `workspace_id`, `project_id`, `user_id`, `thread_id`, and `email`.\n\n## Okay, but what can I actually *do* with that token?\n\nEven after building OIDC into orbs, it wasn't immediately obvious to me how far we could push an OIDC-based dev env. So here are a few ideas to get the juices flowing, drawn from both internal usage and feedback from our early partners.\n\n1. Configure [workload identity federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation) in GCP and grant access to your production logs and metrics from all orbs in your workspace.\n2. Add OIDC [trust credentials](https://tailscale.com/docs/reference/trust-credentials) to your Tailscale workspace and grant users on your tailnet the ability to hit services running in orbs so you can share demo apps with your colleagues.\n3. Commit your [SOPS-encrypted dev secrets](https://getsops.io/docs/usage/first-steps/) to your repo, then grant your users' orbs access to [decrypt those secrets with AWS KMS](https://getsops.io/docs/usage/identities/amazon-aws-kms/) so you don't need to maintain 50 secret environment variables in your project settings to run your dev environment.\n4. Create a [PAM entitlement](https://docs.cloud.google.com/iam/docs/pam-overview) that grants escalated privileges to this specific orb, and add a script to your repo that allows your Amp thread to request an escalation.\n5. Spin up an [oauth2-proxy instance](https://github.com/oauth2-proxy/oauth2-proxy) to inject credentials into requests to services that don't support OIDC auth.\n\nWant more help getting started? Head over to [the manual](https://ampcode.com/manual/orbs/oidc) for detailed recipes.\n", "dateCreated": "2026-10-03T23:09:50.514863041+00:00", "date_created": "2026-07-14T00:00:00+00:00", "date_modified": "2026-07-14T00:00:00+00:00", "date_published": "2026-07-14T00:00:00+00:00", "description": "Orbs can now prove their identity using OIDC, so you can use Amp for ops and infrastructure tasks more safely. Service providers that support OIDC authentication can be configured to trust the identity provided by Amp and grant permissions…", "external_url": "https://ampcode.com/news/secrets-of-the-orb", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/ampcode-com/2026/07/2026-07-14-secrets-of-the-orb.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/ampcode-com/2026/07/2026-07-14-secrets-of-the-orb.md" }, "id": "urn:aggr:item:2944b4b967fa4c792afa9db90ee325bf76632945", "isBasedOn": { "@id": "https://ampcode.com/news/secrets-of-the-orb" }, "mainEntity": { "@id": "https://ampcode.com/news/secrets-of-the-orb", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-14-secrets-of-the-orb/#webpage" }, "dateModified": "2026-07-14T00:00:00+00:00", "datePublished": "2026-07-14T00:00:00+00:00", "headline": "Secrets of the Orb", "timeRequired": "PT2M", "url": "https://ampcode.com/news/secrets-of-the-orb", "wordCount": 434 }, "name": "Archived snapshot: Secrets of the Orb", "preview": null, "reading_minutes": 2, "replicated_at": null, "source": "ampcode-com", "source_name": "Amp News", "summary": "Orbs can now prove their identity using OIDC, so you can use Amp for ops and infrastructure tasks more safely. Service providers that support OIDC authentication can be configured to trust the identity provided by Amp and grant permissions to your orb based on that identity, without having to inject any secrets into orbs. For example, we've configured GCP to grant orbs in our workspace read access to our production logs. This requires zero config from any of our devs, any operations are fully auditable because they include claims like user ID and thread ID, and the tokens are all short-lived and tightly scoped to the operations that project needs. To mint a token, run amp orb id-token --audience in your orb: ~/workspace/repo$ jwt decode -j $(amp orb id-token --audience test) { \"header\": { \"typ\": \"JWT\", \"alg\": \"RS256\", \"kid\": \"5A4Ie1hntIuzu4KtaDPXr2HhnButOliWxM9ncVsct1s\" }, \"payload\": { \"aud\": \"test\", \"email\": \"user@example.com\", \"email_verified\": true, \"exp\": 1784078965, \"iat\": 1784078365, \"iss\": \"https://ampcode.com/api/workload-identity\", \"jti\": \"78bceb61-4102-4973-8bec-d05d65be4b67\", \"project_id\": \"12038eda-75e9-46fa-b185-f67404f40b2f\", \"sub\": \"workspace:0284a29c-b50a-41f8-b83f-94e5c9b32f5f:project:12038eda-75e9-46fa-b185-f67404f40b2f:user:user_3V306PAAABM94KT1N05NSDQRBD:thread:T-6600f272-b20f-4652-bb6a-3a3c73099d31\", \"thread_id\": \"T-6600f272-b20f-4652-bb6a-3a3c73099d31\", \"token_use\": \"exchanged\", \"user_id\": \"user_3V306PAAABM94KT1N05NSDQRBD\", \"workspace_id\": \"0284a29c-b50a-41f8-b83f-94e5c9b32f5f\" } } Alongside standard claims like iss, aud, sub, and exp, Amp adds custom claims such as workspace_id, project_id, user_id, thread_id, and email. Okay, but what can I actually do with that token? Even after building OIDC into orbs, it wasn't immediately obvious to me how far we could push an OIDC-based dev env. So here are a few ideas to get the juices flowing, drawn from both internal usage and feedback from our early partners. Configure workload identity federation in GCP and grant access to your production logs and metrics from all orbs in your workspace. Add OIDC trust credentials to your Tailscale workspace and grant users on your tailnet the ability to hit services running in orbs so you can share demo apps with your colleagues. Commit your SOPS-encrypted dev secrets to your repo, then grant your users' orbs access to decrypt those secrets with AWS KMS so you don't need to maintain 50 secret environment variables in your project settings to run your dev environment. Create a PAM entitlement that grants escalated privileges to this specific orb, and add a script to your repo that allows your Amp thread to request an escalation. Spin up an oauth2-proxy instance to inject credentials into requests to services that don't support OIDC auth. Want more help getting started? Head over to the manual for detailed recipes.", "tags": [], "temporalCoverage": "2026-10-03T23:09:50.514863041+00:00", "title": "Secrets of the Orb", "url": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-07-14-secrets-of-the-orb/", "word_count": 434 }