it was ['notify'], on the argument that "an agent may tell me things" is far
smaller than "an agent may act as me", and that everything else an agent needs
it already has because it runs as somebody, in their home, with their files.
both true. the second is what undid the first.
an owner's agent has a shell AS THE OWNER, unsandboxed. it can read .env, query
postgres, decrypt a plugin's stored credential, docker exec into a container.
so scoping its key to notify never made it safer — it made it unable to use the
platform POLITELY while every impolite route stayed open. that became visible
today: a chat asked to take a proxy host out of service correctly reported it
could not, having read this file, while sitting one docker exec from the same
container.
a route through the platform is authorised, logged and bounded by a permission.
one around it is none of those. withholding the first does not prevent the
second, it only chooses which gets used.
so: the holder's own authority, minus admin. a RULE against the live registry,
not a list — a plugin installed next year works from a chat without this file
changing. the alternative on the table was adding each plugin's key to an array
here, which puts plugin names in core and hands every plugin to every chat, one
line at a time, forever.
execution needs no exclusion; authorize.ts strips it whatever a row says. admin
is the one worth naming: an agent may use the server and may not administer it.
accounts, grants and plugin installs stay with a person.
and it is NARROWER for a member, which is where it counts — their agent runs as
their own linux user with no owner environment, so this key is a real boundary
resolving to exactly what their role was granted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5
355fcaf1e5