Policy and Identity Control Plane: Target Architecture
This page describes the unified policy and identity architecture AxonFlow is building toward, published early so platform teams can plan integrations against the target contract.
Authorization in current releases is decided by the documented system-policy and tenant-policy model. For what governs your requests today, read Policy Overview, Architecture Overview and Runtime Request Paths.
The rollout is staged and observable rather than a flag day. From v10.2.0 the foundations on
this page ship in the platform, and the identity model can run in a record-only mode (the
AXONFLOW_IDENTITY_COMPAT_MODE switch documented in the v10.2.0 release notes) that records
what the new model would have decided while changing no authorization outcome. Each
enforcement path adopts this architecture only after it proves equivalence in shadow, as
described in Rollout without a flag day below. Until a path
cuts over, read this page as design direction, not as a description of what your deployment
enforces.
AxonFlow is building a unified policy and identity control plane for AI agents, tools, workflows, LLM gateways, and MCP connectors. It is designed to give every governed operation the same answer to four questions:
- Who or what is acting?
- What exact action and resource are involved?
- Is the action permitted in the current context?
- Which safeguards must be completed before execution?
Throughout this page, the present tense describes the designed behavior of that target architecture. Where a sentence says the control plane does something, read it as what the design specifies, not as what a v10.2.0 deployment performs.
The mental model
The control plane works like a security checkpoint immediately before an AI system reads data, calls a model, invokes a tool, or changes an external system.
The important point is that one policy language does not need to perform every job. The deterministic policy decision, content inspection, human approval, budget reservation, execution, and audit have different correctness requirements. AxonFlow coordinates them without collapsing them into one large, stateful rule engine.
One request model
Every authorization request is reduced to four parts:
| Part | Question | Example |
|---|---|---|
| Subject | Who is asking? | Sarah, acting through a finance agent and Jira connector |
| Action | What are they trying to do? | Update a Jira issue |
| Resource | What are they acting on? | FIN-17 in the Finance project |
| Context | Under what circumstances? | Corporate network, confidential attachment, current policy version |
This follows the Subject-Action-Resource-Context model used by OpenID AuthZEN and standard attribute-based access control. Request context is not a separate category of policy. Time, network, data classification, tool arguments, cost, agent depth, and risk signals are typed facts available to the same decision.
That gives an organization one decision meaning across gateways, MCP tools, workflows, connectors, and other enforcement points.
Identity means more than a token
An AI operation often involves several identities:
Sarah
-> Finance Assistant Agent
-> Jira Connector Workload
The control plane models this as an ordered actor chain. The first identity is the person or service on whose behalf access is requested. Each later identity is an intermediary that acted for the previous one.
Adding an intermediary can never increase authority. The effective authority is limited by every actor in the chain, which prevents a low-privilege user from inheriting the power of a high-privilege agent or connector.
Trust realms
A trust realm describes an organization-scoped identity authority such as Okta, Microsoft Entra ID, a workload identity system, or an AxonFlow-managed agent realm.
It defines more than an issuer URL. It also defines accepted audiences, credential and subject types, signing algorithms and keys, claim mappings, assurance levels, time limits, revocation, and directory capabilities.
A validly signed token from an undeclared or disabled realm is not enough to establish an identity.
Canonical identities
Users, agents, services, workloads, clients, and groups receive immutable, realm-qualified identifiers. An email address or display name remains an alias and is never the security identifier.
This prevents two identity providers from accidentally producing a user or group name that AxonFlow treats as the same authority.
Organization and application identity
The customer organization and the calling application remain separate concepts:
org_idis the hard customer isolation boundary.client_ididentifies the application or credential making the call.
An application identifier does not become a human identity and cannot choose the customer organization through policy input.
For today's authentication and provisioning surfaces, see Identity and Access Management and SCIM 2.0 Provisioning.
Four policy authorities
The architecture separates policies by what they are allowed to do.
Permission
A permission can open a door:
Finance members may update issues in the Finance project.
No matching permission means deny in steady state.
Constraint
A constraint can close or narrow a door, but cannot grant access:
Confidential customer data may leave only through an approved connector.
An explicit constraint denial wins over every permission. The product experience may call permissions "grants" and constraints "ceilings."
Requirement
A requirement attaches a mandatory safeguard to an otherwise permitted operation:
- redact selected fields;
- obtain human approval;
- require stronger authentication;
- use an approved route;
- reserve quota or budget;
- create enhanced audit evidence.
If the enforcement point cannot perform a mandatory safeguard, it does not execute the operation.
Inspection
Inspection selects content and risk controls such as PII detection, malware scanning, prompt-injection detection, or risk scoring. Inspection may restrict an operation but cannot grant authorization by itself.
Known, absent, and unknown are different
Enterprise authorization fails when missing information is treated as if a condition did not apply. AxonFlow distinguishes three states:
| State | Meaning |
|---|---|
| Known | The authoritative source established a value |
| Absent | The authoritative source established that an optional value has no value |
| Unknown | The source could not establish the fact |
For example, "Sarah is not a member of Finance" is different from "the directory could not answer whether Sarah is a member of Finance."
The second result cannot silently bypass a Finance-related constraint. If an unknown fact could change the authorization result or a mandatory requirement, the operation remains non-executable.
Mandatory safeguards compose predictably
Different safeguards need different composition rules:
- Field transforms move toward less disclosure. An unsupported or incomparable combination denies rather than choosing one arbitrarily.
- Approval requirements remain a conjunction of threshold clauses.
- Allowed routes are intersected.
- Authentication requirements select the strongest assurance and compatible methods.
- Every applicable budget and quota rule must be satisfied atomically.
- Audit and notification requirements are combined and deduplicated.
There is no global ranking such as "block beats redact beats warn." Each safeguard family has one defined rule.
Approval example
An operation might require:
2 of {Security, Platform}
AND
1 of {Data Owners}
These clauses are not merged into a single pool. AxonFlow also checks whether enough distinct, interactive approvers can satisfy every clause after excluding the requester and the actor chain.
A known impossible clause is denied immediately instead of waiting for an approval timeout. If directory reachability is temporarily unknown, the challenge remains non-executable and bounded by its expiry. Timeout never means approval.
Four operational results
The enforcement point receives one of four states:
| Result | Meaning |
|---|---|
ALLOW | The exact operation may execute with the listed safeguards |
DENY | Policy or a mandatory safeguard prevents execution |
CHALLENGE | Approval or stronger authentication is required |
ERROR | A safe decision could not be produced |
Only ALLOW permits execution. A directory outage, invalid policy bundle, unsupported
obligation, expired approval, unavailable budget reservation, or mismatched proof never
becomes an implicit allow.
Signed decision proofs
In the target design, an allowed operation that crosses a process boundary carries a signed decision proof. The proof binds the authorization to the exact:
- organization, principal, client, session, and actor chain;
- action, tool, resource, and normalized argument digest;
- policy, identity, registry, resource, and schema versions;
- obligations, approval evidence, and budget reservations;
- target enforcement point, audience, expiry, and replay protection.
The connector or other enforcement point verifies the proof immediately before execution. Changing the actor, attachment, destination, arguments, policy version, approval, or target invalidates the proof.
This closes the time-of-check gap between "AxonFlow allowed this" and "the connector executed something."
Worked example: a finance agent updates Jira
The walkthrough below is illustrative of the target design: it shows how the pieces above compose, so that teams planning enforcement points know what contract to build against.
Sarah asks an AI agent:
Update Jira issue FIN-17 and attach this customer export.
The control plane processes the request as follows:
- Sarah is authenticated through Acme's Okta trust realm.
- AxonFlow establishes
Sarah -> Finance Agent -> Jira Connector. - The tool registry maps the operation to a canonical Jira update action and hashes the normalized arguments.
- Identity and resource data show that Sarah belongs to Finance,
FIN-17belongs to the Finance project, and the attachment contains confidential customer information. - A permission allows Finance members to update Finance project issues.
- Constraints require an approved connector, an allowed delegation depth, and an approved confidential-data route.
- Requirements demand SSN redaction, one Data Owner approval, one Security approval, budget admission, and enhanced audit.
- The initial result is
CHALLENGE. Jira is not called. - After approval, AxonFlow rechecks eligibility, reserves budget, verifies redaction capability, and issues a signed proof.
- The Jira enforcement point verifies the proof and executes the exact approved operation once.
If Sarah's group lookup is unknown, the result is not allow. If the connector cannot enforce redaction, the operation is denied. If the attachment changes after approval, proof verification fails.
Integration model
AxonFlow separates central management from local decisions:
Policy decisions are designed to run locally in the enforcement service using signed, immutable bundles, so that the hot path does not acquire a dependency on a remote policy service. Central systems own authoring, testing, signing, distribution, audit, and rollback.
The intent is to give platform teams a consistent policy contract without adding a network availability dependency to every governed operation.
Rollout without a flag day
Existing enforcement paths migrate independently. Each path first produces the new canonical request beside the current one, then runs both decision models in shadow mode and records semantic differences.
A path can cut over only after it proves:
- expected users, agents, actions, and resources have explicit permission coverage;
- unknown identity and context cannot create an unexplained fail-open difference;
- every mandatory safeguard is supported;
- signed proofs and replay protection work at the enforcement point;
- the same conformance cases produce the same meaning across supported paths;
- rollback to a previously verified policy bundle works.
The legacy and replacement systems are not intended to become a permanent dual-write architecture.
What this means for architecture teams
For staff engineers, the primary integration contract becomes one canonical authorization request and one set of enforcement outcomes.
For engineering managers, identity, policy, approval, inspection, and audit have explicit owners and failure contracts instead of route-specific behavior.
For directors and security leaders, the model provides:
- default-deny authorization;
- explicit delegated-agent identity;
- deterministic, replayable decisions;
- mandatory safeguards that cannot be ignored by a connector;
- approvals bound to the exact operation;
- proof of what was authorized and what executed;
- staged migration with measurable semantic differences.
