Security & Compliance

Enterprise-Grade Security Architecture

Zero-trust by design. Every layer — from DNS ingress to database partition — enforces isolation, encryption, and auditability. Built to satisfy the most demanding CISOs in oil & gas, government, and critical infrastructure.

AES-256

Encryption standard

TLS 1.3

Transport security

Ed25519

Audit log signatures

7-Year

Audit log retention

Architecture Overview

Seismic Swift AI runs on a zero-trust network model. Every request is authenticated and authorised at every layer — there is no implicit trust based on network location.

Request path — ingress to storage

InternetCloudflare DNS + DDoS ShieldAzure Front Door WAF (OWASP 3.2)Kubernetes Ingress (mutual TLS)Service Mesh NetworkPolicyDatabase (CMK encrypted)

WAF RulesetAzure Front Door WAF — OWASP ModSecurity Core Rule Set 3.2, custom geo-blocking, rate limiting at edge

DDoS ProtectionAzure DDoS Protection Standard — volumetric, protocol, and application-layer attack mitigation

Service MeshIstio with mTLS between every pod; SPIFFE/SPIRE workload identity; automatic certificate rotation every 24 h

Pod IsolationKubernetes NetworkPolicy — default-deny all; explicit allow only for required service-to-service paths

Secrets ManagementAzure Key Vault with Managed Identity; secrets never stored in environment variables or container images

Container RuntimeKubernetes with VM-isolated workload sandboxing for ML workloads; seccomp profile enforced

Zero-trust means our corporate VPN compromise cannot reach production. Every service call requires a valid JWT, passes through service-mesh mTLS, and is authorised against the RBAC policy engine before any data is touched.

Encryption at Rest

All data at rest is encrypted with AES-256. Customers on the Enterprise plan control their own encryption keys via Azure Key Vault — we never have access to plaintext.

AlgorithmAES-256-GCM (NIST SP 800-38D) — authenticated encryption with additional data (AEAD)

Key Hierarchy3-tier envelope encryption: Data Encryption Key (DEK) → Key Encryption Key (KEK) → Customer Master Key (CMK) in Azure Key Vault HSM

Customer-Managed KeysEnterprise tier: CMK stored in customer-owned Azure Key Vault Premium (FIPS 140-2 Level 3 HSM). Seismic Swift AI cannot decrypt without customer authorisation.

Key RotationAutomatic DEK rotation every 90 days. Customer-initiated CMK rotation supported with zero-downtime re-wrap.

DatabaseDatabase server-side encryption with customer-managed keys (CMK). Each workspace uses a distinct DEK (per-workspace envelope encryption).

Blob StorageObject storage with server-side encryption and CMK. ONNX model weights, SEG-Y volumes, and export artefacts all encrypted.

Backup EncryptionGeo-redundant backups inherit the same CMK chain. Backup tapes never leave Azure's FIPS 140-2 boundary.

Per-workspace envelope encryption means a compromise of one tenant's DEK does not expose any other tenant's data. Key material is never written to disk in plaintext.

Encryption in Transit

All data in transit uses TLS 1.3 minimum. TLS 1.0 and 1.1 are disabled at the edge. Strict Transport Security is enforced with a one-year HSTS policy preloaded into browsers.

ProtocolTLS 1.3 (RFC 8446) enforced everywhere; TLS 1.2 permitted for legacy enterprise proxies with AES-256-GCM cipher suite only

HSTSStrict-Transport-Security: max-age=31536000; includeSubDomains; preload

Certificate AuthorityDigiCert EV certificates for public endpoints; Let's Encrypt ACME (DNS-01) for internal services via cert-manager on AKS

Internal mTLSIstio service mesh — all pod-to-pod communication uses automatically rotated mTLS certificates via SPIFFE X.509-SVIDs. No plaintext HTTP inside the cluster.

Security Headers

Content-Security-Policy: strict-dynamic, no unsafe-inline
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Permissions-Policy: camera=(), microphone=(), geolocation=()

