Security

Security pages usually mean "trust us." This one aims for "check it." The scan is linked below, the portal's code lives in a private repo and we'll walk you through it on request, and there's a section on what we don't have yet. If you can't verify a claim on a vendor's security page, that's the page you should trust less, not more.

Scores and checks

The Lighthouse numbers below were run live against this site on 2026-10-21, after it moved to Cloudflare, with mobile emulation and simulated throttling. We ran it three times and publish the median run; Performance scored 100, 98 and 98. Raw report: LIGHTHOUSE_2026-10-21.json . Lighthouse scores move between runs and machines, so read them as a dated measurement, not a guarantee.

• Lighthouse (mobile): Performance 98, Accessibility 100, Best Practices 100, SEO 100. LCP 1.9s, CLS 0, total blocking time 0ms (October 2026). The July run scored Performance 92 with LCP 2.7s.
• axe-core: the most recent full run (2026-09-19, WCAG 2.2 A/AA, every page in both themes) found violations on 31 of 38 page and theme combinations. We fixed them the same day and the re-run found 0. Axe doesn't run in CI yet, so treat that as a dated result, not a guarantee.
• CI: required status checks gate merges to main on seven repos: the portal, the agent runner, the four demos, and this site. Provenance, the newest, doesn't have them yet.

Tenant isolation

The customer portal uses a two-gate model for what a user can see, and it's a pure function, not a pile of scattered if checks (code walkthrough on request). An app shows up for a customer user only if both gates pass:

• Gate 1: the user's company (tenant) has that app assigned.
• Gate 2: an admin has individually flipped that specific user's access on for that app.

Losing either gate hides the app, and the logic has its own unit tests. It's not just the UI trusting itself either: every admin server action repeats its own authorization check in the function body, not just at the page-layout level. That closes the classic Next.js hole where a server action gets called directly, skipping whatever gate the page around it had.

Auth and SSO

Cross-app SSO into the portal's tiles runs on signed JWTs, not shared cookies or a homegrown token scheme.

• Tokens are signed with asymmetric keys (RS256).
• Private signing keys are encrypted at rest before they touch the database, with an encryption key that is kept out of the repo and out of the container image.
• Key rotation overlaps the old and new keys, so an app checking tokens doesn't get caught mid-rotation with a key it doesn't recognize yet.
• Every token carries issuer, audience, and expiry, and every verification checks all three. A token minted for one app can't be replayed into another.
• Login failures are deliberately generic: a wrong password, a missing account, and a deactivated account all get the same message. No enumeration surface from the error text.

Code walkthrough on request.

Data hygiene

• Database access runs through an ORM with parameterized queries, and user input never gets spliced into SQL.
• The public access-request and token-check endpoints validate their request bodies against a schema and are rate-limited, and the signup endpoint only answers browser requests from origins on an allowlist.
• No committed secrets: in July 2026 we pattern-scanned every tracked file and the full git history across the six repos that were active then, for API keys, private key blocks, and credentialed connection strings. Nothing turned up. Worth being precise about what that means: it's a pattern scan we ran ourselves, not a certified third-party audit, and it won't catch something cleverly obfuscated. We're not overselling it.
• Dependency hygiene: GitHub's native vulnerability alerts and automated security fixes are on across the same seven repos, and delete_branch_on_merge is on everywhere so merged branches don't pile up as forgotten attack surface.
• The portal's framework is kept on a release patched for CVE-2025-29927 (the Next.js middleware auth-bypass CVE). Demo mode is pinned off and the environment is pinned to production in the prod build, after an earlier incident where demo mode leaking into a real deploy was exactly the kind of mistake this page exists to make less likely.

What we don't have yet

This is the part most vendor security pages skip, and it's the part worth reading first if you're deciding whether to trust the rest of it.

• No SOC 2 or other formal compliance certification yet.
• No third-party penetration test yet. Everything above is self-audited and code-reviewed, but nobody outside the studio has been paid to try to break it.
• Tenant onboarding is manual and admin-only. There's no self-serve signup.
• This is a solo-engineer shop. That's a real bus-factor risk and worth weighing against whatever else is on this page, not something we'd rather you find out later.

Report a vulnerability

Found something? Email security@paradigm.codes directly. Don't open a public GitHub issue for it.

• Include the affected URL or app, steps to reproduce, and the impact if you can.
• We'll acknowledge within 2 business days and give you a straight timeline, not a form letter.
• Give us a reasonable window to fix it before any public disclosure.
• Good-faith testing that doesn't touch real customer data, doesn't degrade the service, and stays inside the scope you reported won't get you a legal threat from us.