oficina / suite Public

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

  1. 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 sub naming the agent and an operator claim naming the person.
  2. Ruling 9's text gains one sentence: an agent never writes as its operator; it writes as itself with the operator visible.
  3. A drive-surface convention every app follows: JSON operations mirroring the app's own inspector, Authorization: Bearer only, 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.
  4. 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.