Home / Guides
SWT3 Protocol

Security Architecture

Technical security controls, data handling, and infrastructure design for enterprise security evaluators and vendor risk managers.

Who this is for: CISOs, vendor risk analysts, procurement security reviewers, and GRC teams conducting vendor due diligence. This document maps to standard vendor security questionnaire categories (SIG, CAIQ, VSAQ). No prior SWT3 knowledge required.

Critical Assessor Notice: Boundaries of Cryptographic Evidence

SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.

Contents

1. Architecture Overview 2. Data Classification and Clearing Levels 3. Infrastructure Security 4. Identity and Access Management 5. API Security 6. Cryptographic Design 7. Vulnerability Management 8. Change Management and Deploy Gates 9. Sub-Processor Security 10. Incident Response 11. Audit Logging 12. Business Continuity 13. Compliance Status 14. Transparency and Auditability Appendix: Questionnaire Quick-Reference

1. Architecture Overview

TeNova operates the Axiom Sovereign Engine, a platform for the SWT3 AI Witness Protocol. The platform provides independent, cryptographic accountability for AI systems. It is not a security product, not an AI provider, and not a compliance certifier. It is an evidence engine that mints immutable witness anchors proving that governance controls were active at specific points in time.

Hash-Only Data Model

The core architectural principle: the platform never receives, processes, or stores raw AI inputs or outputs. The SWT3 SDK runs inside the customer's infrastructure, computes SHA-256 hashes and numeric factors locally, and transmits only derived cryptographic evidence to the platform.

CUSTOMER ENVIRONMENT TENOVA PLATFORM --------------------- --------------- AI Application | SWT3 SDK (open source, Apache 2.0) | +-- Computes SHA-256 hashes locally +-- Extracts numeric factors (latency, token count, confidence) +-- Applies clearing level (strips data before transmission) | +-- Wire payload: hashes + factors only ---------> Ingestion API | Raw prompts, responses, training data Witness Ledger NEVER leave customer environment (hashed anchors only)
Verification guarantee: All 10 SDK packages are open source (Apache 2.0). Any customer security team can audit the SDK source code to verify exactly what data leaves their environment. The SDKs are published on PyPI, npm, crates.io, NuGet, RubyGems, and Swift Package Index.

2. Data Classification and Clearing Levels

SWT3 clearing levels control what data appears in the wire payload transmitted to the platform. The customer selects their clearing level at SDK initialization. Higher levels strip more data before transmission.

Level Name What is Transmitted What Stays Local
0 Analytics SHA-256 hashes, numeric factors, model identifier, contextual metadata (provider name, guardrail config) Raw prompts, raw responses, training data
1 Standard (default) SHA-256 hashes, numeric factors, model identifier, contextual metadata Raw prompts, raw responses, training data
2 Sensitive SHA-256 hashes, numeric factors, model identifier only All contextual metadata, provider name, guardrail names, system fingerprint
3 Classified Numeric factors only. Model identifier is hashed before transmission. All hashes, all metadata, original model identifier
Critical distinction: Clearing level and air-gapped mode are independent configurations. Clearing level controls what data is in the anchor. Air-gapped mode (available on Sovereign deployments) controls where anchors are stored. Even at Clearing Level 0, raw prompts and responses never leave the customer's infrastructure.

Certain operational metadata survives all clearing levels by design: agent identifier, lifecycle cycle ID, signing key reference, jurisdiction, legal basis, and purpose class. These are required for regulatory compliance (GDPR, EU AI Act) and cannot be stripped without breaking chain-of-custody guarantees.

3. Infrastructure Security

Component Implementation
Compute US-based data center, dedicated compute instance (not shared hosting). Provider holds SOC 2 Type II certification.
Transport encryption TLS 1.3 (minimum version enforced). HSTS headers enabled. HTTP/2 multiplexing.
Firewall UFW with deny-all-inbound default policy. Allowed: SSH (22, key-only), HTTP (80, redirect to HTTPS), HTTPS (443).
SSH access Key-only authentication. Password authentication disabled. Root login disabled. Idle timeout: 300 seconds.
Login banner DoD-style warning banner displayed before authentication (AC-8).
SYN flood protection TCP SYN cookies enabled (SC-5).
Process management Cluster-mode process manager with automatic restart on failure. Health endpoint monitored at regular intervals.
At-rest encryption AES-256 encryption managed by database provider (Supabase). Application-layer data encrypted at infrastructure level.

