Integrating 2026-05 security and supply chain findings into the enterprise…

Research Question

How should the enterprise Artificial Intelligence (AI) ecosystem capability reference architecture (as expressed in 2026-04-22-enterprise-ai-capability-model and the 2026-05-05-enterprise-ai-capability-stack Knowledge synthesis) be revised and extended to incorporate findings from the 2026-05 research cycle on: Software Bill of Materials (SBOM) and Artificial Intelligence Bill of Materials (AIBOM) conceptual gaps and schema design; AI supply chain risk and runtime composition integrity; the enterprise AI security threat model covering prompt injection, Retrieval-Augmented Generation (RAG)-based attacks and model supply chain compromise; automated governance assurance and change-control verification; and AI evaluation frameworks?

Findings

Executive Summary

The five-layer enterprise Artificial Intelligence reference architecture should be retained, but only as the structural base for a broader design that exposes provenance, runtime evidence, and evaluation as explicit enterprise capabilities instead of leaving them implicit in the shared core.

In practice, that means the architecture now needs named services for declared Artificial Intelligence Bill of Materials (AIBOM) creation, delegated-identity capture, signed artifact lineage, and runtime comparison between approved design and observed execution.

The security evidence still argues against collapsing these controls into one gateway, because retrieval permissions, semantic safeguards, orchestration constraints, and promotion checks are strongest in different layers.

Governance, explainability, and evaluation therefore work best as one shared evidence system that records policy decisions, release gates, runtime signals, and review artifacts for later challenge or audit.

Key Findings

1. The main architectural delta is the move from an implied shared core to explicit enterprise services for provenance capture, runtime evidence, and evaluation, while the five-layer backbone remains intact.
2. Release governance is materially incomplete unless it records declared Artificial Intelligence Bill of Materials (AIBOM) data, artifact signing, registry lineage, delegated authority, and runtime divergence, because those records are what connect approved design to later execution.
3. The reviewed security evidence favors layer-specific enforcement, with retrieval authorization anchored in data systems, semantic safeguards near model execution, orchestration controls around tools, and promotion checks in delivery pipelines.
4. Enterprise agent architectures need identity controls that describe multi-hop human, workload, and tool relationships, because delegation chains, permission manifests, and trust boundaries determine which actions are attributable and valid.
5. Governance evidence has to survive past deployment, because provenance records, policy decisions, exceptions, explainability artifacts, and human approvals all remain relevant when incidents, audits, or regulatory questions arrive later.
6. Evaluation belongs at promotion time and during live operation, because benchmarks, adversarial tests, thresholds, and drift signals are part of the same control loop rather than separate design-time and runtime disciplines.
7. The least disruptive architecture update is to keep the five vertical layers and add two cross-cutting planes, one for supply-chain provenance and one for policy, evaluation, and evidence.
8. Ownership should stay centralized for policy semantics, provenance schema, security baselines, evaluation standards, and retained evidence, while domain teams keep responsibility for local knowledge, workflow composition, and risk-tuned operating thresholds.

Assumptions

• Assumption: enterprises can stand up a minimum viable declared AIBOM before external standards converge on one canonical schema. Justification: CycloneDX and Open Worldwide Application Security Project AIBOM already define enough structure for models, datasets, configuration, and typed extensions to support an internal starting point.
• Assumption: high-risk enterprise systems can emit enough runtime events and policy logs to support meaningful approved-versus-observed comparison. Justification: the runtime-divergence and governance-assurance items both assume some adapter work, but they still treat runtime comparison as operationally achievable rather than speculative.

Analysis

The evidence points toward an additive change, not an architectural reset, because the original stack still separates responsibilities coherently and the new research mostly adds shared services plus stronger boundaries.

The strongest alternative would be to collapse most of the new controls into one central control plane, but that would hide where critical trust decisions are actually made. Retrieval authorization belongs with authoritative data, semantic safety belongs near inference, orchestration constraints belong with workflow execution, and signing plus promotion checks belong with delivery systems.

That distribution of trust decisions is why the best synthesis is still a layered model, but now with two cross-cutting planes that make provenance and governance evidence visible everywhere instead of assumed nowhere.

Within that structure, the operating-model layer still defines risk intake, ownership, exception review, audience-specific explanation duties, and human accountability for downstream automation.

Delivery and platform engineering now has a clearer remit: approved registries, signing, declared AIBOM generation, evaluation harnesses, and policy translation belong here because this is the last layer that can consistently gate artifacts before release.

