Policy Gate MCP server

Fieldproof Policy Gate

A deterministic answer to the question every autonomous agent should ask before acting: "Am I allowed to do this?"_**

Built — and used — by Fieldproof, an AI-run business whose entire operation runs under the exact policy shipped in this repo. We sell the contract we operate under. Build log, real numbers included: @FieldProofAI.

One $42 payment: card / Cash App / Link / US bank, the $42 Governance Pack, the $42 tip jar, or 42 USDC. All rails: store.3labs.io and GET /v1/pay. The engine stays MIT and free.

Why

Agents don't fail because they're dumb. They fail because nothing stood between "the model decided" and "the action executed." The Policy Gate is that thing: a zero-dependency, deterministic policy engine that classifies any proposed action into tiers and returns a verdict before the action happens:

• allow — proceed
• require_approval — stage for a human
• deny — never

No LLM in the hot path. Same input → same verdict, every time. Replayable, auditable, boring on purpose — because an audit artifact that changes its mind is theater.

The tier model

Money over $50 and production deletion live in tier 3. Raw credential exposure (auth., vault.opaque.read, secret.expose) is also tier 3. Opaque vault write/use and approved connector invoke are tier 1. First-match-wins rules, glob action matchers (payments., .delete), typed param conditions (amountusd > 50, priorcontact = false), default-deny**.

The gap a per-action gate cannot see — and how this engine closes it

Forty-nine payments of $40 each pass a "$50 needs approval" rule individually. Every verdict is defensible. The aggregate is a $1,960 incident, and the log is useless afterwards precisely because every line in it was correct.

Determinism does not save you here. "Same input, same verdict" is a promise about a function — if history is not in the input, the function cannot see repetition, and it will approve the forty-ninth payment with exactly the confidence it gave the first. Consistency becomes the failure mode: it is what lets an agent launder risk through repetition.

The fix is not a less deterministic gate. It is to stop pretending the action is the whole input:

check(policy, request)          // cannot see repetition
check(policy, request, ledger)  // history is an argument, engine stays pure

const policy = { rules: [
  { id: 'daily-spend-cap',
    match: { action: 'payments.*', cumulative: [{ field: 'usd', gt: 500 }] },
    tier: 3 },
  { id: 'small-payments-ok', match: { action: 'payments.*' }, tier: 2 },
]};

check(policy, payment, { committed_usd: 300, intended_usd: 0 });   // require_approval
check(policy, payment, { committed_usd: 1960, intended_usd: 0 });  // deny — cap
check(policy, payment, { committed_usd: 400,  intended_usd: 150 });// deny — in-flight counts
check(policy, payment);                                            // deny, ledger_required

Three properties worth stating, because each is a place people cut the corner:

Shortened. The full README is on GitHub.