Policy engine

One line of policy, enforced on every call.

No production database access for any agent is a single rule. Match a tool pattern, add context like IP, time, or agent labels, choose allow, deny, or require approval, and let deny-overrides resolve the rest.

Glob + context · deny-overrides · approval built in

rule
name no production database
match tool db.*
when environment = production
then deny
one rule, every agent, enforced on every call
0
Precedence tiers
0
Context predicates
0
Actions
<0ms
Evaluated on the hot path

Anatomy

A pattern, some context, and an action.

Every rule is the same shape. Match what the call is, narrow it by who and where, then say what to do.

Tool pattern

A glob over the tool name, like db.* or aws.s3.delete*, so one rule can cover a whole family.

Context

Client IP or range, a time window, the egress host, agent labels, and even a threat class.

Action

Allow, deny, or require approval. Deny-overrides decides which rule wins when several match.

Two ways to match

Pin to a detected signal, or gate on a score.

Most rules are one of two kinds. Use whichever fits the risk you are managing.

Signal-pinned

Fire whenever a category like secret or destructive is detected, regardless of the number. Content inspection makes this actionable.

Threshold

Deny when the risk score crosses a number you set, a simple gate for anything that scores high without naming a category.

Build a policy

Compose a rule and watch it decide.

Build a rule on the left and watch it run against sample calls on the right, using the same engine and the same deny-overrides order the gateway uses. Toggle context to see a rule narrow.

Your rule

Deny
Allow
Require approval

context (optional)

Agent labels
Client IP in range
Time window (UTC)

Sample calls

evaluated live · deny-overrides
  • db.query81deny
    DELETE FROM users
    Destructive

    denied by policy "your rule"your rule won

  • db.read50deny
    SELECT one row by id

    denied by policy "your rule"your rule won

  • aws.s3.deleteBucket96deny
    Delete bucket with a leaked key
    Secret

    denied by policy "deny-live-secret" (secret detected)

  • gmail.send84deny
    Email a customer
    PII

    risk 84 >= threshold 75 (policy "risk ≥ 75")

  • github.read10allow
    Read a README

    risk 10 < threshold 75 (policy "risk ≥ 75")

Precedence

Deny-overrides, top to bottom.

When more than one rule matches, the order is fixed. The first matching tier wins, and a deny always outranks an allow.

First match wins, top to bottom. A deny always sits above an allow.

deny when secret is detected stops a leaked key, whatever the score.

Hold for a human

Require approval turns a risky call into a request.

A hold does not just block. It opens a request your team can resolve fast.

Approvals are built in

A held call becomes a pending approval with signed one-click email links, an optional two-person rule, and a hold window you set. Approve or deny without opening the console.

Make no production database access a one-line rule.

Write a policy once and it runs on every call, in order, in under 100 milliseconds.