AI supply chains extend well beyond application code. A single AI service may depend on third-party foundation models, pretrained weights, datasets, model repositories, open-source libraries, embedding models, vector databases, plugins, agent tools, cloud runtimes, APIs, and external evaluation services. Each dependency can affect confidentiality, integrity, availability, safety, and legal obligations.

The current ISACA AAISM outline includes a dedicated AI vendor and supply-chain management area, while ISACA AAIA explicitly requires evaluation of AI vendors and supply-chain management programs. The security objective is therefore to know what the AI system depends on, verify the integrity and trust of those dependencies, and retain the ability to detect, contain, replace, or revoke them.

Build a dependency map before evaluating controls

List every external and internally supplied component that influences model behavior or system actions: models, adapters, fine-tunes, datasets, libraries, containers, APIs, prompts, retrieval sources, plugins, tools, orchestration frameworks, content filters, and hosting platforms.

For each dependency, record owner, supplier, version, source, approved use, update mechanism, privileges, data access, network access, integrity mechanism, and downstream systems. A dependency that can only generate text has a different impact from one that can send email, query a database, or change infrastructure.

Map transitive dependencies where they are material. A commercial AI platform may itself use a hyperscale cloud provider, model provider, content-moderation service, and support subcontractors. Those layers create concentration and incident-notification dependencies.

Verify model and artifact provenance

Know where model weights, adapters, containers, and libraries came from. Prefer trusted registries and controlled promotion pipelines over ad hoc downloads. Preserve hashes or signatures where supported and verify them before deployment.

Record license terms, model-card information, training or fine-tuning provenance available from the supplier, known limitations, safety assumptions, and supported versions. Provenance will not prove that a model is safe, but missing provenance makes it harder to assess tampering, licensing, data, and support risk.

Restrict who can publish model artifacts into approved repositories. Separate experimental and production registries so a convenient test model cannot silently become a critical production dependency.

Treat datasets as supply-chain components

Training, fine-tuning, retrieval, evaluation, and feedback datasets can introduce poisoning, bias, privacy violations, intellectual-property issues, and hidden instructions. Record source, ownership, collection method, approval, classification, quality checks, transformations, and permitted uses.

Validate ingestion pipelines. A trusted source can become unsafe if an attacker can alter the transfer path, repository, preprocessing job, or labeling workflow. Monitor unexpected volume, schema, distribution, and provenance changes.

For retrieval-augmented systems, source integrity must continue after deployment. A malicious or compromised document can influence model behavior even though the base model and application code are unchanged.

Constrain plugins, tools, and agent integrations

Plugins and agent tools convert model output into actions. Evaluate each integration as a privileged software dependency: authentication, authorization, allowed operations, parameter validation, data exposure, rate limits, transaction limits, and logging.

Do not rely on the model to enforce access control. The tool should independently verify the calling identity and reject unauthorized actions. Use least-privilege service accounts and separate credentials for development, testing, and production.

Review combinations of tools. Individually acceptable read and send capabilities can become a data-exfiltration path when an agent can chain them. Supply-chain risk includes the composition of dependencies, not only the security of each component alone.

Perform vendor assurance around AI-specific risk

Traditional vendor due diligence still matters: security program, vulnerability management, incident response, resilience, privacy, subcontractors, financial condition, and contractual controls. AI services add questions about customer-data use, model training, prompt retention, model updates, safety testing, abuse monitoring, model access, and deletion of derived artifacts.

Clarify which changes the provider can make without customer approval. Hosted models may change versions, safety behavior, context limits, pricing, or regional availability. Determine how material changes are communicated and which changes trigger customer reassessment.

Contracts should address incident notification, data use, intellectual property, subprocessor changes, audit or assurance rights, deletion, portability, service continuity, and exit. If the provider will not make a critical control commitment contractually, treat that limitation as risk rather than assuming marketing material is enforceable.

Protect build, registry, and deployment pipelines

Apply software-supply-chain controls to AI artifacts. Restrict repository access, require reviewed changes, scan dependencies, protect CI/CD credentials, isolate build runners, verify signed artifacts, and record the exact components promoted to production.

Model registries should capture version, approval, evaluation results, owner, source, and deployment status. Prevent production services from pulling arbitrary “latest” artifacts from public repositories. Pin approved versions so changes are intentional and reversible.

Secrets used to access model providers, data stores, or tools should be managed centrally and rotated. A leaked model API key can expose data, enable abuse, or create large unexpected cost even when no traditional server is compromised.

