@nullsquare/agent-authority 0.4.0

package/ROADMAP.md

@@ -0,0 +1,149 @@
+# Agent Authority Roadmap
+
+Agent Authority is implementation-first. We are not trying to invent a new authentication protocol or policy language.
+
+The product thesis we are validating is:
+
+> **Give an agent a task, not standing account permissions.**
+
+A human-approved task becomes temporary execution authority. As the agent discovers concrete resources through authorized work, authority may follow those resources through provenance-bound facts, but it may never silently broaden.
+
+## Current invariant
+
+```text
+Task Lease authority <= Mission authority
+```
+
+Across delegation and integrations:
+
+```text
+authority may stay the same or shrink
+never silently grow
+```
+
+## M0 — Enforcement foundation — complete
+
+- [x] mission validation
+- [x] allow / deny / require-approval outcomes
+- [x] explicit deny precedence
+- [x] resource constraints
+- [x] expiry and budgets
+- [x] delegation attenuation
+- [x] mission revocation
+- [x] action receipts and request hashes
+- [x] protocol-neutral `guard.run()` enforcement
+- [x] one-time approvals
+- [x] mutation idempotency
+- [x] short-lived local agent-instance auth
+- [x] encrypted development credential vault
+- [x] GitHub brokered execution
+- [x] MCP v2 gateway proof
+- [x] harness-managed connector grant proof
+- [x] Node 20/22 CI, coverage, package checks and CodeQL
+
+## M1 — Task Lease / derived-authority proof — current
+
+- [x] Task Lease object around an existing mission
+- [x] explicit authority roots
+- [x] derived facts anchored to same-mission `ALLOW` receipts
+- [x] parent-fact lineage
+- [x] exact context-field bindings
+- [x] unresolved facts fail closed
+- [x] resource mismatch becomes an authority-delta step-up signal
+- [x] explicit mission deny remains the ceiling
+- [x] task completion immediately removes authority
+- [x] independent task-lease expiry
+- [x] task-lease ID/hash in receipts
+- [x] self-contained cross-system demo: Gmail-thread fact -> Calendar attendee
+- [ ] exercise the same pattern against two real provider operations
+
+**Success criterion:** a real multi-step agent workflow discovers a resource during an authorized read and can use exactly that resource in a later side effect, while an unrelated resource is technically blocked without requiring approval for every normal task step.
+
+## M2 — Durable task execution
+
+Build only what the real M1 workflow proves necessary.
+
+- [ ] durable Task Lease persistence/recovery
+- [ ] atomic fact/binding updates
+- [ ] approved authority delta can safely attenuate/update a live lease
+- [ ] completion state survives process restart
+- [ ] durable lineage query: why was this exact action authorized?
+- [ ] concurrency tests for multiple agent workers operating under one lease
+
+**Success criterion:** a Task Lease survives daemon/process restarts without gaining authority or losing its provenance lineage.
+
+## M3 — Trustworthy derived facts
+
+Today the trusted host/adapter supplies the derived value and selector. This is an explicit v0.4 limitation.
+
+- [ ] define a small adapter contract for extracting authority-relevant fields from provider results
+- [ ] bind derived fact records to provider/result evidence where practical
+- [ ] adversarial tests for forged extraction, confused-deputy mappings and stale facts
+- [ ] conformance fixture for operation -> resource-context mappings
+- [ ] define invalidation rules when a source resource changes
+
+Do **not** build a general semantic policy language unless real integrations require it.
+
+**Success criterion:** an adapter cannot claim a value was derived from an authorized operation without satisfying the documented extraction/evidence contract.
+
+## M4 — Same task, multiple transports
+
+Prove Agent Authority is not an MCP product or SDK wrapper.
+
+- [ ] same Task Lease through ordinary `guard.run()` SDK call
+- [ ] same Task Lease through MCP gateway
+- [ ] same Task Lease through brokered provider execution
+- [ ] at least one non-bypassable harness/tool-middleware integration
+- [ ] interoperability test vectors across transports
+
+**Success criterion:** changing transport or harness does not expand the task's authority.
+
+## M5 — Production credential and approval UX
+
+Only after the task-bound enforcement model is validated.
+
+- [ ] GitHub browser/App onboarding instead of token-stdin
+- [ ] reusable OAuth/OIDC connection engine
+- [ ] OS keychain / KMS-backed secret backend
+- [ ] automatic short-lived agent session bootstrap
+- [ ] compact approval UI showing the exact authority delta
+- [ ] signed receipt experiment
+
+**Success criterion:** an external developer can install Agent Authority, connect one real provider, authorize one task, and complete it without exposing a long-lived credential to the model.
+
+## M6 — Ecosystem and contribution layer
+
+- [ ] adapter/conformance starter template
+- [ ] framework integration examples
+- [ ] `good first issue` tasks based on real mappings/tests
+- [ ] independent contributor implementation of one adapter
+- [ ] release packaging and npm publication
+- [ ] documentation site only when README/docs become too large
+
+## M7 — Standards interoperability
+
+Only after operational evidence.
+
+- [ ] map Task Lease concepts to emerging task/intent authorization work
+- [ ] accept external authorization envelopes where useful
+- [ ] avoid creating a competing identity/token standard
+- [ ] publish stable test vectors for non-amplification and authority lineage
+- [ ] evaluate an appropriate standards venue only if multiple independent implementations exist
+
+## What we are not prioritizing
+
+- another agent harness
+- a new OAuth replacement
+- an MCP replacement
+- a giant connector marketplace
+- a proprietary universal policy DSL
+- a dashboard-first enterprise product
+- A2A support before task-bound tool execution is validated
+
+## Research questions
+
+1. What is the smallest trustworthy representation of an authority-relevant derived fact?
+2. How should an approved authority delta update a running task without opening a broader wildcard permission?
+3. How should source-data changes invalidate downstream derived authority?
+4. What provider/tool metadata is required to map operations to resource context reliably?
+5. Can the same non-amplification conformance suite work across SDK, MCP, CLI and brokered execution?

