Policy Evaluation

Policy Evaluation is the real-time decision path a live call actually goes through — as opposed to Policy Management, which is authoring. Its core is a pure function, Evaluate(rules, request), that takes a candidate rule set and a request and returns a decision with no database access of its own; the module keeps it that way specifically so the decision logic is directly testable apart from rule lookup.

Before that function ever runs, the service narrows down which rules even apply. Rules bound to the call's exact target (and, hierarchically, to its parent — a tool inherits its MCP server's rules) are loaded and deduplicated, then filtered by subject: a rule with no agent or role binding applies to everyone, one scoped to specific roles or an agent only fires for a match — except a role-scoped deny still fires when the caller's roles couldn't be resolved at all, because missing identity must never grant access. A second filter checks target bindings with AND-across-types, OR-within-type semantics: a rule bound to both an MCP server and a resource only fires when a call touches both.

What's left is sorted by priority, descending, then filtered per rule by action, subject selector, resource selector, and conditions. The resource selector is a small DSL — side-effect type, an exact or regex tool name, resource type, or a literal-value fallback against any other context key — with every key present required to match. Conditions add time-of-day windows, environment tags, sensitivity tags, actor confidence state, and rate-limit / token-budget ceilings whose current counts the gateway pre-computes before evaluation runs. Among whatever rules match, only the ones sharing the single highest priority decide the outcome; a tie between different effects resolves deny > warn > audit > allow, and zero matches means implicit deny.

A single tool call can resolve to more than one target — a SQL query touching several tables runs the evaluator once per inferred resource or column and combines the results, with any deny winning. A target with literally no rules attached is treated as "no opinion" rather than an implicit deny, so one ungoverned table doesn't block a call the tool-level policy already allowed.

The same rule set also compiles into a portable form: published and approved rules render into a Rego module — a policy "bundle" — that a sidecar Enforcer can evaluate locally at the edge, independent of this central path, which is what backs policy bundle evaluation below.