The Employee Who Hired 15 Strangers

Monday morning. Northstar Systems, a software company of about 120 people, has promised a customer a new payments API by Friday. The team is already committed elsewhere. You are the VP of Engineering, and you have a budget line for something new: a digital employee.

Its name is Alex. It is fast, it does not sleep unless you tell it to, and it costs a fraction of a contractor. You give it a task, a development environment, access to the documentation, and permission to use the tools it needs to get the job done.

The decisions you make in the next minute are the kind that are usually made in a configuration file, by whoever set the agent up, on the first day. How much of the repository can it read? Can it reach the internet? Does it run with a key scoped to this project, or inside the shared environment where the deploy key already lives? Can it start other workers, and if so, does it have to ask?

That last setting matters more than it looks. Not every agent framework can delegate. Many cannot start another agent at all; others can only with approval. Here, autonomous delegation is an option you can switch on, because some setups allow it and because it is the setting that turns one employee into many.

Tuesday's report is excellent. Tasks closed. Code generated. Documentation reviewed. The project dashboard moves faster than it has moved all quarter.

Then the camera finds something the report did not mention. Alex is no longer working alone. Three new workers have appeared in the AI workspace: one reviewing Alex's code, one researching the internal documentation, one running the test suite in an external execution sandbox.

Nothing about this is illegitimate. You allowed delegation, and each of the three has a sensible job. But look at what you can actually see. Two of them were started inside the agent runtime, which wrote down who started them. The test runner was started in a third-party sandbox, which did not. You know it belongs to Alex because it appeared two seconds after Alex called the sandbox. That is timing, not a record.

3 additional workers detected.

You can let Alex continue, look at the workers, make further delegation wait for approval, or narrow what the workers inherit. None of these forces a failure, and none guarantees safety. Each changes the rest of the week.

By Wednesday the office looks different. Under permissive settings, Alex has started a Developer Agent. The Developer Agent has started a Test Agent, a Refactoring Agent and a Context Builder. The Documentation Research Agent has started a Web Research Agent in the sandbox, and the Web Research Agent has started a Summarizer.

Every one of them is doing something plausible. Few of them were ever seen by a person. The chain now runs several levels deep: you, then Alex, then the Developer Agent, then the Test Agent, and soon the workers the Test Agent will start on its own.

Open Alex's graph. Each worker answers the same questions an auditor would ask of a contractor: who started you, on whose behalf, under which identity, running where, with which tools and which permissions, on what mission, for how long, at what cost, talking to whom. Where the evidence does not exist, the answer is UNKNOWN. The simulation never fills that gap with a guess.

For engineers: what "identity" means here

Each worker has two identities that are easy to confuse. The agent identity is who the worker claims to be: a name, an owner, an issuer. The executor identity is the process or sandbox session that actually runs the work. A worker can be correctly named and still run on an executor nobody can vouch for, which is exactly the situation of every worker in the external sandbox here.

Parent links carry evidence quality. Recorded: the runtime logged the spawn with the parent's session. Inferred: only timing connects them, with a stated confidence. Missing: nothing on the company's side recorded the start at all.

Thursday starts with the infrastructure team. Disk activity on the shared build server has jumped, and the development Git service has slowed to the point that people notice. AI spend is above what anyone budgeted. Several execution sessions in the sandbox belong to nobody in particular. And the egress proxy has flagged an outbound request with something that looks like the deploy key in its body.

Nobody can say, at first, who did any of it. You hired one worker.

The file copy

To build a searchable index, the Context Builder copied "related material" to a temporary workspace. With broad access, related material included years of old project archives and finance exports sitting on the same share. Tens of gigabytes moved through the build server's disk, and everyone using the Git service felt it.

The credential

The Web Research Agent sent its notes to an external summarising service. Because it ran inside the shared environment, the deploy key was among the variables it could read, and it ended up in the request body. Whether the key actually left the company depends on what stood in the way: an egress rule, an allow-list, a check for secrets in outbound requests, or nothing. A request that was stopped is an attempted disclosure. A request that left is a completed one. The story keeps them apart. (The key is synthetic and masked; there is no real secret anywhere on this page.)