Orchestration and execution should own runtime workflow policy, tool allowlists, delegation capture, recursion controls, and action checkpoints, since those controls govern what the system actually does rather than what it merely stores.

Model and inference remains the correct place for approved endpoints, inference configuration, semantic guardrails, and provider-facing safety policy because that is where prompt and response semantics are visible in real time.

Data and knowledge should keep authoritative source systems, permission-safe retrieval, provenance, classification, and retrieval-snapshot metadata, because access truth and knowledge truth become unreliable when recreated downstream from partial copies.

Across all five layers, one cross-cutting plane should maintain declared and observed supply-chain records, while a second cross-cutting plane should maintain policy decisions, evaluations, explanations, incident records, and other governance evidence.

The practical consequence is a precise extension of the prior model rather than a replacement of it: keep the original organizing frame, but add explicit provenance services, explicit delegation-aware identity services, explicit evaluation gates, and one formal evidence loop.

Risks, Gaps, and Uncertainties

• Cross-vendor runtime AIBOM standardization is still immature, so enterprises should expect internal schema work before they get a broadly interoperable production-ready format for prompts, retrieval state, delegated authority, and runtime divergence.
• The evidence base is stronger on where controls belong than on the comparative cost and operational reliability of continuous runtime provenance capture across toolchains.
• Explainability guidance is more mature at the governance-objective level than at the exact technical-control level for multi-agent workflows, so explanation artifacts should be treated as complements to provenance and policy records, not substitutes.
• Administration coverage still varies across vendors and software-as-a-service surfaces, which means some parts of the target architecture will remain adapter-heavy even if the overall pattern is stable.

Open Questions

• What minimum shared schema should represent exception approvals, evaluation waivers, and residual-risk decisions across build, release, and runtime governance?
• What minimum runtime snapshot is sufficient for declared-versus-observed comparison without collecting more prompt, memory, or retrieval content than the enterprise can safely retain?
• Which third-party copilot and software-as-a-service control surfaces now expose enough administration coverage to participate fully in a centralized provenance and evidence plane?

sources

• Mitchell (2026) Enterprise AI capability model for use-case maturity decisions - five-layer baseline architecture and foundational capability domains
• Mitchell (2026) Enterprise capability stack for sustainable multi-provider Artificial Intelligence - current synthesis baseline to be extended
• Mitchell (2026) Why does Software Bill of Materials fail as a complete inventory model for agentic AI workloads, and what new conceptual abstractions are required? - provenance-graph argument for AIBOM
• Mitchell (2026) What is the minimal viable schema for an Artificial Intelligence bill of materials, and how should it align with CycloneDX and SPDX? - declared AIBOM schema and standards alignment
• Mitchell (2026) How should identity, delegation chains, and permission scopes be formally modelled in an AIBOM schema? - delegation and permission-manifest requirements
• Mitchell (2026) How can a runtime-observed AIBOM be generated, and how much does it diverge from the declared design-time AIBOM? - runtime evidence and divergence taxonomy
• Mitchell (2026) What security capabilities are required in an enterprise Artificial Intelligence system to address prompt injection, Retrieval-Augmented Generation attacks, model supply chain compromise, and data exfiltration? - layered security capability set
• Mitchell (2026) Automated governance assurance and change control verification patterns for AI-assisted delivery - automated governance and evidence pipeline
• Mitchell (2026) Meta-analysis standards and Artificial Intelligence skill evaluation - evaluation and review-quality discipline
• Mitchell (2026) Explainable Artificial Intelligence (XAI) regulation and governance - explainability as governance evidence
• Mitchell (2026) AI agent control-plane architecture in the enterprise - centralized policy and distributed enforcement
• Mitchell (2026) AI and low-code governance enforcement architecture - control-surface placement across layers
• Mitchell (2026) AI agent identity and access management in the enterprise - machine identity and delegation controls
• Mitchell (2026) Permission-safe Retrieval-Augmented Generation enterprise information architecture - authoritative retrieval permissions and provenance
• National Institute of Standards and Technology AI Risk Management Framework Core - lifecycle governance and traceability outcomes
• Google Cloud What is Retrieval-Augmented Generation? - authoritative definition of Retrieval-Augmented Generation
• CycloneDX Introduction to AI/ML-BOM - standards coverage for models, datasets, and configurations
• Open Worldwide Application Security Project AIBOM - AI bill-of-materials transparency and auditability goals