4. Identity and Access Management

Authentication

Role-Based Access Control

Role Permissions Enforcement
Admin Full access: configuration, attestation, exports, key management, user management Database RLS + middleware
Analyst Read access + attestation. No user management, no key management. Database RLS + middleware
Assessor Read-only. All POST routes return 403. Cannot access configuration, evidence, or user management. Database RLS + middleware + API-level enforcement

Tenant Isolation

Cross-tenant data access is architecturally impossible. The database client wrapper automatically injects the tenant identifier into every query at the client level. The application code cannot construct a query that crosses tenant boundaries. This is not a policy check -- it is a structural constraint in the query builder.

Defense in depth: Tenant isolation operates at three layers: (1) the query builder injects the tenant filter, (2) database Row-Level Security (RLS) policies enforce tenant boundaries independently, and (3) middleware validates the session's tenant claim before the request reaches application code.

5. API Security

API Key Management

Rate Limiting

Per-tenant token bucket rate limiter applied to witness ingestion endpoints:

Tier Requests / second Burst capacity
Open1010
Pro5050
Enclave200200
Sovereign500500

Error Handling

All API errors are sanitized through a central error handler. Non-admin callers receive category-level messages with an AXM-XXXX reference code for incident correlation. Full diagnostic details are restricted to admin sessions. No stack traces, internal paths, or database details are exposed to external callers.

Public Endpoints

Three endpoints require no authentication by design: anchor verification (client-side SHA-256 recomputation), the DID document (/.well-known/did.json), and the JSON-LD vocabulary context. These are read-only and contain no tenant-specific data.

6. Cryptographic Design

Witness Anchor Fingerprint

Every witness anchor includes a deterministic fingerprint computed using SHA-256 with domain separation:

fingerprint = SHA256("WITNESS:{tenant}:{procedure}:{fa}:{fb}:{fc}:{timestamp_ms}").hex()[:12]

Anchor Signing

Method Algorithm Use Case
Standard HMAC-SHA256 Default for all witness anchors. Shared-secret authentication.
Verifiable Credential Ed25519 (eddsa-jcs-2022) W3C VC export for Enclave+ tiers. Non-repudiation via public key in DID document.

Merkle Rollup

Daily per-tenant Merkle tree with domain-separated leaf and node prefixes (SWT3:LEAF: / SWT3:NODE:). Produces a single root hash per tenant per day for batch integrity verification.

Public Verification

Anchor verification runs entirely in the client's browser using the Web Crypto API. The verifier recomputes the SHA-256 fingerprint from the anchor's components and compares it to the stored fingerprint. No server trust is required. The verification page executes no server-side code.

7. Vulnerability Management (RA-5 / SI-2)

Severity Remediation Target
CRITICAL7 days
HIGH30 days
MEDIUM90 days

8. Change Management and Deploy Gates

Every production deployment passes through two automated gates. Gate failure blocks deployment. There is no override mechanism.

Pre-Deploy Security Gate (9 layers)

  1. API auth coverage -- verifies all API routes enforce authentication
  2. Dangerous code patterns -- scans for eval(), innerHTML, hardcoded secrets, SQL string concatenation
  3. Shell lint -- static analysis on all probe commands
  4. Script lint -- static analysis on deployment scripts
  5. SQL safety -- verifies RLS policies, no GRANT ALL, no dynamic EXECUTE
  6. YAML schema validation -- all control definitions have required fields
  7. Server hardening verification -- SSH config, firewall, password policy
  8. STIG alignment cross-check -- XCCDF cross-reference against DISA rules
  9. KEV exposure check -- CISA Known Exploited Vulnerabilities correlation

Validation Gate

87+ automated checks covering witness pipeline integrity, fingerprint formula correctness, clearing level enforcement, and multi-provider compatibility. Runs after every build, before process restart.

Every gate run is logged with timestamp, git commit hash, pass/fail result, and findings count.

9. Sub-Processor Security

Provider Function Certification Data Handled
Supabase Database, authentication, row-level security SOC 2 Type II Hashed witness anchors, user accounts, tenant configuration
Vultr Compute infrastructure SOC 2 Type II Application runtime, encrypted backups
Stripe Payment processing PCI DSS Level 1 Payment methods, billing metadata (no compliance data)
Plausible Privacy-preserving analytics EU-hosted (Estonia), no cookies Page views only, no personal data collected

Inherited Controls

