Skip to main content

Policy-as-Code

AxonFlow provides a policy-as-code system for AI governance. Policies are evaluated in real time to protect against security threats, support compliance, and enforce business rules.

Concept page. A policy is a server-side rule that inspects requests and responses and decides whether to allow, block, redact, warn on, or hold them for approval. This page explains the model. The start-here path below takes you from that model to a tuned, tested policy. You do not send policy definitions with your requests; the server evaluates them for you.

Start here​

  1. Understand the model (this page): the shipped policies, your organization's policies, and the actions.
  2. Why governance is not the same as authentication: OAuth vs Governance.
  3. Where a rule belongs: Policy Hierarchy (the platform's root and your organization's).
  4. See what ships, and what each shipped policy does: Shipped Policy Posture, with the detection patterns in System Policies.
  5. Write policies of your own: Typed Policy Authoring, with the document shape in Policy Syntax.
  6. Test before you enforce, then copy a template: Policy Testing and Examples.

How policy works in v11​

One policy decision engine decides every governed request, on every enforcement plane, for every organization and edition. It reads two sets of policies on each request:

┌─────────────────────────────────────────────────────────────┐
│                     PLATFORM POLICIES                        │
│     Shipped by AxonFlow, enabled from the first boot         │
│   Your organization switches each one and sets its action    │
├─────────────────────────────────────────────────────────────┤
│                   YOUR ORGANIZATION'S POLICIES               │
│   The organization-editable policies AxonFlow ships, plus    │
│   the grants, ceilings and requirements you write            │
└─────────────────────────────────────────────────────────────┘
SetWhat it isWhat you can change
Platform policiesThe policies AxonFlow ships on its own policy rootDisable, re-enable, or change the action of each one, for your organization
Your organization's policiesThe organization-editable policies AxonFlow ships, and everything you author, in your organization's typed policy documentEverything, through the document

An organization that has published nothing is governed from the first request: it runs the shipped set. You write a document when you want policies of your own.

The shipped policy set​

AxonFlow ships:

  • 85 platform policies: 70 pattern-based policies (SQL injection, prompt injection, PII by country, secrets and credentials, administrative-table access) and 15 condition-based policies (risk, compliance, cost, access and media governance);
  • 22 organization-editable policies, which v10.x shipped as tenant policies: the dangerous-command blocks, the DROP TABLE and TRUNCATE guards, and a few PII and EU AI Act rules;
  • 9 detectors that ship disabled.

Their actions observe rather than intervene by default: most policies warn or log, a few redact content that is unambiguously sensitive, and a short list of destructive patterns blocks. Shipped Policy Posture lists every one, with its action on each plane.

Policy Actions​

ActionDescriptionEffect
blockRefuse the requestRequest rejected
redactMask sensitive contentContent masked before it is used or returned
warnRecord the match and raise a notificationContinues
logRecord the match on the audit trailContinues

These are the actions a shipped policy takes and the ones your organization can give it. On Enterprise, a policy you write can also attach a human approval as a requirement, which holds the request for a person.

EU AI Act Compliance

Human approval enables the Human-in-the-Loop (HITL) workflows required by EU AI Act Article 14 for high-risk AI decisions.

How a Request Is Decided​

Request → Authentication and identity admission
        → Policy decision engine (platform policies + your organization's policies,
          restricted to what this plane can evaluate)
        → Allow (with any safeguards), deny, or hold for approval

A matching ceiling denies; otherwise the request proceeds with every safeguard the matching requirements attach. There is no priority order and no "first match wins": see Policy Hierarchy.

Quick Start​

See what governs your organization​

# The platform policies, read-only: 116 compiled from the 85 shipped rows
curl -s http://localhost:8080/api/v1/typed-policies/system \
  -H "Authorization: Basic $(echo -n 'my-tenant:your-client-secret' | base64)"

# Your organization's active document, if it has published one
curl -s http://localhost:8080/api/v1/typed-policies/active \
  -H "Authorization: Basic $(echo -n 'my-tenant:your-client-secret' | base64)"

Write a policy of your own​

Validate a document, publish it with its test cases, then activate it by digest:

curl -s -X POST http://localhost:8080/api/v1/typed-policies/validate \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'my-tenant:your-client-secret' | base64)" \
  --data @my-policy.json

Typed Policy Authoring walks through the whole lifecycle, and Policy Syntax shows the document shape.

See a decision​

Every governed request returns its verdict and the policies that matched, and records which engine and which policy bundle decided. Decision Mode shows an allow and a deny on POST /api/v1/decide.

Policies are Server-Side

All policies are defined and evaluated on the AxonFlow server. You do not send policy definitions with your requests. The server evaluates the shipped policies and your organization's policies against every request.

Mode Support​

FeatureProxy ModeGateway ModeDecision ModeMCP governance
Decided by the v11 policy engine✅✅✅✅
Shipped policies✅✅✅✅
Your organization's policies✅✅✅✅

Every mode is decided by the same engine and the same policies. What differs by plane is which policies can apply: a plane runs the ones it can evaluate, so a request-only plane does not run response-phase policies.

Workflow Policy Enforcement​

The same engine decides workflow orchestration:

  • Multi-Agent Planning (MAP): a plan is decided before it executes, and a denied plan is not run.
  • Workflow Control Plane (WCP): each step gate an external orchestrator (LangChain, LangGraph, CrewAI) calls is decided by the engine, and answers allow, block, or require approval.

See WCP Policy Configuration for the step gate context a workflow policy can use, and Workflow Control Plane for full documentation.

Documentation​

GuideDescription
Policy HierarchyThe platform's policy root and your organization's
Shipped Policy PostureEvery shipped policy and its action
System PoliciesThe detection patterns behind the platform policies
Typed Policy AuthoringWriting, publishing and activating your organization's policies
Policy SyntaxThe typed document shape
ExamplesReady-to-use policy templates
TestingTest and validate policies

Community vs Enterprise​

FeatureCommunityEnterprise
Shipped policy set, enabled from the first boot✅✅
Per-policy control of the shipped policies✅✅
Your own typed policies through /api/v1/typed-policies✅ Up to 20✅ Unlimited
Portal Policy Authoring editor❌✅
Separation of duties on activation❌✅
HITL approval queue (human approval gates)❌✅
Customer Portal UI❌✅
Enterprise Policy Features

Enterprise adds the portal Policy Authoring editor, separation of duties so a policy's author cannot put it in force, and HITL approval gates for high-risk decisions. Compare Editions | Contact Sales | AWS Marketplace

See Enterprise Policy Management for details.

Rollout Checklist​

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

Last updated on