package/SECURITY.md

@@ -0,0 +1,116 @@
+# Security Policy
+
+Agent Authority sits on a security-critical side-effect boundary. Please treat vulnerabilities that could bypass policy, expand task/delegated authority, substitute request parameters, forge approvals/receipts, defeat revocation, cross Task Lease boundaries, or leak credentials as sensitive.
+
+## Reporting
+
+For non-sensitive hardening ideas, open a GitHub issue.
+
+For exploitable vulnerabilities, use GitHub private vulnerability reporting / Security Advisory flow when available rather than publishing exploit details in a public issue.
+
+Never include real passwords, OAuth refresh tokens, API keys, session cookies, customer data, or production secrets in reports, screenshots, logs, or reproductions.
+
+## Current status
+
+Agent Authority is a public pre-alpha validation implementation. It has live provider-boundary evidence, but it is **not production-ready** and should not yet be treated as a complete credential broker, IAM replacement, or hardened sandbox.
+
+See [`docs/evidence.md`](docs/evidence.md) for executable proof and current limitations.
+
+## Security claim
+
+The narrow claim of the current runtime is:
+
+> If an effect is reachable only through an Agent Authority enforcement boundary, the effect callback is not invoked unless the mission and Task Lease authorize that exact semantic request (or a required approval has completed).
+
+A Task Lease may narrow mission authority around concrete resources discovered during an authorized task. It cannot grant an action the mission does not already permit.
+
+```text
+Task Lease authority <= Mission authority
+```
+
+## Critical trust boundary
+
+Agent Authority cannot secure a provider path it does not control.
+
+This is bypassable:
+
+```text
+agent ----> Agent Authority ----> provider
+   \
+    +---------------------------> provider (unguarded)
+```
+
+This is the intended boundary:
+
+```text
+agent
+  |
+  v
+Agent Authority
+  |
+  v
+provider
+```
+
+If the agent itself possesses a provider credential and can call the provider through another path, application architecture must remove or isolate that path before claiming non-bypassable enforcement.
+
+## Task Lease invariants
+
+1. **Mission is the ceiling.** A Task Lease cannot override explicit deny or create a new action class.
+2. **No side effect before authorization.** `DENY` and `REQUIRE_APPROVAL` do not invoke the guarded effect.
+3. **Same request.** The semantic request evaluated must be the request executed.
+4. **Same task lineage.** Derived authority must be anchored to an `ALLOW` receipt from the same Task Lease.
+5. **Parent authority exists.** Derived facts must descend from at least one existing task authority fact.
+6. **No silent resource expansion.** A different concrete bound resource produces an authority delta instead of inheriting authority.
+7. **Task completion removes authority.** Completion and expiry are independent of provider credential lifetime.
+8. **Delegation attenuates.** Child authority may stay equal or shrink; it must not exceed parent authority.
+9. **Revocation survives later calls.** A revoked mission must stop subsequent actions.
+10. **Mutation retries are conservative.** Idempotency handling must not silently duplicate external side effects.
+
+## Derived-fact trust assumption
+
+The v0.4 implementation records:
+
+- parent fact IDs;
+- source receipt ID/hash;
+- source service/action/request hash;
+- Task Lease ID;
+- trusted extraction selector.
+
+The trusted host or adapter currently supplies the extracted value. Agent Authority does **not** yet cryptographically prove that a value such as `output.number` was actually extracted from the provider response described by the receipt.
+
+Do not present recorded provenance as cryptographic data-lineage proof.
+
+## Credentials
+
+When Agent Authority owns/brokers a provider credential, the design goal is to keep long-lived credentials out of model context. The current encrypted-file vault is a pre-alpha local backend, not equivalent to an OS keychain, KMS, HSM, or enterprise secret manager.
+
+For in-process guard integrations, the host application may continue to own its provider credential. In that mode Agent Authority controls guarded execution; it does not isolate the host's credential by itself.
+
+## Current non-goals / incomplete protections
+
+The current release does not yet guarantee:
+
+- durable Task Lease recovery after process failure;
+- cryptographically verified provider-output extraction;
+- non-bypassability when the agent has another provider path;
+- production OAuth onboarding;
+- OS keychain/KMS/HSM-backed credential storage;
+- hardened remote multi-tenant deployment;
+- automatic safe application of approved authority deltas;
+- complete concurrency-safe multi-agent budget/accounting semantics.
+
+These limitations are intentional and should remain visible in documentation and demos.
+
+## Security review contributions
+
+Especially valuable reports/tests include:
+
+- direct-path bypasses;
+- request substitution between evaluation and execution;
+- cross-lease provenance substitution;
+- confused-deputy behavior across adapters;
+- approval replay or authority-delta replay;
+- revocation races;
+- concurrent budget/idempotency races;
+- provider-output extraction attacks.

