Permissions

Capability tokens, not sessions

Where most platforms hand out a session that can do everything the user can do, our support threads and similar surfaces use per-resource capability tokens. A token grants exactly one thread. If it leaks, the exposure is that thread — never your identity, never anyone else's data, never an escalation path. Tokens are unguessable random values, checked server-side on every request, and revocable individually.

Task scopes in the runtime

Inside Y0, every data read must trace to a task the user initiated. A granted scope is a loan, not a standing license: it is bounded to the task, logged in the audit trail, and expires with the run. The trust kernel sits between every model call and every byte of user context and enforces this mechanically — a prompt-injected model cannot widen its own scope, because scope is checked outside the model.

Properties the model enforces

• ↳Least privilege by construction — the default grant is nothing.
• ↳No ambient authority — every access names the task that justified it.
• ↳Revocation is one action and takes effect on the next request.
• ↳Admin access runs on a separate key namespace; a visitor token can never escalate into operator access.

The honest limits

Within a granted scope, the runtime sees what it sees — task scoping bounds the blast radius of a compromised run, it does not make the run trustworthy. And scope definitions are written by us, which means a scope drawn too wide is a policy bug the architecture will faithfully enforce. Scope reviews are part of spec review for exactly that reason.