COMPANY
Who we are
TrigGuard AI Limited is a UK company (Company No. 16597262) building deterministic execution authorization infrastructure: explicit PERMIT / DENY / SILENCE decisions, fail-closed defaults, and verifiable receipts before irreversible actions.
We publish technical material under Protocol, Architecture, and this Trust Center so buyers and auditors can evaluate the system without marketing abstraction. For how authorization flows in practice, see the execution trace walkthrough. For procurement, security review, or engineering questions, use Contact or reach the team at sales@trigguardai.com / security@trigguardai.com as appropriate.
ORIGIN
Why TrigGuard exists
TrigGuard is currently developed by its founder, Mohamed Salem, with input and collaboration from engineers and advisors in distributed systems, security, and infrastructure. The shared observation was simpler than "AI safety" as a slogan: once automation can execute against real surfaces at high frequency, the control plane that matters is the one that runs before irreversible commits, with outcomes that can be replayed and verified.
TrigGuard exists to ship that layer as infrastructure: deterministic execution authorization, fail-closed defaults where execution must not proceed under ambiguity, and signed receipts so risk, security, and compliance teams do not have to trust a single vendor UI or log pipeline. We are not building a model benchmark or a governance dashboard; we are building the authorization and evidence contract around execution itself. Technical detail lives in Protocol, Architecture, and Verify; commercial terms on Pricing.
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.
Fail-closed and SILENCE
TrigGuard defaults to denial when evaluation cannot complete safely. SILENCE - a state distinct from DENY - covers ambiguous or incomplete evaluation without issuing false authorization. Under uncertainty, the system does not guess.
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.
Certifications and audit reports
Current status: Pre-certification. We are operating appropriate controls for a security-sensitive platform at this stage of deployment.
SOC 2 Type II: Planned. Timeline disclosed to enterprise buyers under NDA.
ISO 27001: Under evaluation.
Penetration test: Completed internally; third-party assessment scheduled for production launch.
Audit reports and certifications will be published here as they become available. Enterprise buyers on the critical-infrastructure path may request our security review package via Contact.
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.