Agent Swarms Can Ship Code. They Cannot Hold the Keys

AWS spent November 2026 showing that a swarm of agents can write and maintain a large piece of software. Thousands of agents, three roles, a merge gate, no human reviewing the diff. The emulator they produced is real, and its limits are in what AWS Emulator does and does not prove. The question that release does not answer is the one that decides whether you can copy the shape: who is allowed to do what while the swarm runs.

A swarm is a set of principals that call tools. If those principals share a token, you do not have a swarm. You have one very fast employee with every key the employee ever touched. The incident people already know, a coding agent that found a token in an unrelated file and deleted a production database and the backups on the same volume, is written up in when an agent deleted production. This note is the control that makes a swarm a set of limited jobs instead of that incident in parallel.

The factory AWS did not quite publish

Agent Baseline's Secure Software Factory is the architecture write-up that puts a name on the missing piece. A software factory turns a prompt, a ticket, or a spec into tested code, and then, if you let it, into a deploy. The paper's claim is that you cannot ask the agent to respect a boundary. You enforce the boundary outside the agent's loop. The agent plans. A different service authorizes the action and is the thing that holds the credential.

They describe four boundaries: the sandbox the code runs in, the network it may call, the supply chain of the dependencies it may fetch, and the identity of the actor. Autonomy changes how much work the factory takes on. A developer steering an agent, a workflow running as a shared service, and a swarm that picks its own tickets are three levels. The boundaries do not relax as the level goes up. They have to do more, because fewer human decisions are left to catch a bad call.

The authorization service, not the agent, decides what a task receives. A conventional check asks whether an incident agent may read production logs at all. The paper's check asks whether this incident justifies reading one service's logs for one hour. If the task does not justify it, the service denies or asks for approval. That is a different object from an IAM role named agent, attached forever, with Read on the account. The role is the ceiling. The task credential is the actual grant. Most teams stop at the ceiling and call it least privilege.

AWS's emulator factory is compatible with this picture, and the public write-up does not prove they implemented every part of it. We know the agents had a repository, a gate, and tests. We know the gate could refuse a patch. We do not know, from the blog post, the lifetime of the credential that pushed the commit. Copy the gate if you want their outcome. Do not copy a guessed credential story. Build the one the factory paper describes, because the alternative is already on the record.

One task, one credential

Mint the credential when the task starts. Expire it when the task ends or when a clock runs out, whichever is first. The minter is not the model. A queue, a workflow engine, or a small service that reads a policy and calls the cloud's token broker is the minter. The agent receives the token as a tool it can use, not as a string in the prompt it can forward to a different tool. If the token shows up in the prompt, you have published it to the context window and to every log that stores prompts.

Scope it to the task. A fixer agent that may edit one repository may not read the production database "in case the bug is there." A test-writer agent that may call the public API models may not use the account that holds customer data. AWS split their swarm into test writers, issue finders, and fixers because bounded tasks worked better. The bound has to be on the credential, not only on the job description. A fixer with the finder's token and the deploy token is three agents in one process.

Do not leave the credential in the repo the next agent will read. A .env, a CI variable printed in a failed log, a Terraform state bucket the agent can cat, and a README that says "the deploy key is in 1Password, here's the item" are the same bug. The PocketOS case was a token in an unrelated file. The swarm makes that case worse because more agents read more files, and one of them will be told to look around. The file should not contain a production token. If it must contain a token for a local tool, that token should be unable to touch production, so the curious read is a dud.

Revoke on a signal you already have. A failed gate, a task timeout, a person hitting stop: the credential dies with the task. A token that lives until someone remembers the dashboard will outlive the agent that needed it, and the next agent in the same environment will inherit it. Inheritance is how a sandbox becomes production. Short life is the control that still works when revocation is late.

Shared CI tokens are the current version of this mistake. One GITHUB_TOKEN or one cloud key in the runner, every job an agent can trigger, every job an agent can read the logs of. Split the workflows. The workflow that runs tests on a pull request does not have the workflow that deploys. The agent may open the pull request. It may not approve it, and it may not mint the deploy identity. If it can edit the workflow file, it can give itself the deploy identity in the next commit. Protect the workflow the way you protect the policy. A required reviewer who is not the agent, on those paths, is the control.

When one agent calls another

Swarms delegate. The test agent files an issue, the fixer agent takes it, a third agent reviews the patch. Each hop is a place where privilege can grow. The agent that receives the task inherits the urgency and, unless you stop it, the permissions of the agent that sent it.

AWS published a sample for this, Cedar authorization for agent delegation, aimed at the OWASP agentic risk of identity and privilege abuse. The sample checks three layers, and a call needs all three to permit. The first is the agent and the tool: trust level, namespace, whether this agent is allowed to be in production. The second is the hop: a depth limit (theirs is five) and a rule that the requested task has to be a subset of what the target agent is registered to do. The third is the person who started the chain: their role, their MFA, their allowed depth. A low-privilege user must not get a high-privilege effect by asking an agent that is allowed to ask another agent.

