// 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 a deeper threat and operations view, see the Trust Center; for system layout, Architecture.
// 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)
- 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)
- 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. For lawful bases, subject rights, and international transfers, read our Privacy Policy; for platform rules, see Terms of Service and the Trust Center.
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 uses Ed25519 for all receipt signatures. Receipts can be verified offline against published public keys.
| Component | Standard |
|---|---|
| Signature Algorithm | Ed25519 |
| Key Discovery | /.well-known/trigguard-keys.json |
| Receipt Format | JSON with deterministic serialization |
// 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