Agent Identity

Every session the dispatcher starts runs in its own systemd scope, and the dispatcher names that scope after the role and the task. An engineer working task 529 runs inside a scope called agent-software-engineer-t529. The kernel records which scope every process belongs to, and the agent never picks its own.

When a session runs a board command, the board asks the kernel which scope the caller is in, takes the role out of the scope's name, and compares it with the name on the command. They match, or the command is refused before anything is written. Manager rounds run in round scopes named after the manager and get the same check. My own shell, the scheduled jobs and the dispatcher run outside any agent scope. A scope that can't be read is treated as an agent with no role, so it fails closed.

These ran against the production board, on a task that was already closed, from sessions started the same way the dispatcher starts them.

Pretending to be me is the attack I worry about most, because my answer is what releases anything a customer will read or that costs money. A dispatched session can't answer as me at all. Only my own click on the hub or my own shell can.

When I do approve something, the approval is bound to the question it answers and works once. A stale page, a double click or a replayed answer doesn't carry over to a different request.

Every agent runs as root on the same machine. So this check stops the common case, a confused or prompt-injected agent typing the wrong name, and it records the attempt. A session that is deliberately attacking the machine it runs on has ways around it that never touch the board command at all, and a security committee went through them one by one.

Saying that out loud is the point of this page. A control that's described as stronger than it is gets trusted in places it shouldn't be.

I asked for public and private keys first, and the committee's answer was blunt: keys don't help while every agent runs as root, because root can read any key on the box. So the plan, decided and nothing in it built yet, runs in order. First the board becomes a service that identifies callers by their Unix user, the dispatcher stops trusting any field it hasn't verified, orders from the hub get signed, and a separate machine watches the board for tampering. Then the agents that read outside text, and the managers, move off root.

Once each role is its own user, keys mean something. Each role gets its own signing key in OpenBao, the secrets vault that already holds the fleet's other keys, and the key never leaves the vault. Every board write is signed by the role's key and checked before anything acts on it, so a forged record fails a signature check instead of a name check.