Skip to main content

Policy Syntax

In v11 a policy is an entry in a typed policy document: your organization's document for the policies you write, and the platform's own for the policies AxonFlow ships. This page documents the shape of one policy, then the categories, actions, severities and pattern syntax behind the shipped policies. For the lifecycle around a document (validate, publish, activate), see Typed Policy Authoring.

Policy Structure​

Every policy, shipped or yours, has the same parts. This is one of the condition-based policies AxonFlow ships, as the platform stores it (bookkeeping fields omitted):

{
  "id": "corpus:dynamic_policies:sys__dyn__anomalous__access",
  "authority": "requirement",
  "root": "system",
  "scope": { "organization": true },
  "actions": { "any": true },
  "where": {
    "kind": "and",
    "operands": [
      { "kind": "compare", "path": "signal.risk_score", "op": "gt", "literal": 0.6 },
      { "kind": "compare", "path": "args.context.user_2e_access__pattern", "op": "eq", "literal": "anomalous" }
    ]
  },
  "obligations": [
    { "type": "notification", "params": { "kind": "alert", "severity": "warning" }, "mandatory": false }
  ],
  "assurance": "advisory"
}
PartWhat it says
idThe policy's identifier. It is what a decision's evaluated_policies names when the policy matches
authorityWhat the policy may do: permission (a grant), constraint (a ceiling), requirement (a mandatory safeguard) or inspection
rootWhose policy it is: system for the platform's, organization for your organization's
scopeWhich principals it applies to: the whole organization, or named groups
actionsWhich registered actions it reaches, or any action
whereThe condition, over request arguments, identity attributes and detector findings. Paths are typed by the deployment's vocabulary, and a path the vocabulary does not declare is refused at validation
obligationsFor a requirement, the safeguards it attaches: a redaction, a notification, an audit record, an approval
assuranceHow a failure to evaluate the policy is treated: enforcement and gating_risk controls fail closed, an advisory one does not

GET /api/v1/typed-policies/edition reports the vocabulary your deployment validates against, and the validator returns every finding with a code and the value that caused it.

How a shipped action maps to a policy​

A shipped policy's action is its authority and obligations, and changing the action for your organization changes which of these it carries:

ActionAuthorityObligation
blockconstraintnone: a matching constraint denies
redactrequirementa mandatory redaction of the matched content
warnrequirementa notification
logrequirementan audit record

Categories​

The shipped pattern-based policies are classified by category, and the category is what Shipped Policy Posture groups them by. A category-wide override your organization records (for example, every platform PII policy to redact) re-actions the platform's policies in that category; it does not reach the 22 organization-editable policies, which your organization changes in its own typed policy document.

CategoryDescriptionExample Use Case
security-sqliSQL injection detectionUNION SELECT, stacked queries, blind injection
security-adminAdmin access controlUsers table access, audit log access
security-dangerousDangerous-instruction patternsIndirect prompt injection: template markers, instruction-override and role-reassignment phrases, system-prompt exfiltration; and the organization-editable dangerous-command blocks
pii-globalUniversal PII detectionEmail, phone, credit card, passport
pii-usUS-specific PIISSN, bank account numbers
pii-euEU-specific PIIIBAN
pii-indiaIndia-specific PIIPAN, Aadhaar (DPDP Act 2023)
pii-singaporeSingapore-specific PIINRIC, FIN, UEN
pii-indonesiaIndonesia-specific PIINIK, NPWP, +62 phone numbers, bank account numbers
code-secretsSecret/credential patternsAWS keys, API tokens, private keys
code-unsafeUnsafe code patternseval(), exec(), shell injection
code-complianceCode compliance patternsLicense violations, deprecated APIs
sensitive-dataCredentials and secrets in user queriesPasswords, API keys, tokens, connection strings

Actions​

The action decides what happens when a shipped policy matches:

ActionDescriptionEffect on Request
blockRefuse the requestRequest returns an error naming the policy
redactMask sensitive contentRequest proceeds with the matched content masked
warnRecord the match and raise a notificationRequest proceeds
logRecord the match on the audit trailRequest proceeds

