Security Whitepaper

This document describes how Panguard AI is built and operated. We are an early-stage, open-source security company. We document what we have today, what we plan, and what we do not pretend to have. Where a control is in flight, we mark it as such.

1. Architecture Overview

Panguard ships as three components: (a) Panguard CLI / Guard, an open-source endpoint scanner installed by users on their own machines under MIT license; (b) Threat Cloud, a hosted aggregation API at tc.panguard.ai; (c) ATR (Agent Threat Rules), the public rule corpus on GitHub. The CLI is local-first by design; customer skill content is never transmitted to Panguard servers. Only anonymized fingerprints (SHA-256 hashes, severity verdicts) flow to Threat Cloud, and only when the user opts into community telemetry.

1.1 Hosting

Threat Cloud runs on a single-region production deployment hosted on a SOC 2 Type II certified cloud provider. Multi-region deployment is planned for Q1 2027 once a paying customer requires it. We do not currently maintain infrastructure in North America or Europe — that is on the roadmap, not in production.

2. Encryption

2.1 Data at Rest

Threat Cloud's database uses AES-256 encryption at rest, provided by the underlying cloud provider's managed disk service. We do not run a hardware security module and we do not offer customer-managed keys today.

2.2 Data in Transit

All traffic between the CLI / Guard and Threat Cloud is over TLS 1.3. We use an industry- standard TLS configuration; we do not maintain custom certificate pinning today.

3. Access Control

3.1 Authentication

CLI / Guard does not require authentication for local scanning. Threat Cloud aggregation requires an API key auto-issued to each Guard install. Single sign-on (SAML 2.0 / OIDC), enforced MFA, and WebAuthn are not implemented today; they are part of the AIAM identity layer scheduled for Q3 2026.

3.2 Internal Access

Production access to Threat Cloud is held by the founding team only. We do not yet operate just-in-time provisioning or role-based access control beyond the  admin-vs-client distinction in the API. Both are roadmap items for SOC 2 Type 1.

4. Logging & Audit

Threat Cloud writes an immutable audit log of all admin actions, configuration changes, and rule promotions. The schema is at migrations.ts in the open-source threat-cloud package; rows include actor, action, resource, and timestamp. Audit log retention is 365 days. We do not yet operate a dedicated SIEM with correlation rules; the audit log is the system of record.

5. Incident Response

We maintain a written incident response runbook. The team is small enough that on-call rotation is the founding team only — there is no 24/7 SOC. We notify affected customers within 72 hours of any confirmed incident. Tabletop exercises and external IR engagement are planned alongside SOC 2 Type 1.

6. Compliance

Status of compliance work in flight:

7. Third-Party Audits

We have not yet engaged third-party penetration testing or external code audit. Both are scheduled to begin alongside SOC 2 Type 1 in Q3 2026. Customers requiring vendor-risk evidence prior to that timeline should contact us — we will share what we have today (architecture diagrams, audit log samples, threat model) under NDA.