TrustRail sits between an AI agent and the systems it acts on — enforcing delegated limits before a request ever reaches a downstream connector, and recording a signed receipt of every decision and execution.
Owners and admins issue root grants; agents can delegate narrower child grants to other agents. Every child grant is a strict subset of its parent's actions, amounts, and expiry — attenuation is enforced server-side, never just advised.
Versioned, typed policy bundles decide ALLOW, DENY, or REQUIRE_APPROVAL — never an LLM's judgment call. The gateway holds the only downstream connector credential, so an agent has no path around it.
Root grants, child grants, and policy-level daily budgets are reserved atomically with deterministic lock ordering, tested under genuine concurrent load — not just documented as a limit.
Every decision and execution is recorded as an Ed25519-signed JWS receipt. Anyone holding a receipt — not just TrustRail's own dashboard — can verify signature validity, issuer trust, and recorded outcome independently.
An approval is bound to one exact action, principal, grant chain, and policy version. A stale policy invalidates it. Self-approval is rejected. Nothing about the flow is advisory.
The dashboard, the TypeScript and Python SDKs, and the MCP adapter all call the same REST API — nothing the UI can do that an integration can't.
The same grant/policy/receipt engine enforces two independent connectors today, proving the architecture is genuinely action-agnostic rather than built around refunds specifically.
A customer-support agent issues refunds through a synthetic merchant sandbox, constrained by a delegated grant (amount cap, daily budget, approval threshold), producing signed receipts of every decision and execution. Money is not real in this version.
An IT onboarding agent grants license credit, changes a plan, activates a feature, or invites a user against a synthetic SaaS sandbox — each action with its own limits: a hard allow-list for which plans are eligible, a downgrade that always needs human approval, a feature flag that’s a pure allow/deny gate, and an invite that hard-blocks admin roles while escalating any other exception to a reviewer. Recreates a real worked example directly: “grant a new hire access for 30 days, no admin rights, and up to EUR 150 of licenses — require approval for any exception.”
TrustRail doesn’t judge whether a plan change is a good idea or a message is true — it enforces the limits a human already decided, and asks for a decision when a request falls outside them.
Every capability above is covered by automated tests run against a real, non-mocked PostgreSQL instance and real HTTP sandboxes for both connectors, plus a live Docker Compose deployment and a passing CI run — not just described. This site makes no claims about customers, revenue, or third-party endorsement.