Security

Last updated: July 26, 2026

Thomas has spent thirty-five years securing other people's infrastructure, so it would be poor form not to explain how this one is put together. This page describes the actual measures protecting thomasbedell.com and Ava, its AI assistant — no more and no less.

1. Architecture

The site is a static set of files served by nginx from a container running on Google Cloud Run. Ava's backend runs as a separate process inside that same container, reachable only over the container's own loopback interface — it is never exposed to the internet directly. nginx proxies the small set of paths under /api/ava/ to it and nothing else.

Keeping Ava in-process with the site means requests to her are same-origin: no cross-origin API surface, and no credentials in the browser.

2. Credentials

• There is no AI API key at all. Ava reaches the model through Vertex AI using the workload's own Google Cloud identity, so there is no key to leak, ship, or rotate — and none in the page source.
• Remaining secrets are injected at runtime from Google Secret Manager. They are not committed to source control and are not baked into the container image.
• Access is least-privilege — the service account running the site can read the specific secrets it needs and nothing else.

3. Transport and delivery

All traffic is served over HTTPS with TLS terminated by Google's edge; the managed certificate is renewed automatically. Requests to www are permanently redirected to the canonical host. Connections from Ava's backend to the AI, speech, email, and CRM providers are made over TLS.

4. Handling untrusted input

Everything arriving from a browser is treated as hostile until proven otherwise:

• Conversation history is re-validated on every request. Only plain-text visitor and assistant turns are accepted; anything else — forged tool results, injected instructions posing as system content — is discarded before it reaches the model.
• Length and volume caps apply to message size, conversation length, and request body size.
• Rate limiting per IP address on both the chat and speech endpoints, with separate budgets, so abuse of one does not starve the other.
• Output is escaped before display. Ava's replies are HTML-escaped first and only then converted to links and emphasis, so no text she produces can inject markup or script into the page.

5. AI-specific safeguards

An AI assistant introduces risks a static page does not. The ones that matter here are handled as follows:

• A narrow tool surface. Ava can do exactly two things beyond talking: record an inquiry and request a call. She has no access to a filesystem, a shell, a database, or any ability to browse or execute code.
• No privileged reads. She cannot look up other visitors, retrieve past conversations, or query the CRM. Information flows one way — out to Thomas.
• Bounded turns. Tool use is capped per turn, so no prompt can drive her into an unbounded loop.
• Prompt-injection resistance. Because visitor-supplied history is filtered to plain conversational turns and her tools cannot reach anything sensitive, a successful injection yields at most a badly worded email to Thomas.
• Explicit behavioural limits. She is instructed never to quote pricing or contractual terms, never to claim work that isn't published on the site, and to identify herself as an AI whenever asked.

6. Data minimisation

• No payment data is collected anywhere on this site. There is no checkout, no card form, and no payment processor.
• No accounts, no passwords. Nothing to log into means no credential database to breach.
• No advertising or analytics trackers, so there is no third-party script with access to the page.
• Conversations are not stored server-side between messages. Only an inquiry you deliberately submit is recorded.

What is collected, and who processes it, is set out in full in the Privacy Policy.

7. Monitoring

Inquiries and delivery failures are written to structured application logs, so a lead is never lost silently if an email or CRM provider is unavailable. Logs are reviewed when something misbehaves and are retained on the schedule described in the privacy policy. Application logs deliberately record inquiry contents — please keep sensitive information out of the chat.

8. Dependencies

Ava's backend runs on a deliberately small dependency tree — the official Google GenAI SDK and a WebSocket client — to keep the supply-chain surface narrow. Dependencies are pinned by lockfile so a build is reproducible, and the container is rebuilt to pick up base-image and dependency patches.

9. What this page does not claim

Being straight about the boundaries matters more than a longer list:

• This site holds no formal certification — no SOC 2, ISO 27001, HIPAA, or PCI attestation. It is a professional profile site, and it is scoped like one.
• It has not been through a third-party penetration test.
• The third-party AI, speech, email, and hosting providers Ava depends on are secured by those providers under their own programmes, not by this one.
• No system is perfectly secure, and nothing here is a warranty. See the Terms of Service.

Engagements with Thomas are governed by their own agreements, which is where security obligations for actual client work belong — not here.

10. Responsible disclosure

Reports of genuine security issues are welcome and will be taken seriously.

• Email info@thomasbedell.com with "Security" in the subject, describing the issue and how to reproduce it.
• Expect an acknowledgement within three business days.
• Please give a reasonable window to fix the issue before disclosing it publicly.
• Please do not run automated scanners at volume, access or modify data that isn't yours, degrade the service for others, or attempt social engineering.

There is no paid bug bounty, but credit is gladly given to anyone who reports a real issue in good faith.

11. Contact