Policy Parameters Explained
Policy Syntax documents the parts of a v11 policy, and Typed Policy Authoring the lifecycle around a document. This page answers the question a v10.x user asks first: what happened to the parameters I used to tune, and where do I tune that now?
In v10.x two families of policy, system (static) and tenant (dynamic), were tuned through a set of parameters on each row. In v11 those families are read-only, and one decision engine reads the shipped policies and your organization's typed policies instead. Some parameters kept their meaning, some moved, and one, priority, no longer exists.
At a glance
| v10.x parameter | What it did | In v11 |
|---|---|---|
category / type | Classified a system policy; selected how a tenant policy was evaluated | A shipped policy keeps its category, and a category-wide override applies to every shipped policy in it. Your own policies are classified by their authority: grant, ceiling, requirement or inspection |
severity | Tuned masking depth, a fallback action and a risk label | Still carried by the shipped pattern-based policies; see Severity |
priority | Ordered evaluation | No equivalent. The engine reads every applicable policy and combines them by kind; see Priority |
phase | Request, response or both | The planes and phase each shipped policy binds to, listed in Shipped Policy Posture |
action / actions | What happened on a match | For a shipped policy, the action your organization gives it: log, warn, redact or block. For your own policy, its authority and the obligations it attaches |
conditions | When a tenant policy matched | Your policy's where clause, over the deployment's vocabulary |
enabled | On or off | For a shipped policy, disabled or enabled for your organization. Your own policies are on when the document that holds them is active |
tier | System, organization or tenant | The root: the platform's or your organization's. There is no tenant tier |
Category and type
What it does
The category of a shipped pattern-based policy is more than a label. It is what a category-wide override your organization records reaches (for example, every pii-global policy to redact), and together with severity it selects how a redaction masks the matched text (see the severity table).
The categories are listed in Policy Syntax. The v10.x tenant-policy type (content, risk, rate-limit and so on) selected an evaluator in the tenant-policy engine, which authors no verdict in v11; see Access-control policy types for what each one becomes.
Severity
severity is one of low, medium, high, or critical, and the shipped pattern-based policies carry it.
What it does
Severity never blocks a request on its own. The action is what blocks, redacts, warns, or logs. Severity influences:
- Redaction depth. When a policy redacts, severity (together with category) selects how aggressively the matched text is masked. See the severity-to-redaction-depth table.
- Risk classification. When a match escalates to a human-in-the-loop approval, severity maps to an EU AI Act risk label:
criticalandhighmap to high-risk,mediumto limited-risk, andlowto minimal-risk.
In v10.x severity had a third effect: a system policy with no action stored for the phase being evaluated fell back to a category default, and a critical security policy fell back to block. That fallback no longer runs. The shipped policies were compiled into v11 with the action v10.x actually resolved on each plane, fallback included, so the action is fixed and visible in Shipped Policy Posture rather than derived at runtime.
Severity is not a restrictiveness ranking. A
low-severity policy whose action isblockblocks; acritical-severity policy whose action islogonly logs. Set the action to the behavior you want, and read severity as masking depth and risk labeling.
Severity to redaction depth
When a pattern-based policy's action is redact, the masking strategy is chosen from the policy's category and severity. The strategies are:
- Mask -- full masking: the value is replaced with asterisks, keeping only the first and last character as anchors (values of four characters or fewer are fully masked).
- Partial -- light masking: the first two and last two characters stay visible.
- Remove -- the match is replaced entirely with a
[REDACTED:<type>]token.
| Category | Severity | Strategy | What the reader sees |
|---|---|---|---|
| Any PII category | critical | Mask (full) | j••••••••e |
pii-global | high | Mask (full) | j••••••••e |
pii-global | medium or low | Partial | jo••••le |
pii-us, pii-india, pii-eu, pii-singapore | any | Mask (full) | j••••••••e |
| Any other category | non-critical | Remove | [REDACTED:email] |
Two consequences worth knowing:
- For region-specific PII (
pii-us,pii-india,pii-eu,pii-singapore), masking is full regardless of severity. - A non-critical
pii-indonesiapolicy is not in the full-mask set, so it uses Remove like other non-PII-region categories.
Priority
What it did in v10.x
priority was an integer, and policies were evaluated highest-priority-first. It decided the order in which redactions were collected and which of two overlapping overrides was considered first. It never decided a block-versus-warn contest: the most restrictive action won regardless.
In v11
There is no priority. The engine does not walk policies in order and stop at a match: it reads every policy that applies to the request and combines them by kind. A matching ceiling denies, whatever else matched. Every matching requirement contributes its safeguard, and safeguards of one kind compose by a defined rule: redactions toward less disclosure, audit and notification records combined. The result does not depend on the order policies were written or activated. See Policy Hierarchy → How policies combine.
If you used priority to make one redaction apply before another, write the redaction you want as one requirement; two redactions of the same content compose to the stricter of the two.
Phase
In v10.x phase (request, response or both) controlled whether a system policy inspected the inbound request, the outbound response, or both, and action_request / action_response could give one policy a different action on each side.
In v11 a shipped policy binds to planes, and a plane evaluates a request, a response, or both. Where v10.x enforced a different action on different planes (a PII policy that warned on requests and redacted responses, for example), the policy ships with one action per plane group and each plane keeps the action it enforced. Shipped Policy Posture lists the planes for each action.
Actions
For a shipped policy, the action is one of block, redact, warn, or log, and your organization can give it any of them, or disable it. A change can make a shipped policy more lenient as well as stricter.
For a policy you write, the action is its authority and obligations: a ceiling denies; a requirement attaches a redaction, a notification, an audit record or an approval. See Policy Syntax → How a shipped action maps to a policy.
When to change it
- Leave a shipped policy at
warnorlog, watch what it records on your traffic, then make itredactorblockonce you trust it. This is the safest rollout path. - Use an approval requirement instead of a ceiling when a human should make the final call.
- Use
redactwhen the request should proceed with sensitive content masked rather than rejected.
Conditions and operators
In v10.x a tenant policy matched on an array of { field, operator, value } conditions, evaluated by the tenant-policy engine. In v11 a policy you write carries a where clause: a typed condition over request arguments, identity attributes and detector findings, whose paths the deployment's vocabulary declares. A path the vocabulary does not declare is refused when you validate, rather than silently never matching.
Risk thresholds are conditions, not a field
There is no settable risk-threshold parameter. To gate on risk, write a condition against the computed risk score, as the shipped anomalous-access policy does:
{ "kind": "compare", "path": "signal.risk_score", "op": "gt", "literal": 0.8 }
The risk score is a value from 0.0 to 1.0 computed before the decision. Reading it, like any signal.* fact, needs Evaluation or Enterprise.
Enabled and tier
Enabled
For a shipped policy, enabled is now a per-organization switch: disable a policy for your organization while you tune it, rather than working around it with another rule. Your own policies are in force when the document that holds them is the active one.
Tier
v10.x had three tiers (system, organization and tenant). v11 has two roots: the platform's, for the policies AxonFlow ships, and your organization's, for the organization-editable shipped policies and everything you write. A rule that used to be a tenant policy is a policy on your organization's document scoped to that team's group. See Policy Hierarchy.
Access-control policy types
v10.x shipped four tenant-policy types for governing MCP tool and connector access: rate-limit, budget, time-access and role-access. Each was evaluated by the tenant-policy engine, which authors no verdict in v11, so a v10.x policy of one of these types no longer decides anything.
| v10.x type | What it did | In v11 |
|---|---|---|
role-access | Allowed or denied a connector or tool by role | A ceiling on your organization's document, scoped to the whole organization with an Except when clause naming the groups that may use it |
budget | Capped spend over a rolling period | The budget system in Cost Management and the Cost Controls API, which holds organization, team, agent, workflow and user caps |
rate-limit | Capped requests per window | Not a policy in v11. |
time-access | Restricted access to business hours | Not a policy in v11. |
Related
- Policy Syntax -- the parts of a v11 policy, and the shipped categories, actions and patterns
- Shipped Policy Posture -- every shipped policy's action on each plane
- Policy Hierarchy -- how the platform's policies and your organization's combine
- Cost Management -- the LLM budget and spend-control system
- Governance Overview -- where policy enforcement fits in the wider governance layer
