In one sentence: a scheduled AI agent gets in with a machine key that only opens the
specific doors you chose, signs every request so it can't be forged or replayed, expires each message in minutes, and can be
switched off instantly — and it never gets your password or your code.
The everyday analogy
Think of a hotel key card, not a house key. A house key is a password: copy it once and it opens
everything, forever. A hotel key card is different — it only opens your room, it stops working at checkout,
and if you lose it the front desk deactivates it and prints a new one in seconds. The old card is now a worthless piece of
plastic. The Console MCP token is that key card.
The five things that make it safe
- 1. It's a key, not a password. The agent never types a password anywhere. It holds a token that the
Console issued. And we never store the token in a readable form — even the platform can't print it back to you,
which is why you only see it once when it's created.
- 2. Every message is sealed. Each request the agent sends is stamped with a cryptographic signature
(an HMAC) computed from the message plus a timestamp and a one-time number. Change one character of the request and the
seal breaks. Copy an old request and replay it — it's rejected, because the timestamp is more than five minutes old.
- 3. The key only opens the doors you granted. When you create the key you pick its boundaries. A
"read the doctrine" key literally cannot publish anything; a "publish reports" key can't reach beyond its assigned
cartridge. There is no master key.
- 4. One click to kill it. A key can be rotated (new secret, same key — the old one dies instantly)
or revoked (switched off entirely). A leaked key is a one-click problem, not an emergency.
- 5. Your repo and your computer stay yours. The agent runs on the operator's own machine. The platform only ever
sees the scoped key and the finished report — never the source code, never the operator's login.
What a request actually goes through
the agent's machine the platform
────────────────── ────────────
1. sign the request ──────HTTPS (TLS)──────▶ 2. CloudFront checks a shared secret
(secret + message) (blocks anything not coming through the front door)
3. the MCP checks the seal + timestamp
(forged or replayed → rejected, before anything else)
4. is this key still active? which doors?
(revoked → rejected; wrong boundary → tool hidden)
5. do the one allowed thing
(read doctrine OR publish a report)
Notice the order: the seal and the key are checked before the platform does any work. A bad request never
reaches the part that reads or writes data.
What could go wrong — and why it's contained
| Worry | Why it's contained |
|---|
| "Someone steals the key file." | Rotate or revoke it in the Console — the stolen copy dies immediately. And the key only ever had the narrow doors you granted. |
| "Someone copies a request and replays it." | Every request expires in ~5 minutes and carries a one-time number; a replay is rejected. |
| "A read-only agent tries to publish." | The publish tool isn't even visible to a grounding-only key. The boundary is enforced server-side, not by trust. |
| "Someone hits the platform directly, bypassing the front door." | The request lacks CloudFront's shared secret and is refused (403). |
The bottom line
The worst case for a leaked Console MCP key is "an attacker could read published doctrine or file a report into one
cartridge, for a few minutes, until you click revoke." It can't touch your code, your login, or any other cartridge.