Enterprise Policy Management

Every AxonFlow edition runs the shipped policy set from the first boot, lets an organization control each shipped policy, and lets it author policies of its own. Enterprise policy management adds what larger organizations need to operate that across many teams: a portal editor, separation of duties on every activation, and the review and rollback surfaces that make policy change auditable.

This page explains the public-facing value proposition and the enterprise operating model. Customer-specific portal screenshots, environment setup, and private rollout details belong in protected partner packs.

The model on this page is the v11 policy decision and identity control plane: one decision engine on every enforcement plane. For what decides a request and what each decision records, see Policy and Identity Control Plane.

The Public Baseline

Every edition, Community included, gets:

• the shipped policy set, enabled from the first boot, listed in Shipped Policy Posture;
• per-policy control of each shipped policy for the organization: disable, re-enable, change its action;
• policies of its own, as a typed policy document through /api/v1/typed-policies.

That is enough for many single-team or early production use cases.

What Enterprise Adds

Enterprise policy management becomes important when governance is no longer one team's concern and has to scale across business units, teams, or regulated operating models.

The biggest additions are:

• the portal's Policy Authoring editor, so governance teams review and change policy without scripts;
• separation of duties: a version is activated by one of its recorded approvers, never by its author, unless the organization has enabled self-approval;
• the published-version history, each version's signed source, and rollback by digest in the portal;
• a stronger operating model for policy review, rollout, and cross-team governance.

Enterprise Policy Model

Policy lives on two roots, and one engine reads both on every request:

Root	What it is for	Who changes it
Platform	The platform policies AxonFlow ships	Nobody edits them; each organization chooses each one's state and action for itself
Organization	Company-wide governance: the organization-editable shipped policies, plus the grants, ceilings and requirements your organization writes, scoped to the whole organization or to named groups	Your organization, through its typed policy document

The shipped set is 85 platform policies (70 pattern-based, 15 condition-based) and 22 organization-editable policies; Shipped Policy Posture lists each one. Policy Hierarchy explains how the two roots combine.

Typed Policy Documents and the Active Document

An organization authors one versioned typed policy document. Publishing a version validates, compiles, tests and signs it, and puts nothing in force. A version is in force once it is activated, by its digest: on Enterprise, by one of the version's recorded approvers and never by its author unless the organization has enabled self-approval; on Community and Evaluation, where separation of duties does not apply, the author can activate their own version. The most recent activation is the organization's active document, and a rollback makes an earlier activated version active again.

The active document is what the policy decision engine enforces for the organization, on every enforcement plane, together with the platform's shipped policies. An organization with no active document is decided under the shipped set.

Enterprise Operating Surfaces

The concrete request and response shapes are documented here:

• Typed Policy Authoring for /api/v1/typed-policies: the vocabulary, validation, publication, activation and the active document
• Shipped Policy Posture for what the platform enforces before you write anything
• Detection posture for category-wide action overrides recorded for an organization
• Overrides API: the legacy per-policy override routes, which the v11 engine does not read, and the v10.x session overrides, which do not silence it
• Policy Simulation for simulation and impact-report workflows
• Evidence Export for audit packs after rollout

Enterprise customers also get portal workflows around those surfaces, so governance teams can inspect, stage, and review policy changes without relying on scattered scripts.

How the Operating Model Changes

The biggest difference is not just “more policies.” It is that policy management becomes a shared platform capability instead of an app-team-only concern.

Stage	Typical owner	What breaks down
Early trial	one engineering team	the shipped posture and the API are usually enough
Multi-team rollout	platform or shared AI team	policies need consistency across apps
Broader enterprise use	engineering + governance + security	policy review and activation need separate owners

Enterprise policy management exists for that third stage, where governance is no longer just a code problem.

Why This Matters

The technical problem changes as adoption grows.

Early on, the question is usually:

• can we govern our requests and workflows at all?

Later, the question becomes:

• can we operate governance consistently across the company without every team inventing its own policy process?

That is the gap enterprise policy management is meant to close.

What Engineers Usually Want to Know

Senior engineers reviewing this page are usually asking:

• can we start with the shipped posture and the API?
• what becomes operationally difficult as more teams adopt the platform?
• when do separation of duties and portal review surfaces start to matter?

The answer is that every edition is a good starting point for a single-team rollout, while Enterprise policy management becomes more valuable as governance ownership broadens and consistency across teams becomes part of the success criteria.

Typical Signals That a Team Has Outgrown the Public Baseline

• multiple teams need consistent governance standards
• approvals and audit reviews involve non-engineering stakeholders
• policy ownership is moving from one app team to a platform or governance function
• rollout decisions need a clearer operational surface than raw APIs alone
• the person who writes a policy change and the person who puts it in force need to be different people

Recommended Operating Pattern

Start from the shipped posture

Read Shipped Policy Posture before changing anything. The shipped actions observe rather than intervene: most policies warn or log, a few redact, and a short list blocks. Watch what they record on your traffic before you tighten any of them.

Tune shipped policies per organization

If a shipped policy is wrong for your organization, change its action or disable it. That is the product's core control surface, and it is cheaper to reason about than a second policy written to work around the first.

Use your organization's document for shared standards

Company-wide privacy rules, shared security controls, and vertical or regulator-specific baselines belong in your organization's document, where they are versioned, signed and reviewed.

Use groups for local behavior

A rule for one product line, business unit, region, or specialized workflow is a policy on the same document scoped to that group. Group scope is an Enterprise construct.

Roll out safely

A strong policy rollout usually follows this path:

