Okay Seal

Audited and re-planned on 2026-09-02. This replaces the v1 handoff. Every external claim below was re-checked against primary sources on that date; anything that could not be verified is marked. Read Part 0 first: it lists what changed and why.

The v1 thesis survives: the valuable layer is authority, not the model. Humans give agents a Mission; deterministic software enforces it; the LLM proposes and never enforces. What changed is the rails, the security model around the browser, and the order of work.

Part 0 — What changed since v1 (read this first)

Part 0.5 — The full vision, delivered today

The v1 "success" statement was: "Create a purchasing agent. It can use my browser and company email. Give it $2,000 per month. It can automatically buy from existing vendors under $300. Ask me for any new vendor or subscription. It can spend 200 USDC per month on APIs. Never let it change account passwords. Let it run all the time." Here is how each clause works today, autonomously, with no partner approval. Nothing in this table needs Stripe, Visa, Google or a bank to say yes.

The only things that remain genuinely human-in-the-loop are the ones the user asks to be (new vendors, thresholds), 3DS challenges on some card purchases, and sites that reject automation outright.

Part 1 — Verification ledger

Status key: Verified = primary source read on 2026-09-02. Changed = source says something different from v1. Unverified = not confirmable from primary sources; treat as unknown.

Stripe

Browser providers

Crypto

Legal and policy tech

Part 2 — Audit of the v1 plan's logic

Findings are independent of any vendor. Each has a fix that goes into the v2 architecture.

Authority and approval

A1. mission.approve is on the agent-facing API (v1 §43). That violates Invariant 1 by construction: an agent could call it. Fix: split the surface into an Agent API (can only approval.request) and a Human API (approve/widen/revoke) that requires a fresh passkey/WebAuthn step-up. Approvals arrive via push, the web approval center, or MCP elicitation URL mode. Never via an API key.

A2. Budget checks race. "Read prior spend, compare, allow" double-spends when two executions (subagents, retries, parallel tool calls) run concurrently. Fix: a reservation ledger. payment.request atomically reserves against the Mission budget in one database transaction (SELECT … FOR UPDATE or a serializable ledger row), then commit or release on outcome. Every spend request carries an idempotency key. Test H in Part 8 proves it.

A5. Policy change is itself privileged. v1 versions policies but doesn't say who may widen them. Fix: widening authority (higher limit, new origin, new recipient, longer expiry) requires human step-up and creates a new immutable PolicyVersion that applies to future executions only. Narrowing and revocation are immediate and may be triggered by anyone with owner rights, by the risk engine, or by the kill switch.

A6. Delegation attenuation is only a database check. Fix: issue Biscuit capability tokens per execution. The Mission token carries the ceiling as Datalog checks; a subagent token is the parent token plus an attenuation block. The verifier is offline and public-key; a child physically cannot present more authority than its parent. Keep the database check too.

A19. The user approves what the LLM wrote, not what will be enforced. Fix: a deterministic policy-to-English renderer. The user reads a plain-language description generated from the compiled Cedar policy, never from the LLM's paraphrase. "What you read is what is enforced."

A20. Mainstream users need templates, not a policy editor. Purchasing Agent, Travel Agent, Research Agent, Inbox Agent, each with default-deny beyond the template. The built-in AI proposes template + parameters; the user adjusts sliders and toggles.

Browser, credentials and observation

A3. Observation leakage after injection (largest gap). After the trusted worker types a password, TOTP or card number, the value sits in the DOM (input.value), in the accessibility tree, in screenshots, in recordings and in the live view. Any of those flowing to the model breaks Invariants 3–4. Steel blurs screenshots only. Fix, all four layers:

1. Blind window. The driving model's observation stream is paused from "navigate to origin" through "form submitted and page settled." The injector, not the model, performs fill and submit.
2. Redaction filter on every observation returned to any model: strip values from type=password, any autocomplete=cc-*, one-time-code, and any element the injector touched (tracked by element handle). Applies to accessibility snapshots, DOM text, and screenshots (mask rectangles).
3. Recording and live view off for any session that has an active credential grant, or masked where the provider supports it (Anchor does; Steel does not document it).
4. Egress DLP gate. Every tool result, email body, file write and HTTP body leaving the execution boundary is scanned against secret fingerprints (HMAC of the plaintext, last-4 patterns, Luhn hits, TOTP-shaped strings). A hit blocks the action and raises a RiskEvent.

A4. Origin binding must be checked live. Not "the origin the agent asked for," but the live top-frame origin (scheme + host + port, exact) of the frame owning the target input, at the moment of injection, after navigation has settled. No iframes, no cross-origin frames.

A15. Who drives the browser? v1's browser.execute(task) implies we run the driving model, which means we pay tokens and we are responsible for prompt-injection behaviour. Raw CDP access for external agents would let them read the DOM after injection. Decision: v1, we drive (metered as credits, model behind ModelProvider). v2, a filtered action API (navigate, click, type, read, all passing through the PEP and the redaction filter). Never raw CDP to a tenant.

