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.

Examples of L1 capabilities deployed today: government-grade identity proofing services that verify personal documents, perform biometric matching, and produce credentials at the IAL2/AAL2 standard. APERION integrates L1 identity proofing into the Trust Fabric for regulated tenants who need cryptographic certainty about who is behind every agent action.

Layer 2: Access Governance

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

This is where the existing identity and access management stack does most of its work. 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: it does not bind those authorizations to the agent that is actually performing the action. When a user starts an agentic workflow, the workflow may spawn three, five, or twenty agents. Each agent acts. Access governance authorized the workflow. It did not authorize the agent.

The Trust Fabric does not replace this layer. It integrates with it. APERION extends existing access governance investments by binding agent actions back to the user authorization that initiated them.

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 APERION operates and where the runtime control plane category is being built.

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: identity proofing at L1, existing IAM stack at L2, runtime governance product 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 builds the runtime plane and the audit layer of the Trust Fabric. We integrate with identity proofing partners at L1 and existing access governance investments at L2.

SmartFlow is 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 chain that downstream audit requires.

The Regulatory Exam Suite is our audit layer. It formats evidence to specific regulator requirements and produces the artifacts that auditors and risk officers need to demonstrate compliance.

Together they form the L3 and L4 of the Trust Fabric for regulated industries.

We do not replace your IAM. We do not replace your workflow platform. We do not replace your data governance stack. We govern 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.

Craig Alberino is CEO and Co-Founder of APERION. APERION builds the runtime governance and audit layers of the Trust Fabric for regulated industries.