EventHub / KafkaEvent-driven messaging with TLS 1.3 and token-based authentication; messages encrypted in transit

Upload IntegrityX-Content-SHA256 header: client-computed Web Crypto SHA-256 verified server-side before processing; 422 on mismatch

Tenant Isolation

Seismic Swift AI is a true multi-tenant platform built on defence-in-depth isolation. Tenant data is segregated at every layer — database, network, ML pipeline, and audit log. Cross-tenant data access is architecturally impossible.

Database partition-key isolation: every document is partitioned by tenant_id. Queries without a matching partition key return zero results by design, not by policy check.
JWT claim enforcement: every API request validates the tid claim against the requested resource. IDOR attempts are blocked and logged as ViolationType.MISMATCH.
Unicode homoglyph detection: tenant IDs are normalised via Unicode UAX #15 NFC before comparison. Cyrillic/Greek/fullwidth confusables are mapped to ASCII canonical form (TR39 §4). Bidi override characters (11 codepoints) and zero-width characters (5 codepoints) are rejected.
Enumeration probe detection: a sliding-window detector (60 s window, 5-attempt threshold) identifies and blocks tenant-ID enumeration attacks, logging them as ViolationType.ENUMERATION_PROBE.
Kubernetes NetworkPolicy: each service is labelled with its tenant context. NetworkPolicy objects enforce default-deny; ML worker pods handling one tenant's data cannot establish TCP connections to another tenant's namespace.
RBAC96 (Sandhu 1996): permission resolution enforces tenant scope before role scope. A super_admin of tenant A cannot read tenant B's data even with elevated permissions.

We commissioned a penetration test specifically targeting tenant cross-contamination. No cross-tenant data access was achievable. Full report available under NDA.

Authentication & SSO

Seismic Swift AI delegates authentication to your identity provider. We support every major enterprise SSO protocol and never store passwords.

ProtocolOpenID Connect (OIDC) over OAuth 2.0. Azure Active Directory as the primary IdP; federated to customer IdPs via SAML 2.0 / OIDC.

Token formatJWT signed with RS256 (RSA-PKCS1-v1_5, 2048-bit minimum). Claims validated on every request: iss, aud, exp, tid, roles.

Key rotationJWKS endpoint with frequent key rotation. RSAAlgorithm.from_jwk() converts JWK → public key for offline validation — no OIDC round-trip per request.

MFATOTP (RFC 6238) and FIDO2/WebAuthn enforced for all admin roles. Enterprise SSO users inherit MFA policy from their own IdP.

SAML federationSP-initiated SSO with signed assertions (RSA-SHA256). NameID format: persistent. Attribute mapping for roles and tenant_id claims.

Session managementAccess tokens: 1-hour TTL. Refresh tokens: 8-hour TTL with rolling expiry. Silent refresh via PKCE code flow. Server-side session revocation propagates within 5 minutes.

Brute-force protectionCUSUM anomaly detector (Page 1954) on the auth endpoint. Progressive lockout: 5 failures → 15-min lockout; 10 failures → account lock + CISO alert.

Credential storageNo passwords stored. Credential validation delegated entirely to the customer IdP. Seismic Swift AI holds only the public JWKS.

Supported identity providers

Microsoft Entra ID (Azure AD)

Okta

Ping Identity

Auth0

OneLogin

Google Workspace

AWS IAM Identity Center

ADFS (on-premises)

Any SAML 2.0 / OIDC IdP

Authorization (RBAC)

Seismic Swift AI implements RBAC96 (Sandhu, Coyne, Feinstein & Youman, 1996) with a strict role hierarchy and 25 fine-grained permissions across 8 resource domains.

Role hierarchy (ascending privilege)

viewer⊂editor⊂admin⊂super_admin

Each role inherits all permissions of roles beneath it. super_admin may only be granted by another super_admin via dual-control approval (NIST SP 800-53 AC-3(2)).

Permission domains (25 permissions across 8 domains)

