An API key leak is a product-ending trust event. Every engineering decision around key handling was made with that outcome in mind.
Frontend key handling
The API key input field is treated as a credential from the moment the user types it.
Key stored in React component state only — never localStorage, never sessionStorage
Input field has autocomplete="off" and data-analytics-exclude
Content Security Policy headers prevent XSS from reaching the input field value
Analytics tools (PostHog, Sentry) are explicitly prevented from capturing key input field values
<input
type="password"
autocomplete="off"
data-analytics-exclude
onChange={setKey}
/>
Backend key handling
Once the key reaches the backend, the same discipline applies throughout the session lifecycle.
Key held in session object memory only — never written to Postgres, Redis, or any log sink
Central logger throws an exception if any log call attempts to write a credential field
Key is passed directly to the LLM SDK — it is never serialized, stored, or forwarded elsewhere
Session teardown explicitly nulls the key reference before deallocating the session object
if (data.apiKey || data.key) {
throw new Error(
'Credential in log call'
);
}
Content Security Policy
The frontend enforces a strict CSP that eliminates the most common XSS injection vectors.
No inline scripts or eval — all JS must be from trusted sources
No external script loading from non-allowlisted origins
Strict-Transport-Security enforced — no HTTP fallback
Content-Security-Policy:
default-src 'self';
script-src 'self';
connect-src 'self'
wss://backend
api.openai.com;
Chrome Extension isolation
The Chrome extension operates in a strict isolation model — it cannot be used to exfiltrate data from the page.
Manifest V3 — service worker model, no persistent background page
Extension only has access to tab audio — no DOM access on meeting tabs
Content scripts are scoped minimally — no access to page JavaScript context
Extension to backend communication uses the authenticated WebSocket only