AI can request. It cannot grant itself authority.
Enterprise AI becomes unsafe when model output is treated as permission to access or change business systems. AI Fabrix separates reasoning from enterprise authority.
A Role Assistant defines the governed business purpose and operating boundary. An approved AI interface can provide interaction. AI has no independent organisational authority.
Enterprise Runtime owns execution. Its Decision Engine determines each continuation, while Operational Trust determines whether governed work is authorised to proceed.
Prompt instructions can guide AI behaviour. They are not an authorization boundary.
Enterprise identity and organisational authority remain owned by the customer identity and business environment.
Operational Trust evaluates governed work against that current customer authority. It checks the verified principal, active Business Role, applicable scope, permissions, policy, approval state and certification.
Prompts, retrieved content, conversation history and model reasoning cannot create new organisational authority.
This creates a clear boundary:
AI may propose work. Enterprise Runtime determines what happens next. Operational Trust determines whether the governed work is authorised to proceed.
AI-assisted enterprise work is evaluated for a verified principal acting under an active Business Role.
The principal is an identified person. The AI model itself does not become an organisational principal merely because it can reason or call tools.
A Business Role is the governed responsibility under which the identified person performs the work. Existing identity, permissions, organisational scope and approval conditions continue to apply.
Verified principal → active Business Role → organisational authority and scope → governed Runtime context
Knowing who the principal is does not answer whether every operation is permitted.
Operational Trust can evaluate the applicable combination of:
The question is therefore not merely: Can this identity access the system?
May this governed work proceed for this principal, under this Business Role and current enterprise context?
AI Fabrix separately validates the quality and completeness of its compiled enterprise configuration. COM, the enterprise compilation layer, includes a Trust Model describing the completeness and consistency of that configuration, including relationship, identity, governance, capability and authority coverage.
Operational Trust is different. It is the runtime authority responsibility that determines whether governed work is authorised for the current principal, role, scope and context.
COM does not grant runtime authority. Operational Trust does not redefine canonical enterprise meaning.
Enterprise authority is often scoped by business context such as region, legal entity, customer ownership, department, project or business unit.
For example, work may be permitted only for a particular region or legal entity, or only for customers within the person's authorised scope.
AI Fabrix uses governed Dimensions to bind those business boundaries to enterprise resources and capabilities.
Datasource definitions bind enterprise Dimensions to connected-system data. COM owns and compiles their canonical meaning. Enterprise Reality supplies the current authorized facts, and Operational Trust evaluates the applicable grants and scope during governed work.
This avoids solving every business boundary by creating another technical role.
Security depends on keeping information responsibilities distinct.
Enterprise Reality supplies current authorized business facts.
Enterprise Knowledge supplies reusable governed organisational understanding through role- and permission-aware retrieval. Authority remains enforced through the governed Runtime and Operational Trust boundary.
Evidence supplies validated operational knowledge, obligations, decisions and business-significant conditions.
Operational Trust determines whether governed work is authorised to proceed.
Relevant information is therefore not automatically permitted information, and information appearing in model context does not create authority.
Relevant is not the same as permitted.
Enterprise Runtime does not commit to a model-generated plan or predefined workflow.
Its Decision Engine evaluates the current governed execution snapshot and determines one continuation at a time.
Operational Trust is part of that governed decision context. When work changes, new facts or validated responses are incorporated into Runtime, the next continuation is determined from the resulting governed snapshot rather than from stale private model state.
This matters for security because previous authority, context or approval is not assumed to remain valid forever.
Where the next continuation requires an enterprise operation, current authority is revalidated against the current governed snapshot, capability, operation and bound inputs before execution.
CIP — Composable Integration Pipeline — performs the connected-system integration and operation. It does not own continuation or organisational authority.
The public execution boundary is:
Governed Runtime decision → current authority confirmed → certified capability execution → CIP → authoritative enterprise system
Raw vendor APIs, credentials and connection parameters remain behind the governed execution boundary rather than becoming the AI-facing business contract.
Connected systems require approved authentication. Those credentials are handled by the governed integration and execution path according to the Connected System and customer deployment architecture.
The AI-facing contract remains a certified business capability.
This means an AI interface can request governed work without receiving the underlying vendor credential or unrestricted raw API as its enterprise contract.
Operational Trust authorises the governed AI Fabrix operation. CIP executes it using the connected system's approved authentication and integration contract. The authoritative system then applies the native security controls associated with that connection and operation.
The exact authentication mechanism remains deployment- and system-specific.
A model can be influenced by user instructions, retrieved documents and other untrusted content.
Those inputs may influence a proposal. They cannot create a certified capability, organisational permission or approval state.
Before enterprise execution proceeds, current authority is enforced outside model reasoning.
If the required conditions are not satisfied, the operation does not execute through the governed AI Fabrix path.
This does not mean prompt injection ceases to matter. It means model output is not treated as enterprise authorization.
Missing or unverifiable authority information is not permission.
If Runtime cannot establish the required identity, Business Role, scope, permission, policy, approval or capability conditions, governed execution does not proceed.
If Operational Trust denies the requested action, the Decision Engine determines the governed consequence, such as a safe stop or wait with an explicit rejection. Approval-required and owner-routing conditions follow their own governed human-interaction paths.
Cannot verify means do not execute.
Safe stop is a valid governed outcome when continuing would require guessing, using stale or conflicting state, exposing protected information or bypassing authority.
Human interaction remains inside the governed Runtime loop.
An Ask requests information needed to continue.
An Approval records explicit human authority required for governed work to continue.
A validated human response becomes part of the governed Runtime context. It does not bypass Runtime, grant permanent authority or remove later trust checks.
Approval applies to the governed work for which it was obtained; material changes require authority to be evaluated again.
The Decision Engine determines the next continuation from the new governed snapshot.
Validation and certification establish whether governed artifacts and capability surfaces that require certification are ready for use.
Operational Trust establishes whether the current governed work is authorised now.
A capability can therefore be certified and still not be authorised for the current principal, Business Role, scope or approval state.
Certified does not mean currently authorised.
Authoritative execution state does not depend on hidden model memory or private agent state.
Each Runtime decision is tied to the governed enterprise state and validated results used to make that decision, so it can later be explained and reviewed.
Conversation history can help explain what was discussed, but it does not by itself prove which identity, role, scope, approval, capability or authoritative system result applied.
Evidence and technical audit records retain their own separate responsibilities.
AI Fabrix is deployed entirely into the customer's own Azure tenant. The customer retains control of enterprise data, identity, network, keys and deployment policy.
Existing enterprise systems remain authoritative for the records, facts and transactions they own. Customer-selected AI models and interfaces remain interchangeable interfaces to AI Fabrix rather than becoming the enterprise authority layer.
Deployment-specific network, key-management and operational-access controls are defined by the selected deployment architecture rather than inferred from the Runtime architecture.
| Responsibility | Architectural owner |
|---|---|
| Enterprise identity and organisational authority | Customer identity and business environment |
| Governed business purpose and operating boundary | Role Assistant |
| Execution | Enterprise Runtime |
| Each continuation decision | Decision Engine within Enterprise Runtime |
| Current authorized business facts | Enterprise Reality |
| Reusable organisational understanding | Enterprise Knowledge |
| Validated operational knowledge and decisions | Evidence |
| Canonical enterprise structure and configuration Trust Model | COM |
| Current authority enforcement | Operational Trust |
| Certified business capability execution | Enterprise Runtime through its governed execution boundary |
| Connected-system integration execution | CIP |
| Authoritative records, facts and transactions | Existing enterprise systems |
| AI interaction and model reasoning | Approved AI interface / model |
Throughout this path, Enterprise Reality supplies current authorized facts, Enterprise Knowledge supplies reusable organisational understanding, and Evidence supplies validated operational knowledge.
The security principle is simple:
AI may propose work. Enterprise Runtime owns execution. Operational Trust protects organisational authority. If authority cannot be established, execution does not proceed.
Review the complete architecture in your own environment.
