Inspiration

AI agents are starting to act, not just talk. They can issue refunds, access customer data, and trigger operational workflows. Most teams still guard those agents with prompt instructions. But a prompt is only a suggestion. A jailbreak, an injection, or a plain misunderstanding can push a model past it, with no reliable enforcement or audit trail.

We built PolicyGate to move trust from prompt instructions to runtime enforcement.

What it does

PolicyGate is a runtime permission gateway for AI agent tool calls. It sits at the tool execution boundary. The model proposes a candidate action, and deterministic code decides whether it can run.

In our synthetic commerce support demo, PolicyGate:

  1. Compiles written SOPs into machine checkable policy
  2. Extracts candidate tool calls and risk signals from natural language requests
  3. Returns ALLOW, APPROVAL, or DENY from deterministic TypeScript
  4. Auto approves only low value and low risk refunds
  5. Routes risky actions to human approval
  6. Denies repeated refund abuse and forbidden actions
  7. Links every decision back to the SOP line that caused it
  8. Records every decision in an audit timeline

Example scenarios include an attack trying to refund $5000, a clean $500 refund denied by amount boundary, a $30 low risk refund allowed, a suspicious small refund routed to approval, repeated refund abuse denied, and customer data export blocked.

How we built it

PolicyGate has two AI assisted steps and one deterministic enforcement step.

First, the SOP compiler uses OpenAI Structured Outputs to convert written operating rules into structured policy JSON.

Second, the action extractor converts natural language requests into candidate tool calls, such as refund_order, with amount, risk level, and supporting signals.

Third, the deterministic policy engine checks the candidate action against policy before execution. The final ALLOW, APPROVAL, or DENY decision is made by TypeScript code.

The stack is Next.js, React, TypeScript, Tailwind CSS, Zod, OpenAI Structured Outputs, Vitest, Vercel, GitHub, and JSON based policy definitions.

The model handles language understanding and structured candidate generation. The final permission decision is enforced by deterministic code.

Challenges we ran into

The most important challenge was policy ordering.

During development, we found that an LLM compiled policy could place a low risk small refund ALLOW rule before refund abuse DENY rules. That could allow a repeat abuser to slip through with a small refund.

We decided not to trust LLM generated rule ordering. PolicyGate now applies deterministic policy normalization after compilation, so refund abuse and high risk DENY rules always outrank small refund ALLOW rules.

This became one of the core lessons of the project: even model generated policy should be checked before it is trusted.

Accomplishments that we're proud of

The deterministic enforcement layer passes 31 test cases.

Current evaluation results:

  1. Policy decision accuracy: 100%
  2. Approval routing accuracy: 100%
  3. False allow rate: 0%
  4. False deny rate: 0%
  5. Injection action block rate: 100%
  6. Abuse guard accuracy: 100%
  7. Repeated refund block rate: 100%
  8. Forbidden action block rate: 100%

The metric we care about most is false allow rate. In this demo, unsafe actions do not execute.

We are also proud that every decision has audit proof. A denied action is not only blocked before execution, but also linked back to the SOP line that caused the decision.

What we learned

Reliable agent safety depends on where the final decision is made.

Models are useful for understanding user requests, extracting candidate actions, and helping compile structured policy. But permission decisions for real actions should be testable, auditable, and deterministic.

The key lesson is:

AI proposes. TypeScript decides.

We also learned that low amount does not always mean low risk. A small refund can still be suspicious if the account has repeated refund history or missing evidence. This is why PolicyGate includes a Refund Abuse Guard instead of relying only on amount thresholds.

What's next for PolicyGate

Next, we would like to expand PolicyGate beyond the synthetic commerce support demo.

Future directions include:

  1. More action types, such as account changes, data exports, credits, and workflow approvals
  2. Reusable policy packs for common support and operations workflows
  3. Signed and versioned policies
  4. Exportable audit logs for compliance and review
  5. A broader tool permission gateway that can sit in front of more agent frameworks and tool runtimes

All data in this project is synthetic. It uses no internal company data, code, table names, business rules, private customer data, credentials, or real payment systems.

Built With

Share this project:

Updates

Submission history