Enterprise AI is moving faster than the architecture meant to govern it.

CISOs are deploying coding agents in production. CROs are signing off on agentic workflows that touch customer data. CIOs are building agent platforms that orchestrate dozens of specialist agents per workflow. And the governance stack underneath all of it was built for a different problem.

The problem the existing stack solved is human identity and human access to systems. Authentication, authorization, role-based access control, audit logging. That stack works for humans clicking buttons and service accounts running scheduled jobs. It does not work for agents that spawn dynamically, call other agents, retrieve data on behalf of users they do not represent, and execute actions whose outcomes the user never sees.

The Trust Fabric is the four-layer architecture that closes this gap.

This piece explains what each layer does, why all four are required, and how regulated industries should think about procurement. It is the reference architecture that every subsequent piece of APERION's work builds from.

Why "Trust Fabric"

The term comes from the observation that no single layer can govern agentic AI on its own.

Identity governance can authenticate. It cannot enforce policy at the call boundary between agents.

Access governance can authorize roles. It cannot bind those authorizations to the dynamic, ephemeral identity of agents spawned at runtime.

Runtime governance can enforce policy at the call boundary. It cannot produce regulator-grade audit evidence on its own.

Audit infrastructure can store evidence. It cannot connect that evidence back to the human operator who initiated the workflow that started the agent chain.

Each layer is necessary. None is sufficient. The fabric is what they form together when they are designed to compose.

This is different from how the existing security stack thinks about itself. Identity vendors think they are the trust layer. Access vendors think they are. Runtime governance vendors think they are. Audit platforms think they are. All four are right within their layer. None is right across the whole stack.

The Trust Fabric names the architecture in which all four layers compose.

The four layers

Layer 1: Verified Identity

The foundation. Before any access decision happens, the human operator behind the request must be verified to a defined assurance level.

For regulated industries, this is NIST IAL2/AAL2 or equivalent. Identity Assurance Level 2 means the person has provided verified evidence of their real-world identity. Authenticator Assurance Level 2 means the authentication method is resistant to common attacks.

What this layer does that nothing else can: it establishes that the human operator is real, is the person they claim to be, and is authenticated through cryptographically strong mechanisms.

What this layer does not do: it does not govern what that human operator is allowed to access, what agents act on their behalf, or what audit evidence the system needs to produce.

APERION operates Layer 1 as a macro layer. Identity proofing vendors participate through it. Government-grade proofing services, EU digital wallet identity, and biometric matching providers plug into the macro layer as backends. The customer does not integrate each vendor separately. The customer interacts with APERION's SDK and API, and the macro layer resolves identity to the IAL2/AAL2 standard regardless of which proofing backend sits underneath. APERION owns the L1 interface so that the rest of the fabric has one consistent, cryptographically strong answer to the question of who the human operator is.

Layer 2: Access Governance

The authorization layer. Once the human operator is verified, what are they authorized to do?

This is where existing identity and access management runs. Okta, Microsoft Entra, Active Directory, Veza, SGNL. Modern access governance platforms manage role-based and attribute-based access control, just-in-time elevation, privileged access management, and access reviews.

What this layer does that nothing else can: it answers the question "is this user allowed to perform this kind of action against this kind of resource?"

What this layer does not do on its own: it does not bind those authorizations to the agent that actually performs the action. When a user starts an agentic workflow, the workflow may spawn three, five, or twenty agents. Each agent acts. The IAM stack authorized the human. It did not authorize the agent, and it has no record connecting the agent's entitlements back to the human's.

APERION operates Layer 2 through entitlement provenance. The customer's existing IAM stack feeds in. APERION synchronizes the human directory entitlements and expands them into agent entitlements, deriving what each agent is permitted to do from what the human who created it is permitted to do. Agent entitlements never exceed the human's. The provenance chain, from human authorization to agent action, is held at this layer.

This is necessary because of the relationship between human and agent entitlements. An agent is not a new principal with its own rights. It is an extension of the human who initiated it, and its authority must trace back to that human at every step. Owning Layer 2 is what lets APERION hold that entitlement provenance, so that when the runtime layer enforces policy and the audit layer produces evidence, both can prove the agent acted inside the authority the human actually held. APERION does not replace the IAM investment. It operates the layer that makes the IAM investment governable for agents.

Layer 3: Runtime Governance

The enforcement layer. This is where agentic AI breaks existing architecture.

Runtime governance operates at every prompt, every response, every tool call, every agent-to-agent call. It inspects the action the agent is about to take, evaluates it against policy, enforces decisions inline, and produces the provenance record that downstream audit will require.

What this layer does that nothing else can: it enforces policy at the call boundary where agents actually act. Workflow governance can see that the workflow ran. Data governance can see that the data was touched. Identity governance can see that the user was authenticated. None of them can see, in the moment, whether the specific call the agent is about to make satisfies the policy requirements of the workflow, the regulatory framework, the data classification, and the audit standard simultaneously.

What this layer does not do: it does not replace workflow governance, data governance, or identity governance. It composes with them. ServiceNow AICT governs the workflow. Oracle Deep Data Security governs the data. Okta governs the user. APERION SmartFlow governs what happens at every call those layers do not see.

This is the layer where the runtime control plane category is being built, and the layer APERION operates on the wire.