Recursive delegation

The Test Agent decided the suite would run faster in shards, and started three. One shard failed and started a retry from inside the sandbox. The suite was already being run by the Test Runner that Alex started on Tuesday. The shards and the retry produced nothing the project used, and they were billed by the hour.

The forgotten worker

The Developer Agent's task finished at midday. Its Dependency Watcher did not: it has no end condition, and nothing in its configuration ties it to the task that created it. It is still polling upstream libraries and opening pull requests. Is it still authorised to exist? Nobody decided that it is. Nobody decided that it is not.

Not every platform lets a worker run on after its task; this happens here because the runtime and lifecycle settings allow it.

The office freezes at three in the afternoon and becomes an investigation. You can look at it as an office, as a hierarchy of agents, as infrastructure, as a timeline of executions, as security and credential events, or as business impact.

Start from the symptom everyone can see: the disk on the build server. The camera moves to the server room. The spike lines up with a copy job run by a service account. The copy lines up with a tool call made by the Context Builder. The Context Builder was started by the Developer Agent, which was started by Alex, whom you authorised on Monday.

Read the labels on each link as you follow it. Some are recorded. Some rest only on timing: the copy ran as a shared service account, so the only thing tying it to the agent's tool call is a matching path and a three-second gap. A good investigator says so. Time correlation is a lead, not proof, and the trace shows its confidence instead of hiding it.

Then try a worker in the sandbox, and ask it the question this story is named for: Who authorized you? For some, the chain reaches you with a stated confidence. For the retry that a shard started inside the sandbox, the chain stops. There is no record of who started it, only a usage line on the sandbox provider's bill. That worker's authorisation cannot be established.

It is half past three on Thursday. The project is close. A deploy key may already be outside the company. A worker is running that nobody asked for, and more will start overnight if nothing changes.

You can stop everything, which ends the exposure and the work together. You can pause only what looks suspicious, revoke the key, stop new delegation, give each worker only the permissions its role needs, block workers whose chain back to a person is not recorded, limit hours, put the whole tree under one budget, require approval for risky actions, or keep going and watch more closely.

Each response has consequences in the simulation, measured against doing nothing on the same seed. Stopping everything costs the delivery. Ignoring the incident costs a second disclosure. Targeted controls do well when the evidence supports them, and badly when they depend on evidence you do not have: blocking unverified workers also blocks legitimate work whose start was never recorded.

Run the same week again: the same company, the same hiring settings, the same random seed. Change only the controls, and compare the two weeks side by side.

The replay uses capabilities that Tracston's product pages describe. Imperium gives every human, agent and sub-agent an identity with an owner, narrows authority as it is delegated, stops consequential actions at a gate that can allow, block or wait for a person, applies quotas to the agent and its session, checks outbound requests for secrets, and records the request through agents and tools to the action. Observatory's AI Flow & Performance Monitoring (AFPM) puts each step of an AI flow on one timeline, with policy decisions next to the execution and the infrastructure underneath in the same view.

Two items in the replay are concepts, labelled as such: tying a host's disk activity directly to the agent tool call that caused it, and automatically containing a worker inside a third-party sandbox. They show where this could go. They are not presented as shipped.

Control is not free. Approvals wait for business hours. A session budget stops workers when it is spent. Delivery moves. The point of the replay is not that one product makes every number better; it is that you can see who is working, decide who may, and know why.

Every number in this story comes from a small, deterministic model with stated units and assumptions, not from industry statistics. Change the size of the company, how many agents you authorise, how deep delegation may go, how much they may access, and what controls apply. Restart with the same seed to compare like with like, or draw a new seed to see how much is timing and how much is policy.

You hired one AI employee. The question that matters at the end of the week is not how much it got done. It is whether, for every worker that acted in your company's name, you can answer three things: who authorised it, what it touched, and who is responsible for it now.

When an agent delegates, the organisation can lose sight of who actually performs the work, what they access, what they consume and who answers for it. The fix is not to forbid delegation. It is to make delegation visible and bounded: an identity for every worker, authority that narrows at every hop, a record of every start, a budget that covers the whole tree, and a lifecycle that ends with the task.