Jobsjob:read, job:create, job:cancel, job:admin

Data / Uploaddata:read, data:upload, data:delete

Exportexport:read, export:create, export:admin

Annotations / HITLannotation:read, annotation:create, annotation:approve, annotation:admin

Tenantstenant:read, tenant:create, tenant:update, tenant:deactivate

Usersuser:read, user:invite, user:role_assign, user:remove

Billingbilling:read, billing:admin

Approvalsapproval:read, approval:decide

Privilege escalation prevention: a user cannot grant themselves or others a role equal to or higher than their own current role (Ferraiolo & Kuhn, 1992 least-privilege).
Separation of Duties: find_redundant_roles() detects overlapping role assignments that violate Clark–Wilson (1987) SoD policy.
Role assignments are validated against 7 forensic rules (RV-001→RV-007) referencing NIST SP 800-53 AC-2, AC-3, AC-5, AC-6, and ISO 27001 Annex A.9.2.
Every role change is written to the append-only, signed audit chain within the same transaction — no role change is silent.

Audit Trail

Every state-changing operation produces an immutable, cryptographically-linked audit record. The chain is designed to make undetected tampering computationally infeasible.

Hash algorithmSHA-256 (NIST FIPS 180-4) — each record's hash is computed over its content plus the previous record's hash, forming a Merkle-style chain

Digital signaturesEd25519 (RFC 8032) optional per-record signatures. StaticEd25519KeyProvider with key rotation via KeyChain (NIST SP 800-57). HMAC-SHA256 (NIST SP 800-107, ≥32-byte key) also supported.

Tamper detectionverify_integrity() walks the full chain, recomputes hashes, and checks signatures. Returns ChainVerificationResult with broken_records, tampered_signatures, and non_monotonic_timestamps tuples.

PersistenceAzure Cosmos DB with stored procedures for atomic append-then-validate within a single partition transaction. Optimistic concurrency control (OCC) with etag-based conditional writes prevents lost-update races.

Retention7-year retention with ttl=-1 (permanent) flag on all audit documents. Records cannot be deleted via any API — only a Key Vault administrator can revoke CMK access.

Timestamp monotonicityTimestampViolationEvent records BACKDATED and UNPARSEABLE violations. Non-monotonic timestamps are forensically disambiguated from hash/linkage failures in verification results.

Coverage8 orchestration events (stage completion, retry, failure, timeout, cancel, auto-approve, intermediate transition, publish failure) + all RBAC changes + all tenant operations + all approval decisions

SIEM exportAll audit records include to_alert_payload() serialisation in ECS 1.12 format (event.kind, event.category, event.outcome). Directly ingestible by Splunk, Elastic, Microsoft Sentinel.

An attacker who gains write access to Cosmos DB and recomputes forward hashes will still be caught: Ed25519 signatures over the original records will not match the recomputed chain. This two-layer defence (hash chain + signatures) is the same model used by Certificate Transparency logs (RFC 6962).

Dual-Control Approval

High-risk operations require a second authorised approver — no single person can unilaterally escalate privileges, increase quotas, or assign admin roles.

StandardNIST SP 800-53 AC-3(2) — Dual Authorization / Two-Person Integrity

Trigger operationsTenant tier upgrades, quota increases >2×, admin role assignments, super_admin grants

Anti-self-approvalThe requestor cannot be the approver. SelfApprovalError is raised at the service layer before any state change. This cannot be bypassed via any API.

TimeoutPending requests auto-reject after 24 hours. Expired requests log an ApprovalDecisionRecord with outcome=EXPIRED for audit.

Rubber-stamp detectionApprovals granted in < 60 seconds are flagged as potential rubber-stamps (SOC2 CC5.2). These are surfaced in the security dashboard and included in SOC 2 evidence packages.

State machineApprovalRequestStatus: PENDING → APPROVED | REJECTED | EXPIRED | CANCELLED. Transitions are validated by a finite automaton. Invalid transitions raise ApprovalTransitionError.

