Keys and Authority
Which keys control policy, wallet ownership, signing, approval, and trusted state.
Pakt uses separate keys for separate jobs. There is no all-powerful “Pakt key,” and an MCP-connected agent receives no owner or wallet private key.
Agents Never Receive Private Keys
The owner retains policy and recovery authority. The secure boundary verifies one request, the wallet provider signs it, and the MCP agent receives none of their private keys.
Keys the Owner Controls
- Backed-up passkey: activates or terminally disables one exact Pakt root. Its public credential is also registered as the execution wallet's root owner. The private key stays in the owner's authenticator.
- Existing EVM wallet: funds the execution wallet and is recorded as its recovery destination. For Hyperliquid, this wallet is the master that approves or revokes the execution agent. Its private key stays in the owner's wallet.
For Hyperliquid, these roles do not conflict: the passkey owns the hosted execution wallet, while the existing EVM wallet remains the Hyperliquid master.
Keys Used by the Service
- Approver key: creates an approval stamp after one exact request passes proof and payload verification. The wallet provider requires this stamp, but the approver key cannot sign a venue request or move funds.
- Receipt credential key: signs the exact verified artifact stored with an allowed receipt. The browser checks this signature against a pinned public key. It is evidence of authorization, not a venue signature.
- Execution signing key: is held by the wallet provider. It signs an exact Hyperliquid or Ethereum request after approval. It cannot activate or change a Pakt.
Keys That Authenticate State
- State-attestor keys: sign market and account facts such as prices, balances, and positions. A Pakt records the public keys it accepts. These keys supply evidence; they cannot authorize an action.
The passkey controls the Pakt lifecycle and the execution wallet's root ownership. The existing wallet funds it and, for Hyperliquid, retains master-level exit and agent-revocation authority. Both remain under owner control.
Identity Is Not a Signing Key
OAuth tells the hosted service which account is calling. Owner approval tells Pakt which agent may act for that account. Neither gives the agent a passkey, wallet key, approver key, or state-attestor key.
When an action is allowed, the agent receives a signed request, not the private key that signed it. The receipt separately carries the credential signature that records the authorization. When an action is refused, no approval stamp, credential signature, or wallet signature is released.
Continue with the authorization pipeline to see how those roles handle one action, or the trust model for the full boundary diagram.