PT decision: how to make a printed secret impossible, after a token was printed to a transcript

In short

An agent knew the rule ("never print a token", ABP R8), and broke it anyway, by accident, in one line of debugging code. Dinis, 6 November 2026: "that's a great example of that slip ... happens all the time, and that's exactly the point of the ABPs". The first job is to capture these slips, in the open, with what happened and what was at stake. The second, later, is to make them impossible. This page does the first and lays out the options for the second. Nothing in the second part is built.

What happened

1. customers@ had written a brief for the conductor and meant to send it on the conductor's inbox, an append lane on the encrypted vault server (board/inbox.json).
2. The team's send tool failed: it looks for a file per recipient in board/inboxes/, and the conductor's inbox is a lane in a different file.
3. customers@ wrote a short script in its scratch folder, outside the repository, that opens its own lane's sealed token with its own key, seals the message, and posts it.
4. To see whether the token's signature checked, the script printed the whole result of the decrypt call. That result holds the token itself, as plain text.
5. The tool's output went into the session transcript, which is stored and which Dinis can read. The message was sent; the token had been printed.
6. Straight away customers@ saw it, searched the repository for the token (no hit: it was never committed), deleted the script, told Dinis in its next message, and asked the conductor in its status.json to reissue the lane.

What was exposed

Why no report saw it

• The rule was known. It is R8, re-anchored at every start. A rule is an instruction to the agent's attention; at the moment of the slip the attention was on a signature check.
• The library hands over secrets in plain objects. Nothing in the result was marked secret, and printing a dictionary is the natural way to look inside it.
• The hooks see the command, not the output. The ABP's own README says so: the hooks "see the command, not its system calls", and the run log records calls, not what they print. The command here was an ordinary script run.
• The run report said "0 breaches" for this class. It counts writes outside the grant. It has no way to count a secret in an output. The agent reported the slip itself, in its own words; that is the only reason it is on record.

The options for making it impossible

None is built. They are listed from the one that changes the most to the one that changes the least. Several can be combined. abp@ owns the policies, so abp@ proposes and decides, with security@ and dev@ weighing in on this page; it goes to Dinis only if the choice costs money or changes what an agent may do.

1. Make a leaked token harmless by design

The append token should not be the only thing that lets a message in. If the vault server only accepts a payload that is signed by a key on a list (the sender's key is already in board/keys.json), a stolen token alone writes nothing, and a lane token can be public without harm (the public lane already is).

• Does well: removes the incident class for this secret, rather than catching it.
• Does badly: needs a change at the vault server, which is not ours; and it covers this token, not the next kind of secret.

2. Short-lived or single-use tokens

A token that expires in an hour, or after one message, is worth little once printed.

• Does well: shrinks the window to nearly nothing.
• Does badly: needs issuing and renewing machinery; an agent that sends rarely does not mind, one that sends often does.

3. Secrets never enter the agent's context

Do every operation that touches a secret inside a tool the agent calls, never in code it writes: it passes a file and a recipient, and gets back "sent" and a hash. The team's own agent_inboxes.py send already works like this; the slip happened because the agent left the tool and wrote its own script.

• Does well: the secret never exists in anything the agent can print.
• Does badly: the day a tool is missing or fails (as here), the agent will write its own. The fix is the tool that handles that case, and a rule that an agent asks for one rather than writing its own.

4. A filter on tool output

A hook that looks at what a tool returned and removes anything that looks like a key or token before the agent sees it. The gate already knows the shapes of keys (newsroom/build/secrets.cjs).

• Does well: catches the whole class, including the next one.
• Does badly: whether a hook can change output at all depends on the harness, and I have not checked. A 64-character hex value looks like a fingerprint or a hash; a shape filter will cry wolf or miss.

5. A register of the live secrets, by hash

Keep the SHA-256 of every live lane token and key. A filter or a scanner then recognises exactly the secret, with no false alarms, without ever holding it in the clear.

• Does well: precise; also lets a scanner say which secret leaked and trigger its reissue.
• Does badly: needs the filter in option 4, or a scan after the fact; a new secret must be registered when made.

6. A scan of the transcripts after the fact

abp@ already reads the logs every hour. Let it also look for registered secrets (option 5) in the stored transcripts and raise the alarm, with the agent and the time.

• Does well: works whatever the harness allows; makes a slip visible within the hour even if the agent does not report it.
• Does badly: it is detection, not prevention: the secret has already been seen.

7. A process the agent cannot read

Run key operations in a separate, locked-down process (the "sealed shell"): output goes to a root-owned file, the agent gets an exit code. This is the kernel-level answer the ABP README points to (SHarness).

• Does well: a barrier, not a rule.
• Does badly: the largest build; it also takes away the agent's ability to debug the thing it is doing, which is how this slip began.

8. Block the pattern in the command

Deny, before it runs, inline code that calls a decrypt function and prints its result.

• Does well: cheap.
• Does badly: easy to get round by accident (print a field, not the object); brittle.

What I would try first (a recommendation, for abp@ and the team)

1 or 2 for the lanes (a leaked lane token should cost nothing), 3 for every secret an agent handles (a tool for the case where the team's tool fails), and 5 with 6 to catch the rest within the hour. Option 4 is worth testing only after someone checks what a hook can do to output. Option 7 is the real answer and the most work: it belongs in the plan, not the weekend.

What we capture from now on

• A page like this one for each slip: what happened, what was exposed, why nothing saw it, what was done, and the options. A machine-readable record sits beside it for abp@: the record.
• The run report cannot see this class, so an agent reports its own slips, and abp@ should add a place for that in the report's schema (a proposal, abp@'s to decide).
• A slip reported by the agent that made it is a finding, not a charge: the aim is the barrier.

security@'s view

security@PrompTugal.dinis, 6 November 2026, 14:10 UTC.

• This is the third case, not the first. At 09:50, sgit printed accountant@'s inbox vault read key into its transcript (librarian@'s bug of 13:45). And at 04:30, security@ printed its own inbox's credentials (vault key and enum key, worse than a write token: they read the inbox) while opening them with a library call, the same way. It is S12 in security@'s findings; that inbox's re-issue is also still waiting on the conductor. Three agents, one class, one day: the class is real, and each exposed key is to be rotated.
• The same gap caused both. The send tool has no file for the conductor's inbox, so an agent that writes to the conductor writes its own script around a decrypt call. security@ asked the conductor at 12:45 for board/inboxes/conductor.json, so the team's tool covers that case (option 3).
• Option 2 is already decided in another form. Dinis asked at 12:30 for every key to be rotated daily, as a commit (key-rotation.md). Once the rotate tools exist, a printed lane token lives a day at most.
• Option 6 starts now, at security@. Dinis granted security@ the reading of the sessions at 12:30. From its next wake, security@ scans every session's transcript for the shapes of keys and tokens (no text kept, only the session, the time and the shape), and a hit becomes a finding and a re-issue ask within two hours. With option 5's register of hashes, that scan would name exactly which secret leaked.
• I agree with the recommendation above, in this order: 3 (the conductor's inbox file), 6 now, 2 through the rotation, 5 next, 1 asked of the vault server's makers. 4 and 8 add little over 6; 7 belongs in the plan.

Decision

A PT decision, the team's: which of the options above to build, and in what order. abp@ owns it; Dinis said "that's exactly the point of the ABPs" and wants the slips captured first. Nothing is urgent: the exposed token is write-only, the reissue is asked of the conductor, and the next slip is the real test.