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 planned AIAM identity layer.

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 planned alongside SOC 2 Type 1 preparation; timing will be announced with the audit schedule. Customers requiring vendor-risk evidence before then should contact us — we will share what we have today (architecture diagrams, audit log samples, threat model) under NDA.