The ArcaKey Triad Audit

An independent, founder-signed assessment of your encryption posture across the four surfaces a regulator, an insurer, or an acquirer will ask about: transit, rest, use, and boundary. Framework-agnostic. Delivered in 21 days. Signed against the ArcaKey post-quantum attestation chain.

Methodology proven via an internal pilot engagement 2026-05-21. Customer cohort opening 2026-Q3. To register interest in advance, write to randall@arcakey.ai.

Why now

Two thirds of the encryption triad — in transit and at rest — are table stakes across regulated software. The third, encryption in use, is where almost no AI vendor closes the loop. And underneath the triad sits a fourth surface that the technical standards rarely name: the credentials, signing keys, and operator access that bootstrap the encrypted system in the first place.

Public incidents in 2026 made the boundary surface impossible to ignore. A US federal contractor exposed cloud administrative credentials and plaintext password backups through a public source-control repository. The encryption controls on the systems those credentials administered were strong; the boundary was unprotected. The triad held; the boundary did not.

If your firm processes regulated data with AI in the workflow, four questions are now asked of you with increasing frequency:

• ·Can you show, surface by surface, where encryption is enforced and where it ends?
• ·Can you explain, in writing, what runtime your data lives in when an LLM is processing it?
• ·Can you produce an inventory of operator credentials and the controls preventing them from being exposed the way the public incidents of 2026 exposed theirs?
• ·Can you sign that documentation against a verifiable chain that a regulator can check on their own?

Most firms cannot. The Triad Audit is the answer.

The four surfaces

Each engagement scores your posture on four surfaces. The first three are the canonical encryption triad. The fourth — Boundary — is what the triad assumes about your operators and what the public incidents of 2026 proved that assumption no longer holds.

1. 01 · Transit

   TLS configuration, certificate transparency, edge posture.

   TLS 1.3 is universal across regulated SaaS. Verification here is straightforward but not skippable. We test the actual configuration against the published one, confirm certificate transparency logs, and identify any legacy or fallback paths that quietly accept weaker ciphers.

2. 02 · Rest

   AES-256-GCM at the storage layer; per-record encryption where the regulatory framework warrants it.

   At-rest encryption on the storage layer is necessary but not sufficient. Data inside an encrypted database is still readable by the database's service operators when queried. For regulated workloads, we look for per-record encryption with customer-controlled keys — the pattern that prevents an operator with full database access from reading the rows.

3. 03 · Use

   Confidential computing for the LLM runtime — Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing.

   When a model processes a prompt, the prompt is decrypted in the model's runtime memory. Whoever controls that runtime can in principle read the memory. Encryption in use closes the loop: the LLM operator becomes operator-blind, with attestation evidence that the runtime is what it claims to be. This is the layer almost no AI vendor closes.

4. 04 · Boundary

   The credentials, signing keys, and operator access that bootstrap the encrypted system.

   Source-control hygiene; build-and-deploy pipeline secrets; operator credential lifecycle and MFA; signing-and-attestation key custody. The triad's other three pillars assume operators handle these correctly. Public incidents of 2026 made that assumption insufficient on its own. The Boundary surface is now part of every Triad Audit Pro and Sovereign engagement.

Findings are scored per surface with a four-level severity rubric: Critical (24-hour remediation), High (7 days), Medium (30 days), Low (90 days). Cross-references are explicit where one surface amplifies another.

What you receive

An 8–14 page written memo, founder-signed, signed against the ArcaKey post-quantum attestation chain. The memo is the document you put in your AI governance file, your sponsor due-diligence packet, your insurer's underwriting evidence, or your acquirer's data room.

Executive summary

Written for your board, your CISO, or your client — not for cryptographers.

Scope and methodology

The four surfaces in scope, the evidence collected per surface, the regulatory frameworks cross-referenced (PHIPA, 21 CFR Part 11, Reg S-P, HIPAA, Bill 25, or another framework named in your scoping letter), and the technical standards used (NIST FIPS 203 ML-KEM, FIPS 204 ML-DSA, NIST SP 800-204D, OWASP ASVS).

Findings by severity

