Actsurance
I. Charge
AI agents execute tool calls against customer data, payment systems, and external APIs without any deterministic access control layer between them and the tools they invoke.
II. Investigation
Production AI systems often treat agent-to-tool communication as trusted. An agent that is tricked by a prompt injection attack, or that simply makes a bad inference, can execute a destructive tool call with no structural barrier to stop it. Actsurance sits between the agent and its tools. Every tool call passes through a policy evaluation layer before execution. The gateway produces a tamper-evident audit receipt for each decision, whether the call was allowed, denied, or escalated to a human reviewer.
III. Exhibits - Architecture
- The L1 firewall uses the RE2 regex engine to inspect tool call payloads for SQL injection patterns, shell commands, and PII before any policy evaluation runs. A match returns HTTP 403 immediately.
- A routing splitter separates requests into two paths. The fast path evaluates Open Policy Agent (OPA) rules for deterministic RBAC decisions and executes in under 180 ms. The slow path stages the request in PostgreSQL, starts a Temporal workflow, and returns HTTP 202. That workflow waits for a human approval signal or times out after 48 hours.
- An ONNX risk model scores prompt intent on the fast path. If the model returns a high-confidence score, the request proceeds. Ambiguous scores are treated as escalation triggers rather than approvals.
- The Sealed Broker pattern prevents credential exposure. The gateway retrieves secrets from a Vault cache and injects them into the outbound request at the last moment. The agent never receives the raw credential.
- An offline verifier worker reads the PostgreSQL audit trail and validates every routing decision independently. This proves system behavior without trusting the gateway's own logs.
IV. Cross-Examination
Q: Why run both an OPA policy engine and an ONNX risk model?
A: OPA handles deterministic RBAC. You cannot train your way out of a hard deny for a resource the agent should never access. The ONNX model handles the probabilistic case, where the parameters look valid but the intent is suspicious. If the ONNX model crashes or returns a low-confidence score, the system defaults to ESCALATE rather than ALLOW.
Q: Why model ESCALATE as a first-class outcome instead of just DENY?
A: A hard deny drops the action silently. An ESCALATE pauses it and routes it to a human reviewer via the Temporal workflow. For sensitive operations, a human decision is more appropriate than an automatic rejection. The agent is told to wait, not told it failed.
V. Failure Modes
- ONNX model crash triggers a fail-safe ESCALATE. The fast path never silently approves a request when the model is unavailable.
- Temporal cluster outage blocks the slow path. Fast path requests continue executing against OPA rules. Escalated requests queue until Temporal recovers.
VI. Lessons Learned
- Early designs included Saga-based compensation workflows for payment reversals. That added significant complexity for a system whose primary function is a security gateway, not a payment processor. Removing the compensation logic clarified the scope and reduced the surface area of the implementation.
VII. What I'd Build Next
- Build and deploy the L1 RE2 firewall as the first production component. Layer the OPA evaluation on top once the firewall is stable. Add the Postgres audit trail and the offline verifier before the ONNX model, so the audit infrastructure exists before probabilistic routing is introduced.
Verdict
ESCALATE - Implementation starts with the L1 firewall. Selected to present at NIC Lahore and NIC Hyderabad.