When Recovery Becomes the Outage

• Across the city, staff are preparing tomorrow’s fire rosters and updating administrative records.
• Several departments depend on the same sign-in service.

• They check services, investigate faults, and carry out repairs within assigned permissions.
• His small team gets through more work because of them.

Repair helpers prepare work for different departments. Each sees its own assignment; several depend on the same sign-in service.

• The security lead approves a reset. Agents begin carrying it out across departments.
• Staff are signed out. They try to return.
• Requests pile up at the service that was already struggling.

• A 2025 campaign. In its account of a 2025 espionage campaign, Anthropic described attackers directing an AI agent against roughly 30 organizations through smaller tasks. It reported successful intrusions in a small number of cases. Anthropic’s account.
• In the lab. Researchers have also demonstrated the problem in controlled experiments: combining models across subtasks enabled misuse that either model alone handled less successfully. Jones, Dragan and Steinhardt, ICML 2025.

• The adversary’s route. In Anthropic’s account, attackers broke an intrusion into routine-looking tasks, hiding the larger malicious purpose from the model.
• The operator’s route. In our fictional city, approved helpers acting on a wrong diagnosis, each within its own allowance, together exceeding what the sign-in service can carry.
• The city’s symptoms. Retry storms, queue depth climbing, recovery jobs competing with production for the capacity they need. Intent matters to the investigation; the service needs relief now.

• Before an action executes, a KTP implementation checks the agent’s authority, applicable boundaries, supporting evidence, and current environmental conditions.

You can’t. Fast water and debris now fill the crossing that was dry ten minutes ago. The truck, the license and the driver’s skill are the same as they were. The wash changed, and the wash decides.

• Approved earlier, checked again now. When the agent reaches the sign-in service, the question is whether the service can take the repair at that moment, not whether it could when someone approved it.
• A repair that adds load can wait. If the service is already overloaded, one more restart or retry piles onto the thing it is meant to fix. A repair that would exceed the service’s current limits would be held or narrowed.
• The check runs at the moment of action. The engineer on call is no longer the only thing standing between a well-meant repair and a deeper outage.

• Short by design. A proof that lapses in seconds cannot be reused after it lapses or stretched across a shift. KTP Core specification.
• Fresh evidence, every time. A new proof needs current supporting evidence. Refreshing a token does not make an old observation fresh.

An agent halfway through a long repair does not keep the permission it started with. Every few seconds it has to show again that conditions still support what it is doing.

Back in the city, every department’s repair agent is inside its own allowance. None of them is misbehaving. All of them are hammering the same sign-in service, and that service has one capacity, not one per department.

• All three repeated the same faulty status feed.

The design keeps track of where each piece of evidence came from, so echoes never add up to confirmation.

• Each retry adds another request to the crowded service.
• The engineer stops the bulk job, but the exceptions now need review.

• Hold, don’t hammer. KTP’s handback proposal pauses affected repairs while a decision waits, instead of letting them retry into the crowded service.
• Respect the reviewer’s bandwidth. The handback accounts for how much the receiving team can take, so the on-call engineer is not buried.
• People set the priorities. The protocol carries them out. The security lead and department heads decide what matters most, and those calls reach execution intact.

• The clerk’s file goes through. The work people depend on does not stall behind a repair storm.
• Repairs help instead of piling on. Recovery load stays inside what the service can carry.
• The engineer gets decisions, not a flood. Only the real exceptions reach a person.

• The conditions, not just the verdict. KTP’s Flight Recorder keeps the environment behind each decision, so the night can be replayed decision by decision.

• Use the Trust Infrastructure Audit v0.1 to examine nine things: the trust object, what depends on it, cost, witness, reciprocity, repair, time horizon, lasting residue, and owner.

• Bring evidence for what you know.
• Mark what you cannot yet establish.
• Identify the people who bear the consequences and the person responsible for the next test.

The city may have capacity to run a task and no good reason to run it. An efficient system may pursue a goal that people never agreed to.

Leaders must decide which purposes SHOULD be pursued, who benefits, who carries the cost, and who has standing to object. Those decisions belong before deployment and remain open to review as consequences emerge.

KTP addresses what the environment CAN support within declared boundaries. The complementary work of governing purpose is Tamed Autonomy, developed by Robin Martherus.