Trust Without Asking: the security architecture of the Key 102 portal

A technical briefing for buyers, auditors, and security teams. What the platform is built to prevent, what it cannot do by design, and how to verify those claims without trusting Key 102's word for it.

Key 102 Consulting · 2026 · Veteran-owned. Practitioner-signed, cryptographically anchored readiness for the defense supply chain (CMMC) and high-stakes payment ecosystems (PCI DSS v4.0.1).

KEY 102 SOLUTIONS LLC · DBA KEY 102 CONSULTING key102consulting.com · Phoenix, AZ · CAGE 1EWP2 · UEI TXQFV5FJX797

The vendor-evaluation question that doesn't get asked

Compliance buyers spend weeks on framework coverage, pricing tiers, and assessor-handoff features. They almost never spend an hour on the platform itself. The questionnaires they send their compliance vendors are the same questionnaires they'd send a CRM:

• Where is data stored?
• Who has access?
• What's the SOC 2 status?
• What happens on offboarding?

The questions are reasonable. They are also insufficient. A compliance platform is not a CRM. It is the system of record for the work that proves your regulated operations are working. If that system can be silently tampered with — by an insider, by a support engineer, by the platform's own database administrator — every deliverable it produces is a vendor claim, not assessment evidence. (We wrote a separate paper on what that distinction means for the artifacts themselves. This one is about the platform that produces them.)

This paper walks through the five architectural choices Key 102 made to remove the "trust us" gap, and how to verify each one without taking our word for it.

Choice 1 — Don't store the regulated data

The simplest defense against a regulated-data breach is to not have the data. The Key 102 portal does not store the regulated data itself: no Cardholder Data, no Controlled Unclassified Information. What it stores is documentation about that data — policies, procedures, evidence references, gap-remediation notes, attestation signatures.

This is a deliberate boundary, not a future state. It's enforced at the schema level: there are no CHD columns. There is no plaintext PAN field that could be written to by accident. Customers upload documentation files (policies, diagrams, training records, vendor attestations) and link them to controls; they don't paste cardholder data or controlled technical data into a notes field.

How to verify: schema-boundary inspection of the documents and evidence tables can be arranged case-by-case for qualified enterprise buyers under NDA. The review is focused — typically a 20-minute walk-through of the schema definitions to confirm there are no regulated-data-shaped columns. Scope is discussed during commercial diligence.

The consequence: a worst-case Key 102 breach would expose documentation about customer compliance work — including some genuinely sensitive context — but not the underlying CHD or CUI. That's a meaningfully different blast radius than a compliance platform that ingested sample cardholder data or controlled defense data for "AI-powered scoring."

Choice 2 — Tenant isolation enforced in the database, not in app code

The most common multi-tenant failure mode in compliance SaaS is the accidental cross-tenant query: a developer writes a feature, the WHERE clause works correctly in development with one tenant, and in production a missing predicate lets tenant A read tenant B's data. App-layer authorization is the wrong defense against this failure — it's an opt-in check the developer has to remember to write.

The Key 102 portal enforces tenant isolation in the database layer, not the app layer. Every table that holds customer data carries a Row-Level Security policy that filters by auth.uid(). The database itself refuses to return cross-tenant rows, even if an app-layer query forgets to constrain on engagement_id. A developer who forgets WHERE doesn't expose customer data; they get zero rows.

This is enforced by what we call the evil-twin regression suite: an automated test that signs in as a deliberately restricted user and greps every API response for a randomly-generated tenant token that the user has no right to see. If the token appears anywhere, the test fails the CI gate. The suite has caught real holes during development before they reached production — including tenant-isolation gaps we discovered and patched in the same week we shipped the agency tier.

How to verify: evil-twin test source review and CI pass/fail history can be arranged case-by-case for qualified enterprise buyers under NDA. The conversation happens as part of commercial diligence; scope and format are tailored to the buyer's review needs.

Choice 3 — The no-impersonation policy is in the code, not just the contract

Most compliance platforms have a clause in their MSA promising staff won't impersonate customers. Key 102's portal makes the promise unforgeable in code: every endpoint that creates a signature — on a System Security Plan, a SPRS affirmation, a Practitioner Agreement, an NDA — checks that auth.uid() equals the named signer's user ID. Service-role bypass, the database administrator's override key, does not satisfy that check.

The consequence: even Key 102's CEO cannot sign a System Security Plan on a customer's Authorizing Official's behalf. The portal will reject the request with a specific error code. If the AO loses the ability to log in — they leave the company, lose their MFA device, get hit by a bus — the SSP has to be re-drafted with a new named signer. There is no admin-side workaround for the missing signature. That's not a UX feature. It's the architecture that prevents a future Key 102 employee from forging a customer attestation.

How to verify: the policy is reflected in the database's profiles.role ACL grants, in the per-signature trigger logic that enforces signer identity, and in the API route source. A security reviewer can inspect any one of the signing endpoints (SPRS L1, SPRS L2, Fortress SSP, Fortress POA&M) and trace the auth.uid() check by hand.

