Skip to content

Security & Trust

Parrot puts an AI on your real phone line, so the trust questions are fair: who can reach the line, who can hear the calls, and how the pieces prove they are who they claim to be. This page is the trust model. For what data is collected and how long it's kept, see Privacy.

Three separate identities

Parrot keeps three trust boundaries distinct on purpose, so a leak in one doesn't cascade into the others:

  • Your console login — a signed session cookie. It's how you reach the console.
  • API keys — how anything outside the console acts on your account: an MCP agent, or the bridge. Each key is bound to exactly one device and can touch only that line.
  • The board's identity — baked into the board when you flash it (its device id and Bluetooth name), and cryptographically verified on every connection (below).

The key is the leash

The one-key-one-line rule is what makes "my AI has my phone" a sentence you can say calmly:

  • A key gives its holder one line and nothing else — no way to enumerate your other devices, spend past the account's limits, or reach another user's hardware.
  • Revoking is instant and total. Delete a key on the API keys page and the holder's very next request fails with 401: no grace window, no cached session survives it. That's the kill switch if a key leaks or an agent misbehaves — and the phone line itself is untouched.
  • Rotate without downtime: create the new key, update the client config, then revoke the old one. Both work during the overlap.
  • Keys are bearer credentials over TLS, stored hashed. A key that resolves to nothing is rate-limited per source IP, so probing for valid keys is not productive.

The board proves the server, and the server proves the board

The link between board and server is mutually authenticated, so neither a rogue server nor a spoofed board can slip in:

  • The server proves itself to the board. The firmware carries a public key and periodically challenges the server to sign a nonce with the matching private key. A server that can't sign is refused by the firmware, so a man-in-the-middle can't impersonate Parrot to your board. This proof is public and auth-independent: even a connection that's about to be refused for the wrong account gets a valid identity answer first, so a refused bridge never mistakes an authorization failure for an impostor.
  • The board proves itself to the server. The device id baked in at flash time, plus the device-bound key the bridge authenticates with, mean a bridge can only ever run the one board its credentials were issued for. Knowing a device id is not enough — see below.
  • Version gate. The server checks the firmware and bridge versions on connect and can refuse an outdated one with a structured upgrade prompt rather than running a known-broken combination.

Ownership, not just visibility

Reaching a device requires being its owner, not merely knowing it exists. Device ids are hardware addresses, not secrets, so the server never treats "I know the id" as access. A signed-in non-owner — or an anonymous probe — is refused, and API responses for a device you don't own are a flat 404, never a "not allowed" that would confirm the device is real.

Your call data

  • Recordings and transcripts are stored server-side, keyed by call, and shown back to you in History. Only the account that owns the line can read them.
  • Over MCP, agents get the text transcript, never the audio — an agent can read what was said but can't extract the recording.
  • Bring your own vendor key. You can point an assistant at your own provider credentials so the AI vendor bills you directly and the audio goes to the vendor you chose — see AI providers: your own key. Provider keys you supply are encrypted at rest.

What Parrot can't protect

Being honest about the edges:

  • The Bluetooth link is a local radio link, exactly like any hands-free car kit — its security is whatever your phone's Bluetooth pairing provides. Keep the board somewhere you control physically.
  • The bridge lives in a browser tab. Anyone at your unlocked computer with that tab open is on your line — see The bridge.
  • A key is a bearer credential. Whoever holds the string can use the line until you revoke it. Treat it like a password: don't commit it, don't paste it into shared chats, and give each agent its own so you can revoke one without disturbing the others.