Monitor dependencies for change and compromise

Supply-chain assurance is not complete at onboarding. Track security advisories, model or package updates, supplier incidents, terms-of-service changes, license changes, deprecations, and new subprocessors. Tie critical dependencies to owners who can assess impact.

Baseline model and system behavior so unexpected changes become visible. A dependency compromise may appear as altered output quality, new unsafe behavior, unusual tool calls, unexpected network traffic, or changes in data accessed.

The broader set of AI risks and challenges becomes more actionable when teams know which supplier or dependency could introduce each risk and how it would be detected.

Prepare to revoke, replace, and recover

For critical AI dependencies, define containment actions before an incident: disable a plugin, block an endpoint, revoke a key, quarantine a model version, remove a dataset, switch to a fallback provider, disable autonomous actions, or route work to human processing.

Test whether those actions are technically possible and operationally understood. A theoretical alternative model is not a recovery strategy if it uses incompatible APIs, lacks required data residency, or has never been validated for the use case.

Preserve evidence when a supply-chain incident occurs: versions, hashes, prompts, data, tool traces, logs, supplier communications, affected decisions, and containment actions. That record supports both investigation and later assurance.

Open-source AI components require the same discipline as commercial suppliers. Popularity, download counts, or a public repository do not prove trustworthy maintenance. Review maintainer history, release cadence, security advisories, licensing, provenance, dependency behavior, and whether the organization can pin and internally mirror approved artifacts.

Model updates deserve controlled promotion. A new model version may improve accuracy while changing safety behavior, tool use, token limits, supported regions, or pricing. Test the new version against representative evaluation sets, compare outputs and failure modes with the approved baseline, and maintain a rollback path until production behavior is understood.

Supplier access is another supply-chain path. Support engineers, managed-service personnel, and vendor administrators may have privileged access to tenant data or configuration. Require strong authentication, time-bounded access, logging, approval, and review. Contract terms should clarify remote support, subcontractor access, and emergency access procedures.

Business continuity should address supplier withdrawal as well as outage. A provider can discontinue a model, change license terms, leave a jurisdiction, or make the service economically impractical. Critical systems should know what data and configuration must be exported, which alternative providers are viable, how long migration would take, and which functionality would be lost.

Threat modeling helps prioritize supply-chain controls. Consider what happens if a model artifact is replaced, a dataset is poisoned, a plugin is compromised, an API response is manipulated, a vendor account is taken over, or a package update introduces malicious behavior. Map each scenario to preventive, detective, and recovery controls so the program does more than collect supplier attestations.

Data egress should be controlled at dependency boundaries. A plugin or external model may receive far more context than it needs if the orchestrator simply forwards the full prompt, retrieved documents, or conversation history. Minimize data passed to third parties and enforce allowlists for sensitive sources where possible.

Supply-chain metrics can include unapproved dependencies, critical artifacts without verified provenance, overdue vendor reviews, unsupported versions, supplier incidents, time to revoke compromised components, concentration by provider, and systems lacking tested fallback paths. These measures make systemic dependency risk visible before an incident exposes it.

Procurement teams should also record whether a supplier can provide advance notice of material model, pricing, region, or policy changes. Sudden commercial or technical changes can force unsafe migrations or unplanned architecture decisions. Notice periods and transition support are therefore part of supply-chain resilience, not merely contract administration.

Evidence from suppliers should be time bounded. A security assessment, penetration test, or assurance report can become stale after a major platform change. Critical dependencies should have defined reassessment triggers so old evidence is not treated as permanently valid.

That lifecycle view should include decommissioned suppliers as well. Remove credentials, revoke integrations, confirm data return or deletion, and verify that old endpoints are no longer reachable after migration.

Manage concentration and systemic dependency risk

Inventory common providers across the enterprise. Multiple teams may independently select the same foundation model, cloud region, vector database, or identity service, creating a shared failure domain that is invisible when each application is assessed separately.

Concentration is not automatically unacceptable. It can simplify controls and improve operational expertise. The risk decision should consider criticality, switching cost, recovery options, contractual leverage, geographic concentration, and whether one supplier incident could affect several essential services at once.

AI supply-chain work links security, risk, and audit across ISACA certifications. The durable control objective is to preserve trust across dependencies throughout their lifecycle with provenance, least privilege, vendor assurance, monitored change, and credible revocation paths—not a one-time questionnaire attached to a rapidly changing AI stack.