Provable constraints for AI agents
Every agent invocation checked, settled, and written to a signed evidence log — anchored on-chain so anyone can verify independently.
How it works
Every agent belongs to someone
Owner registers with KYC/KYA binding
Set policy before the call
Per-call caps, allowlists, escalation thresholds
Agent calls the tool
Request flows through the PEP gateway
Policy evaluated in real time
PDP checks Cedar policy before settlement
Settle on permit
Payment settled, decision written to evidence log
Verify independently
RFC 6962 Merkle proof anchored on Base
Identity: every agent provably belongs to someone
Before an agent can call a tool, a verifiable chain runs from the owning organisation’s KYB attestation down to the credential in the JWT header. Every step is a signed artifact — not a config flag.
Organisation identity
Org identity is anchored in three checks: ① Authorised representative verified — live via Sumsub KYC (FATF-aligned, sandbox simulated here). ② Company registry check — production slot (Sumsub Business Verification or registry APIs). ③ UBO screening — production slot. Production also slots eIDAS 2.0 / EU Digital Identity Wallet credentials. The attestation is stored in the owner record and hashed into every decision record.
{
"provider": "sumsub",
"status": "representative_verified",
"scope": "authorized_representative",
"components": {
"representative_kyc": { "status": "verified", "provider": "sumsub" },
"company_registry": { "status": "production_slot" },
"ubo_screening": { "status": "production_slot" }
},
"attested_at": "2026-06-11T09:00:00Z"
}Org key fingerprint
TrustGate mints a key pair for the org and stores a SHA-256 fingerprint of the public key.
{
"owner_id": "own_01KTTTWKC4Y6P",
"domain": "acme.com",
"pub_key": "sha256:4e9d2f7a1b3c8d5e...",
"demo": false
}Agent credential issued
TrustGate issues an ES256-signed JWT. The subject is a W3C DID binding the agent to the org key.
{
"iss": "self:trustgate",
"sub": "did:web:acme.com:agents:agt_01KTTTWKC...",
"agent_id": "agt_01KTTTWKC4Y6P",
"iat": 1749632400,
"exp": 1749639600
}Agent register
The agent is written to the registry as ACTIVE. Every status change (including revocation) is auditable.
| agent_id | owner_id | status | issued_at |
|---|---|---|---|
agt_01KTT…WKC | own_01KTT…4Y6P | ACTIVE | 2026-06-11T09:00:00Z |
agt_01KTT…OLD | own_01KTT…4Y6P | REVOKED | 2026-05-01T08:00:00Z |
Runtime binding check
On every invocation the gateway verifies the full chain — before any policy is evaluated.
- Owner found in datastore
- Agent status is ACTIVE
- Policy loaded for owner
- Credential signature valid (ES256)
Transaction: every action through the filter, into the log
A single invocation — agent_7 → get_quote → €12.50 — runs through every policy rule in sequence. The decision is deterministic: all rules pass, PERMIT fires.
Worked example: get_quote €12.50
| Rule | Configured | Request value | Verdict |
|---|---|---|---|
| Per-call cap | ≤ €100.00 | €12.50 | PASS |
| Daily cap | ≤ €5,000.00 | €0.00 spent today | PASS |
| Tool category | market-data | market-data | PASS |
| Publisher KYB | required | kyb_verified: true | PASS |
{
"record_id": "rec_01KTTTWKC4Y6P",
"seq": 1,
"agent_id": "agt_01KTTTWKC...",
"tool": "get_quote",
"amount_minor": 1250,
"decision": "permit",
"signed_at": "2026-06-11T09:00:01Z",
"anchor": "pending (HH:00 batch)"
}Escalation scenario: place_order €600.00
When the request amount exceeds the per-call cap, the gateway routes the action to the owner for approval rather than denying outright.
| Rule | Configured | Request value | Verdict |
|---|---|---|---|
| Per-call cap | ≤ €100.00 | €600.00 | ESCALATE |
| Daily cap | ≤ €5,000.00 | €12.50 spent today | PASS |
| Tool category | market-data | market-data | PASS |
| Publisher KYB | required | kyb_verified: true | PASS |
Owner approves via the portal → two records written: one for the escalation event, one for the final permit decision. Both carry the same request_id so the chain is auditable.
Built for every agentic workflow
Trading bots with spend limits
Enforce per-call and daily caps before settlement — not after.
Social media automation
Category allowlists prevent agents calling out-of-scope tools.
AI purchasing agents
Escalation thresholds route high-value orders to owner approval.
Enterprise AI governance
Every action traces to a verified owner identity and policy snapshot.
Multi-agent pipelines
Each agent in a chain carries its own credential and constraints.
MCP tool marketplace
Publishers require KYB verification before agents can call their tools.
Why this design
Liability needs attribution
When an agent causes harm, someone is accountable. Every action traces to a verified owner identity — before the call, not after.
Open standards, end to end
AuthZEN 1.0, W3C VCs, AP2, x402, MCP, RFC 6962. No proprietary lock-in — verify with any compatible tool.
The deny is the product
A constraint that can be bypassed is decoration. The deny fires before settlement — enforcement, not an audit trail.
See it run against a live system
Three acts, real policy decisions, signed evidence — nothing simulated.
Run the live demo →