Skip to main content

Policy Hierarchy

Concept page. This explains where a policy lives and how policies that both apply to a request combine. For every policy AxonFlow ships see Shipped Policy Posture; for writing your own see Typed Policy Authoring.

Policy roots are not license tiers

This page explains where a policy lives: on the platform's root or on your organization's. License tiers such as Community, Evaluation, Plugin Pro, and Enterprise decide which authoring surfaces and limits are available in a deployment. For edition limits, see Community vs Evaluation vs Enterprise and Plugin Pro.

Two roots​

In v11 every policy lives on one of two roots, and one decision engine reads both on every request:

┌────────────────────────────────────────────────────────────────────┐
│                          PLATFORM ROOT                             │
│  • The platform policies AxonFlow ships                            │
│  • Signed by the platform; nobody edits them                       │
│  • Your organization can disable, re-enable or re-action each one  │
├────────────────────────────────────────────────────────────────────┤
│                        ORGANIZATION ROOT                           │
│  • Your organization's typed policy document                       │
│  • Starts from the organization-editable policies AxonFlow ships   │
│  • Grants, ceilings, requirements and inspections you write        │
│  • Scoped to your whole organization, or to named groups           │
└────────────────────────────────────────────────────────────────────┘
RootWhat lives thereWho changes it
PlatformThe 85 platform policies: 70 pattern-based and 15 condition-basedNobody edits them. Your organization switches each one on or off and chooses its action, for itself only
OrganizationThe 22 organization-editable policies AxonFlow ships, plus every policy your organization writesYour organization, through its typed policy document

The v10.x model had three tiers: system, organization and tenant. There is no tenant tier in v11. A rule that used to belong to one team is a policy on your organization's document scoped to that team's group. Group scope is an Enterprise construct; on Community and Evaluation a policy applies to the whole organization.

A document your organization activates replaces the 22 organization-editable policies with its own content, so carry the ones you want to keep; the publish response lists any your document drops. A document can carry them on every edition, Community included, because they count as the deployment's policies rather than ones your organization wrote.

How policies combine​

The engine does not sort policies and take the first match. It reads every policy that applies and combines them by what each kind of policy is allowed to do:

  1. A ceiling that matches denies. An explicit constraint wins over every grant, on either root. A platform policy whose action is block is a constraint.
  2. A grant is what allows. No matching grant means deny. The shipped set comes with the deployment's baseline permissions, one grant per registered action, so a request is allowed unless something denies it. The baseline permissions compose beside a document your organization activates too, so the document narrows them with ceilings and never has to re-declare them.
  3. Requirements attach safeguards. Every matching requirement contributes its obligation: redactions compose toward less disclosure, audit and notification records are combined, and an approval requirement holds the request for a person. A platform policy whose action is redact, warn or log is a requirement.
  4. Unknown is not a match. If a fact a policy needs could not be established, the policy is not treated as if it did not apply: the request is not executed.

There is no ranking such as "block beats redact beats warn" across roots, and no priority number: a constraint wins, and every other safeguard composes by its own rule. See Mandatory safeguards compose predictably.

Changing a platform policy for your organization​

Your organization cannot edit a platform policy, but it controls how each one behaves for itself: disable it, re-enable it, or give it a different action (log, warn, redact or block). The change applies to your organization only. A detection-posture override recorded for your organization re-actions the platform's policies in a whole category at once (for example, every platform PII policy to redact); it does not reach the organization-editable policies, which your organization changes in its own typed policy document.

A change can make a policy weaker as well as stronger. v10.x allowed an override only to tighten a system policy; v11 treats the shipped actions as a default your organization owns, not a floor.

Product-tier availability​

Policy surfaceCommunityEvaluationEnterprise
Shipped policies, enabled from the first bootIncludedIncludedIncluded
Per-policy control of the shipped policiesIncludedIncludedIncluded
Your own typed policies, through /api/v1/typed-policiesUp to 20Up to 50Unlimited
Group scope and human approval requirementsNoNoYes
Conditions on detector findings and the risk score (signal.*)NoYesYes
The portal's Policy Authoring editorNoNoYes
Separation of duties on activationNoNoYes
Policy simulationNoLimitedYes
Evidence exportNoLimitedYes

