Trust Model
The owner-approved agent, authenticated state, proof boundary, wallet provider, and independent verifier.
An approved agent may propose actions, but it does not decide whether they are safe and it cannot obtain a wallet signature by itself. The owner controls the agent identity, active constraints, and exit authority.
Approved Does Not Mean Trusted
Treat agents, orchestration, proving, and caller-supplied data as untrusted. Authority is released only after trusted state, the active Pakt, the proof, and the exact signing payload all agree.
- The owner approves a delegated agent for the account.
- The owner generates or imports a Pakt and approves its exact root.
- That approved agent proposes an exact action against an active root.
- State sources authenticate the inputs needed to evaluate it.
- The committed constraint evaluator checks the exact action inside the proof.
- Secure hardware re-checks the proof and exact payload before issuing an approval stamp.
- The wallet provider signs only a stamped request.
- Anyone can re-run the receipt verifier locally in the browser.
Untrusted or Replaceable
- The drafting agent and its natural-language explanation
- The approved action agent's reasoning and proposed venue fields
- The orchestration service that coordinates the authorization job
- The proof service that computes the cryptographic proof
- Caller-supplied state, price, account, environment, wallet, and signer claims
The action agent is approved to make requests, but Pakt does not trust it to follow the constraints. Agent approval controls who may ask. The proof gate decides whether one exact request may be signed.
Trusted Boundaries and Named Assumptions
- The owner's backed-up passkey for Pakt lifecycle authority
- The wallet/venue binding that recognizes the approved delegated agent
- Authenticated state sources for the claims they attest
- The pinned Pakt verifier and committed constraint evaluator
- Ordered proof and payload verification inside the secure approver
- The wallet provider's custody and signing policy
- Venue semantics for the signed request it accepts
The remote prover can see proof inputs and can fail to respond, but it cannot forge a proof that passes verification.
Authority That Remains Separate
- A passkey authorizes Pakt lifecycle changes; it is not a venue key.
- A wallet-owner or venue-master key remains the owner's exit and revocation authority; Pakt never receives it through MCP.
- The delegated agent may propose supported actions but receives no generic sign, transfer, withdrawal, key-export, or owner operation.
- A policy refusal releases no stamp or wallet signature.
For implementation-level threat analysis, see SECURITY.md and the design document.