Layer 4: Audit & Evidence

The accountability layer. The previous three layers produce decisions and actions. This layer produces the evidence that regulators, auditors, and risk officers can use to demonstrate compliance.

The distinction between observability and audit is the distinction that most enterprise architectures get wrong. Observability tells you what happened. Audit evidence is structured to satisfy specific regulatory requirements about identity, authorization, action, outcome, and human oversight. They look similar from a distance. They are not the same thing.

What this layer does that nothing else can: it produces evidence formatted to specific regulator requirements. SR 11-7 for model risk in US banking. EU AI Act Article 14 for human oversight of high-risk systems. DoD CDAO requirements for defense AI. FFIEC, NIST AI RMF, Five Eyes CSI controls. Each regulator wants evidence in a specific shape. Generic logging does not satisfy any of them on its own.

What this layer does not do: it does not generate the data. The data has to come from the other three layers, structured at the point of capture, with cryptographic chains that downstream audit can verify.

APERION's Regulatory Exam Suite operates at this layer.

The Workflow Plane

The four-layer Trust Fabric is the security and governance architecture. There is also a workflow plane that sits parallel between Layer 2 and Layer 3.

ServiceNow AICT is the workflow plane example most enterprise architects are familiar with today. Microsoft Agent 365 is another. These platforms orchestrate agentic workflows, manage approvals, route work between agents, and handle the operational mechanics of running agents at enterprise scale.

The workflow plane is not part of the Trust Fabric. It is the orchestration layer that the Trust Fabric governs. Different procurement, different buyer (CIO and engineering leadership), different failure mode. When the workflow plane fails, an agent runs the wrong workflow. When the runtime plane fails, an agent sends regulated data to a public model.

The clarity that this separation provides is important. Customers asking "do I need APERION SmartFlow if I have ServiceNow AICT" are asking the wrong question. The right question is "what governance does my workflow platform produce, and what governance does my runtime plane have to produce on top of it." The answer is almost always that the workflow platform produces operational governance for the workflow, and the runtime plane has to produce the security, identity, and regulator-grade evidence on top.

Why all four layers are required for regulated industries

The Trust Fabric is not a checklist. It is the architecture that satisfies the combined requirements of regulated procurement.

A regulated enterprise deploying agentic AI faces simultaneous requirements:

• Verified human identity behind every privileged action (driven by Know Your Employee, sovereign workforce requirements, DPRK sleeper concerns in security-sensitive industries)
• Existing access governance investments preserved and extended, not replaced
• Inline policy enforcement at the agent call boundary
• Regulator-grade audit evidence produced at the moment of action, not reconstructed from logs after the fact

No vendor in the market today satisfies all four requirements from a single product. The realistic architecture is a composition: a macro identity layer at L1 with proofing vendors underneath, entitlement provenance at L2 over the existing IAM stack, runtime governance at L3, audit suite at L4.

The Trust Fabric is the integration architecture that makes that composition coherent.

How to evaluate vendors against this architecture

Three questions to ask any vendor claiming to govern agentic AI:

Which layer do you operate at? A vendor that claims to do all four is either marketing or building too thin. The realistic answer is one layer with explicit integration points into the others.

What evidence do you produce at the audit layer? Generic logging is not audit evidence. Ask for sample audit artifacts. Ask which regulatory framework the audit format satisfies. If the answer is "we produce OpenTelemetry traces," the vendor is at the observability layer, not the audit layer.

How do you bind identity to action? The hardest architectural question. If the vendor cannot explain how the human operator who initiated the workflow connects to the specific tool call an agent is making four hops downstream, the runtime governance is not regulator-grade.

These three questions separate the runtime governance category from the broader "AI gateway" and "AI security" market.

What APERION builds

APERION operates all four layers of the Trust Fabric.

At Layer 1, a macro identity layer that resolves verified identity to the IAL2/AAL2 standard, with proofing vendors participating as backends behind APERION's SDK and API.

At Layer 2, entitlement provenance that synchronizes the customer's existing IAM and expands human entitlements into agent entitlements, holding the chain from human authorization to agent action.

At Layer 3, SmartFlow, our runtime governance product. It enforces policy inline at every prompt, response, and tool call. It binds human identity to agent action. It produces the provenance record that downstream audit requires.

At Layer 4, the Regulatory Exam Suite. It formats evidence to specific regulator requirements and produces the artifacts that auditors and risk officers need to demonstrate compliance.

We do not replace your IAM. We operate the layer above it that makes agent entitlements traceable to it. We do not replace your workflow platform. We do not replace your data governance stack. We operate the fabric that governs the layer where agentic AI breaks every assumption those investments were built on.

What comes next

This piece is the cornerstone. Subsequent pieces in this series will go deeper on:

• Identity proofing for AI agents at the L1 layer
• The runtime plane and why it cannot be replaced by workflow or data governance
• The buyer and failure-mode test that separates the four layers in procurement
• How EU AI Act Article 14 maps to the runtime plane specifically
• The audit evidence format that regulator-grade L4 has to produce

If you operate in regulated industries and want to discuss how the Trust Fabric applies to your specific deployment, we are at aperion.ai.

The architecture is the work. The category is being built right now. The vendors who recognize this first will be the ones who matter.