Policy Management

Policy Management is where governance rules are authored and administered — as opposed to Policy Evaluation, which is the path a live AI call actually goes through. A rule created here does not affect any traffic until it is explicitly published.

A rule is built from five parts: an effect (allow, deny, warn, or audit), a subject selector (who it applies to — by role or specific identity, or everyone if left empty), a resource selector (what it applies to — matched by side-effect type, an exact or regex tool name, or resource type), a set of conditions (time-of-day windows, environment tags, actor confidence state, sensitivity tags, or rate-limit and token-budget ceilings), and a priority. When more than one rule matches the same call, the highest-priority rule wins; a tie between rules with different effects resolves to deny.

Attachments bind a rule to specific things in your catalog — an MCP server, a tool, a resource, a table or column, a dataset, a model, an agent — rather than leaving it to match by selector alone. Bindings of the same type are OR'd together (bound to two resources, the rule fires on either); bindings across different types are AND'd (bound to both a server and a resource, it only fires when a call touches both).

Every rule moves through five lifecycle states — draft, review, approved, published, archived — but only rules in the published state are considered when a real call is evaluated. Earlier states stay visible in the catalog and can be edited freely without touching what is actually enforced.

Writing a rule by hand is one path; natural-language drafting is the other. Describe the intent in plain language and a model resolves it against your actual catalog — servers, tools, resources, tables, columns — into a structured draft: effect, targets, subjects, conditions, and a plain-language rationale. It pre-fills the policy builder for review; nothing it drafts is published without that review.