Critical / High / Medium / Low. Each finding has a one-paragraph description, the evidence reference, the recommended remediation, and the cross-references to other surfaces where relevant.

Positive findings

Explicit recognition of the controls that are already in place. Useful for the documentation file even when the engagement also identifies gaps.

Remediation roadmap

A 90-day window with severity-aligned timing. Sequence respects the operational constraints we discover during evidence collection.

Attestation-signed PDF

The memo PDF is signed against the ArcaKey production signing chain — Ed25519 for present-day verification, ML-DSA-65 for post-quantum forward-compatibility. The signature is verifiable from a public ArcaKey attestation page; your regulator or counterparty can check it without contacting us.

How it works

Four phases. 21 days for Pro; 14 days for Lite; 30–45 for Sovereign.

1. Day 1

   Scoping

   A 30-minute call defines the in-scope repositories, build pipelines, identity-provider tenants, and signing chains. You sign a scoping letter authorising read-only evidence collection. Out-of-scope systems — personal devices, third-party SaaS not connected to the AI workflow — are explicitly excluded.

2. Days 2–10

   Evidence collection

   Read-only collection across the four surfaces. Where possible, evidence is collected via your own observability tooling (audit logs, identity-provider reports). Where direct credential issuance is required, scoped read-only credentials are issued for the engagement period and revoked on completion.

3. Days 11–16

   Analysis

   Findings are scored against the four-level severity rubric. The analysis cross-references findings with the regulatory framework named in your scoping letter and flags findings whose risk profile is amplified by that framework.

4. Days 17–21

   Memo

   The memo is drafted, internally reviewed, founder-signed, and signed against the production attestation chain. Delivered as a branded .docx and a hash-anchored, attestation-signed PDF. Engagement closes; 90-day follow-up review is scheduled.

Pricing

Three tiers. Flat fees. No negotiation.

Boundary pillar available as a +$1,500 USD supplement on Lite engagements where the regulatory framework or counterparty requirement specifies it.

What is not included

• ·Penetration testing. The audit covers configuration and posture, not active exploitation. Where a finding suggests a penetration test is warranted, we recommend a referral.
• ·Legal advice. The audit is technical and regulatory in nature; it is not legal counsel. Where a finding requires legal interpretation, we cite it as such and recommend you engage counsel.
• ·Implementation work. The audit produces a memo and a roadmap. We do not build, integrate, or operate replacement systems as part of the engagement.
• ·Ongoing monitoring. The audit is a snapshot at the date of delivery. Continuous Defensibility Monitoring is a separate ArcaKey subscription product.

How this differs from the Defensibility Audit

ArcaKey offers two audit engagements. They are different products with different scopes; one is not an upgrade of the other.

• ·The Defensibility Audit (at arcakey.ai/audit) is a Title 21-specific advisory engagement covering AI governance for regulated biotech and life-sciences submissions. The deliverable is a 16–22 page memo addressing FDA defensibility under 21 CFR Subparts B, C, D, and E.
• ·The Triad Audit is framework-agnostic. It scores encryption posture across the four surfaces (Transit, Rest, Use, Boundary) and is appropriate for healthcare under PHIPA or HIPAA, finance under Reg S-P, legal under Bill 25, or any AI-adjacent workflow where the buyer or regulator is asking about encryption.
• ·The two engagements can be sequenced. Customers who plan a Defensibility Audit and want the underlying encryption posture documented separately often start with a Triad Audit Pro engagement and follow with the Defensibility Audit.

Apply

The customer cohort opens 2026-Q3. The methodology has been validated through an internal pilot dated 2026-05-21. Engagement letter and scoping template are available on request — reply within 5 business days.

Confidential by default. Mutual NDA available before scoping.

The ArcaKey Triad Audit is a written technical assessment of encryption posture across four surfaces. It is not legal counsel, does not constitute a legal opinion or regulatory submission, and does not warrant any specific regulatory outcome. ArcaKey AI is not a law firm and does not practice law. Where a finding requires legal interpretation, the audit memo will explicitly recommend that the customer engage independent legal counsel. The audit is a snapshot at the date of delivery; conditions discovered after delivery are out of scope unless covered by Continuous Defensibility Monitoring or a re-engagement.