Your governed enterprise AI foundation runs in your Azure tenant
AI Fabrix is deployed into the customer's own Azure environment and runs within the customer's Azure tenant. The governed enterprise foundation — including business context, authority controls and enterprise execution — runs within that customer Azure environment.
Enterprise Runtime, enterprise context and governed execution do not depend on a shared AI Fabrix SaaS control plane.
The organisation selects the target subscription and approved deployment configuration while keeping the deployment within its Azure governance boundary.
Installation is one customer journey with two technical steps: Azure Marketplace deploys the Miso Controller foundation inside the customer's Azure tenant, then that in-tenant Miso Controller performs Tenant Activation. It applies the licensed operating model and deploys the selected environments and Platform Apps. Marketplace completion alone is not platform readiness; activation verifies identity, endpoints, required applications, network configuration and platform health end to end.
Miso Controller is part of the AI Fabrix foundation deployed in the customer's Azure tenant. It is not a publisher-hosted shared control plane, and it does not move enterprise Runtime, business context, customer data, identity or secrets into an AI Fabrix vendor tenant.
The exact deployment mechanism, Azure resources, SKUs and topology can vary by deployment model and customer-approved configuration.
The stable architecture claim is simpler:
AI Fabrix's governed enterprise foundation runs inside the customer's own Azure tenant.
Customer-selected AI models and interfaces may sit inside or outside that tenant. They remain interaction and reasoning technology rather than becoming the enterprise authority or execution control layer.
Azure-resource access depends on edition. Community and Standard customers manage the deployment through Miso Controller rather than direct Azure-resource access. Enterprise customers manage the Marketplace managed resource group through the Managed Application customer-access model and their own Azure RBAC. This distinction does not change the customer-tenant deployment boundary or give AI independent authority.
Azure Marketplace creates the foundation in the customer's tenant. Miso Controller Tenant Activation then resolves the licensed edition, size, environment topology, identity, AI model source, endpoints and supported network policy before deploying the selected environments and Platform Apps.
Azure owns the Managed Application name and managed resource-group selection. The customer provides only the initial AI Fabrix platform-administrator password. PostgreSQL, Keycloak, encryption and other internal credentials are generated separately and stored in Azure Key Vault. They are not exposed through deployment outputs, interfaces, APIs or logs.
Before resources are changed, deployment checks required Azure providers, quotas, permissions, DNS, network prerequisites and whether the selected edition, size and network combination is supported. Deployment is resumable, and installation is complete only after end-to-end readiness verification succeeds.
The deployed product provides the services required for enterprise configuration, governed execution, connected-system integration and the enterprise state AI Fabrix manages.
Depending on the selected deployment architecture, Azure resources can include application hosting, PostgreSQL, Storage, Key Vault, networking and monitoring resources.
Those implementation components support the product responsibilities already defined across the architecture:
Azure deployment choices do not change which part of AI Fabrix is responsible for meaning, authority or execution.
The deployed architecture separates administration of the AI Fabrix environment from governed enterprise business execution.
Administrative services manage the platform environment, enterprise definitions, configuration and release processes. These platform operations are distinct from governed business work.
Enterprise Runtime governs business execution. Operational Trust constrains whether that execution is authorised, and only approved business capabilities can cross the governed boundary to connected systems.
An administration surface or AI interface does not become an alternate route around Runtime authority and execution controls.
The organisation connects AI Fabrix to its enterprise identity environment, including Microsoft Entra ID where established by the deployment architecture.
Governed work is performed only under verified identity and authority recognised by the customer organisation.
AI models, interfaces and Role Assistants do not become substitute enterprise identities or independent sources of organisational authority.
Detailed administrator bootstrap, provisioning and break-glass procedures belong in deployment documentation and technical evaluation rather than the public architecture page.
Connected systems require approved authentication.
Those credentials are handled by the deployed integration and execution environment according to the Connected System and customer deployment architecture rather than becoming the AI-facing enterprise contract.
The AI-facing contract remains the approved business capability.
Runtime confirms current authority before an approved business capability can act through the governed integration layer on an enterprise system.
Azure Key Vault stores generated infrastructure secrets and the secrets, certificates and connection information required by platform services. These secrets remain behind the governed boundary and are not exposed to AI context.
The exact connected-system authentication mechanism remains system- and deployment-specific.
AI Fabrix applies supported, policy-driven public or private network profiles. PostgreSQL, Azure Storage, Azure Key Vault and Azure OpenAI follow the selected secure network policy, and a private profile does not silently fall back to public access.
Azure Front Door, custom domains, Private Link, VNet integration, private endpoints and private DNS are used only in supported combinations. Front Door alone does not make a deployment private: origin restrictions, routing, DNS, allowed ingress and allowed egress must all match the selected architecture.
Enterprise customers can apply customer-managed Azure networking through the Managed Application access model. Existing customer resources or network attachment are supported only where a validated deployment profile establishes them.
Regulated networking is an explicit customer architecture choice, not an automatic claim. AI Fabrix does not imply that every connection is private or that outbound traffic is universally restricted. Model endpoints and connected enterprise systems may require approved external connectivity.
AI Fabrix uses resources in the customer deployment for platform metadata, configuration, governed execution state, Knowledge, Evidence, secrets and monitoring according to the selected architecture.
AI Fabrix stores and processes governed enterprise state inside the customer deployment. Authoritative source data may remain in connected enterprise systems, and customer-selected AI services can have their own residency characteristics.
Product information remains separated by purpose:
The exact Azure storage service, retention policy, immutability configuration, telemetry flow and observability integration are deployment-specific unless explicitly established by the selected architecture.
SAP, Salesforce, ServiceNow, SharePoint and other enterprise systems remain separate platforms with their own operational and security responsibilities.
They can be located inside or outside the customer's Azure tenant. The important boundary is that they remain outside AI Fabrix product authority, not that they must be physically outside Azure.
AI Fabrix reaches them through governed Connected Systems and CIP execution, using the enterprise definitions compiled from the organisation's Business Entities.
Those systems remain authoritative for the records, facts and transactions they own.
AI Fabrix may synchronize, normalize, index or derive authorized business context without replacing the source system's authority over its records and transactions.
AI Fabrix does not turn normalized data or Runtime state into a replacement transactional master.
Customer-selected AI models and interfaces may run inside or outside the customer's Azure environment.
They provide interaction and model reasoning while AI Fabrix retains the governed enterprise responsibilities behind them: canonical enterprise meaning, current Reality, Knowledge, Evidence, Runtime execution and Operational Trust.
Customer-selected AI technology can change without moving AI Fabrix's governed enterprise responsibilities into the model or interface.
| Responsibility | Owner / control boundary |
|---|---|
| Azure tenant, subscription and deployment target | Customer |
| Managed Application name and managed resource-group selection | Azure Marketplace |
| Edition, size, environment topology and supported network profile | Resolved during Miso Controller Tenant Activation from customer-approved inputs and licence policy |
| Region and customer-approved deployment parameters | Customer |
| Enterprise identity and organisational authority | Customer identity and business environment |
| Network and security configuration | Customer-approved deployment architecture |
| AI Fabrix application software | AI Fabrix product running in customer Azure |
| Enterprise managed-resource-group administration | Customer administrators through customer Azure RBAC |
| Community and Standard deployment administration | Customer through Miso Controller |
| Deployment and workload Azure permissions | Scoped Miso Controller, deployment and Platform App managed identities |
| Enterprise definitions and release decisions | Customer-controlled administration using AI Fabrix |
| Canonical enterprise compilation | COM within AI Fabrix |
| Governed execution | Enterprise Runtime within AI Fabrix |
| Each continuation decision | Decision Engine within Enterprise Runtime |
| Current authority evaluation and enforcement | Operational Trust within AI Fabrix |
| Approved business capability execution | Enterprise Runtime through its governed execution boundary |
| Connected-system integration execution | CIP within AI Fabrix |
| Current authoritative business records and transactions | Customer enterprise systems |
| AI models and interaction interfaces | Customer-selected technology |
| Human approvals | Authorised people in the customer organisation |
This table describes architectural responsibility. Customer Azure authority and workload identity are separate: customer access does not replace deployment managed identities, and workload permissions do not grant authority to customer users. Publisher access exists only where the selected Marketplace operating model explicitly defines it.
The customer-tenant boundary is stable. Some operational controls depend on the selected deployment architecture and support model.
A technical evaluation should verify the exact implementation of:
These questions refine how the customer deployment is operated. They do not change the logical architecture law that governed enterprise execution runs inside the customer's Azure boundary rather than depending on a shared AI Fabrix SaaS Runtime.
Customer organisation owns enterprise identity and organisational authority, governs its Azure tenant and deployment policy, and owns business decisions and authoritative enterprise systems.
Customer Azure tenant contains the AI Fabrix product boundary:
Customer-selected AI models and interfaces interact with AI Fabrix and may run inside or outside the Azure tenant.
Authoritative enterprise systems connect through governed integration, remain outside the AI Fabrix product authority boundary and may run inside or outside Azure.
The architectural result is straightforward:
Your governed enterprise AI foundation runs in your Azure tenant. Your systems remain authoritative, your organisation retains authority, and AI models remain replaceable technology.
Review the complete architecture in your own environment.
