What it is
Policy enforcement is the engine that makes governance decisions. For every 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 escalate (send to human review).
The policy engine understands threat semantics. It doesn't just look at text patterns — it understands that rm -rf is destructive deletion and should be blocked, while ls -la is a safe read operation.
Why it matters
Without policy enforcement, everything is either fully automated or fully manual. Policy enforcement enables nuance: routine actions run automatically, high-risk actions require approval, and clearly malicious actions are blocked immediately.
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. Self-serve pattern editing from the dashboard is on the roadmap; the policy view there is read-only today. This lets security teams tune enforcement without a code change.
How it works
Intercis's policy layer is a deterministic deny-list of 110 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.
The policy is version-controlled and auditable. Decisions are logged, on a best-effort basis, with the rule that triggered each and the agent's context at the time.
How Intercis implements it
Intercis's policy engine is a deterministic deny-list of 110 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, roughly a 30-second budget). Only traffic on the LLM-API wire is visible; hosted, server-side MCP tool calls the provider executes directly are not governed or logged today. 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.
Related terms
- Tool Call Interception — Where policy enforcement decisions are applied.
- Human-in-the-Loop — the human-review (escalate) decision, a concept Intercis does not run as a live verdict today.
- Agentic AI Threats — The threat model that informs policy decisions.