package/docs/account-connections.md

@@ -0,0 +1,173 @@
+# Account Connections: authorize once, reuse across agents
+
+The user experience goal is simple:
+
+> Connect each account once to Agent Authority. Reuse that connection from any authorized agent or harness without handing the agent the long-lived credential.
+
+Agent Authority cannot literally authenticate every internet service with one universal login: GitHub, Google, Microsoft, Slack, AWS, and legacy systems each control their own authorization. The abstraction therefore separates **provider consent** from **agent authority**.
+
+## User setup flow
+
+```text
+1. Install / open Agent Authority
+            |
+            v
+2. Create local or cloud Authority identity
+            |
+            v
+3. Connect accounts once
+   GitHub  [Connect]
+   Google  [Connect]
+   Slack   [Connect]
+   Cloudflare [Connect]
+            |
+            v
+4. Provider OAuth / credential setup happens once
+            |
+            v
+5. Agent Authority stores only a connection record + vault reference
+            |
+            v
+6. Any approved agent/harness can request actions through Agent Authority
+```
+
+Later sessions should not repeat provider login. Reauthorization is needed only when the provider revokes/expires the grant, the user disconnects the account, or the requested action needs scopes that were never granted.
+
+## Runtime flow
+
+```text
+Agent / harness
+    |
+    | service=github, action=repo.read
+    v
+Agent Authority
+    |
+    +-- 1. identify principal + agent + mission
+    +-- 2. evaluate mission policy
+    +-- 3. resolve connected account
+    +-- 4. refresh/exchange credential if needed
+    +-- 5. execute through provider adapter
+    +-- 6. sanitize response
+    +-- 7. emit receipt
+    v
+Agent receives result, not credential
+```
+
+The credential broker must live outside model context. A prompt-injected agent should not be able to ask the system to print its GitHub refresh token or Google session cookie because those objects are never tool outputs.
+
+## We do not build every integration from scratch
+
+Coverage is layered.
+
+### 1. Generic auth engines
+
+One implementation can serve many providers:
+
+- OAuth/OIDC Authorization Code + PKCE
+- OAuth device flow where appropriate
+- API key / PAT vault storage
+- cloud STS / workload-identity exchange
+- CLI credential helpers
+- isolated browser-session brokerage
+
+Providers then supply thin profiles: endpoints, scopes, refresh behavior, account discovery, and capability mappings.
+
+### 2. Native provider adapters
+
+We should build native adapters for strategically important services where security and UX justify direct support, initially GitHub, Google, Cloudflare, and one enterprise identity/cloud platform.
+
+### 3. MCP compatibility
+
+An authority-aware MCP proxy can wrap existing MCP servers. The MCP server keeps using its normal OAuth/authentication mechanism; Agent Authority adds mission policy, approval, delegation and receipts before forwarding the call.
+
+### 4. Connector networks
+
+Existing connector platforms can sit behind an Agent Authority adapter:
+
+```text
+agent -> Agent Authority -> connector network -> SaaS API
+```
+
+This can provide broad early coverage without making the authority project maintain hundreds of unrelated SaaS SDKs.
+
+## Connection object
+
+A safe connection record contains metadata and a vault reference, never the secret itself:
+
+```json
+{
+  "connection_id": "connection:...",
+  "principal_id": "user:123",
+  "service": "github",
+  "account_id": "octocat",
+  "auth_kind": "oauth",
+  "credential_ref": "vault:...",
+  "scopes": ["repo", "read:user"],
+  "status": "active"
+}
+```
+
+The model-facing API should omit `credential_ref` as well.
+
+## Scope step-up
+
+A user might initially connect Google with calendar read permission. Months later an agent mission may require Gmail send. The correct behavior is not to grant a giant permanent scope during onboarding.
+
+Instead:
+
+```text
+requested capability
+      |
+      v
+existing connection sufficient? -- yes --> continue
+      |
+      no
+      v
+request provider scope step-up + human approval
+      |
+      v
+update connection grant
+```
+
+This keeps the initial consent small while allowing smooth expansion.
+
+## Mission consent vs provider consent
+
+These are intentionally different events.
+
+**Provider consent**: “Agent Authority may access my GitHub account under these provider scopes.” This is normally done once and reused.
+
+**Mission consent**: “This coding agent may maintain repository X for the next two hours, but may not delete repositories or change billing.” This can be short-lived and task-specific.
+
+The provider connection is durable. The mission authority is bounded.
+
+## Multiple accounts
+
+The same principal may connect multiple accounts or organizations:
+
+```text
+github/personal
+github/null-square
+google/personal
+google/work
+```
+
+A mission can select an `account_id`, and organization policy can restrict which account a given agent is allowed to use.
+
+## Future protocols
+
+New agent-auth protocols should plug into the connection/credential boundary rather than replacing Mission Manifests. OAuth Rich Authorization Requests can carry fine-grained authorization details, and OAuth Token Exchange already defines delegation/impersonation token exchange primitives. Agent Authority should map to such standards when providers support them rather than inventing incompatible token mechanics.
+
+## Production security requirements
+
+The current in-memory secret store is explicitly development-only. Production versions need:
+
+- encrypted at-rest credentials
+- OS keychain, HSM/KMS, or dedicated vault backing
+- refresh-token rotation support
+- provider revocation handling
+- no secret values in logs/receipts/errors
+- process/IPC authentication between harness and sidecar
+- anti-confused-deputy resource binding
+- explicit capability-to-provider-operation mappings
+- audit trail for connection creation, scope changes, use, and revocation

