Enforcement, programmable
Integrations
Broker for verification; Policy Engine for decisions; hardware controllers for the physical action.
TrustGate is thin by design. Verification is delegated; decisions are delegated; hardware is delegated. TrustGate owns the site/zone/door model and the access log.
Thoryn catalog composition
TrustGate + Broker
Pattern: TrustGate delegates all verification to Broker. The door device never holds credentials; it relays them and receives a decision.
TrustGate + Policy Engine
Pattern: Optional but common. After Broker verifies, Policy Engine decides ALLOW / DENY based on verified claims (age, role, site membership). No Policy Engine config → any valid credential grants entry.
TrustGate + Trust Registry
Pattern: Transitive, via Broker. TrustGate doesn't talk to Trust Registry directly; Broker does on every verification and returns the decision.
TrustGate + Hardware controllers
Pattern: TrustGate's webhook integration speaks HTTP to any door controller that exposes a lock/unlock API. Integrators bring their own hardware; TrustGate is protocol-pure on the access-decision side.
TrustGate + SIEM
Pattern: Access-log entries shipped via structured logs (syslog, JSON, or a configured forwarder). Integrates with Elastic, Loki, Splunk, or any standard ingestion.
Also on TrustGate
Ready to gate doors with credentials?
Request access to mount TrustGate at your first zone.