01. Secret isolation
No privileged credential, bearer token, or unrestricted data key reaches the browser bundle. The server owns secrets and exposes only the narrow operation required.
The Public AI Feature Threat Model
One button. Five attack surfaces.
A practical launch guide for securing public AI generators, calculators, assistants, assessments, and lead magnets from browser to data store.
Get the guideSee the five gates
The hidden product
The prompt is only the visible surface.
A public AI feature connects multiple systems in one click. Treating it like an ordinary form hides the places where privileged access, untrusted instructions, generated output, personal data, and unbounded usage cross boundaries.
01Browser
02Server boundary
03AI model
04Output renderer
05Lead store
The launch contract
Five gates before public traffic.
02. Input contract
Define allowed length, structure, task, content classes, and rejection behavior. Treat visitor text as untrusted instructions, not as an extension of the system prompt.
03. Model containment
Give the model the minimum data, tools, and privileges the feature needs. High-risk actions require deterministic policy and human approval.
04. Output safety
Generated content is untrusted data. Render plain text where possible; otherwise validate, encode, and sanitize for the exact downstream context.
05. Abuse and data controls
Set rate, token, cost, retention, and read-access ceilings. Log enough to investigate abuse without collecting data the feature does not need.
Launch proof
Run adversarial inputs, inspect the production bundle, test permission boundaries, verify cost controls, and rehearse key rotation and endpoint shutdown.
First-party correction
A browser was holding responsibilities that belonged on the server.
An internal recruiting-product audit found a public generator where privileged credentials were delivered to the browser and visitor-influenced model output could reach a raw HTML rendering path. The correction moved generation server-side, protected the model credential in a vault, capped public input, returned plain text, and narrowed lead capture to the access it required. This guide shares the defensive pattern without naming the product, repository, vendors, credentials, endpoints, or exploit details. No breach or customer harm is claimed.
Move power server-side
Rotating a browser-exposed key is temporary if the replacement must still ship to every visitor.
Treat the model as untrusted
A plausible answer is not necessarily safe HTML, SQL, a file path, or an instruction for another tool.
Grant the narrow operation
A public page that only appends a lead should not receive credentials capable of reading the lead store.
48-hour launch gate
Test the boundary, not only the happy path.
Inspect
Search the built browser assets for credential patterns, provider hosts, privileged tokens, private endpoints, and unexpected configuration.
Attack the task
Try role changes, instruction overrides, long inputs, encoded payloads, hostile markup, repeated requests, and cross-user data access.
Constrain cost
Define per-request and per-identity ceilings, daily budget alerts, timeouts, concurrency limits, and an emergency disable switch.
Prove recovery
Rotate credentials, revoke the old path, disable generation, preserve safe lead capture, and confirm the product fails honestly.
Authoritative guidance
Build the controls on documented boundaries.
OpenAI API documentation says API keys must not be exposed in client-side code. OWASP documents prompt injection, improper output handling, and safe output sinks and encoding. React warns that raw HTML rendering should receive only trusted, sanitized data.