package/docs/announcement-draft.md

@@ -0,0 +1,13 @@
+# Announcement draft — hold until registry verification
+
+NullSquare is open-sourcing **Agent Authority**, an experimental runtime for task-bounded AI agent side effects.
+
+AI agents often inherit account permissions much broader than the task a user approved. Agent Authority keeps the existing identity, OAuth, SDK, MCP server, or agent framework, but places a Task Lease immediately before consequential effects.
+
+A Task Lease can follow resources discovered through authorized execution without silently broadening to unrelated resources. In the public validation suite, Agent Authority discovers a live GitHub issue, derives that issue number as task authority, performs one real comment mutation, blocks a different issue before the provider call, then blocks the previously authorized issue after the task completes.
+
+The developer preview also includes a Vercel AI SDK integration that wraps ordinary `ToolLoopAgent` tools at their existing `execute` boundary.
+
+**Give your agent a task, not your account.**
+
+This is a developer preview, not a claim that NullSquare invented task-scoped authorization and not a production-ready security control. The repository documents the current trust assumptions and bypass boundaries explicitly.

package/docs/architecture.md

@@ -0,0 +1,106 @@
+# Architecture
+
+Agent Authority is a **mission-scoped authority control plane** for AI agents. It sits above authentication mechanisms and below agent intent/tool execution.
+
+## Placement
+
+```text
+Human / organization
+        |
+        | approves mission
+        v
+Mission Manifest
+        |
+        v
+Authority Runtime  <---- policy / approvals / revocation / receipts
+        |
+        | only after ALLOW
+        v
+Credential + transport adapters
+OAuth | MCP | API key | cloud IAM | CLI | browser/legacy | future protocols
+        |
+        v
+Services and tools
+```
+
+The model or agent should not be trusted with permanent root credentials. The preferred enforcement point is outside the model process: tool middleware, local sidecar, connector wrapper, MCP proxy, or remote control plane.
+
+## Core primitives
+
+### Principal
+The human or organization that owns the authority.
+
+### Agent
+The runtime identity acting under delegated authority. This may be a coding-agent session, autonomous workflow, subagent, CI job, MCP client, or future workload identity.
+
+### Mission
+A durable statement of *why* the agent is acting and the authority granted for that objective.
+
+### Capability
+A normalized service/action pair such as `github:repo.write` or `cloudflare:workers.deploy`.
+
+### Constraint
+Limits such as expiration, monetary budget, resource boundary, rate, environment, delegation depth, or execution window.
+
+### Approval
+A policy outcome requiring the runtime to return to a human before execution.
+
+### Receipt
+A tamper-evident record of the mission, requested action, decision, and delegation context. The MVP hashes receipts; signatures and append-only persistence are roadmap items.
+
+## Decision pipeline
+
+1. Validate mission structure.
+2. Check mission revocation and expiry.
+3. Check delegation depth and contextual constraints.
+4. Resolve service/resource policy.
+5. Apply explicit deny rules before broad allows.
+6. Determine whether human approval is required.
+7. Emit an action receipt.
+8. Only on `allow`, resolve a credential/transport adapter.
+9. Adapter obtains or injects the minimum practical credential for the requested action.
+10. Service call occurs outside or behind the authority boundary.
+
+## Why adapters matter
+
+The authority model must not depend on every service adopting a new protocol. Existing OAuth, API-key, CLI, cloud IAM, MCP, enterprise SSO, and browser-session systems can be hidden behind adapters. A future agent-native auth standard should be implemented as another adapter.
+
+This lets the project solve a different problem from authentication itself: **portable bounded authority over heterogeneous authentication systems**.
+
+## Security invariants
+
+- explicit deny overrides allow
+- child missions may only attenuate parent authority
+- revoked/expired missions fail closed
+- root credentials stay outside the mission manifest and model context
+- approval is evaluated before credential dispatch
+- receipts identify the principal, agent, mission, service, action, and decision
+- unknown services/actions fail closed
+
+## Deployment modes
+
+### Embedded middleware
+Best when the application controls tool execution.
+
+### Local sidecar
+Best for coding agents and developer harnesses. Agent calls a localhost authority API before sensitive operations.
+
+### MCP proxy
+Best for MCP-compatible clients. The proxy evaluates mission policy before forwarding tool calls and can broker upstream OAuth.
+
+### Connector platform
+Best for a provider with many SaaS integrations. Existing connectors become credential/transport adapters behind the authority layer.
+
+### Hosted enterprise control plane
+Best for shared policy, centralized approvals, audit, revocation, compliance, and workload identity.
+
+## What is deliberately not decided yet
+
+- canonical signed mission token format
+- universal capability vocabulary
+- agent runtime identity standard
+- receipt signature/log format
+- browser-session isolation design
+- how mission semantics map into emerging IETF agent authorization work
+
+These should be validated through implementations and interoperability tests before being frozen into a protocol.

