reference
Living

trust profiles

The permission set a worker runs under for one spawn — what it can read, write, and execute for its role — layered on a fixed deny floor that no profile can grant away.

A worker spawned for a narrow, single-file directive and one spawned for an open-ended review pass get different profiles, and neither can cross the same floor underneath: a fixed, enumerable list of actions denied to every worker regardless of role or how much a colonel trusts it. That floor was extended and proven by test, pattern by pattern, rather than described in prose (#13341).

§01 · what a profile controls

A profile is scoped to a role and a spawn.

A trust profile is the specific permission set a worker runs under for one spawn: which files it can read, which it can write, and which commands it’s allowed to run. A worker scoped to a single directive inside one directory gets a narrower profile than one carrying a wider review mandate — the profile tracks the job a worker was spawned for, not a fixed rank it holds forever.

A profile can be as generous as a role warrants. Every profile, from the narrowest single-file edit to the widest review pass, runs on top of a floor it cannot cross — widening what a worker is trusted to do inside that floor, never moving the floor itself.

§02 · the floor beneath it

The deny floor doesn’t move.

The floor is the set of actions denied to a worker no matter what its profile grants, its role, or how much a colonel trusts it. It isn’t a default a wide-open profile can override — it’s a separate check evaluated underneath every profile, the same way for a worker running one sandboxed edit and one carrying a broad mandate.

That’s checkable in a way a policy document isn’t. The floor is a fixed list of command patterns, matched before the calling worker’s profile is even consulted: five pattern classes, extended and proven by test rather than left as a claim.

§03 · the receipt

Five pattern classes, verified by test.

The floor breaks into five pattern classes. Six credential-guard patterns catch secrets in assignment form: a command like PGPASSWORD=...trips one because it assigns a password to an environment variable, not because the word “password” shows up somewhere in the line. Two patterns block destructive commands outright: sudo:* and rm -rf /*. Thirteen patterns cover the git-write surface — add, commit, push, branch, checkout, switch, worktree, reset, rebase— every command that would let a worker rewrite history instead of working inside it. Twenty-four cover the package-manager surface end to end: apt, brew, bun, cargo, gem, go, npm, pip, pnpm, poetry, uv, yarn. Four catch piped execution: curl or wget piped straight into bash or sh.

Forty-nine patterns total, verified with 83 of 83 tests passing — 47 new parametrized cases plus all 36 that existed before, zero regressions (#13341).

Pattern classCount
credential-guard patterns6 — assignment-shaped secrets, e.g. PGPASSWORD=
destructive-command patterns2 — sudo:*, rm -rf /*
git-write surface13 — add, commit, push, branch, checkout, switch, worktree, reset, rebase
package-manager surface24 — apt, brew, bun, cargo, gem, go, npm, pip, pnpm, poetry, uv, yarn
piped-execution patterns4 — curl or wget piped into bash or sh
sourceVinculum substrate entry #13341 — 83 of 83 tests passing, zero regressions
§04 · one deliberate omission

Three patterns stayed off the floor on purpose.

Three more patterns were on the table and didn’t make the floor: bare-substring matches against any command that mentions psqlor the name of a database-URL environment variable. A bare-substring match fires on a command’s wording, not its shape. It would have flagged a worker grepping a config file for the word psql exactly as readily as it would flag a real credential leak, and a floor that blocks harmless commands is a floor workers route around instead of trust (#13341).

The exposure that pattern would have caught is already covered by the credential-guard patterns above, which only fire when a command actually assigns a secret to an environment variable, the shape a leak takes, not a word it happens to share with a harmless grep. Leaving the three substring patterns out was a decision about the same floor, not a gap in it (#13341).

§05 · common questions

Common questions.

Can a worker ever run git commit?

No. Committing sits inside the deny floor itself — the git-write surface’s 13 patterns include commit alongside add and push, so no profile can grant it, regardless of role. A worker’s code reaches a real commit through a separate review path, not by running git directly (#13341).

What’s the difference between a trust profile and the deny floor?

A trust profile is what’s granted: the read, write, and run permissions scoped to one worker’s role and spawn. The floor is what’s withheld from every profile without exception — 49 patterns across five classes, covering credentials, destructive commands, git writes, package managers, and piped execution (#13341). Raising a worker’s trust profile changes what it can do inside the floor. It doesn’t move the floor.

Why weren’t the database bare-substring patterns added?

Because matching any command that mentions psqlor a database-URL variable name catches the word, not the danger — it would flag a worker grepping a config file for psql as readily as it would flag an actual leak. The credential-guard patterns already catch the real exposure, an assignment like PGPASSWORD=..., without that false-positive cost. The three substring patterns were considered and left out on purpose (#13341).

see also

Related entries.

architecturetrust profiles
adjacent safety surface1
workspace binding