EXPERIMENT_028 // LOCAL.SECURITY-POLICY.INTERCEPTION.MIDDLEWARE

Local Security-Policy Interception Middleware

Watch a mock agent propose tool calls — reads, writes, deletes, publishes, credential access — and this experiment intercepts each one in real time, scores it against an editable local policy schema, and blocks anything at or above your threshold until you approve or deny it.

🖱MOUSE OR TOUCH INPUTCREATED 2026.08.05BETA

LOADING EXPERIMENT...

A bundled fixture set of ten mock tool calls — from a benign local file read to a production database delete — runs through the interception middleware the moment you load the page, entirely in your browser: nothing is sent to a server unless you explicitly click "Generate live scenario batch." Each call is scored against a policy schema built from named, weighted rules across four dimensions (action class, target scope, reversibility, credential sensitivity). Calls below your threshold auto-pass with a visible log line; calls at or above it hold in a keyboard-navigable approval queue until you approve or deny them. Edit the policy schema or move the threshold slider and the entire scenario set re-scores immediately.

HOW IT WORKS

An additive rule schema, not a black-box classifier

Every rule in the policy schema fires independently when a call's action class, target scope, reversibility, or credential sensitivity matches its `appliesWhen` condition, and its weight adds to the running score (clamped 0-100). A call that is both an irreversible, production-targeting delete with high-sensitivity credential access fires four separate rules and the final score is visibly their sum — every rendered score is paired with the exact named rules that produced it, so there is nothing to take on faith.

Threshold and schema are both live controls

The approval threshold is a slider; the policy schema is an editable JSON textarea validated by Zod on "Apply & re-score." Either control re-runs `runScenario()` over the full call set from scratch — move the threshold from 50 to 30 and calls that previously auto-passed can flip into the approval queue on the next render, with no page reload and no server round-trip.

Fixture-first, live-optional, and honest about which is which

The ten bundled fixture calls are the default and work fully offline. Clicking "Generate live scenario batch" posts to `/api/experiments/policy-interception-gate/generate`, which asks an OpenAI model (via `@diabolicallabs/llm-client`) to invent a handful of additional tool-call proposals tagged along the same four dimensions — the model only proposes scenario content, it never scores or decides anything. Every live-generated call carries a visible "live" tag in the log. If `OPENAI_API_KEY` is absent or the call fails for any reason, the route returns 503 `provider_unavailable`, the button disables itself, and a "Provider unavailable — fixture mode only" label appears — the demo never crashes and never silently drops a request.

How this differs from the linters

Unlike the Trust-Tier Compliance Linter, which statically scores a pasted description of an agent's declared trust tier against its described behaviour after the fact, this experiment intercepts each tool call in real time, before it would execute. Unlike the ASI-Checklist Linter, which runs a one-time static scan of a pasted agent configuration against the ten OWASP ASI categories, this experiment scores each individual call as it is proposed, one at a time, in a running session. Unlike the Reversibility Approval Gate, which classifies each proposed call along a single fixed reversibility tier using a non-editable classification module, this experiment scores every call across four independent risk dimensions against a policy schema you can edit and re-run live.

WHAT THIS PROVES

The week this experiment was built, OpenAI paused its Astra preparedness framework and Check Point disclosed eleven CVEs spanning agent frameworks — both make the same operator-side case: containment gates belong at your own boundary, not upstream in a vendor's infrastructure you don't control. A small, local, fully-inspectable interception layer — one you can read every rule of, edit live, and watch block a call before it runs — is a concrete, buildable mirror of that argument at demo scale, not a rhetorical stand-in for it.

This is a sandbox demonstration, not production enforcement — it does not touch the fleet's real `enforce-delegation.sh` hook, and its policy schema and approval queue are scoped entirely to this browser tab. What it proves is narrower and more honest: that real-time interception, unlike a static audit, can be made fully legible — every score traceable to named rules, every gate decision reversible by threshold, every scenario re-runnable — without needing an opaque model to decide what's dangerous.

← BACK TO PLAYGROUND

SYSTEM.INT // 2026 LABS_CORE v2.108.0

LATENCY: STATUS: NOMINAL