← Back to how we built this

How we secured the AI assistant after launch

This is the security follow-up to our build write-up. Same system, now hardened with production abuse controls and verification evidence.

Quick recap of the initial rollout

When we launched the diagnostic assistant, security was part of v1 from day one: fixed mission catalog, conversation boundaries, input limits, rate limiting on the AI path, and hard prompt boundaries for jailbreak and abuse attempts.

We also ran adversarial prompt testing before rollout. That included prompt injection attempts, hostile/off-topic prompts, and forcing the model to invent services or prices. If it broke constraints, it did not ship.

Need the full technical build context first? Read How we built this AI assistant →

That gave us a solid baseline. The follow-up work below hardened the operational abuse surface around email capture and public write endpoints.


What we hardened next

All sensitive credentials (AI keys, email provider keys, token signing secrets, and challenge secrets) are stored as encrypted Netlify environment variables — never shipped to the browser and never committed to the repo.


Security flow at a glance

Request path for /api/diagnostic-email with explicit control points and response codes.

POST /api/diagnostic-email
  1. 1) Netlify code-based rate limit 20 req / 60s by ip+domain. Exceeded traffic returns 429.
  2. 2) Input and mission validation Reject invalid email/mission IDs and malformed payloads with 400.
  3. 3) Session token verification (HMAC) Validate signed token (scope, exp, and blob_key binding). Failures return 400 or 503 if signing secret is unavailable.
  4. 4) Conditional challenge gate If force-challenge conditions are met, require Turnstile token and verify via Cloudflare /siteverify. Missing/failed checks return 403 with challenge_required or challenge_failed.
  5. 5) Email send + conversation update On pass, send recommendation email, notify internal recipient, update blob metadata, return 200.
Controls in sequence: 429 gate -> 400 validation -> HMAC token check -> 403 challenge gate -> 200 send path

How we verified in production

We did controlled burst tests and challenge drills in production, then validated outcomes in Netlify Observability:

Security controls only matter if they hold under traffic and still preserve conversion. We tested for both.


Current posture and residual risk

After these updates, abuse resistance on diagnostics moved from high-risk to low-medium in our internal assessment. The biggest win was adding enforceable controls on public write/send endpoints and proving them with real telemetry.

Residual risk is now in predictable places: replay-hardening depth, stricter schema validation, and automated alerting quality. Those are iterative engineering tasks, not blind spots.

Full implementation notes and test evidence are documented in our internal security delta report for this rollout cycle.


Want this level of rigor in your AI rollout?

We implement AI systems with measurable controls and production validation — not just demos. If you’re shipping MCP or agent workflows, we can help you move fast without cutting security corners.

See MCP Jumpstart →