Talon Security Architecture

Post-quantum encryption. Cryptographic proof. Hardware isolation on the roadmap.

1. The Problem

Founders submitting to a VC firm hand over their most sensitive assets: source code, patent applications, financial models, technical architecture. Traditional firms protect this with NDAs and good intentions.

We protect it with post-quantum cryptography, timing-safe authentication, rate limiting, and cryptographic proof that the system does what we claim.

2. Deployed Encryption LIVE

All founder data is encrypted using NIST-standardized post-quantum algorithms. This protects against both classical attacks today and quantum attacks in the future.

Why hybrid KEM? We combine classical X25519 with post-quantum ML-KEM-768. If either algorithm is broken, the other still protects the data. The shared secret is derived via HKDF-SHA256 from both contributions.

Why post-quantum now? Nation-states run harvest-now-decrypt-later campaigns—capturing encrypted traffic today to decrypt when quantum computers mature. Your source code submitted in 2026 could be decrypted in 2035 with classical encryption. With ML-KEM, it cannot.

3. Deployed Security Controls LIVE

Beyond encryption, Talon enforces multiple layers of defense in production today:

4. How a Submission Works LIVE

Founder CLI                           Talon Server
    |                                        |
    |--- GET /keys ------------------------->|  Fetch server ML-KEM + ML-DSA public keys
    |<----------------------------------------|
    |                                        |
    |--- ML-KEM encapsulate + X25519 ECDH ---|  Derive shared secret (both PQC + classical)
    |--- AES-256-GCM encrypt submission -----|  Seal code with PQC-derived key
    |                                        |
    |--- POST /submit {encrypted} ---------->|  Ciphertext enters server
    |                                        |
    |   [Decapsulate -> Decrypt -> Analyze]  |  Raw code exists only during analysis
    |   [Sign report with ML-DSA-65]         |  Tamper-proof output
    |   [Destroy raw data]                   |  Cryptographic shredding
    |                                        |
    |<-- 202 {submission_id} ----------------|
    |                                        |
    |--- GET /report/{id} ------------------>|
    |<-- {report, ML-DSA signature} ---------|
    |                                        |
    |--- verify(signature) ------------------|  Founder confirms report integrity
    

What the founder controls:

• Encryption happens client-side. Data leaves the founder's machine already encrypted.
• The founder's CLI verifies the ML-DSA signature on the returned report—confirming it was generated by Talon and not modified.
• Submissions require an invitation token. No open access.

5. What the Operator Cannot Do Today

• Cannot see raw source code. The operator receives the diligence report—structured findings, risk scores, architecture assessment. Never the submission itself.
• Cannot modify reports. Reports are signed with ML-DSA-65. Any modification invalidates the signature. Founders verify independently.
• Cannot retain data. Raw submissions are cryptographically destroyed after analysis. Multi-pass overwrite with verification that the data is gone.
• Cannot bypass token auth. Timing-safe comparison prevents brute-force and timing side-channel attacks against invitation tokens.

6. Analysis Engine LIVE

Talon runs six concurrent analyzers on every submission:

All models run locally. No founder data is sent to OpenAI, Anthropic, Google, or any third-party API. The LLM26 (Qwen2.5-Coder 7B) runs on local GPU hardware. During analysis, outbound network access is limited to public vulnerability databases (OSV, NVD, EPSS, PatentsView).

7. Deployed Operational Controls

Data Destruction LIVE

After analysis completes, raw submission data is destroyed:

1. Multi-pass overwrite with cryptographically random bytes
2. Zero-fill final pass
3. File unlink (deletion)
4. Verification that the file no longer exists on the filesystem

Only the signed diligence report persists. The report contains structured findings—never raw source code, never file contents, never verbatim excerpts beyond short snippets cited in findings.

Data Retention

• Raw submissions: Destroyed immediately after analysis (typically within minutes)
• Diligence reports: Retained 90 days, then deleted
• Metadata (submission ID, timestamp, hash): Retained for audit trail
• Deletion on request: Founders can request immediate report deletion at any time

Access Control LIVE

Talon uses invitation-based access. Founders cannot submit without a pre-shared token issued by the operator.

• Tokens are cryptographically random (256-bit)
• Stored as SHA-256 hashes—even a database breach does not expose valid tokens
• Each token is bound to a company name and issuance date
• Token validation uses hmac.compare_digest to prevent timing attacks
• Unauthenticated requests return 401 immediately—no information leakage

8. Roadmap: Hardware Isolation & Attestation

8a. AMD SEV-SNP Enclave Isolation

Phase 4 will deploy Talon on Azure Confidential VMs with AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging). This technology encrypts all VM memory at the hardware level, meaning:

• The host operating system cannot read enclave memory
• The cloud provider (Azure) cannot inspect the VM contents
• Even with root access to the host, data extraction is physically impossible
• Memory encryption keys are managed by the AMD CPU, not by software

Why this matters: Today, Talon protects data with post-quantum encryption in transit and at rest, plus immediate destruction after analysis. But during processing, data exists unencrypted in server memory. AMD SEV-SNP will close this final gap by encrypting memory at the hardware level, making data extraction physically impossible even with root access to the server.

8b. Cryptographic Attestation (Planned)

When deployed on Azure Confidential Computing, the /attest endpoint will return a hardware-signed attestation report proving:

• What code is running in the enclave
• What security configuration is active (debug mode, network access)
• That the measurements match published hashes

Founders will not need to trust SpringOwl. They will be able to cryptographically verify the enclave state before submitting.

9. What We Got Wrong

Transparency requires acknowledging gaps:

10. Technical Implementation

For technical reviewers, here is where each deployed security claim maps to code:

The codebase is in a private repository. Access is available to qualified security researchers under NDA.

Document History:
Version 2.1 | February 14, 2026 | Separated deployed vs. roadmap capabilities
Version 2.0 | February 2026 | Rewritten from production codebase
Version 1.0 | February 2026 | Initial framework (superseded)
This document is public and may be shared with attribution.