Security overview
Built around least access.
EV ChitChat connects voice requests to a physical vehicle, so security is part of the product boundary, not an add-on. This page separates controls already implemented from controls required before the beta expands.
What this means for you
- Your Tesla password never touches EV ChitChat. You sign in on Tesla's own page, and we only ever hold the permission it hands back.
- We never receive your location. Not your position, not your routes, not your trip history. We do not request that category from Tesla, so there is nothing to leak or subpoena.
- Your credentials stay encrypted on our servers. Never in your browser, never in a log, never in an Alexa response.
- Alexa cannot send arbitrary commands to your car. Six specific operations are allowed. Unlocking, driving, doors, trunks, windows, and the horn are not among them and are not planned.
- Every command is checked several times over against your account, the permissions you granted, your paired key, and a switch we can flip to disable all commands at once.
- You can walk away instantly. Disconnect Tesla or delete your account from the Account page, any time, without asking us.
What EV ChitChat can read
- Battery level and estimated range
- Charging state, charge limit, and time to full
- Plug state and lock state
- Cabin and outside temperature, climate on or off
- Tire pressure
- Software-update availability
- Odometer
Read once, when you ask. Never stored.
What it never touches
- Location, routes, heading, speed, or trip history
- Your Tesla password, or your Google password
- Arbitrary Tesla API commands
- Unlock, remote start, doors, trunks, windows, horn
- Continuous telemetry or driver-behavior profiles
- Alexa voice recordings
Not requested, so there is nothing to leak.
Your devices
Holds an opaque EV ChitChat token, never a Tesla credential.
HttpOnly session cookie only. Firestore denies every browser read and write.
Identity delegated. Passwords are never seen or stored.
Platform checks
Amazon signature, timestamp, and skill IDSpeech becomes a structured request. No audio reaches EV ChitChat.
Ten-minute server-held state. Tokens random, hashed, rotating.
EV ChitChat servers
Per-account auth and daily fair-use limitsEvery route authenticated or origin-checked. Tokens, VINs, and locations are banned from logs.
No service-account keys anywhere. Short-lived federated credentials per request.
Deny-all client rules. Only tokens, VINs, and preferences are kept, all encrypted. Short-lived records self-delete.
Isolated signer, then Tesla
Cloud Run IAM, one caller, audience-bound tokenExactly six allowlisted operations with fixed bodies. Arbitrary Tesla paths impossible.
Exists in one place, mounted only into the signer. Never in Vercel, GitHub, or a browser.
Owner-authorized scopes. Vehicle readings answer your question and are discarded, never stored. The location category is never requested.
- “Alexa, ask Chit Chat to start climate”
- Signature verified
- Token finds account
- Limits and key checked
- Signed in isolation
- Your Tesla acts
Always
- One vehicle read per question, only when asked
- Disconnect and full deletion, self-serve, any time
- Emergency switch disables all commands at once
Never
- Passwords seen or stored, Google or Tesla
- Location, trips, or continuous telemetry
- Waking a sleeping car, or commands that unlock or move it
If a layer fails
- Stolen cookie: no database access, fair-use capped
- Compromised web app: still cannot sign a command
- Leaked database: tokens and VINs are ciphertext
Implemented now
- Official Tesla OAuth and minimum MVP scopes; EV ChitChat never asks for a Tesla password.
- Google sign-in uses a top-level redirect through a same-origin Firebase auth helper (no pop-ups, no third-party iframes), and a recently authenticated token is exchanged for a host-only HttpOnly server cookie. An optional server-side Google OAuth path adds S256 PKCE, a single-use server-stored state, and ID-token issuer, audience, and nonce checks.
- The browser Firebase session is session-scoped and cleared after the server session is created.
- Server access to Firebase and Google Cloud is keyless: Vercel's per-request workload identity is exchanged for short-lived Google credentials through Workload Identity Federation. No service-account key files exist in Vercel, source control, or the browser.
- Firestore rules deny every browser read and write, including authenticated browser clients, with emulator tests enforcing the rule.
- Server-private Tesla refresh tokens and full VINs are encrypted with contextual AES-256-GCM before Firestore persistence.
- OAuth state is random, hashed at rest, ten-minute, single-use, transactional, and bound to the signed-in EV ChitChat user.
- Disconnect deletes EV ChitChat Tesla records; account deletion requires recent authentication and removes the Firebase-backed account records.
- Alexa requests are checked for Amazon signature, timestamp, and registered Skill ID; vehicle access additionally requires a valid linked EV ChitChat token.
- Alexa account linking uses exact redirect allowlisting, optional S256 PKCE, hashed opaque credentials, one-hour access tokens, and transactional refresh rotation.
- Alexa account linking completes with Google sign-in inside the Alexa app; the Alexa request is held in a ten-minute, single-use server record and bound to the account only after authentication. A one-time code approved from an existing EV ChitChat session remains available as a fallback; only hashes of the code and polling token are stored.
- Every Alexa request is answered from a single read of the vehicle and never wakes a sleeping car; the skill reports that the car is asleep instead.
- Cabin climate start and stop, maximum defrost, and road-trip charge presets are live as paid features under EV ChitChat Plus. Every command passes independent account, subscription-entitlement, scope, virtual-key pairing, feature-gate, and allowlist checks. Entitlement is enforced server-side in the vehicle service at the single shared choke point used by both intent handlers and Alexa Routine task invocations. The isolated signer exposes exactly six normalized operations with fixed request bodies, never arbitrary Tesla API paths.
- The Tesla signing key is stored in Google Secret Manager and mounted only into the isolated Cloud Run signer.
- Vehicle commands sit behind an emergency disable switch, and preview deployments receive no production command credentials.
Required before broader beta
- Production verification and failure-recovery testing for the implemented atomic Tesla refresh-token lease and rotation.
- Continued production verification of replay protection and request idempotency under real load; account linking and per-user authorization are verified.
- Production verification of disconnect, account deletion, Tesla consent revocation guidance, and virtual-key removal guidance.
- Short retention schedules, privacy-safe audit events, billing alerts, incident procedures, and command-disable drills.
Vehicle-data boundaries
The skill reads only Tesla's charge, climate, and vehicle-state categories: battery, range, charging, charge limit, plug and lock state, cabin and outside temperature, climate state, tire pressure, software-update availability, and odometer. It never requests the location category, so position, heading, speed, and trips are never received, and it does not retain live readings, raw API responses, continuous telemetry, or driving profiles.
Credential boundaries
- Tesla refresh tokens are server-only and encrypted before database persistence.
- Short-lived Tesla access tokens are stored encrypted beside the refresh token under a distinct context, never in logs or any response, and are treated as expired five minutes early. They are strictly less powerful than the refresh token already held in the same record, so this adds no new trust boundary while removing a Tesla round trip and a refresh-token rotation from every request.
- The Tesla command-signing private key is never stored in Firebase, Vercel, GitHub, browser code, or an Alexa response.
- Public Firebase configuration and the Tesla client ID identify applications; they are not Admin credentials.
- Admin credentials, token-encryption keys, authorization headers, and OAuth codes must never enter browser-visible variables or analytics.
Command safety
Each command must pass independent account, scope, vehicle, pairing, environment, feature-gate, and allowlist checks. Retries and wakes are bounded. Ambiguous results must be reconciled before a command is retried. Unlock, remote start, doors, trunks, windows, location, horn, and arbitrary commands are not part of the product and are not planned.
Logging and monitoring
Logs may contain opaque correlation IDs, normalized intent, result category, latency, and estimated billing category. They must not contain tokens, codes, full VINs, locations, signed payloads, authorization headers, or raw Tesla responses.
Reporting a concern
Report a suspected vulnerability or unauthorized vehicle action to projects@buildingrome.dev. Do not include passwords, tokens, private keys, a full VIN, or precise location in email. We will acknowledge and investigate good-faith reports.
No absolute guarantee
Security controls reduce risk but cannot eliminate it. The private beta should not be used for emergencies or relied on as the only way to verify vehicle state. Read the Privacy Policy and Terms of Use for additional boundaries.
Security posture · Updated September 4, 2026