Operational Trust depends on knowing who is acting and how credentials are managed — without exposing secrets to AI clients or duplicating identity in every integration.
AI Fabrix works with the organisation’s existing Azure controls, including Entra ID for identity and Key Vault for secrets. It does not replace the identity provider or create a separate user identity store.
Why it matters
Enterprise systems use many authentication models: API keys, OAuth, certificates, and platform-managed credentials. Architects need a trust lens — which method fits which system class, where secrets live, and what AI never sees — separate from integrator JSON editing.
If authentication is treated as “just connect the API,” teams store keys in prompts, share tokens in chat, or grant AI broad service accounts. Operational Trust blocks that pattern: humans and platform services authenticate; Role Assistants request capabilities, not vendor credentials. AI has no authority of its own — every action runs for an identified person.
How it works
Enterprise identity (users, roles)
↓
Platform credential store (encrypted, audited)
↓
Integration authentication (method + secret reference)
↓
Governed capability execution (no raw secrets to AI)
| Concern | Trust boundary |
|---|---|
| Human login | Corporate identity — who may administer and who may use Role Assistants |
| Caller authority for AI Fabrix APIs | Real-user authority — not an autonomous system actor |
| Vendor / Connected System credentials | Encrypted store; referenced by integrations, never pasted in prompts |
| Platform-managed downstream | Platform acquires and injects downstream tokens where configured — still not a substitute for real-user authority on business work |
| AI access | Capability keys and metadata — never vendor API keys |
Declare method on the Connected System, bind secrets through the platform vault, validate before upload, and re-certify when credentials rotate. Integrators confirm current methods on the authentication methods catalog.
When identity cannot be verified, Operational Trust stops safely — cannot verify means do not execute.
When architects choose what
| System class | Typical pattern | Trust note |
|---|---|---|
| SaaS with private app / API key | API key in vault | Rotate on offboarding; scope to sandbox for pilots |
| Enterprise OAuth | OAuth client + secret in vault | Prefer dedicated integration app registration |
| Platform-owned shells / facades | Platform-managed downstream auth | No vendor secrets on the slot; business calls still require real-user authority |
| Microsoft / Entra workloads | Certificate or Entra | Align with corporate identity governance |
| Public read-only APIs | No vendor credential | True anonymous downstream only — not “forward the user token” |
Architects document who may create credentials, rotation cadence, and which environments share secrets (dev vs prod never share keys).
Example
A CRM integration uses an API key stored in the platform vault. Sales Managers authenticate to AI Fabrix with corporate identity; the Sales Assistant requests customer.list — the platform executes with the integration credential. The assistant never receives the CRM key; audit logs show user, role, capability, and outcome.
Common mistakes
| Mistake | Risk | Mitigation |
|---|---|---|
| Shared service account for all AI use | No user-level accountability | Role-scoped subjects in governance certification |
| Keys in environment files on laptops | Leakage, drift | Vault references in manifests only |
| Skipping re-validation after rotation | Silent production failures | Include auth changes in release checklist |
Business value
Clear authentication boundaries make AI programs auditable: identity proves who, credentials prove system access, and capabilities prove what AI may request.
Limits
Supported authentication methods and vault key patterns evolve with platform releases — integrators confirm current methods on the authentication methods catalog before production rollout.
Corporate policies may forbid specific methods (for example long-lived API keys) even when vendors allow them — this page does not replace enterprise security standards.