9 NIST 800-53 controls are inherited from infrastructure providers with documented attribution:

No third-party AI providers: The platform witnesses customer AI models. It does not run, host, or access any AI models itself. No AI provider is a sub-processor.

10. Incident Response

Breach exposure is limited by design. The platform stores cryptographic hashes and numeric factors, not raw AI data. A platform breach would expose witness anchor metadata (procedure IDs, hashed model identifiers, numeric compliance factors), not customer AI inputs, outputs, or training data. At Clearing Level 3, the exposed data consists of numeric values with no identifying context.

11. Audit Logging (AU / SI-12)

All security-relevant events are logged to an RLS-protected audit table:

Audit logging uses a fire-and-forget pattern: logging failures do not block application operations. Each event includes an AXM-XXXX reference code for correlation.

Retention by Tier

Tier Anchor Retention Audit Log Retention
Open7 days7 days
Pro90 days90 days
Enclave365 days365 days
SovereignUnlimitedUnlimited

12. Business Continuity

Metric Target Notes
RTO 8 business hours From incident detection to service restoration (business hours, US Eastern)
RPO 24 hours Maximum data loss window for application-layer state. Witness anchors in the ledger are not affected.
Backups Daily encrypted Managed by database provider (Supabase) with point-in-time recovery. 7-day rotation for application-layer backups.
Uptime target 99.5% monthly Measured from health endpoint. SLA credits apply for Pro and Enclave tiers.

Honest Limitations

Platform unavailability does not disrupt customer AI workloads. The SWT3 SDKs buffer witness anchors locally when the platform is unreachable and flush them when connectivity is restored. The witness pipeline is observational -- it records what happened, it does not gate AI inference. Customer AI systems continue operating normally during any platform outage.

13. Compliance Status

Certification Status Notes
SOC 2 Type II (own) Planned Evaluating audit firms for independent security review
SOC 2 Type II (Supabase) Inherited Database and authentication infrastructure
SOC 2 Type II (Vultr) Inherited Compute infrastructure
PCI DSS Level 1 (Stripe) Inherited Payment processing. No cardholder data stored by TeNova.
NIST 800-53 controls Self-assessed 123 controls active, 72 passing, 9 inherited. Continuous deterministic evaluation using the Axiom engine.
OSCAL exports Available SSP, POA&M, and Assessment Results validated against NIST oscal-cli reference implementation
Framework coverage 36 frameworks EU AI Act, NIST AI RMF, CMMC, FedRAMP, SR 11-7, ISO 42001, and 30 more via crosswalk engine
Compensating transparency: In lieu of an independent SOC 2 report, all SDK source code is publicly auditable (Apache 2.0), the protocol specification is published, and the platform continuously evaluates its own compliance posture using the same deterministic methodology applied to customer environments.

14. Transparency and Auditability

Independent verification requires no platform trust. A customer can verify any anchor using the published fingerprint formula, the open source SDK, and client-side SHA-256 computation. The platform cannot forge an anchor that the customer's own verification would accept, because the customer holds the inputs (tenant ID, procedure, factors, timestamp) and can recompute the fingerprint independently.

Appendix: Questionnaire Quick-Reference

For security reviewers using standard vendor assessment questionnaires, the following table maps common categories to the relevant sections of this document.

SIG / CAIQ Category This Document
A. Risk Management13. Compliance Status
B. Security Policy8. Change Management
C. Organization of Security4. Identity and Access Management
D. Asset Management2. Data Classification
E. Access Control4. IAM, 5. API Security
F. Cryptography6. Cryptographic Design
G. Physical Security9. Sub-Processors (inherited from Vultr)
H. Operations Security7. Vulnerability Mgmt, 8. Change Mgmt
I. Communications Security3. Infrastructure, 6. Cryptographic Design
J. Incident Management10. Incident Response
K. Business Continuity12. Business Continuity
L. Compliance13. Compliance Status

This document is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. Security controls described herein reflect the publisher's current implementation and are subject to change. Consult your organization's security team and qualified legal counsel before making vendor selection decisions based on this content.

Patent Pending. SWT3 and Sovereign Witness Traceability are trademarks of Tenable Nova LLC.

This project is not affiliated with, endorsed by, or sponsored by any third-party AI provider, cloud infrastructure provider, or security vendor. All third-party product names, logos, and trademarks mentioned in this document are the property of their respective owners and are used for identification and interoperability purposes only.