// THREAT MODEL
What we defend against
TrigGuard sits in front of irreversible execution: infrastructure changes, data exports, financial movement, model publication, and other automated actions that must not run without explicit authorization.
We design for realistic failure modes: compromised tooling, leaked tokens, confused deputies, forged or replayed evidence, and attempts to bypass policy. The objective is fail-closed authorization with deterministic outcomes and verifiable receipts—not “trust the pipeline.”
For system boundaries and trust assumptions, see Architecture and Protocol spec.
// SECURITY ARCHITECTURE
How security is structured
Authorization is evaluated at a dedicated execution boundary before side effects occur. Decisions are explicit (PERMIT, DENY, SILENCE) and designed to default to denial when evaluation cannot complete safely.
Governance hooks, policy sources, and verification are separated so that “can this run?” and “can we prove what was permitted?” remain distinct, inspectable concerns—aligned with the Gate / Verify / Control / SDK product split.
Deep technical detail lives in Architecture, Security model, and Documentation.
// DATA HANDLING
Data we touch
TrigGuard processes the minimum data required to evaluate an execution request and produce a signed receipt: request metadata, policy inputs, and cryptographic material needed for verification. We do not sell personal data or use it for advertising.
Retention, subprocessors, and legal bases for personal data are described in the Privacy Policy. Enterprise data processing terms are available through commercial agreements.
// CRYPTOGRAPHIC DESIGN
Receipts and verification
Execution receipts are signed so offline verification can confirm what decision was issued and bound to a request context. Public key discovery and receipt structure are documented under Receipts and the receipt schema specification.
For protocol-level execution authorization semantics, see TG-EXECUTION-AUTH-01.
// OPERATIONAL SECURITY
How we run the service
We maintain operational controls appropriate to a security-sensitive platform: access minimization for production, change management, monitoring of critical surfaces, and incident response procedures. Specific certifications and audit reports are published here as they become available.
For commercial security reviews or architecture sessions, contact Contact or Governance.
// RESPONSIBLE DISCLOSURE
Report a vulnerability
We accept good-faith reports for the website, protocol interfaces, verification flows, and hosted runtime. Full process, scope, and contacts are on the Security page.