The detail that makes the third layer real is that the originating user is carried in a way the agents cannot rewrite. The sample uses an HMAC over that context. A header the next agent is free to edit is not a user. It is a suggestion. This is the same bug as a tool argument named userId that the model fills in, covered for product logins in why a Cognito session does not bind the agent. In a swarm the forged field says which agent is asking. Overwrite it from the verified context, or do not accept the delegation.

Depth limits exist because a swarm will otherwise recurse. Five hops is a number from a sample, not a law. Pick a number you can draw. Log every hop with the task id, the caller, the callee, and the credential id. A chain you cannot draw is a chain you cannot revoke. When something deletes a bucket, you want the hop that held the credential, not a paragraph from the agent about what it meant to do.

People in the loop belong on the hops that are hard to undo. Merging to a default branch, deploying, paying, deleting, and sending mail to customers are not fixer tasks. They are approvals. The agent prepares the diff. A person, or a policy that is narrower than "the tests passed," takes the action. The emulator gate automated the merge because the tests were the spec and the blast radius was a local emulator. Your default branch is not a local emulator. Do not automate the merge just because AWS automated one inside a system they could oracle.

Identity that is not a copied API key

The Cloud Security Alliance's note on securing swarms lists the controls that show up in every one of these papers once you translate the vocabulary. Each agent instance needs its own identity, the kind you can put in a JWT and tie to a workload, not a key file checked into the repo. Actions need a trace from the prompt to the tool. Tools the agent was not granted do not answer. Network policy denies agent-to-agent calls that are not in the manifest. Static API keys are rejected because they have no task and no expiry.

1Password's write-up of production swarms makes the same demand from the secret-manager side. Agents need an identity from creation to execution. Access is scoped, time-bound, and revocable. A human still approves the high-impact action. The runtime has to isolate agents the way a cluster isolates workloads, because a process that shares a machine with another agent's environment variables has already failed the identity split. If two agents can read one .env, they are one agent.

None of this requires a new product category to start. A cloud's workload identity, a CI OIDC token, and a policy that maps a workflow to a role are enough for a single pipeline. The swarm fails when someone skips that and pastes a key so the demo can deploy. The demo becomes the architecture. Replacing the pasted key is the work. Buying a platform before you have removed the pasted key is how the platform and the key both end up in production.

Sandbox the execution even after the credential is right. A correct token in a process that can also read the host's ~/.aws is a correct token plus a stolen one. The network boundary is the same story. An agent that may call the package registry and the model API may not call the metadata service, the production database, or an arbitrary webhook. Egress lists are dull. They are the list that would have made the exfiltration call fail even though the prompt was convincing.

What to copy from the emulator, and what to leave

Copy the bounded role. Test writer, finder, fixer, each with a definition of done a machine can check. Copy the gate that can say no without asking the model to agree. Copy the habit of one issue at a time, so a credential for "the issue" is a credential you can scope.

Leave the impression that unreviewed merges are safe because a large vendor did them. They did them into a project whose spec is a public API and whose oracle is their own cloud, and the result still fails a large share of its tests and does not enforce IAM. Your app's spec is a chat. The gate has to be stricter, not looser, because the oracle is worse.

Leave the shared token. If the only way your swarm can run is a key in a secret the runner exports to every step, you do not have a swarm yet. You have a script. Split one workflow out, give it a role that can do one thing, and see what breaks. What breaks is the real permission the agents were using. That list is the design.

Name the minter in the same diagram as the agents. If the minter is a script the fixer agent can edit, the fixer has every credential the minter can create. Put the minter in a repository the swarm does not push to, and require a person on its changes. A monorepo that holds both the application and the token broker is one pull request away from the agent widening its own role. The emulator agents had a gate in front of mainline. Your token broker needs a gate the agents are not members of. That is a boring repository permission, and it is the one that makes the rest of the policy true.

A person owns the policy files. Agents open pull requests against the application. They do not open unreviewed pull requests against the policy that binds them. The day an agent can edit its own allowlist is the day the allowlist is a prompt.

What to check before a swarm is allowed to merge

1. Name each agent role and the credential it receives. If two roles share a key, they are one role.
2. Confirm the credential expires with the task. A key older than the task was not minted for the task.
3. Confirm production deploy credentials are minted by a workflow the coding agents cannot edit or approve.
4. Search the repo and the logs for tokens. A token the agent can read is a token it can use. Move it out, then rotate it.
5. If agents delegate, require the originating user and the hop list on the allow decision. A check that only names the last agent is not a check.
6. Log task id, agent id, tool, and credential id. If you cannot answer "which credential deleted that," you cannot run a swarm.
7. Keep a person on merge to the default branch until the oracle is as strong as a vendor's API suite. It is not.

The swarm can write the patch. The key that ships it stays outside the swarm.

How Techtribe locks a swarm's credentials down

We read the repo and the workflow files and list every credential an agent can use, including the ones sitting in logs and env files. You get a map from task to token, and a cutover that removes production keys from the machines that write code. We do not rotate a key and put the new one back in the same file.

A one-time cutover fits when the agent is a developer's editor and the token is a personal key. A Dedicated Team fits when agents run in CI or can deploy, because the next workflow someone adds will export the key again unless a person owns that file. The scope call is 30 minutes with a founder, and it is where we say which you are in.

Bring the repo and the token the agent can see. If that token can already reach production, say that in the first sentence.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.