SECURITY MODEL
Deterministic authorization before execution
TrigGuard enforces policy evaluation before irreversible work. Every automated action must pass verification against declared rules; only then may execution surfaces (payments, infrastructure, data systems, or internal tools) proceed.
Receipts are cryptographically signed and can be verified offline against published keys. The design is fail-closed: if authorization cannot be established, execution does not proceed.
For system layout and pipeline context, see Protocol architecture (same content as Architecture). For disclosure, vulnerability reporting, and operational security narrative, see the Trust Center.
SECURITY ARCHITECTURE
High-level components
TrigGuard separates evaluation from execution. In production-shaped deployments these roles map roughly as follows:
- Control plane — policy and configuration surfaces you integrate with
- Policy distribution — how rules reach the evaluation path
- Execution gate — deterministic PERMIT / DENY / SILENCE before commit
- Receipt infrastructure — signed decision records (Ed25519 over canonical payload)
- Verification authority — key discovery and offline receipt checks (
/.well-known/trigguard-keys.json, Verify)
SITE PRACTICES
Infrastructure practices
Public marketing and docs sites are served over HTTPS with HSTS, CSP, and related headers on HTML responses. Policy enforcement and signed receipts are core product behaviors, not marketing claims; the protocol and API docs describe the contract in depth.
- HTTPS for production web traffic
- HSTS, CSP, and security headers on hosted pages
- Policy enforcement before irreversible execution (product contract)
- Cryptographically signed receipts (Ed25519, immutable, offline-verifiable)
- Minimal attack surface by design: evaluate declared signals; no hidden policy layers
Privacy & data handling
TrigGuard is designed to evaluate action metadata for authorization, not to warehouse your full application payloads. Deployment options support metadata-only processing, regional residency, and zero-retention sidecar models where policy requires it. Lawful bases, subject rights, international transfers, and customer-facing data commitments are summarized in the Trust Center and detailed in the Privacy Policy; platform rules in the Terms of Service.
WHAT THE SYSTEM COMMITS TO UNDER DECLARED POLICY.
Single-outcome evaluation
Every policy evaluation produces one finite decision: PERMIT, DENY, or SILENCE.
Fail-closed execution
If authorization cannot be established, execution cannot proceed.
Cryptographic receipts
Decisions can be recorded as signed receipts and verified independently of TrigGuard uptime.
Replayable evaluation
Policy outcomes can be reproduced from the original signal frame and declared rules.
No hidden policy layers
TrigGuard does not recommend actions, coach operators, or modify your execution logic, it evaluates and binds outcomes.
SECURITY PROOF
Evidence, not interpretation
Immutable record
Every PERMIT, DENY, and SILENCE is recorded with cryptographic binding. Receipts are tamper-evident and verifiable without asking TrigGuard to vouch after the fact.
Minimal disclosure
Evaluation uses declared structure and policy-relevant fields, not ad-hoc data mining. You supply what the policy needs; TrigGuard enforces the contract, not a narrative about your payloads.
RESPONSIBLE DISCLOSURE
Reporting Vulnerabilities
We welcome responsible disclosure of security issues affecting the website, protocol interfaces, verification flows, or hosted infrastructure. Please email security@trigguardai.com with reproduction steps, impact, and affected endpoints or URLs. We aim to acknowledge reports within 48 hours and coordinate remediation in good faith.
When reporting, please include:
- Affected URL or component
- Reproduction steps
- Expected vs actual behavior
- Impact assessment if known
SCOPE
What to Report
Reports related to:
- POST /execute endpoint
- /.well-known/trigguard-keys.json
- Receipt verification
- Site vulnerabilities (XSS, CSRF, etc.)
- Hosted authorization runtime
GOOD FAITH
Good-Faith Disclosure
TrigGuard will not pursue action against researchers who:
- Act in good faith
- Avoid privacy violations
- Avoid service disruption
- Give us reasonable time to investigate before public disclosure
RESPONSE
Response target
We aim to send an initial acknowledgment within 48 hours for reports sent to security@trigguardai.com. Complex issues may require more time to validate and fix; we will keep reporters informed when contact details are provided.
BUG BOUNTY
Bug Bounty
TrigGuard does not currently operate a public bug bounty program.
CRYPTOGRAPHY
Protocol Cryptography
TrigGuard signs receipts with Ed25519 over a canonicalized JSON payload. Receipts are immutable once signed and verifiable offline against the issuer's published public key.
| Component | Standard |
|---|---|
| Signature Algorithm | Ed25519 — live conformance key |
| Key Discovery | /.well-known/trigguard-keys.json (JWK Set, Ed25519 / EdDSA) |
| Canonicalization | Lexicographic key sort, recursive, undefined-omitted, no whitespace |
| Payload anchor | Optional payload_hash = hex SHA-256 of canonical signed payload |
| Versioning | Additive-only; new algorithms may be added without removing Ed25519 |
SECURITY.TXT
security.txt
Our security contact information is published at the standard well-known location per RFC 9116:
Contact: mailto:security@trigguardai.com Contact: mailto:abuse@trigguardai.com Expires: 2027-01-01T00:00:00.000Z Preferred-Languages: en Canonical: https://www.trigguardai.com/.well-known/security.txt Policy: https://www.trigguardai.com/security