The account that reasons holds no secret: agents and authority

Give an agent a token and a convincing enough request will make it use it. A rule in its instructions does not stop that; an account that simply does not have the token does. Our whole setup follows one principle: the account that reasons holds no secret, and the account that holds the secrets does not reason. You cannot talk round a program that does not read.

What you get. Agents that deploy, open pull requests and create repositories all day, with no credential in their reach. Every powerful action goes through a small service that checks who is calling and accepts only a name from a fixed list.

1. Authority behind a socket

A small service, running under its own account, holds the forge token. It listens on a Unix socket, and the kernel tells it which user is calling (SO_PEERCRED): no password to steal, no token to leak. The agent sends "open a pull request from this branch"; the service checks the request, then acts. The agent never sees the token.

2. Deploy without a password: a closed list

Our deploy daemon runs as root and accepts exactly one thing: the name of a component from a table written inside the daemon. No path, no branch, no command. For that name it refreshes the mirror, reads the file at main, validates it, backs up the installed copy, installs, restarts what the table says, and answers one line of JSON.

Each rule was paid for:

• The daemon is not in its own table. When it was, one merged commit could rewrite what root was allowed to write, and it was used that way three times in one day. Updating the daemon now takes a human and a password.
• The mirror is refreshed before every read, or a deploy right after a merge installs the previous version and says "ok".
• Invalid content never goes in place: Python is compiled, YAML parsed and checked, before any write.
• A file mounted into a container is written in place: a rename gives it a new inode and the container keeps reading the old one, silently.
• A client that hangs up must not kill the listener: it once did, and systemd counted the failures until it refused to start.

3. No repository without its guard

Creating a repository is one call: create, protect the main branch, push the first commit, wait for the CI, tag, publish the release. The protection step is the same code every path uses. If it fails, the new repository is deleted; if the deletion fails too, the error names the unprotected repository. And the CI result is polled by the service, never asserted by the caller: there is no "green" argument anywhere.

4. A bug becomes code, never a note

A rule written in a guide in the morning was broken in the evening by the person who wrote it. What holds is ordinary code: a lock, a check, a refusal. What cannot become code becomes a journal entry you can search.

Traps

Do not let the tool that enforces the limits be deployable by the limits it enforces. Updating the guard must need a human.

Exit codes are part of the contract: 0 done, 1 a named failure, 2 a named refusal, 3 and above a technical problem, never a verdict.

Found this useful? Tell us what to measure next.