GET /api/v1/typed-policies/edition reports what your edition may write. If you are validating organization-wide policy design before procurement, use the free 90-day Evaluation License. If one sponsored workflow needs Enterprise controls and founder-led support to reach a production decision, use the paid Production Program.

The platform root​

The platform policies provide security and compliance coverage from the first boot. They are signed by the platform and anchored to the binary that ships them, so a deployment verifies it is running the set AxonFlow shipped. Each plane runs the subset it can evaluate: a plane that never sees a response does not run response-phase policies.

The full list, with each policy's action on each plane, is Shipped Policy Posture. The detection patterns behind the pattern-based policies are documented in System Policies.

To read them from a deployment; the endpoint serves the 116 policies compiled from the 85 shipped rows, because a row whose action differs by plane ships as one policy per action: 

curl -s "http://localhost:8080/api/v1/typed-policies/system" \
  -H "Authorization: Basic $(echo -n 'CLIENT_ID:CLIENT_SECRET' | base64)"

The organization root​

Your organization's typed policy document is where everything your organization decides lives:

  • the organization-editable policies AxonFlow ships - the dangerous-command blocks, the DROP TABLE and TRUNCATE guards, and a few PII and EU AI Act rules - which v10.x shipped as tenant policies and which remain yours to change;
  • grants and ceilings you write, scoped to the whole organization or to named groups;
  • requirements such as a redaction or an approval.

An organization with no document of its own runs the shipped set, the platform's policies and the organization-editable ones, from the first boot. See Typed Policy Authoring for writing, publishing and activating a document.

Best Practices​

1. Start from the shipped posture​

The shipped policies observe rather than intervene by default: most warn or log, a few redact and a short list blocks. Read Shipped Policy Posture before you change anything, and watch what the warn and log policies record on your traffic before you make one of them block.

2. Tune a shipped policy before you write a new one​

If a platform policy is too strict or too loose for your organization, change its action or disable it. A second policy written to work around a shipped one is harder to reason about than a shipped policy with the action you want.

3. Scope with groups, not copies​

A rule that applies to one team is one policy scoped to that team's group, not a copy of the organization rule edited for that team. Group scope is Enterprise; on Community and Evaluation, write the rule for the whole organization.

4. Test before you activate​

Publication runs the test cases you declare, and activation builds the engine before the document goes live. Use policy simulation against real inputs before you activate a ceiling.

5. Give every change a reason​

Activations and rollbacks record who made them and why. A reason that says what changed and why is what makes the history useful in an audit.

Worked examples​

These examples show how the two roots combine in practice. The shipped actions quoted are from Shipped Policy Posture.

Example 1: Banking - PAN numbers​

A bank's fraud investigators must be able to search by PAN, but no line of business should see a PAN in a response.

Platform root:     sys_pii_pan ships warn on request planes and redact on
                   response planes.

Organization root: a ceiling denies requests carrying a PAN, except when the
                   caller is in the fraud-investigation group.

Result:
  - Fraud investigators: a query by PAN is allowed and recorded, and the PAN
    is masked in what comes back.
  - Every other group: a request carrying a PAN is refused.
  - A new line of business is covered by the ceiling from its first request.

This example needs Enterprise for the group, and Evaluation or Enterprise for the condition on a detector finding (signal.*).

Example 2: Healthcare - PHI​

A healthcare platform must keep patient identifiers out of model output, and its research group must not send them at all.

Platform root:     the SSN and date-of-birth policies ship redact on response
                   planes, so identifiers in output are masked for everyone.

Organization root: a ceiling denies requests carrying an SSN for the research
                   group.

Result:
  - Clinical teams: identifiers in responses are masked.
  - Research group: a request carrying an SSN is refused.
  - A ceiling wins over everything else that matches, so nothing in the
    research group's own policies can re-open it.

Example 3: Spend caps​

Per-team spend caps are not a policy's job in v11. Use the budget system documented in Cost Management, which holds organization, team, agent, workflow and user caps and checks them atomically.

Rollout Checklist​

Use this page as one layer of the broader governance rollout:

Last updated on