A17. The router must not be a bypass. Every route for a capability (Gmail API, browser Gmail, SMTP) passes the same PDP with the same inputs. A DENY on one route is not retried on another.

A18. Egress channels leak data even without credential reveal. An agent that legitimately read a bank balance can email it out. Fix: recipient allowlists on email, destination allowlists on HTTP/file, plus the DLP gate from A3.

A12. Step-ups are the normal case, not failures. 3DS, SMS OTP, passkeys and CAPTCHAs will happen on most real checkouts. Fix: first-class Handoff, a push notification with a magic link that opens the exact step on the user's phone (via the live view or a native form), then hands control back. Link's own outcome tags list 3ds_challenge, captcha, login_required as expected outcomes.

Money

A13. Human-completed checkout is the universal zero-approval rail. v1 buried it as ManualHumanPaymentConnector. It should be the default for every user on day one: the agent finds, compares, fills cart, applies policy checks, then hands the payment step to the human, who pays with Apple Pay, Google Pay or Link on their own device. No PCI scope for us, no partner approval, works at every merchant, and it is what Link's consumer product does anyway ("you approve each payment").

A14. Money representation is inconsistent. v1 mixes 50000 (cents) and 82.47. Standardize: integer minor units + ISO currency for fiat; decimal strings with token decimals for crypto ("25.000000" USDC). Never floats.

A16. Model tokens are missing from the cost model. See Part 7.

A27. PCI scope of the injector. v1 assumed a one-time PAN "passing through our trusted executor" was harmless. It is not: transmitting cardholder data for another party makes us a PCI service provider (SAQ D-SP). Fix: isolate the payment injector as its own minimal service, keep every other component out of the cardholder-data path, prefer Handoff Checkout and provider iframe patterns, and plan the attestation.

Platform

A7. Receipts must be tamper-evident. Hash-chain receipts per tenant (each includes the previous hash), sign the chain head periodically, and include the hash of the PDP input and the PolicyVersion id. This is what makes "audit export" an enterprise feature.

A8. Dry-run and shadow mode. A Mission can run in simulate mode: the PDP decides, the receipts are written, nothing executes. New agents default to shadow mode for their first N runs.

A9. Kill switches. One tap revokes everything for a user; per-agent, per-connector and global (operator) switches exist. Revocation is checked at every PEP, not just at Mission start, so a running execution aborts.

A10. Velocity and tripwires. Actions per minute, new recipients per day, spend per hour, and N denials in M minutes auto-freezes the Mission and notifies the owner. A burst of denials is the signature of prompt injection.

A11. Agent authentication. MCP over HTTP per spec 2026-07-28 (OAuth 2.1, RFC 9728 resource metadata, RFC 8707 resource, PKCE). REST clients use per-agent API keys. Every execution receives a short-lived, Mission-scoped Biscuit token; long-lived keys never carry execution authority.

A21–A22. Tenant isolation. Supabase RLS is defense in depth; the PDP runs server-side with the service role. A broker table maps every provider object (session, profile, credential, wallet, connector account) to a tenant, and every provider call passes through the broker's ownership check. Separate provider API keys per environment.

A23. Retention. Receipts and browser profiles are personal data. Define retention per plan, export, and deletion (which also deletes provider profiles and credentials).

A24. Local mode. Keep execution_location ∈ {CLOUD_ALLOWED, LOCAL_ONLY, HUMAN_ONLY} in the schema from day one; do not build the extension in v1.

A26. Capability discovery. A capabilities.get endpoint exposes live provider limits (Link's $500, Steel's 15-minute sessions, CDP networks) so agents and the UI never hard-code them.

Part 3 — Two tracks: ships today vs partner track

"Ships today" means: self-serve signup, published pricing or open source, no underwriting, no waitlist, and terms that permit commercial multi-tenant use. Everything else is the partner track, started in parallel and never on the critical path.

Track A — ships today, zero third-party approval

Track B — partner track (start now, never block on it)

3.1 Card rails without underwriting (verified 2026-09-02)

The "bring-your-own card program" idea holds up, with sharper edges than v1 expected. Ranked by how usable each is today for a third-party platform:

Network programs (Visa Intelligent Commerce, Visa Trusted Agent Protocol, Mastercard Agent Pay, PayPal ACS, Google AP2, ACP) all either require application or do not hand a platform a payment credential. Card issuing (Stripe, Lithic, Highnote, Marqeta) is sandbox-open and production-gated everywhere. New entrants: Skyfire (card path unverified), Nekuda (wallet docs gone), Payman (ACH/USDC only), Locus (API credits only).

The PCI consequence v1 missed. PCI SSC FAQ 1280: "The requirement that prohibits retaining sensitive authentication data after authorization applies even if that data is encrypted." More importantly, any entity that transmits cardholder data on behalf of another is a service provider, and SAQ D for Service Providers is "the ONLY SAQ option for service providers." Transience does not remove scope. So every rail above that returns a PAN to our code puts that code in scope. The architectural answer:

• Handoff Checkout is the zero-scope rail. The human pays on their own device; we never see card data.
• The payment injector is a separate, minimal service (our cardholder-data environment). It is the only component that receives a PAN; it receives it from the provider, types it into the checkout page, and discards it. Application servers, the database, logs, the model and the browser observation channel never carry it. This keeps SAQ D scope small enough to attest to.
• Prefer provider patterns that keep PAN off our servers where offered (Ramp iframe, Slash RSA-to-client, Crossmint iframe).
• Schedule the SAQ D-SP attestation as a Phase 6 compliance task; until then the injector path is opt-in for businesses using their own program.

3.2 Full autonomy for cards today: four modes, all self-serve

v1 treated cards as "Link now, Issuing later" and v2's first draft leaned on Handoff Checkout. Neither is the ceiling. All four modes below give the agent a real card number, minted with the exact amount for that purchase, with no human step, today.

Mode 1 — User's own card program (autonomous, zero float, zero approval). Privacy.com for consumers and small businesses; Mercury, Slash or Brex for companies. Onboarding is "paste your API key." Use MERCHANT_LOCKED (Privacy.com) or per-vendor cards for recurring vendors so monthly card-count limits (12–60 on Privacy.com by plan) are not consumed per purchase; use single-use cards for one-offs. Mercury is free business banking with self-serve signup, so "get a Mercury account" is a two-day ask for a business that wants agent cards.

Mode 2 — Link an existing Visa/Mastercard (consumer, autonomous within a budget). Crossmint Agentic Cards: the user links their existing card once in a PCI iframe with a passkey ceremony, sets maxAmount per period, and the agent receives one-time card numbers. Staging is self-serve today; production approval is undocumented, so test it in Phase 0 rather than assume it.

Mode 3 — Mission Wallet (anyone, autonomous, we are merchant of record). For users with no card program: the user prefunds a Mission (Stripe Checkout, our normal merchant account; authorization hold for the budget). We mint per-purchase virtual cards from our own corporate program (our Mercury/Brex/Ramp account, or Stripe Issuing "cards for your own business," which is a Dashboard application rather than a platform program). The agent buys; we resell to the user at cost plus our fee and capture the hold. This is the model behind concierge and buy-for-me services. It deliberately breaks v1's "never pool funds" rule in exchange for universality, so it carries the heaviest counsel question: it must be structured as retail resale (we are the seller of record with returns, chargebacks and sales-tax exposure), not as transmitting the user's money. Check our card program's terms on third-party purchases before launch.

Mode 4 — Handoff Checkout (universal, human pays). Fallback for everything else and for users who prefer to tap Apple Pay per purchase.

Ordering for the rail router: Mode 1 → Mode 2 → Mode 3 → Mode 4, with Link (personal) available as an opt-in experiment. All four run through the same PDP, reservation ledger and isolated injector.

3.3 Other autonomy unlocks the v1 plan underused

• Agent-owned MFA identity. A provisioned phone number and agent mailbox per user become the second factor for accounts the user chooses to delegate. This turns "sites that need SMS/email OTP" from a failure class into routine autonomous logins. The injector reads the code; the model never does.
• Passkeys in the vault. Hold the user's passkey private key (or enroll a new one on delegated accounts) and install it per session with the CDP virtual authenticator. The private key transits our injector only. This defeats the "passkey-only sites break cloud agents" objection.
• Crypto onramp for mainstream users. "Add $200 to your agent" is Apple Pay → USDC on Base via Coinbase Onramp, inside our app. The user never sees a seed phrase.
• Machine payments where they exist. x402 on Base and Stripe MPP let the agent pay APIs and machine-priced services with USDC and no checkout page at all.
• Deterministic security-page blocking. "Never change my passwords" is a URL-pattern and form-action deny rule, so it holds against prompt injection without relying on the model's judgement.

Part 4 — Architecture v2

4.1 The core (unchanged in spirit, sharpened in mechanism)

Human (passkey step-up)
   │  approves a Mission (reads deterministic English)
   ▼
Mission → compiled to Cedar policies (immutable PolicyVersion)
   │
   ├─► Biscuit authority token (ceiling as Datalog checks)
   │        └─► subagent token = parent + attenuation block
   │
   ▼
PDP (Cedar, deny by default)  ──► ALLOW / DENY / REQUIRE_APPROVAL + reason
   │
   ▼
Reservation ledger (atomic reserve → commit/release)
   │
   ▼
PEPs: Browser · Credential · Payment · Wallet · Email · File · HTTP
   │        each re-checks revocation and expiry at call time
   ▼
Provider-side limit: Spend Permission (on-chain) · card program limit · origin-bound credential
   │
   ▼
Receipt (hash-chained, signed) + AuditEvent + UsageEvent

Three independent enforcement layers for every money action: our PDP, the Biscuit token, and the provider/on-chain limit. A prompt injection has to defeat all three.

