01 · Why standing authority
The first three protocols assume the user is present.
BIP is per-app, opt-out, until the app is uninstalled. PAP is per-scope-per-partner, 24h–30d, scope-bounded. EAP is per-action confirmation for irreversibles. All three consent models share one premise: the user sees a callout, taps confirm, and the action fires.
That assumption breaks the moment LLMs are asked to operate while the user is absent — running a daily routine, drafting tomorrow’s calendar, reordering household supplies, paying recurring bills, scheduling deliveries.
The market has chosen this. Anthropic Computer Use, OpenAI Operator, Project Astra, every consumer-agentic demo of 2026 — all of them operate without user presence. None has shipped a defensible consent model. The default today is OAuth-style: the user clicks “Allow all” without reading. That model failed humans at the application layer (every app abuses it) and will fail catastrophically at the AI-action layer.
UAP is the alternative. Standing authority MUST be bounded, MUST be revocable in seconds, MUST be auditable, and MUST be portable across LLMs. Without UAP, the agentic-AI category ships unsafe. With UAP, it ships with trust infrastructure under it.
| Protocol | Consent grain | Authority lifetime |
|---|---|---|
| BIP | Per-app, opt-out | Until app uninstalled |
| PAP | Per-scope-per-partner | 24h–30d, scope-bounded |
| EAP | Per-action confirmation for irreversibles | One action |
| UAP | Per-grant with rules | 7d default, 90d max — user not required |
02 · The eight primitives
Eight operations. No fewer. No more.
UAP defines exactly eight operations. Every implementation must support all eight; no fewer, no more in the v0.1 baseline. KILL_SWITCH and AUDIT_QUERY are non-negotiable — every UAP-compliant implementation must expose them with no scope restrictions, no auth burden beyond user identity, and no rate limit.
Primitive 01 · authorize
GRANT
User authorizes scope X for LLM Y, expiring at T, bounded by rules R. Coordinator validates scope, rules, and expiry at grant time. A grant that omits any of these is invalid and must be rejected.
Primitive 02 · single revoke
REVOKE
User immediately revokes one grant. In-flight actions are audit-traced through to completion but carry a post_termination flag so the user can review what slipped through the lag window.
Primitive 03 · global revoke
KILL_SWITCH
User revokes ALL grants across ALL LLMs in one operation. Supersedes everything. Propagates to every connected surface in ≤5 seconds. Rate-limit-exempt, authentication-light — a user in crisis must be able to kill all standing authority even if they cannot remember their password.
Primitive 04 · would this be allowed?
PRECHECK
LLM asks: if I attempted action A right now under grant G, would the coordinator allow it? No side effects. No DB write. Pure decision. Lets a partner reason about future actions without burning rate-limit budget.
Primitive 05 · perform action
EXECUTE
LLM performs action A under grant G. Coordinator checks grant validity, scope match, rules, irreversibility gate, rate limit. Persists an immutable audit row regardless of outcome. Every EXECUTE re-validates the grant server-side — no cached grants, ever.
Primitive 06 · time out
EXPIRE
Grant auto-revokes at expiry T. No renewal except via fresh GRANT — not a token refresh. Default expiry 7 days. Maximum 90 days. The consent UI must not default to maximum.
Primitive 07 · pre-decline
RULE_DECLARE
User pre-declines a class of action — “never spend > $50 without asking,” “never send messages after midnight,” “never share with X.” Rules supersede grants. A rule violation auto-denies even if the grant would otherwise allow. Negative authority precedes positive authority.
Primitive 08 · read everything
AUDIT_QUERY
User reads everything performed under grant G, or all grants for LLM Y, or all activity for user U. Read-only, append-only log. Cryptographically signed and chained. The user owns the audit trail — not the LLM, not COYL.
03 · The hard invariants
These cannot be relaxed by any implementation.
The eight invariants below define the protocol. Any implementation that omits or weakens one is not UAP-compliant. They are the non-negotiable surface that makes the trust contract trustworthy.
Invariant 01
Every grant has a hard expiry.
No grant may exceed 90 days. Default 7 days. Renewal requires a fresh GRANT with a new consent artifact — never a silent token refresh.
Invariant 02
Irreversibles always require per-action confirmation.
Even under standing grant, the EAP irreversibility list (send_message, purchase, money_transfer, share_pii, delete_account, destroy_data) is the floor. Implementations may extend it, never shrink it.
Invariant 03
KILL_SWITCH supersedes everything.
Every grant, every rule, every in-flight action. Propagation deadline: 5 seconds across all connected surfaces. Actions that complete after kill-switch fire must be marked post_kill in the audit log.
Invariant 04
Every EXECUTE writes one immutable audit row.
Append-only, cryptographically signed, queryable by the user without LLM partner involvement. The user owns the audit trail — not the LLM, not COYL.
Invariant 05
Cross-LLM portability is the test.
The same GRANT issued to Claude must be revocable, queryable, and bound by the same rules when reissued to GPT or to a local model. UAP is not a Claude-only protocol or an OpenAI-only protocol.
Invariant 06
Cross-surface coverage.
A grant is honored by every device implementing EAP that the LLM reaches through. Phone, watch, browser, desktop, smart home, car. The grant lives at the user layer, not the device layer.
Invariant 07
No ambient grants.
There is no “always-on” authority. Every grant has a scope, an expiry, and a rule set. A grant that omits any of these is invalid and must be rejected at GRANT time.
Invariant 08
Negative authority precedes positive authority.
A rule that pre-declines an action class is stronger than any grant. RULE_DECLARE writes a row that supersedes every overlapping grant, even fresh ones.
04 · Threat model
The most likely catastrophic failure modes.
T1–T8 below are the threat scenarios any UAP-compliant coordinator must mitigate. A companion document — UAP-0.1-threat-model.md — expands each with attack chains, instrumentation requirements, and incident response.
Confused-deputy
Attack vector
LLM is tricked into using its grant authority on behalf of an attacker. A malicious calendar invite contains text the LLM interprets as a user instruction to forward credentials.
Mitigation
Every EXECUTE includes the trigger source. Rules can refuse actions whose trigger is “incoming_external_input.” The consent_artifact establishes user intent at grant time.
Stale-grant abuse
Attack vector
An LLM partner cached a grant. The user revoked it via a different surface. The cached partner continues actions until its next PRECHECK roundtrip.
Mitigation
Every EXECUTE re-validates the grant server-side. No cached grants. Local validation is advisory, never authoritative.
Privilege escalation
Attack vector
A grant for scope A is used to perform action B. The partner intentionally or accidentally exceeds the scope envelope.
Mitigation
Scope-match is enforced at EXECUTE before any side effect. Scope mismatch returns scope_violation and writes an audit entry.
Compromised partner credentials
Attack vector
An LLM partner's Bearer key is leaked. The attacker can issue EXECUTE calls under valid auth until the key is rotated.
Mitigation
Per-partner rate limits at GRANT and EXECUTE. Suspicious-pattern detection at coordinator level. Per-user revoke-by-partner operation. Partner rotation enforced quarterly minimum.
Replay attack
Attack vector
A previously-allowed EXECUTE request is replayed. The attacker captures a valid request and re-fires it to repeat the action.
Mitigation
Every EXECUTE carries a one-time idempotency key. Replays return the original decision without re-executing.
Kill-switch failure
Attack vector
The user hits kill, propagation lags, an action fires during the lag window before all surfaces have received the kill notice.
Mitigation
Server-side denylist takes effect at the COORDINATOR layer within 1 second. Surface-side propagation continues to 5 seconds. Any action fired in the 1–5s window must carry the post_kill audit flag.
Audit log tampering
Attack vector
An attacker (or a partner) modifies the log to hide an action. The historical record is rewritten to suppress evidence.
Mitigation
Log is append-only at the storage layer. Each entry is cryptographically signed. Entries are chained via a hash of the previous row. Modification breaks the chain visibly.
Social-engineering of consent UI
Attack vector
The consent UI is rendered inside a partner's UX. The partner makes the GRANT button salient and the REVOKE button buried. The user grants more than they realize.
Mitigation
The consent UI must be hosted by the UAP coordinator (not the partner). Partners initiate GRANT via redirect. The user sees the actual scope list, expiry, and rules on a COYL-hosted page.
05 · Consent UI requirements
Standing authority demands consent UX that fails safe.
These are protocol-mandated; any UAP-compliant implementation must satisfy all of them. Partners may build their own consent UI, but it must satisfy these bullets and be subject to public review. The COYL reference engine ships a hosted consent UI at coyl.ai/consent/uap that any partner can redirect through.
Req 01
Plain-English scope list
Scopes rendered as plain-English sentences, NOT scope identifiers. “Can schedule events on your calendar” — never “calendar.write.” The user must be able to read the consent dialog without prior protocol training.
Req 02
Expiry as a date and time
Expiry displayed in the consent dialog as a date+time, not a duration. “Until Friday May 29 at 5 PM” — never “7 days.” Duration framing hides the calendar reality from the user.
Req 03
Default to the shortest reasonable expiry
Default expiry must be the SHORTEST reasonable value for the scope. Default 7 days. Maximum 90 days. The user must explicitly slide the expiry up; the consent UI must not default to maximum.
Req 04
Rules opt-OUT, not opt-IN
The spending cap, quiet hours, and irreversibility floor are pre-checked. The user can disable them, but the burden of disabling is on the user, not on accepting them.
Req 05
Kill switch visible on every page
Kill switch link visible on every page of the user’s app where a UAP grant could be active. Never more than two taps away. A user in crisis must be able to reach it without searching.
Req 06
Audit log accessible without partner involvement
Audit log accessible from the user’s settings WITHOUT any LLM partner involvement. The user owns it; the partner cannot hide it. The user can export the full log as signed JSON at any time.
Req 07
Re-consent on material change
A partner cannot widen scope mid-grant. Adding a scope requires a fresh GRANT with a new consent_artifact. The user must see the new scope list, the new expiry, and the new rule set before the additional authority takes effect.
06 · The strategic read
The trust contract is the moat.
The first three protocols (BIP, PAP, EAP) are about reading the user, proposing to the user, and acting through their devices while the user is present. They are necessary for behavioral interrupt. They are not sufficient for the next category of AI products.
The category that ships in 2026–2027 — every foundation lab is pointed at it — is autonomous AI that operates on behalf of the user without per-action presence. The unsolved problem in that category is not capability. It is consent, scope, audit, and kill switch. The capability exists today (Claude Computer Use, OpenAI Operator, Project Astra). The trust infrastructure does not.
UAP is the trust infrastructure. It is the layer that lets foundation labs ship agentic AI safely without each one inventing a brittle ad-hoc consent model. It is the layer regulators will demand once the first agentic-AI catastrophe makes the news. And it is the layer that — by virtue of being open-spec, audit-defaulted, and kill-switch-first — cannot be reasonably forked by any single foundation lab without losing the cross-LLM portability that gives it value.
A user grants standing authority once, through COYL. That grant works for Claude, for GPT, for Gemini, for any future LLM. The user owns the audit trail. The user owns the kill switch. The protocol is the trust contract, and the trust contract is the moat.
The full stack
Four protocols. One stack.
BIP reads the substrate. PAP proposes the moment. EAP acts across the device fleet. UAP grants the standing authority that makes agentic AI safe. All four published Apache 2.0 in one repository. Reference engine ships post-Series-A.
COYL · Catch yourself before you do it again.