feat(aosguard): aosguard operates the estate, it does not create principals #1083

Merged

coilysiren merged 1 commit from aos/claude/ym96-no-user-create into main

2026-08-16 02:09:24 +00:00

coilyco-ops commented

2026-08-16 01:51:40 +00:00

Member

Kai's answer to the open question on #1082: aosguard should not be creating users. Those scripts can stay on aws ssm.

Recorded as denials, not as absence

Absence is not a boundary. The next agent wanting adminCreateUser would have added it and been right to by local reasoning - every other Forgejo admin operation is on this wrapper, so user creation looks like an oversight rather than a decision. A never leaf carries the reason instead.

never create user        adminCreateUser
never delete user        adminDeleteUser
never create admin-org   adminCreateOrg

Verified they fire:

$ aosguard ops forgejo-admin user create
aosguard: aosguard does not create Forgejo users: a guard that can mint a
principal can mint one with any rights. Bootstrap scripts read
/forgejo/admin-token from SSM directly - see scripts/provision-coilyco-ops-bot.sh

The callable surface is unchanged at 28. A never leaf adds no verb.

The line, stated once

aosguard operates the estate and does not create principals in it. Everything it does carry acts on something that already exists - a repo, a label, a secret, a package. Minting a user is a different class, because a guard that can create a principal can create one with any rights, which makes every other restriction here decorative.

What stays on the direct read

provision-coilyco-ops-bot.sh and grant-coilyco-ops-org-repo-create.sh keep reading /forgejo/admin-token from SSM as they do since infrastructure#847. They run approximately once, so the standing capability a verb would create costs more than the direct read does.

Those two remain the only scripts in the fleet that hold the PAT, which is a small enough set to state in a doc and check against later.

Note on the spec

The three /admin/users* paths are vendored so the denials resolve. They are reachable in the spec and callable through no verb.

🤖 Generated with Claude Code

Kai's answer to the open question on #1082: aosguard should not be creating users. Those scripts can stay on `aws ssm`. ## Recorded as denials, not as absence Absence is not a boundary. The next agent wanting `adminCreateUser` would have added it and been **right to** by local reasoning - every other Forgejo admin operation is on this wrapper, so user creation looks like an oversight rather than a decision. A `never` leaf carries the reason instead. ``` never create user adminCreateUser never delete user adminDeleteUser never create admin-org adminCreateOrg ``` Verified they fire: ``` $ aosguard ops forgejo-admin user create aosguard: aosguard does not create Forgejo users: a guard that can mint a principal can mint one with any rights. Bootstrap scripts read /forgejo/admin-token from SSM directly - see scripts/provision-coilyco-ops-bot.sh ``` **The callable surface is unchanged at 28.** A `never` leaf adds no verb. ## The line, stated once aosguard operates the estate and does not create principals in it. Everything it does carry acts on something that already exists - a repo, a label, a secret, a package. Minting a user is a different class, because a guard that can create a principal can create one with any rights, which makes every other restriction here decorative. ## What stays on the direct read `provision-coilyco-ops-bot.sh` and `grant-coilyco-ops-org-repo-create.sh` keep reading `/forgejo/admin-token` from SSM as they do since infrastructure#847. They run approximately once, so the standing capability a verb would create costs more than the direct read does. Those two remain the only scripts in the fleet that hold the PAT, which is a small enough set to state in a doc and check against later. ## Note on the spec The three `/admin/users*` paths are vendored so the denials resolve. They are reachable in the spec and callable through no verb. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-16 01:51:40 +00:00

feat(aosguard): aosguard operates the estate, it does not create principals

ci / ward-doctor (pull_request) Successful in 14s

Details

ci / aos-cli-tests (pull_request) Successful in 20s

Details

ci / gate (pull_request) Successful in 51s

Details

868508d06d

Kai's call on #1082: aosguard should not be creating users. The two bootstrap
scripts that need it can stay on a direct SSM read.

Recorded as never leaves rather than as absence, because absence is not a
boundary - the next agent wanting adminCreateUser would have added it and been
right to, since every other admin operation is here. The denial carries the
reason instead.

    never create user      adminCreateUser
    never delete user      adminDeleteUser
    never create admin-org adminCreateOrg

The argument, in the message: a guard that can mint a principal can mint one
with any rights, which makes every other restriction on this wrapper
decorative. That is a different class from the operations it does carry, all of
which act on things that already exist.

provision-coilyco-ops-bot.sh and grant-coilyco-ops-org-repo-create.sh keep
reading /forgejo/admin-token from SSM. They run approximately once, so the
standing capability a verb would create costs more than the direct read.

The callable surface is unchanged at 28 verbs; a never leaf adds none.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-16 01:51:40 +00:00