Before the public door

A six-agent fleet across three machines is about to open a public SSO door when a key leaks through federation; the learner reasons through tiers, secrets, observability, and what must be true before public access.

Advanced · scenario

By spring, Priya's company ran six agents. It had started with one — a Level 1 project agent on the billing repo — and grown, deliberately at first and then quickly: a second billing-adjacent service agent, a personal Level 2 agent that handled her team's cross-project chores, an agent that watched the data pipeline, and two more that had quietly appeared because they were useful. They lived on three machines: two on the office server, the rest federated onto a cloud host and a spare box in the lab, all talking over the mesh.

The plan for the quarter was exciting: open a public door. A support agent, behind SSO, that customers could query directly about their own accounts. Sales loved it. Priya set the launch for the end of the month and told the team to wire it up.

Two weeks before launch, the lab box filled its disk with logs, and an engineer grepping for the cause found something else: a plaintext API key, for the billing provider, sitting in a log line. It traced back to the original Level 1 agent. Months earlier, someone had pasted the key straight into that agent's system prompt — "just to get it working" — and never removed it. It had been low-risk while the agent ran on one trusted machine. But when the team federated, that agent's context travelled to other hosts, and a debug log on the lab box had captured the prompt verbatim. The key had been sitting in cleartext on a machine half the team had forgotten they owned. Nobody had noticed for weeks, because there was no shared observability — no traces, no metrics, no single place that would have flagged a credential in a log.

Priya killed the launch date. In the retro, the team drew the system they actually had against the one a public door demanded, and three gaps stood out. First, secrets: credentials had never been managed as first-class operational objects. They pulled every key out of every prompt and repo, put them behind a secret manager, and gave each agent only the scoped, rotatable credential it needed. Second, tiers: they had six agents and no one whose job was to manage agents. That was the missing Level 3 — an agent-management tier that owns onboarding, skills, and credential rotation across the fleet, the thing you add once you pass three-to-five agents and the coordination overhead becomes real. Third, observability: they wired OpenTelemetry across the mesh so every agent's actions produced traces and metrics into one place, where a leaked-credential pattern would page someone in minutes rather than surface by accident in a full disk.

Only then did they return to the public door. Public access with SSO and user management was not just a login screen bolted on: it meant the support agent would take input from people outside the company, so its blast radius had to be understood before it was reachable. They scoped it hard — read-only to a customer's own account, no write tools, its own isolated credential, its own traces. The launch slipped six weeks. This time, it held.

Priya's takeaway, written into the fleet's operating doc: you can scale to a company of agents with very little ceremony on day one — one machine, flat files, even a key in a prompt is survivable when the door is closed and everyone is trusted. But every capability you add — a second machine, federation, a public door — widens the surface, and the operational maturity has to arrive before the capability, not after the incident that proves you needed it.

Glossary

agent tiers (Levels 1-4)
Levels of responsibility: Level 1 project/service agent, Level 2 personal/work-function agent, Level 3 agent-management agent, Level 4 listener/orchestrator. — The fleet had Levels 1 and 2 but no Level 3 — no one whose job was to manage agents.
federation (one machine or many)
Running agents across several hosts that talk over the mesh, instead of one box. — Federation moved an agent's context — and the key pasted into it — onto a machine where a debug log captured it.
secrets management
Treating credentials as first-class operational objects: kept in a secret manager, scoped per agent, and rotatable — never pasted into a prompt or repo.
public access with SSO
Exposing an agent to people outside the company behind single sign-on and user management — a step that turns the agent's blast radius into a security question that must be answered before it is reachable.
OpenTelemetry / observability
Traces and metrics collected into one place so agent behaviour — including a credential showing up in a log — is visible and alertable in minutes, not discovered by accident.
blast radius
How much damage a compromised or misbehaving agent can do; every added capability (a machine, federation, a public door) widens it, so each must be scoped and understood before it ships.

Comprehension questions

5 questions — practice and checking happen in the CLI, or sign in on the web to record your results here.

  1. Multiple choice

    How did the billing provider's API key end up leaked?

    • It was pasted into a Level 1 agent's system prompt; when the team federated across machines, that context travelled to another host and was captured verbatim in a debug log.
    • A customer extracted it through the new public support door before launch.
    • The secret manager was misconfigured and exposed it.
    Record your result:
  2. Open response

    The team ran six agents with no one whose job was to manage agents. Which tier were they missing, why does it appear at this point in a fleet's growth, and what would it own?

    Record your result:
  3. Open response

    Sales wants the public support agent shipped on the original date. As Priya, what do you decide, and what must be true before a public door opens?

    Record your result:
  4. True or false

    Federating the agents across several machines carried no new risk beyond running them all on one trusted box.

    Record your result:
  5. Multiple choice

    Why did the leaked credential go unnoticed for weeks?

    • There was no shared observability — no traces or metrics and no single place that would have flagged a credential sitting in a log.
    • The whole team happened to be on vacation for the entire period.
    • The key was encrypted, so no tool was able to read it.
    Record your result:

Practice with the CLI (culture-guide practice), or sign in to check your answers and track a streak.