AI Agent Policy Enforcement

What it is

Policy enforcement is the engine that makes governance decisions. For each tool call an agent attempts, the policy engine evaluates the call against a set of rules and produces a decision: allow (let the action through), deny (block the action), or observe (record it and let it through).

The rules are written against the shape of the command rather than the words around it: rm -rf is destructive deletion, ls -la is a safe read.

Why it matters

Without policy enforcement, everything is either fully automated or fully manual. Policy enforcement enables nuance: routine actions run, risky ones are recorded and let through, and matched ones are blocked.

Policy is tunable per tenant. The deny-list pattern set is maintained by Intercis — it is a compile-time constant in the proxy — and per-tenant exclusions let you adjust which matches apply to your traffic without redeploying the agent or changing your code. The policy view in the dashboard is read-only.

How it works

Intercis's policy layer is a deterministic deny-list of regex patterns, checked in order: first match wins. When the proxy intercepts a tool call, it evaluates the call against each pattern; a match resolves to a policy label, and the label determines the verdict. The patterns are bare (pattern, policy) pairs; there is no per-pattern severity score. The possible verdicts are:

deny: the tool_use block is deleted from the model's response before the agent runtime can execute it.
observe: the call is allowed through but recorded, used during rollout and tuning.
allow: the call is forwarded to the agent unchanged.

Decisions are logged, on a best-effort basis, with the rule that triggered each and the agent's context at the time. The rule set itself has no history you can query.

How Intercis implements it

Intercis's policy engine is a deterministic deny-list of regex patterns (covering shell injection, destructive operations, privilege escalation, data exfiltration, API abuse, and more) plus an LLM classifier that judges execution-, file-mutating-, and MCP-tool calls the patterns do not decide (fail-open). Only traffic on the LLM-API wire is visible; hosted, server-side MCP tool calls the provider executes directly are observed, not governed: one observe row, never judged or blocked. The patterns are bare (pattern, policy) pairs; there is no per-pattern severity to configure.

A tenant runs in one of two modes: enforce mode blocks calls that match a deny policy, and observe mode records the same matches without blocking (useful during rollout). A fourth verdict, pending, exists in the schema for actions that would require human review, but no live reviewer approve/deny action is wired up today. The deny-list is updated in the proxy without redeploying your agents.