package/docs/assets/agent-authority-cover.svg

@@ -0,0 +1,41 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1600" height="640" viewBox="0 0 1600 640" role="img" aria-label="Agent Authority — mission scoped authorization for AI agents">
+  <defs>
+    <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#07111f"/><stop offset="1" stop-color="#121a36"/>
+    </linearGradient>
+    <linearGradient id="accent" x1="0" y1="0" x2="1" y2="0">
+      <stop offset="0" stop-color="#7c5cff"/><stop offset="1" stop-color="#4ecbff"/>
+    </linearGradient>
+  </defs>
+  <rect width="1600" height="640" rx="36" fill="url(#bg)"/>
+  <g font-family="Arial, Helvetica, sans-serif" fill="#fff">
+    <text x="100" y="120" font-size="28" font-weight="700" letter-spacing="3">NULLSQUARE / OPEN SOURCE</text>
+    <text x="100" y="220" font-size="78" font-weight="800">Agent Authority</text>
+    <text x="100" y="285" font-size="34" fill="#b9c7e6">Mission-scoped authorization for AI agents</text>
+    <text x="100" y="355" font-size="27" fill="#8fe1ff">One mission · Any agent · Any auth system</text>
+  </g>
+  <g transform="translate(930 95)" font-family="Arial, Helvetica, sans-serif">
+    <rect x="120" y="0" width="330" height="72" rx="16" fill="#111c34" stroke="#6d85ff"/>
+    <text x="285" y="44" text-anchor="middle" font-size="24" fill="#fff">Human-approved mission</text>
+    <path d="M285 72 V120" stroke="#7786a8" stroke-width="3"/>
+    <rect x="80" y="120" width="410" height="90" rx="18" fill="#171842" stroke="#8b67ff" stroke-width="2"/>
+    <text x="285" y="158" text-anchor="middle" font-size="25" font-weight="700" fill="#fff">AUTHORITY RUNTIME</text>
+    <text x="285" y="190" text-anchor="middle" font-size="20" fill="#b9c7e6">allow · deny · approve · revoke</text>
+    <path d="M285 210 V260" stroke="#7786a8" stroke-width="3"/>
+    <rect x="80" y="260" width="410" height="72" rx="16" fill="#101b30" stroke="#4ecbff"/>
+    <text x="285" y="304" text-anchor="middle" font-size="23" fill="#fff">Adapters / connectors</text>
+    <path d="M285 332 V382" stroke="#7786a8" stroke-width="3"/>
+    <g fill="#101b30" stroke="#4b628c">
+      <rect x="0" y="382" width="135" height="64" rx="14"/><rect x="145" y="382" width="135" height="64" rx="14"/>
+      <rect x="290" y="382" width="135" height="64" rx="14"/><rect x="435" y="382" width="135" height="64" rx="14"/>
+    </g>
+    <g font-size="20" fill="#fff" text-anchor="middle">
+      <text x="67" y="422">OAuth</text><text x="212" y="422">MCP</text><text x="357" y="422">API / CLI</text><text x="502" y="422">Legacy</text>
+    </g>
+  </g>
+  <rect x="100" y="430" width="690" height="2" fill="url(#accent)"/>
+  <g font-family="Arial, Helvetica, sans-serif" font-size="22" fill="#b9c7e6">
+    <text x="100" y="485">Delegation attenuation</text><text x="330" y="485">Human approvals</text><text x="555" y="485">Action receipts</text>
+    <text x="100" y="530">Credential isolation</text><text x="330" y="530">Legacy compatibility</text><text x="555" y="530">Protocol neutral</text>
+  </g>
+</svg>

