Voice Tool Calls and Evidence

Keel can govern consequential money-moving tool calls a voice application routes through its managed payment boundary. The realtime conversation itself is not Keel-governed. The customer’s gateway owns audio, text streaming, provider credentials, tools, and any direct downstream calls.

Supported boundary

For a voice-initiated payment, follow Stripe MPP or x402 and route the exact payment through Keel. An ALLOW for a model invocation or a session turn is not authority to run a tool. DENY, THROTTLE, and unresolved REVIEW produce no managed dispatch on the payment path. An approved REVIEW must still meet positive authority and bind the exact request.

A call your gateway makes directly with its own credentials is outside this boundary. Session evidence and customer-reported atoms do not turn such a call into a Keel-managed effect.

Reference gateway and session APIs

The reference gateway has OpenAI Realtime and OpenAI GPT-Live adapters. Twilio, Vapi, and Deepgram agent adapters are not shipped. The keel-voice-sidecar package is unpublished and is not a customer installation path. This page does not certify compatibility with arbitrary voice providers or gateways.

The existing APIs record session and event evidence:

Raw audio remains at the provider or customer gateway. Send hashes and the supported event fields rather than raw voice media. Optional transcript spans are content; their presence must be considered in the customer’s retention and privacy choices.

Session action-permit requests retain their submitted arguments. See Session action arguments for where they are stored and how they limit exports.

For a separately governed tool call, use the existing managed MCP execution path with an operator-enrolled eligible connector and exact bound request. Its evidence lifecycle is separate from the Session action-permit record. Neither an action Permit nor a session turn dispatches that tool.

Recorded Session actions

GET /v1/sessions/{session_id}/action-ledger reads existing project-owned Session records on every plan with an authorized project credential. It is not a complete record of every tool the customer runtime invokes. A Session action-permit binding is an authorization decision and does not establish tool dispatch, provider receipt, execution or an external effect, including when the child decision is DENY.

For a voice tool authorization entry, before_digest is the request-event hash and after_digest is the Permit-binding hash. Neither is a delivered provider body or proof of withheld media. A legacy signed_event JSON object is not a standalone Ed25519 receipt; verify the actual artifact and its declared claims. Historical entries can retain legacy status labels; a label such as dispatched does not establish dispatch without the corresponding managed lifecycle evidence.

Session entries backed by preserved governance-chain records can remain beyond dashboard log windows; the reader has no hard visibility or deletion cutoff. See Observability and Data Handling.

Evidence and plans

Session APIs and the documented payment paths are available on every plan; signed compliance export requires Production or Enterprise. A voice attestation reports the recorded session events and authority it contains. It does not prove that the whole conversation was intercepted, governed, or externally completed. Provider receipt, execution, and state-change claims require independent supporting observations.

Run the verifier against the downloaded artifacts and trusted signing material. RFC 3161 receipts are included only where configured and produced; absence is not a timestamp claim. Activity after the newest checkpoint has no checkpoint coverage until the next checkpoint is published.