Audit integrationEvery approval decision produces an ApprovalDecisionRecord (SOC2 CC8.1) written to the signed audit chain within the same Cosmos DB transaction as the underlying operation.

Dual-control makes Seismic Swift AI safe to use in environments with strict separation of duties: no engineer on call can grant themselves elevated access without a second authorised administrator approving the request.

Data Residency

Enterprise customers choose a primary region. All data — blobs, database records, event streams, and backups — is guaranteed to remain within that region. Cross-region replication is opt-in and always within the same geographic zone.

East US

Virginia, USA

Default for North American customers

West Europe

Netherlands

Default for EU customers (GDPR primary)

Brazil South

São Paulo, Brazil

Brazil LGPD compliance

Southeast Asia

Singapore

APAC customers — PDPA compliant

Data residency is enforced at the application layer via DataResidencyViolationError — any write targeting a region that doesn't match the tenant's configured residency raises an exception and is logged.
Azure Policy denies resource creation in non-approved regions at the subscription level — a defence-in-depth safeguard below the application layer.
Backup data replicates to a secondary region within the same continent only (East US ↔ West US 2; West Europe ↔ North Europe; etc.).
EventHub data streams and Cosmos DB change feeds are region-scoped. No cross-region message routing occurs without explicit customer consent.
Data Processing Addendum (DPA) available on request — specifies region guarantees as contractual obligations, not just best-effort configuration.

Compliance Matrix

Seismic Swift AI maintains a continuously-updated compliance programme. Evidence packages for each framework are available to enterprise customers under NDA.

Framework	Scope / Key Controls	Status
SOC 2 Type II	CC6, CC7, CC8, CC9 — Security, Availability, Confidentiality	Implemented
ISO 27001:2022	Annex A controls — Information Security Management System	In Progress
NIST SP 800-53 Rev 5	AC-3(2) Dual Control · AC-6 Least Privilege · AU-9 Audit Protection	Implemented
OWASP Top 10 (2021)	A01 Access Control · A02 Cryptographic Failures · A05 Security Misconfiguration	Implemented
FedRAMP Moderate	FIPS 140-2 encryption · PIV/CAC authentication · Continuous monitoring	Planned
GDPR (EU 2016/679)	Art. 25 Privacy by Design · Art. 32 Security of Processing · Art. 33 Breach Notification 72h	Implemented
CCPA	Right to deletion · Data portability · Opt-out of sale	Implemented

Last updated: March 2026. Continuous compliance monitoring via shared/compliance/continuous_monitor.py with automated evidence collection.

Supply Chain Security

Every component — from container base images to Python packages — is cryptographically verified before deployment. We maintain a zero critical CVE policy for production images.

Container scanningTrivy (Aqua Security) runs on every image build in CI. Builds fail on any CRITICAL or HIGH CVE. Production policy: 0 critical CVEs at time of deployment.

Image signingAll production images are signed with Cosign (Sigstore) using keyless signing tied to GitHub Actions OIDC. Policy controller verifies signatures before AKS admission.

Dependency managementDependabot PRs for all Python (requirements.lock), npm, and Helm chart dependencies. Auto-merge for patch updates; manual review for minor/major.

SBOMSoftware Bill of Materials generated at build time (CycloneDX 1.4 format). Available to enterprise customers on request. Includes all transitive Python and system dependencies.

Base imagesDistroless Python 3.11 images (Google) for all services — no shell, no package manager, minimal attack surface. ONNX worker uses nvidia/cuda:12.3-runtime-ubuntu22.04 (scanned).

Secrets scanningGitGuardian and GitHub secret scanning enabled on all repositories. Pre-commit hooks block secrets from entering git history. Rotation policy: any exposed secret is revoked within 1 hour.

Build provenanceSLSA Level 2 build provenance attestations generated for all release artefacts. Provenance includes source commit SHA, builder identity, and build timestamp.