1. read the shipped posture and the active document
2. write the change and validate it
3. declare test cases and simulate impact against real inputs
4. publish, and have an approver activate it
5. watch the decision record, and roll back by digest if something is wrong
6. export evidence later if risk, security, or audit asks for it

Not every risky event should be blocked. Enterprise policy management becomes most valuable when it is paired with approval workflows, audit evidence, and clear ownership.

Governance Setup Workflow

Enterprise policy management is most useful when teams treat governance as an operating model, not only as policy authoring.

The enterprise governance story is best understood as:

• one policy decision engine on every enforcement plane
• a typed policy document per organization, beside the platform's shipped policies
• a portal-backed control surface for authoring, review, activation and rollback

The Enterprise Policy Surface

Typed policy authoring (every edition)

• GET /api/v1/typed-policies/edition
• POST /api/v1/typed-policies/validate
• POST /api/v1/typed-policies/publish
• POST /api/v1/typed-policies/activate
• GET /api/v1/typed-policies/active
• GET /api/v1/typed-policies/system

Community and Evaluation run the whole lifecycle on these routes. On Enterprise they validate and read, but a publication must name approvers other than its author and these routes name none, so an Enterprise organization publishes in the portal.

Portal review surfaces (Enterprise)

• POST /api/v1/typed-policies/diff: compare a draft with the version in force
• GET /api/v1/typed-policies/artifacts: published versions and the activation history
• GET /api/v1/typed-policies/artifacts/{digest}/source: the exact signed source of a version
• POST /api/v1/typed-policies/rollback: activate an earlier digest, with a reason

The v10.x policy APIs

The v10.x system-policy, tenant-policy and unified-policy families are closed to writes in v11: a create, update, delete or import answers 409 LEGACY_POLICY_WRITE_FROZEN and names /api/v1/typed-policies. Their reads remain for exporting what you had before you re-author it, and are removed in a later release. The portal's v10.x Policies page is removed; the Policy Authoring page replaces it.

What Governance Setup Actually Means

For most enterprise teams, governance setup is not “write one giant policy file and walk away.”

It usually means:

1. decide who owns governance in the organization, and who approves activations
2. understand which behavior comes from the shipped posture and which from your own document
3. establish a testing and review workflow
4. connect governance to connector, provider, and workflow rollout decisions

A Practical Governance Operating Model

Enterprise governance setup works best when three groups know their role:

• platform owners define the operating model and runtime boundaries
• security or governance reviewers validate risk posture, approve activations, and set oversight expectations
• application teams adapt their workflows to those constraints instead of bypassing them

That operating model is much more realistic than a page that treats governance as only a policy-authoring exercise.

Recommended Setup Sequence

1. Start with visibility

Before writing anything, review:

• the shipped posture
• your organization's active document, if it has one
• the deployment's vocabulary (GET /api/v1/typed-policies/edition)

That helps platform teams understand the current state instead of layering changes blindly.

2. Establish edit and review ownership

Governance setup works best when there is clear ownership for:

• who writes and publishes policy versions
• who approves and activates them
• who changes a shipped policy's state or action for the organization
• who watches the effect in runtime behavior

3. Use testing and versions deliberately

Every published version carries the test cases it passed, a signed source, and a digest, and every activation records who made it and why. Use them:

• test cases at publication
• simulation before activation
• the activation history and rollback by digest

as part of the governance workflow instead of relying on undocumented manual changes.

What Good Governance Setup Looks Like

In a mature enterprise rollout, governance setup usually includes:

• a clear policy ownership model, with authors and approvers who are different people
• a repeatable test-before-activate workflow
• a known digest to roll back to
• a path for handling exceptions and overrides without losing auditability

That is especially important for organizations building sophisticated multi-agent or multi-connector systems, because governance failures at that stage become platform problems, not just application bugs.

4. Tie governance to runtime configuration

Enterprise governance is not isolated from the rest of the platform.

Whenever teams introduce:

• a new connector
• a new provider
• a new workflow pattern
• a new approval path

they should review whether governance changes are also needed.

Common Enterprise Governance Patterns

Examples of where enterprise governance setup is especially valuable:

• restricting which groups can use specific connectors
• separating higher-trust provider or workflow paths from day-to-day experimentation
• reviewing changes to shipped-policy actions before larger rollout
• aligning approvals, overrides, and evidence expectations to internal security processes

These patterns are part of why enterprise governance is a real enterprise feature rather than simply a bigger policy UI.

Recommended Review Checklist

Before calling governance setup production-ready, verify:

• policy authors and activation approvers are defined, and are different people
• test cases are part of every publication
• the team knows which digest it would roll back to
• the shipped posture has been reviewed against your traffic
• per-policy changes to shipped policies are reviewed, not ad hoc
• connector and provider rollout procedures include governance review

What Not to Assume

Avoid these incorrect mental models:

• that publishing a version puts it in force: activation does
• that the shipped actions are a ceiling you have to work around: they are a default your organization controls
• that enterprise governance is only for compliance teams and not for platform teams

Governance and Enterprise Adoption

This part of the product becomes especially important when a company moves from:

• one or two engineering experiments

to:

• multi-team use
• shared connectors and providers
• more formal oversight
• stronger security and audit expectations

That is exactly where enterprise governance setup becomes a real platform need instead of optional polish.

Related Docs

• Policies Overview
• Shipped Policy Posture
• Typed Policy Authoring
• Policy Hierarchy
• Policy Simulation
• Evidence Export
• Customer Portal
• Community vs Evaluation vs Enterprise