package/docs/clear-path.md

@@ -0,0 +1,53 @@
+# v0.4 clear path
+
+This milestone intentionally validates one thing:
+
+> A normal agent application can keep its existing provider credentials and SDKs while Agent Authority gives each task narrower, temporary resource authority.
+
+## Primary path
+
+```text
+human task
+  -> Task Lease
+  -> guard.run(action, effect)
+  -> ALLOW / DENY / authority delta
+  -> existing SDK or API
+```
+
+## Validation scenario
+
+```text
+"Handle this demo request"
+  -> root: one Gmail thread
+  -> authorized read
+  -> derive sender from the same Task Lease receipt
+  -> bind Calendar attendee to that sender
+  -> exact attendee succeeds
+  -> another attendee requires step-up
+  -> complete task
+  -> later calls fail
+```
+
+## Must be true
+
+- Mission policy remains the ceiling.
+- Derived authority cannot cross Task Leases.
+- Derived authority must descend from an existing task fact.
+- The trusted extraction selector is recorded.
+- Denied and step-up actions never invoke the side-effect callback.
+- Task completion removes task authority independently of provider credentials.
+
+## Deliberately deferred
+
+Do not expand v0.4 to solve these until the primary path has external validation:
+
+- persistent Task Lease storage;
+- automatic application of approved authority deltas;
+- cryptographic proof of output extraction;
+- browser OAuth onboarding;
+- remote ChatGPT app UX;
+- broad connector coverage;
+- multi-agent delegation UI;
+- a new authorization protocol or policy language.
+
+Those are follow-on questions, not requirements for proving the developer primitive.