Red-teaming my own apps

The problem

I ship web applications that people in health care actually use. Anything public will eventually be probed by someone, so the only question was whether I would find the weaknesses first. I am not a security engineer, which made this a test of a second claim I care about: that AI tools put serious security practice within reach of a non-engineer who takes it seriously.

The design

Method only here: no exploit detail, no payloads, no reproduction steps. The practice has three layers:

1. An independent, read-only audit. Commissioned against my own applications with explicit authorization and explicit limits: secret scanners, static analysis with manual data-flow review, dependency advisories, and read-only collectors (no exploit payloads, no password guessing, no denial of service). Every finding was validated before it entered the register.
2. Adversarial testing of the AI surfaces themselves. The agents are an attack surface of their own. Free-text email handling was tested with deliberate prompt-injection attempts and redesigned when it failed the sniff test; the public site assistant ships with an evaluation set that includes injection attempts and must pass all of them, most recently 42/42 with a perfect safety score.
3. AI-assisted hardening with Claude. A systematic survey of every place the code fetches a URL, consolidated into one shared safe-fetch helper with tests, rather than five ad-hoc fixes.

Triage is boring on purpose: every finding gets a severity, an owner, and a date, and remediation order follows severity, not convenience.

The numbers

Figure	Value
Validated findings (July 2026 audit)	21 (1 critical · 7 high · 11 medium · 2 low)
Status four weeks later	16 resolved · 4 partially remediated
Mail-classifier injection test	20/20, including 2 injection attempts
Site-assistant evaluation	42/42, safety 5/5

What a non-engineer learned

The findings that mattered were rarely exotic; they were configuration, defaults and assumptions. The discipline of writing each one down with a date and a fix taught me more about my own systems than building them did. What I would tell other institutional leaders: you do not need a security team to start taking security seriously. You need scope, honesty about what you find, and the willingness to fix boring things first.