Choice 4 — Hash-chained, TSA-anchored audit log

When DCMA — or a C3PAO, or a QSA, or a prime's compliance officer — asks for the evidence of what your team did when, the question they're really asking is: can the platform prove this record hasn't been silently modified since the event happened?

The Key 102 audit log is structured to make that proof free. Every administrative action — every signature, every approval, every status transition, every deletion attempt — writes a row to the audit_events table. Each row carries:

• The hash of the previous row (forming a chain)
• A computed row hash that includes the previous-hash + the row contents
• A timestamp at server time

The chain is append-only by trigger. Updates and deletes are blocked at the database layer; an attempt to modify a row raises a specific error. The chain integrity is verified daily, and the most recent chain-tail fingerprint is timestamped via SSL.com's RFC 3161 Timestamping Authority on a regular cadence. Every TSA response is stored intact and can be re-verified against SSL.com's public infrastructure without any cooperation from Key 102.

The practical consequence: if a Key 102 administrator modifies a historical audit row, the chain breaks. The break can be located to the row that was tampered with. And the TSA anchor proves the chain existed in its unbroken form at a specific moment in time — because SSL.com cryptographically signed the chain-tail fingerprint. We cannot fake a TSA anchor for a chain state we didn't have. SSL.com would have to be compromised to make that possible.

How to verify: the public verify endpoint at portal.key102consulting.com/verify/sprs/... resolves any TSA-anchored deliverable on demand. The TSA response is the fingerprint — paste it into any RFC 3161-compatible verifier (OpenSSL, signtool, the SSL.com web verifier) and confirm the signature against SSL.com's certificate. Key 102 plays no part in that verification path.

Choice 5 — Our own posture is publicly verifiable

The trust gap a compliance buyer faces with their vendor is the same gap their auditor faces with their compliance vendor's deliverables. If we built a recipient-verifiable platform for our customers but asked you to trust us for our own posture, we'd be the joke in our own paper.

Key 102 Solutions LLC's CMMC Level 1 self-attestation is published through the same affirmation pipeline customers use. The affirmation is signed by our Senior Affirming Official, RFC 3161 timestamped, chain-anchored, and verifiable at a public URL:

https://portal.key102consulting.com/verify/sprs/SPRS-L1-2026-512PCZ

A DCMA officer, a prime contractor's vendor-management team, or anyone curious can open that URL and confirm Key 102's CMMC L1 posture without any cooperation from us. The page shows the practices, the signing officer, the timestamp, and the TSA verification path. There is no "log in to see our SOC 2" gate.

This is the dogfood proof point. The platform we ask customers to trust with their compliance posture is the same platform we trust with our own.

What this architecture does not protect against

We aim to be honest about the boundaries. The architecture described above:

• Does not prevent a customer from accidentally uploading regulated data to a documentation field. Sensitivity-detection helpers warn on upload, but a determined customer can paste anything into a notes field. We rely on the customer-side trained-staff control.

• Does not make Key 102 immune to a credential-theft attack against a customer's own account. If your Authorizing Official's password and TOTP factor are both compromised, the attacker can sign on your behalf. MFA enrollment is enforced at the proxy layer; we strongly recommend hardware-token MFA for AOs.

• Does not make Key 102 immune to a Supabase or Vercel zero-day. Both vendors operate at SOC 2 Type II, with public attestations available. We make architectural choices to limit blast radius (no regulated data at rest, audit chain anchoring to an independent TSA), but we are dependent on those platform vendors for runtime security.

• Does not include continuous monitoring SOC services. Key 102 is a compliance preparation and audit-defense firm, not a managed SOC. The portal records what your team did and proves it on demand. It does not chase intruders for you.

What to ask us before you sign

If you are evaluating Key 102 against the architecture above, the fastest path to comfort is to ask for the following:

1. A schema-boundary discussion. Request the focused walk-through that confirms the no-regulated-data boundary by inspecting the documents and evidence tables. Arranged case-by-case under NDA during commercial diligence.

2. An evil-twin diligence session. Request a walk-through of the evil-twin test source and recent CI history that demonstrates tenant isolation. Arranged case-by-case under NDA during commercial diligence.

3. A signing-endpoint trace. Confirm no-impersonation by walking the auth.uid() check through one signing endpoint with an engineer.

4. A chain-integrity verification. Pick any TSA-anchored deliverable (including the dogfood one above) and verify the signature against SSL.com without our help.

5. Our own affirmation. Open the dogfood verify URL above and confirm CMMC L1 posture independently.

None of these requires you to trust us. That's the point.

Key 102 Consulting is the DBA of Key 102 Solutions LLC, a Veteran-Owned Small Business headquartered in Phoenix, AZ. CAGE 1EWP2. UEI TXQFV5FJX797. NAICS 541519. We specialize in practitioner-led compliance preparation for the Defense Industrial Base (CMMC) and payment-acceptance (PCI DSS) sectors. Inquiries: eowilliams@key102consulting.com.