Under the hood · what I built, and what I skipped
Six controls. And the ones I didn’t buy.
wannerlabs.com is a production serverless site, built and deployed under the same discipline this practice sells: least-privilege identity, content security enforced at the edge, independent review before anything ships, and verification of the deployed result rather than the build log. The shortness of that list is the point — choosing which controls a system has actually earned is the work. Some of it you can check yourself right now, from this page’s own response headers; the rest is described honestly below.
Why this matters if you’re buying
The before/after policy card on the homepage is this site’s own pattern, not a textbook example.
For an AI security review
The same scrutiny applied here — least-privilege scoping, threat modeling, verification over assumption — is what a fixed-scope review applies to your AI features, with findings your board can read.
For a fractional CISO
This operating discipline — review gates, documented out-of-band state, verified deploys, and controls sized to the risk — is the programmatic baseline you’d be getting, not a slide deck.
Inspection, honestly scoped
The site’s source repository is private; the artifact you can inspect without an NDA is this site itself — headers, cache behavior, and the publicAI Agent Security Checklist. A walkthrough on a fit call is the fastest way to see the rest.
The stack, in one breath
Serverless-first and static-first: no server to patch, no third-party scripts or trackers, and the whole thing defined as code.
| Edge | One CloudFront router serves every route under a restrictive content security policy: default-src 'self',object-src 'none', frame-ancestors 'none', plus nosniff and a two-year preloaded HSTS. Two deliberate relaxations, named rather than glossed: img-srcpermits data: URIs, and style-srcpermits 'unsafe-inline' — the cost of Astro’s scoped component styles on a site with no third-party script able to inject them. Read the header yourself; it is on this response. |
|---|---|
| Site | Astro, emitted as static HTML. No third-party scripts, no trackers, no external requests: the only client script on the marketing pages is the contact form’s own signed submission handling, and the interactive before/after policy card on the homepage is CSS-only. |
| APIs | Lambda Function URLs — no API gateway, no open surface beyond the router. |
| Data & mail | DynamoDB for the contact flow; SES with DKIM signing on a verified domain. The contact endpoint is reachable only through CloudFront OAC, and its POSTs must carry the SHA-256 of the body. Mail is transactional and low-volume. |
| Analytics | Aggregate queries over the existing access logs — no browser beacon, no third-party tracker on the page. |
| Infrastructure | SST v4 (Ion) over Pulumi — the account’s real resources, defined in code, deployed through OIDC with no long-lived keys in CI. |
How changes actually land
The same delivery discipline this practice would bring to a client engagement — including how multiple agents work on one codebase without colliding.
- 01 · Isolated work
Every change on its own branch, in its own worktree
Work happens in an isolated, claimed worktree and lands through a pull request — nothing is ever pushed directly to the deploy branch. Concurrent agents never edit a shared checkout or stage each other’s files.
- 02 · Independent review
A reviewer who did not write the change
Every PR is reviewed by an independent agent; passing CI is explicitly not a review. The verdict — blocking findings, should-fixes, or ship-as-is — is posted to the PR thread so the record lives with the change, reviewable later by someone who was not there.
Before a merge is even possible, CI runs its security scans on every push: secret scanning over the full git history, dependency vulnerability scanning against the OSV database, static analysis, and a base-freshness check that a PR is based on current master.
- 03 · Squash merge
Push-to-deploy, one clean commit
Merging deploys. The workflow serializes deploys so two pushes queue rather than clobber, and the deploy job asserts security markers in the shipped artifact — bundle controls and CORS posture — before it reports success.
- 04 · Smoke the live site
Verify the deployed result, not the build log
After deploy, the pipeline itself checks the live site: the fresh build is actually served (not a stale cache), every asset the homepage references resolves, and key routes return 200. A green build log without a green site is a failed run.
What earned its place
Not every control, deliberately. These six are the ones that earn their keep on a static marketing site with one write path.
Identity
CI deploys exclusively through OIDC role assumption. No long-lived access keys exist in the pipeline.
Least privilege by denial
The deploy role is allow-listed to specific services and explicitly denied identity minting, admin-policy attachment, unbounded role creation, CloudTrail reconfiguration, and audit-log tampering.
Content security
A restrictive CSP, frame-ancestors none, nosniff, and preloaded HSTS — enforced at the edge for every route, with its two relaxations named above rather than hidden.
Review gate
Nothing merges without an independent review, and the review is posted to the PR itself.
Pipeline scanning
Every push runs secret scanning over the full git history (gitleaks), dependency scanning against the OSV database (osv-scanner), and static analysis (semgrep) — before CI will pass a push.
Audit trail
CloudTrail writes to an audit bucket that CI itself is denied from modifying; analytics run over those logs, not a browser beacon.
And what isn’t here. No WAF, no runtime threat detection, no multi-account separation, no on-call rotation. A static site with no login, no session, and one authenticated write path does not carry the risk those controls are priced for — buying them anyway would be theatre, and the same money is better spent on the deploy role’s permission boundary. Deciding which controls a system has actually earned is the job; a maximal checklist is the easy answer, not the right one.
Where this maps
None of this is bespoke. It lands on control frameworks your auditors, your board, and your customers' security questionnaires already recognize.
| NIST SSDF (SP 800-218) | The review gate, pipeline scanning, and archived build provenance map to the Produce Well-Secured Software and Protect Software practice families. |
|---|---|
| CIS AWS Foundations | Identity, the deny-listed deploy role, and the tamper-resistant CloudTrail destination are the logging and IAM sections of the benchmark, applied rather than attested. |
| OWASP Top 10 for LLM Apps | The engagement-side frame: excessive agency, insecure output handling, and supply chain are the categories a fixed-scope review works through on your AI features — and theAI Agent Security Checklist is the public, inspectable version of that method. |
Want the full walkthrough?
Start a conversation — no pitch, just the system, the guardrails, and what it would look like applied to yours.
Start a conversation