Supply chain attacks (e.g. SolarWinds, Log4Shell) are mitigated by hermetic builds: CI pulls from a private Azure Artifact feed that mirrors approved package versions — no live PyPI/npm traffic during production builds.

Incident Response

Seismic Swift AI maintains a 24/7 on-call rotation with documented SLAs for every severity level. GDPR breach notifications are sent within 72 hours of confirmed discovery.

SEV-1 — Critical

GDPR Clock

Active breach, full outage, data exfiltration

Ack: 15 min

Initial response: 30 min

Escalation: CISO + VP Eng immediately

SEV-2 — High

GDPR Clock

Partial outage, SLA breach, tenant data access anomaly

Ack: 30 min

Initial response: 2 h

Escalation: Engineering Manager + On-call lead

SEV-3 — Medium

Single service degraded, elevated error rate

Ack: 2 h

Initial response: 4 h

Escalation: On-call engineer

SEV-4 — Low

Non-customer-facing, no data risk

Ack: Next business day

Initial response: 5 days

Escalation: Assigned engineer

RunbookIncident runbook maintained in Confluence, reviewed quarterly. Includes war-room setup, communication templates, and forensic evidence preservation steps.

Tabletop exercisesBi-annual incident simulation exercises with engineering, security, and legal. Scenarios include: ransomware, credential compromise, insider threat, and vendor breach.

GDPR notificationData breach notification to affected supervisory authorities within 72 hours of confirmed discovery (GDPR Art. 33). Customer notification within 24 hours of supervisory notification.

Post-mortemBlameless post-mortem published internally within 5 business days. Anonymised summaries shared with affected customers. Action items tracked to closure.

Status pagestatus.seismicswift.ai

Penetration Testing

Annual third-party penetration tests are conducted by an accredited security firm. We operate a responsible disclosure programme and reward valid vulnerability reports.

Annual pentestFull-scope external + internal pentest by a CREST-certified firm. Scope includes API endpoints, web application, Kubernetes cluster, and tenant isolation controls.

Last test dateAnnual independent security audit (latest report available under NDA to enterprise customers). No critical findings unresolved at time of release.

MethodologyOWASP Testing Guide v4.2 + PTES (Penetration Testing Execution Standard) + NIST SP 800-115. Includes manual testing for business-logic vulnerabilities not detected by automated scanners.

Tenant isolation testDedicated tenant cross-contamination test suite (API fuzzing, IDOR, homoglyph bypass, enumeration). No cross-tenant data access achieved.

Automated scanningDAST: OWASP ZAP in CI/CD pipeline on every release candidate. SAST: Semgrep with OWASP ruleset. Infrastructure: Prowler for Azure CIS benchmark.

Bug bountyPrivate bug bounty programme via HackerOne. In-scope: all production API endpoints, web application, and authentication flows. Out-of-scope: social engineering, physical access.

Responsible disclosureEmail security@seismicswift.ai. We acknowledge within 24 hours and provide remediation timeline within 72 hours. We do not pursue legal action against good-faith researchers.

Vulnerability SLA: Critical (CVSS ≥ 9.0) → 24 h remediation. High (7.0–8.9) → 72 h. Medium (4.0–6.9) → 30 days. Low → 90 days.
All findings are tracked in a security backlog with severity, CVSS score, affected component, and remediation owner. Evidence of fix is required to close each finding.
Red team exercises (adversarial simulation) conducted on request for enterprise customers with specific threat models (nation-state, insider threat, supply-chain).

Security Whitepaper

The full 48-page Security Architecture Whitepaper covers our threat model, cryptographic design decisions, compliance evidence package, and third-party audit findings. Available for enterprise evaluations.

Request Whitepaper Schedule Security Review

NDA required for full pentest report. Whitepaper available without NDA.

Built to the highest industry standards

SOC 2 Type II ISO 27001 NIST 800-53 OWASP Top 10 GDPR FedRAMP Ready OSDU R3 EPA Class VI EU CCS Directive IPCC