4.2 Data model additions

Keep the v1 entities. Add:

PolicyVersion.cedar_source        immutable compiled policy text
PolicyVersion.english_rendering   deterministic rendering shown at approval
CapabilityToken                   biscuit, parent_id, attenuations, expires_at
BudgetLedger                      mission_id, reserved, committed, released, currency
SpendReservation                  idempotency_key, amount_minor, state, expires_at
ObservationRedaction              execution_id, element_handles, mask_rects
SecretFingerprint                 hmac, kind (password|pan|totp|token), credential_id
HandoffRequest                    execution_id, kind (payment|otp|3ds|captcha|login), url, expires_at
ProviderObject                    provider, external_id, tenant_id, kind  (the broker table)
KillSwitch                        scope (user|agent|connector|global), set_by, set_at
ReceiptChain                      tenant_id, head_hash, signed_at, signature

4.3 Mission policy v2 (user-facing compiled form)

mission:
  id: mission_boston_1299
  owner: user_123
  agent: travel_agent_5
  execution_location: CLOUD_ALLOWED
  mode: live            # live | simulate | shadow
  expires_at: 2026-09-05T23:59:59Z

browser:
  allowed_origins: [https://www.delta.com, https://www.jetblue.com]
  max_session_minutes: 45
  handoff_allowed: [3ds, otp, captcha]

payments:
  rail_preference: [byo_card_program, handoff_checkout]
  currency: USD
  total_limit_minor: 50000          # $500.00
  per_transaction_limit_minor: 50000
  max_transactions: 1
  merchant_categories: [airline]
  require_approval_when:
    - new_merchant: true
    - amount_minor_gt: 50000

credentials:
  use: [cred_delta_login]           # origin-bound; reveal is not a concept
  totp: allowed

email:
  send: { recipients: [owner], max_messages: 2 }
  read: false

calendar:
  create: true
  update_existing: false
  delete: false

delegation:
  max_depth: 1

velocity:
  max_actions_per_minute: 20
  freeze_after_denials: { count: 3, window_minutes: 10 }

The compiler emits Cedar of the form:

permit (
  principal in AgentAuthority::Mission::"mission_boston_1299",
  action == AgentAuthority::Action::"payment.request",
  resource
) when {
  context.currency == "USD" &&
  context.amount_minor <= 50000 &&
  context.mission_committed_minor + context.amount_minor <= 50000 &&
  context.merchant_category == "airline" &&
  context.now < datetime("2026-09-05T23:59:59Z")
};

forbid (principal, action, resource) when {
  context.kill_switch_active || context.mission_revoked
};

Every rule is also a Biscuit check in the execution token, so a subagent token can only add checks.

4.4 Execution: browser worker with blind-window injection

Scheduler (durable queue: due Mission step)
   ▼
Broker: tenant check → Steel createSession(profileId, region, timeout ≤ cap)
   ▼
Driver loop (our model or filtered action API)
   │   observation → RedactionFilter → model
   │   model action → Browser PEP (origin allowlist, action allowlist) → browser
   │
   ├─ credential.use(cred, session, origin, LOGIN)
   │     Credential PEP: owner, agent, mission, session tenant, LIVE top-frame origin, revocation, risk
   │     ▶ blind window opens (observations paused, recording off)
   │     ▶ injector fills + submits (Steel Credentials v1; own vault later)
   │     ▶ page settles; touched element handles recorded
   │     ▶ blind window closes; DLP fingerprints registered
   │
   ├─ handoff(kind=3ds|otp|captcha|payment)
   │     push + magic link → human completes on phone → resume
   │
   ▼
Checkpoint every N steps (profile persisted) → session destroyed before provider cap
   ▼
Receipt + UsageEvent (browser-seconds, model tokens, proxy bytes)

Sessions are short by design. A long Mission is a chain of short sessions with persisted profile state, which also matches Steel's 15-minute and 1-hour caps.

4.5 Payments: rail router

payment.request(mission, amount_minor, currency, merchant)
   ▼
PDP + reservation
   ▼
Rail router picks the first eligible rail in the Mission's preference order:
   1. byo_card_program   (Privacy.com for consumers; Mercury/Slash/Brex for businesses; single-use card with exact limit)
   2. crypto_spend       (USDC on Base via Spend Permission; if merchant accepts x402/MPP/stablecoin)
   3. link_personal      (only for the account owner's own personal use; POC and opt-in)
   4. handoff_checkout   (universal fallback; human pays on own device)
   ▼
Trusted injector receives the credential reference; the model receives "card ready, last4 1234"
   ▼
Commit or release the reservation on outcome; receipt records rail, provider, decision, policy version

4.6 Crypto: user-held root, on-chain ceiling, our recipient rules

User (email/SMS/Google/Apple) → CDP embedded smart account on Base (createOnLogin: "smart")
   │  user signs a Spend Permission: token=USDC, allowance=25.000000, period=30d, spender=our_server_wallet
   ▼
Agent asks: wallet.transfer(10 USDC → 0xabc)
   ▼
PDP: recipient allowlist, contract allowlist, per-tx limit, velocity     (ours)
   ▼
Server wallet calls SpendPermissionManager.spend(...)                    (on-chain ceiling)
   ▼
30 USDC attempt reverts on-chain even if every layer above is compromised

Business path: company Safe (n-of-m) → Allowance Module setAllowance(agent_delegate, USDC, 5000e6, 43200 min, 0) → agent delegate executes within allowance. We never hold Safe owner keys.

Legal posture this creates: the user holds the root; our spender can only act within a user-signed, on-chain-bounded, user-revocable permission; we cannot widen it unilaterally. That is the "no unilateral and independent ability" shape in both FinCEN's four-factor test and CLARITY Sec. 109. Counsel still has to confirm.

4.7 API surface v2

Agent API (API key or MCP OAuth 2.1; every call carries a Mission-scoped Biscuit token):

agent.list            mission.propose        mission.status
browser.execute       credential.use         payment.request / payment.status
wallet.transfer       wallet.execute         email.send
file.read / file.write
approval.request      handoff.request        receipt.get      audit.search
capabilities.get

Human API (session + passkey step-up; never reachable with an agent credential):

mission.approve   mission.widen   mission.revoke   agent.create   agent.delete
connector.connect  credential.create  wallet.grant   killswitch.set   policy.render_english

Never, on any surface: credential.get_plaintext, card.get_saved_cvv, wallet.get_private_key, session.get_cdp_url.

MCP specifics: HTTP transport with OAuth 2.1 and RFC 9728 metadata; tools annotated (readOnlyHint for receipt.get, destructiveHint: true on anything that spends or sends); approval.request and handoff.request return elicitation URL-mode results so any compliant MCP client can complete the human step.

Part 5 — Security invariants v2 (each becomes an automated test)

1. No LLM output can increase authority. (Fuzz: model emits every widen/approve call; all rejected.)
2. No child token verifies with more authority than its parent. (Biscuit property test.)
3. Credential plaintext never enters model context. (Canary secret; grep all observations, logs, traces, screenshots via OCR.)
4. One-time card PAN never enters model context. (Same canary method with Luhn-valid test PAN.)
5. Wallet root or spender private key never enters model context or logs.
6. Tenant A cannot reference any Tenant B provider object. (Broker fuzz across all provider ids.)
7. Revoking a Mission aborts running executions at the next PEP call.
8. Expired tokens and capabilities are unusable at every PEP.
9. A compromised browser session cannot enumerate or fetch any vault secret. (Session token has no vault scope.)
10. PDP defaults to DENY; an empty policy set allows nothing.
11. Observation redaction: no touched element's value appears in any snapshot after injection.
12. No route bypass: a DENY on one route is never followed by an ALLOW on another for the same request.
13. Reservation atomicity: concurrent spends never exceed the Mission budget by one minor unit.
14. Widening a policy requires a human step-up; the new version applies only to executions started after it.
15. Egress DLP: a fingerprinted secret in an outbound email, file, or HTTP body blocks the action.

Part 6 — Phase 0 proofs v2 (build these ugly, in this order)

Each has a pass condition. If one fails, the architecture changes before any UI is built.

Part 7 — Cost model v2

Browser compute (verified prices)

Before proxies ($6–10/GB) and CAPTCHA. Steel Launch has no base fee but 15-minute sessions and 10 concurrent; fine for Phase 0–2, not for 1,000 users.

Model tokens (the number v1 left out)

If our driver runs the browser, each step sends an observation (a redacted accessibility snapshot, roughly 5–10k tokens) and gets a short action back. Order-of-magnitude at published Claude prices:

Prompt caching cuts the repeated prefix substantially, and BYO-model routes move this cost to the customer entirely. Either way, execution is metered and sold as credits; browser-seconds, model tokens and proxy bytes are the three meters.

Built-in AI tiering

All behind ModelProvider, using structured outputs with strict schemas so the deterministic compiler validates everything the model proposes:

• Mission compilation (natural language → policy proposal): Claude Sonnet 5. Accuracy matters and the output is schema-validated and human-approved.
• Classification, risk labelling, receipt summaries, audit digests: Claude Haiku 4.5.
• Escalate to Claude Opus 5 only if Sonnet's compilation accuracy in Proof G is insufficient.

Everything else at 1,000 users

CDP: roughly $80/mo at 10 sends per user. Safe: gas only. Cedar and Biscuit: free. Supabase: Pro tier. Stripe Billing: standard fees on our own invoices only.

Part 8 — Development order v2

Phase 0 — Break the plan (1–2 weeks). Proofs A–I. No UI. Output: pass/fail per proof and Stripe's written answer.

Phase 1 — Authority core (2–3 weeks). Organizations, users, agents, Missions, Cedar compiler, English renderer, PDP, reservation ledger, Biscuit tokens, approvals with passkey step-up, hash-chained receipts, kill switches, velocity tripwires. Invariants 1, 2, 7, 8, 10, 13, 14 pass in CI.

Phase 2 — Browser and credentials (3–4 weeks). Steel adapter behind BrowserProvider; broker table; blind-window injector on Steel Credentials behind CredentialProvider; redaction filter; egress DLP; handoff; checkpoint/resume; agent-owned MFA (number + mailbox); passkeys via CDP virtual authenticator; security-page deny rules; second adapter (Anchor or Browserbase) to prove the abstraction. Invariants 3, 6, 9, 11, 15 pass.

Phase 3 — Money, Track A only (3–4 weeks). Privacy.com and Mercury connectors; Crossmint if staging proves out; Mission Wallet with Stripe Checkout holds and our own corporate card program; Handoff Checkout; CDP embedded smart wallet + Spend Permissions on Base with onramp; Safe Allowance path; rail router; x402/MPP client. Link stays a flagged personal-use POC. Invariants 4, 5, 12 pass.

Phase 4 — MCP and REST (2 weeks). MCP server per 2026-07-28 spec with OAuth 2.1, elicitation URL mode for approvals and handoffs, tool annotations; REST with per-agent keys; capabilities.get; TypeScript SDK skeleton.

Phase 5 — App (4 weeks). Templates, Mission builder that shows the deterministic English, approval center, handoff screens, audit timeline, spend dashboard, kill switch. Only now.

Phase 6 — Rails and enterprise. Gmail/Calendar OAuth, Slack, GitHub, Turnkey adapter, Link commercial (if Stripe agrees), Issuing sandbox → program, local executor, SSO, multiple approvers, SOC 2, audit export.

Gates before granting real users substantial authority: outside security review of vault → injector → browser; fintech counsel memo; pentest of the multi-tenant broker.

Part 9 — Questions still open (pruned to what changes a decision)

Stripe (ask in the Phase 0 email): Will Stripe issue us a confidential Link OAuth client for a hosted multi-tenant agent? Under what terms may end users make business purchases given the consumer AUP? Does the delegated (create_delegated) path become available to us, and with what limits? Who bears fraud and disputes for agent-initiated transactions (Link's terms currently place them on the user)? Fees?

Steel (ask support; test ourselves): Is any per-org KMS key rotation or BYOK available? Does blurFields affect Runtime.evaluate reads or only rendered pixels (we assume no)? Roadmap for profile encryption statements and geo pinning? Will Credentials remain free after beta?

Coinbase (test ourselves): Does KYT/OFAC screening apply to embedded-wallet Spend Permission spends, or only to Agentic Wallets? Any per-wallet limits? Onramp trial-mode limits before application.

Card programs (test in sandbox): Privacy.com card-count limits per plan and whether "My Business" review is needed for our users; Mercury static-IP allowlisting and agent-card creation flow; Brex PAN-access qualification (unverified claim).

Counsel (written memo before Phase 5 ships to the public): Is the Mission Wallet (prefund → we buy with our own card → resell at cost plus fee) a retail sale rather than money transmission, and what returns, chargeback and sales-tax obligations follow? Do our corporate card program's terms permit purchases resold to customers? Under FIN-2019-G001 and MTMA-adopting states (Florida is not on the CSBS adopted list; confirm current Florida law separately), does operating a user-signed, on-chain-bounded spender key constitute control or money transmission? Does billing a percentage of agent spend as a separate software fee change the analysis? What PCI scope attaches to a trusted injector that briefly handles a single-use PAN from the customer's own card program? Required consent language for delegated signing (Privy's terms show what a vendor expects of us). Insurance.

Google: Timeline and cost for CASA if we want Gmail read via API; until then, reading stays in the browser.

Part 10 — The one rule that does not change

Every external provider is replaceable. Stripe, Coinbase, Steel, Supabase and Anthropic are infrastructure. The product is:

Agent identity + Mission + Authority (Cedar + Biscuit) + Execution (PEPs + injector) + Receipts

If Stripe never issues the OAuth client, Handoff Checkout and BYO programs still work. If Steel raises prices, self-host the Apache-2 core and bring our own vault. If Coinbase changes terms, route to Safe or Turnkey. If a model changes, change ModelProvider.

Part 11 — How this fits Anywhere AI

Anywhere AI (~/Documents/Codex/2026-08-27/new-chat, bundle com.coreycosta.anywhereai) already is the local half of Okay Seal. It has agents with per-permission policies, a Chromium pane that refuses to type into password and payment fields, Keychain credential references, sanitized Page DNA, an audit trail, a localhost MCP/REST surface, a durable loop scheduler with a reserved cloud_browser runner, and a credit ledger with authorize/settle semantics. What it lacks is exactly what Okay Seal adds: a cloud runner, credential injection, money rails, mission-scoped budgets, and a network-facing authority API.

11.1 Concept-by-concept map

11.2 Split it into products, share one core

You are right that these do not have to be one app. The clean split is two products on one core, not three.

Anywhere AI stays the human product: the workspace, the visible Chromium pane, voice, Page DNA, teach-and-replay, loops, memory. It is the local executor and the first client of Okay Seal. "Turn on cloud agents" and "Let agents spend money" become connector toggles inside Anywhere AI that sign the user into Okay Seal.

Okay Seal is headless: Mission compiler, Cedar PDP, Biscuit tokens, reservation ledger, receipts, cloud vault and injector, Steel runner, money rails, and the network MCP/REST/SDK. It sells on its own to developers, enterprises, and other agents (ChatGPT, Claude, Codex, OpenClaw) that will never install Anywhere AI. Anywhere AI is one customer among many, which is what keeps the authority layer honest and replaceable.

Shared core: the packages/contracts package grows to carry permission keys, tool names, the Mission schema, and the receipt format so both products speak the same names. Two Supabase projects, not one. Anywhere AI already shares a project with the Cost of Living app and the memory note records how fragile that is; a money-and-secrets service should not be a third tenant of it. Link accounts with a signed JWT from the Anywhere AI session; Okay Seal verifies it and issues its own tokens.

A third product (a consumer "Anywhere Pay" wallet) is premature. The rails in Part 3 are connectors inside Okay Seal; if one of them becomes the thing users want on its own, spin it out then.

11.3 The integration seams, in code

Each of these is a small, specific change to something that already exists.

1. Make ask_above_threshold real, then replace denial() with a PDP call. Today ask_above_threshold falls through to always_ask. First evaluate threshold (amount, count, origin) locally. Then compile agent_permissions plus a Mission budget to Cedar and evaluate it with @cedar-policy/cedar-wasm inside ToolRouter. Local and cloud enforce the same policy text.

2. Turn the sensitive-field refusal into the local injector. At the located.sensitive branch in browser-runtime.ts, if the caller holds a valid credential.use grant (owner, agent in allowed_agent_ids, live top-frame origin equals credential_references.site), pause instrumentation and Page DNA capture, read the secret from Keychain, type it through CDP Input.insertText, resume capture, record a receipt. Otherwise refuse exactly as today. This is Proof A from Part 6 run locally first, where it is cheapest, before the Steel version.

3. Blind window for browser.screenshot and browser.inspect. While an injection is in flight, those tools return "paused for credential entry" instead of pixels or DOM. Add the touched-element handle list to sanitizeBrowserPayload so the value never re-enters Page DNA after the window closes.

4. Add the tools and permission keys. externalToolDefinitions and BrowserToolName gain credential.use, payment.request, payment.status, wallet.transfer, approval.request, handoff.request, receipt.get. DEFAULT_POLICIES gains credential.use: allowed_within_policy (origin-bound), wallet.spend: ask_above_threshold; purchase and financial_trade already exist with the right defaults.

5. Implement the cloud_browser runner as a dispatch to Okay Seal. loop-runner claims loops as it does now; for runner = 'cloud_browser' it POSTs the loop and the user's Authority token to Okay Seal, which runs a Steel session (or replays a synced semantic workflow) and calls back into finish_loop_run. The existing push pipeline turns the result into a notification. Nothing about the scheduler changes.

6. Generalize the credit ledger to money budgets. Copy the authorize_ai_credits / settle_ai_credits pattern into Okay Seal as reserve_budget / commit_budget / release_budget keyed by Mission, in minor units, with idempotency keys. The replay-is-a-no-op invariant the credit tests already pin is Invariant 13.

7. Hash-chain activity_events. Add policy_version, prev_hash, hash columns and compute them in the writer. Receipts export becomes a query.

8. Upgrade the MCP server, keep it local. Move external-api.ts to protocol 2026-07-28, real inputSchemas, readOnlyHint and destructiveHint annotations. Keep it on 127.0.0.1 with the bearer token; that is correct for local execution. Okay Seal runs the network MCP with OAuth 2.1 and exposes the same tool names, so an external agent sees one namespace and the router picks local or cloud by execution_location.

9. Use workflows as the Mission execution primitive. A checkout taught once on the Mac (with slot: "card" and slot: "login" on the sensitive steps) syncs to Okay Seal and replays in the cloud with the injector filling the slots. This cuts model tokens (the largest cost in Part 7) and makes runs deterministic and auditable.

10. Agent-owned MFA and passkeys land in Anywhere AI's connector UI. "Give this agent its own phone number and inbox for codes" and "let this agent use a passkey for delegated accounts" are toggles per account under the existing website-permission records.

11.4 What changes in the build order

Phase 0 gets cheaper: Proof A (credential injection with redaction) and Proof G (policy round-trip) run inside Anywhere AI on the Mac with Keychain and CDP before any cloud provider is touched. Phase 1 (authority core) becomes the Okay Seal service plus the ToolRouter PDP swap. Phase 2 implements the cloud_browser runner. Phase 3 money rails ship in Okay Seal and appear in Anywhere AI as connectors. Phase 5's app UX is mostly already built; what is new is the Mission builder with the deterministic English rendering, the approval center, and the spend dashboard.

One caution to check before shipping money features inside the iOS app: App Store review treats in-app purchasing of physical goods, third-party card programs and crypto wallets differently from digital content. Keep the money connectors in the Mac app and the web surface first, and confirm the iOS treatment with the guidelines before exposing them there.

Sources (primary, read 2026-09-02)

• github.com/stripe/link-cli (README, CHANGELOG, CLI and SDK source); docs.stripe.com/agentic-commerce/link-cli and /oauth; link.com/terms and /terms/acceptable-use; docs.stripe.com/issuing/onboarding-overview; docs.stripe.com/issuing/agents; docs.stripe.com/agentic-commerce; docs.stripe.com/payments/machine
• docs.steel.dev/overview/pricinglimits, /credentials-api/overview, /profiles-api/overview, /self-hosting/docker; github.com/steel-dev/steel-browser; browserbase.com/pricing; docs.browserbase.com; docs.anchorbrowser.io; kernel.sh/pricing and docs; playwright.dev/docs/api/class-credentials
• developers.privacy.com; docs.mercury.com (createcard, revealcardpan, OAuth); docs.slash.com; developer.brex.com; docs.ramp.com/llms-guides; paywithextend.com; docs.crossmint.com/agents; pcisecuritystandards.org FAQ 1280, DSS v4 SAQ D-SP, glossary; developer.visa.com; developer.paypal.com/agentic-commerce-services; github.com/google-agentic-commerce/AP2
• docs.cdp.coinbase.com (embedded-wallets, spend-permissions, pricing, agentic-wallet, x402); github.com/coinbase/spend-permissions; privy.io/pricing and terms; docs.privy.io/controls/policies; turnkey.com/pricing; docs.turnkey.com; docs.safe.global/home/ai-agent-quickstarts; github.com/safe-fndn/safe-modules; docs.metamask.io/smart-accounts-kit
• govinfo.gov H.R. 3633 (RFS text, Sec. 109); fincen.gov FIN-2019-G001, FIN-2014-R002; developers.google.com/workspace/gmail/api/auth/scopes; support.google.com/cloud/answer/13464325 and /7454865; docs.aws.amazon.com/enclaves; docs.cedarpolicy.com; github.com/cedar-policy/cedar-spec; doc.biscuitsec.org; modelcontextprotocol.io/specification/2026-07-28; csbs.org MTMA model law and April 2026 tracker; federalreserve.gov SR 26-2

Part 12 — Bring-your-own executor (added 2026-09-02 after the build)

The build confirmed the BYO-agent model end to end (MCP + OAuth 2.1, opaque credentials and cards, on-chain wallet ceilings, receipts). What is not built is a bring-your-own executor: the case where the agent's own browser, or the user's local Chrome, performs the fill instead of our Playwright/Steel process. Today the injector assumes it drives the browser.

Design, so it is a defined protocol rather than an afterthought:

interface AuthorityExecutor {
  identify(): { executorId: string; kind: "chrome-extension" | "desktop" | "steel" | "playwright" | "third-party"; attestation?: string };
  navigate(url: string): Promise<{ origin: string }>;
  observe(): Promise<PageObservation>;                       // already redacted by the executor
  useCredential(capability: string, target: { ref: string; kind: "username" | "password" | "totp" | "submit" }): Promise<"FILLED" | "DENIED">;
  usePaymentCredential(capability: string, target: { number: string; cvc: string; exp?: string; submit?: string }): Promise<"FILLED" | "DENIED">;
  approvePasskey(capability: string): Promise<"ASSERTED" | "DENIED">;
  persistSession(): Promise<{ profileId: string }>;
}

• The capability is a short-lived Biscuit token bound to (execution, credentialId or authorizationId, executor identity, exact origin). The secret itself is delivered to the executor over a channel the agent never sees (a WebSocket the executor opened with its own executor token), decrypted only inside the executor, and never echoed back.
• The agent only ever sees FILLED or DENIED. credential.available(origin) (to add to the agent API) lists credential ids the mission permits for the current origin so the agent knows what to ask for.
• Registration: an executor is registered by the human (like a connector) and inherits the mission's execution_location; LOCAL_ONLY credentials can only be delivered to executors of kind chrome-extension or desktop on a registered device.
• Adapters: RemoteExecutorProvider implements BrowserProvider on our side; the Chrome extension, Anywhere AI's Electron pane, Steel and Playwright all implement AuthorityExecutor. The Anywhere AI seam (Part 11.3 item 2) is this protocol's first local implementation.
• Routing: "when my PC is online use local Chrome, otherwise cloud" is a per-mission executor preference list, resolved by the router at execution start, invisible to the agent.

Build order: define the protocol in contracts, implement RemoteExecutorProvider and the WebSocket channel in browser, then the Anywhere AI local injector, then a Chrome extension.