Conveyance

Why moving the credential matters

AI agents sometimes need authenticated requests to be useful. Storing the secret in an environment variable, an agent-readable config file, a secret manager the same host can invoke, or an OS keychain available to the process can improve storage hygiene, but it does not move the secret outside that machine's compromise boundary. A host compromise or agent-directed code execution can still reach what the host is allowed to use.

Conveyance explores a different split for MCP credential isolation. The PC requests a capability; a separate phone possesses the credential; a person sees the request and approves it; the phone executes the authenticated HTTP request; and the PC receives the result rather than the secret. The analogy to a hardware wallet is useful because credential use moves to separate hardware with a physical approval step. It is not literally a cryptocurrency wallet, and the phone remains a critical trust failure because it holds both the credential and approval authority.

Request-bound separate-device approval

MCP client → shim → daemon → encrypted BLE → phone → result

The MCP shim speaks JSON-RPC over stdio and hands a narrow request to a long-lived local daemon. The daemon owns pairing, session state, local logs, and the Bluetooth connection. Over BLE, Conveyance uses an application-layer encrypted session; the security model does not depend on BLE pairing alone. The intended phone side displays the request, requires a physical tap, uses the credential it holds, and returns only the result.

Why bind approval to the payload?

Approval is useful only if it applies to the request that runs. Without a request binding, a compromised PC could show a harmless operation to the user, collect approval, then substitute a different privileged request before execution—a classic time-of-check/time-of-use gap. Conveyance binds the approved and executed payloads after canonicalization, so the exact request the person saw is the one the phone is expected to execute.

The PC-side implementation is implemented: cryptographic and storage components, session and wire handling, pairing state, daemon, MCP shim, CLI, mock-phone flows, and a BLE transport. The BLE central path has been exercised over real radio against a test peripheral; the broader path has been validated with mock transport and a mock phone. A real phone performing pairing, approvals, credential storage, and authenticated execution is not an end-to-end workflow to rely on today.

Exploring the PC-side implementation

Developers can build the Rust workspace, run the daemon and MCP shim, inspect logs, and exercise the supported mock-phone path. The repository's setup instructions cover the OS-keychain requirement, configuration, command surface, and feature flags. A missing keychain is treated as a startup error rather than quietly falling back to weaker storage.

The important expectation is modest: this is a way to study and test the boundary, not a promise that a real phone can approve production requests today. The architecture and phase documents are the right place for protocol choices, state machines, and implementation status.

What the model does not solve

Conveyance makes a deliberately narrow security claim: a compromised PC should not be able to extract a credential it never holds, forge a phone approval, or swap a different payload after approval. It does not make a compromised phone safe; the phone is the endpoint trusted with credentials and approval authority.

Radio jamming, traffic analysis, physical coercion, and other endpoint failures remain outside this boundary. The design uses established cryptographic primitives and keeps its application session above BLE, but it is not a general answer to every kind of agent or device compromise. For a complementary MCP boundary that records local tool use rather than moving credentials, see AuditMCP's local audit proxy.

Sources and further reading

Conveyance README (commit 1753ea7) · Conveyance design specification (commit 1753ea7) · Conveyance implementation phases (commit 1753ea7)