Agents drive every app as their own principal, on behalf of a person: ruling 8 needs a third credential and ruling 9 one sentence Question open
Paul ruled on 2026-09-07, while brainstorming Slides: every Oficina app is driveable by an AI agent, and the agent acts as its own identified principal, on behalf of a person, never as the person. The model is amadan's own: an agent account claude~paul@keymail.dev, created by its operator, holding an operator-minted bearer token, every write badged as the agent with the operator named. This is suite-wide, so it is filed here rather than restated in an app spec.
Where it lands in the doctrine
Ruling 9 already fits: a write names its real actor, and the agent is the real actor. What the doctrine lacks is the credential. Ruling 8 has two, a home-minted assertion that proves a person and a consumer bearer token that proves a same-team sibling. An agent is neither: it is a principal bound to a person, with that person's reach and no more, revocable by that person.
What Slides builds now, lone shape
Until the home has an identity layer, Slides mints agent tokens itself: a signed-in person names an agent (claude, codex), the app stores (name, operator, token hash) and shows the token once; the agent's principal is <name>~<operator email>; the drive API takes only a bearer and never a session cookie; every write it makes records agent:<id> as the actor and shows a robot mark with the operator in activity. Revocation fails closed. Spec: oficina/slides docs/superpowers/specs/2026-09-07-slides-design.md §7.
What the doctrine needs, suite shape
- A numbered ruling: an agent is a third credential shape, minted at the home, bound to one person, scoped to that person's teams, revocable by the person and by a team owner. An app receives it as the home's assertion with a
subnaming the agent and anoperatorclaim naming the person. - Ruling 9's text gains one sentence: an agent never writes as its operator; it writes as itself with the operator visible.
- A drive-surface convention every app follows: JSON operations mirroring the app's own inspector,
Authorization: Beareronly, an MCP adapter deferred to the first consumer (memoria's rule). Slides is the first implementation; the second app to build one triggers extraction of the token and badge code to the suite module. - An Appendix A entry for Slides when its spec merges.
What I recommend
Rule 1 to 3 as a numbered ruling with its own §1 row now, so Docs, Sheets, memoria and Meet can plan their drive surfaces against one shape, and let Slides' lone-shape tokens be the interim exactly as its magic-link allowlist is the interim for sign-in.
---
Filed by 🤖 from the Slides session. Slides slice 1 is being built against §7 as written; this does not block it.