Your organization can give any shipped policy any of these four actions, or disable it. On Enterprise, a policy you write can additionally require a human approval, as a requirement. Approval requirements are an Enterprise construct.

Action Hierarchy​

There is no single restrictiveness ranking that decides between two matching policies. The engine combines them by kind: a matching constraint (block) denies whatever else matched; redactions compose toward less disclosure; notifications and audit records are combined. See Policy Hierarchy → How policies combine.

Nor is there a rule that a change may only tighten a shipped policy. v10.x let an override only make a system policy more restrictive (block > require_approval > redact > warn > log); in v11 your organization can make a shipped policy stricter or more lenient, because the shipped action is a default your organization owns.

Severities​

The shipped pattern-based policies carry a severity:

SeverityDescriptionTypical Use
criticalHighest severity, immediate attention requiredSQL injection, credit card exposure, SSN detection
highImportant security or compliance issueAdmin access patterns, sensitive table access
mediumModerate concern, should be reviewedEmail detection, IP address exposure
lowInformational, for audit purposesBooking references, general logging

Severity is not the same as restrictiveness, and it does not block on its own: the action does. For what severity changes, see Policy Parameters Explained → Severity.

Pattern Syntax​

The shipped pattern-based policies match Go-compatible regular expressions (RE2 syntax) against request and response text. The detector runs the pattern, and the policy's condition reads the detector's finding: the organization-editable shipped policies, for example, match on signal.detector.<policy> rather than restating the pattern. A policy you write reads findings, arguments and identity attributes the same way, through the vocabulary.

Pattern Examples​

PatternDescriptionMatches
(?i)union\s+selectCase-insensitive UNION SELECTUNION SELECT, union select
\b\d{3}-\d{2}-\d{4}\bSSN with dashes123-45-6789
\b[A-Z]{3}[PCHABGJLFT][A-Z]\d{4}[A-Z]\bIndian PANABCPD1234E
(?i)\b(drop|truncate)\s+table\bDestructive SQLDROP TABLE, truncate table

Pattern Tips​

  • Use (?i) at the start for case-insensitive matching
  • Use \b for word boundaries to reduce false positives
  • Use non-capturing groups (?:...) when you don't need capture groups
  • Avoid catastrophic backtracking (nested quantifiers like (a+)+)

Combination Order​

There is no evaluation order to reason about. On every request the engine reads the platform's policies and your organization's together, restricted to what the plane can evaluate, and combines them by kind:

Request → identity admission
        → platform policies + your organization's policies
          (restricted to this plane)
        → a matching ceiling denies; otherwise allow, with every
          safeguard the matching requirements attach

Creating Policies​

Write a policy into your organization's document, then validate, publish and activate it:

curl -X POST http://localhost:8080/api/v1/typed-policies/publish \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'CLIENT_ID:CLIENT_SECRET' | base64)" \
  --data @my-document.json

The response carries the version's digest, which is what activation names. Typed Policy Authoring covers every step.

The v10.x way of creating a pattern policy, POST /api/v1/system-policies, answers 409 LEGACY_POLICY_WRITE_FROZEN in v11 and names /api/v1/typed-policies.

Testing Patterns​

In v11 a pattern is tested where it is published: publication runs the test cases your document declares against the bundle it just compiled, and policy simulation runs an input through the policies that govern your organization, with the engine that enforces.

The v10.x pattern-test route, POST /api/v1/system-policies/test, is removed in v11: it tested a pattern outside the engine that decides. See Policy Testing.

Best Practices​

  1. Start from the shipped posture -- read what ships before you write anything
  2. Use descriptive identifiers -- deny-pan-outside-fraud not policy-1
  3. Declare test cases -- publication runs them, and a document nobody tested has not been shown to do anything
  4. Start with warn/log -- give a shipped policy warn or log first, watch what it records, then make it block once you trust it
  5. One rule per policy -- simpler policies are easier to test, monitor, and disable independently
  6. Review regularly -- audit your document quarterly for relevance and false positive rates

Rollout Checklist​

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

Last updated on