Scene 5 · When the robot acts for you

Robo gets a job

The party went so well that Robo is now an AI helper for every teacher. Ms. Rivera types: Order six pizzas for Friday. Robo has to use her pizza-shop account without ever knowing her password.

Go a level deeper ↓

1 Robo gets its own ID

Two ways to set Robo up. Try both.

2 Ms. Rivera says yes, to some things

The first time, Robo can't just walk in. It sends Ms. Rivera to the pizza shop's own sign-in page, where she sees exactly what Robo is asking for.

Robo only needs to place orders. Does it really need her payment card?

3 Whose token is it?

Different callers ask the vault for Ms. Rivera's pizza-shop token. Who gets it?

The vault releases a token only to the same agent and the same person that obtained it.

4 Robo at the pizza shop

Robo shows the token at the shop. Every single request is checked: is the token real, still valid, and does it cover this?

Activity log

  1. Nothing yet.

5 Ms. Rivera changes her mind

Over the summer she doesn't want Robo ordering on her account anymore. She removes Robo from the pizza shop's "connected apps" page.

What you just used

Robo's own IDagent identity
Agent deskagent identity directory
"Robo wants to…"OAuth consent (authorization code grant)
The checkboxesOAuth scopes
The vaulttoken vault
Same agent, same persontokens bound to the agent and the user
Checked every timeper-request verification of signature, expiry, scope
"Robo, for Ms. Rivera"identity propagation, audit trail
Removing accessrevoking the grant at the provider

Who builds identity for agents

  • Agent platforms: Amazon Bedrock AgentCore Identity, with a token vault and ready-made connections to services like Google, GitHub, Slack, Salesforce and Jira.
  • Identity companies: Auth0 for AI Agents (with its own Token Vault), part of Okta.
  • The open standards underneath: OAuth 2.0, and the Model Context Protocol that agents use to reach tools.
Connects to
  • Who's at the door?: Robo acts only after the teacher signs in and her wristband checks out.
  • The locked box: the agent desk keeps its keys for outside services in a box like that one.
  • Is that badge real?: the same idea, an identity anyone can check, now given to an AI agent.

Go a level deeper

Where Robo lives

The agent desk holds Robo's keys to outside shops. But Robo also needs the school's own services, like the locked box. Where does that key come from? Who hands it out? And how does Robo prove who it is to services outside the school?

+1 Three homes, no key in the pocket

First try the shortcut. Then move Robo into each home and see where its key comes from.

The homes are compute services: a virtual server (Amazon EC2, with an instance profile), a function that runs per request (AWS Lambda, with an execution role), and containers on Kubernetes (Amazon EKS, with EKS Pod Identity). In each, AWS hands over temporary credentials for a role, so there is no long-lived key to leak.

+2 Who else can reach the key?

In the rented room and the kitchen, a front desk hands out keys to whoever is inside. Two strangers try their luck.

🔗 The trick link rented room

A pizza menu Robo reads hides a link to the room's own front desk. Robo follows it and reads the answer out loud.

🧽 The dishwasher twin kitchen of twins

A twin that only washes dishes walks past its own name tag and asks the counter's front desk instead.

The front desk is the instance metadata service. Its newer version, IMDSv2, answers only after a PUT request for a session token, a defense against trick links (SSRF). On EKS, requiring IMDSv2 with a hop limit of 1 keeps pods away from the node's own role. Name tags limit keys, not walls: pods on one node still share it.

+3 The key office behind every key

In every home, Robo's short-lived key came from the same place: the school's key office. Each role has two lists pinned to it: who may wear it and what it may do. Ask the office for a key to the robo-orders role.

Who's asking?

The key office is AWS Security Token Service (STS). Its AssumeRole returns an access key ID, a secret access key and a session token. A role has a trust policy (who may assume it) and a permissions policy (what it may do). A session lasts from 15 minutes up to the role's maximum (1 to 12 hours), 1 hour by default; role chaining is capped at one hour; a session policy can only narrow the role, never widen it; and the session name shows up in the logs. When the key expires, AWS stops recognizing it, so nobody has to cancel it.

+4 A note for the shop across town

Friday's order goes to Speedy Delivery, a service outside the school that doesn't use the school's keys. How does Robo prove it's Robo?

This is IAM outbound identity federation, from the same key office: a workload calls STS GetWebIdentityToken for a signed JWT, good for 1 minute to 1 hour (5 minutes by default), and every request is logged. IAM policies can limit which audiences and lifetimes a role may ask for (sts:IdentityTokenAudience, sts:DurationSeconds). The outside service checks the note with keys published at the account's issuer URL (JWKS), the same offline check as the wristband in Who's at the door?, validates iss, aud, sub and exp, and can check extra claims such as org_id, tags, or the calling Lambda function. It only works outward: these notes can't be used to sign in to AWS.

Agent ID desk: 0/8