Map Your AI Supply Chain Before Agents Connect It

AI Trust & Governance

25 October 2026 | By Ashley Marshall

Your AI assistant may have six suppliers before it completes one task. Can you name the connection that could send, change or expose a customer record?

Your AI tool is already a supply chain

A business buys one AI assistant and thinks it has one supplier. In practice, a useful assistant may depend on a foundation model, a hosting service, a connector to Microsoft 365, a search index, a plugin maintained by someone else and an automation platform that can write back to a CRM. Each link changes what the system can see, where data travels and who can stop an action. The point is not to produce an impressive architecture diagram. It is to know which organisation and component would matter if the answer was wrong, the data leaked or the workflow stopped.

The NCSC research problem book, published on 20 October 2026, makes this distinction explicit. Deployed AI systems are increasingly ecosystems, not isolated models. It names datasets, APIs, plugins, agent frameworks, cloud platforms and human operators as parts of the security problem. That is a useful correction to a procurement checklist that asks only which model a vendor uses. A safe model can still sit inside a badly permissioned workflow. A well-run vendor can still depend on an unexamined connector.

What this means in practice is a one-page dependency map for each production AI workflow. Start with the business task, then trace every read, write and transfer. Name the legal data controller where personal data is involved, the service holding credentials, the person who approves changes and the service that records actions. Mark external services clearly. If nobody can explain a connection, it should not quietly become part of a customer-facing process.

This is not a demand for perfect knowledge of every transistor in a cloud stack. It is a way to identify material dependencies: services that could expose information, alter a business record, make an irreversible decision or prevent the workflow from running. That is the level at which managers can act.

Follow permissions, not brand names

The most revealing question is not "Which AI vendor have we approved?" It is "What can this workflow do with the authority we gave it?" A connector might read a mailbox, download attachments, create contacts, send messages or move files. Those are very different permissions even if all are bundled under one familiar product name. An agent with a broad service account can inherit more authority than the employee who requested the task.

The NCSC interim advice on managing agentic AI risk recommends a sandbox that controls local and network access. It asks operators to consider execution, network, compute, credentials and data boundaries, including what the agent can influence indirectly. It also says model-level safeguards should not be treated as complete protection. For a small firm, the practical version is straightforward: give each workflow its own identity, restrict it to the records and actions needed, and keep write permissions separate from read permissions where possible.

Take a sales assistant that prepares follow-up messages. Reading the relevant notes and drafting a reply is one level of access. Sending the message, changing a deal stage and exporting an entire contact list are three separate levels. The first can often be piloted safely. The others need explicit business rules, technical limits and a named owner. A line in a prompt saying "do not export contacts" is useful guidance, but it is not an access control.

What this means in practice is to put a permission column beside every dependency: read, propose, write, send or administer. Add the scope, such as one folder rather than the whole drive. Check which credentials are reused and where they are stored. Then test whether the workflow can act outside its intended scope. If it can, reduce the permission before expanding the pilot.

Include data protection in the map

Technical access is only half of the story. Personal data can move through prompts, retrieved documents, logs, memory, analytics and human review queues. A business that understands the model provider but not its supporting services cannot give a reliable account of how information is handled. It also cannot easily answer a deletion request or investigate an incident.

In October 2026, the ICO opened a call for evidence on agentic AI. Its six themes are data security, transparency, accountability, automated decision making, fairness and purpose limitations, and lawfulness of processing. The consultation closes on 20 November 2026. These are not six new duties created by the consultation. They are the regulator's current questions about how existing data protection law applies to dynamic, distributed systems. Businesses should avoid presenting an open consultation as a final compliance checklist.

A useful inventory therefore records the purpose of each data flow, the classes of personal data involved, where it is stored, retention settings and the person responsible for checking supplier terms. It should also show whether data is passed to another provider for inference, search, monitoring or support. This does not replace a data protection impact assessment where one is required, but it gives that assessment an accurate starting point. It also makes the privacy notice and internal record of processing easier to maintain.

Consider a recruitment workflow. A CV may enter via email, be extracted by a document service, scored by a model and summarised in an applicant tracking system. The candidate sees one process. The organisation may have four services and several copies of the data. Mapping those stages is more useful than simply telling staff the workflow uses AI. It reveals where human review, retention and correction rights must be designed.

Treat a connector change as a business change

AI supply chains do not stay fixed after procurement. An automation platform adds a plugin, a model provider changes an endpoint, a team member grants a broader OAuth scope, or a vendor introduces a new subprocessor. Each may change the risk of a workflow without changing the product name on the invoice. That makes a static once-a-year vendor questionnaire too weak for operational assurance.

Set a small change gate. Record the workflow owner, its current dependencies and the permissions approved at launch. Require a review when a connection gains a new data source, a new write action, a different hosting region or a different party processing customer information. For a low-risk internal summariser, the review may take ten minutes. For a workflow that updates customer records or influences an employment decision, it should involve security, the relevant business owner and whoever handles data protection.

The NCSC's October research note highlights provenance and trust across AI supply chains as an unsolved area, including questions about when a model or integration should be patched, restricted, replaced or withdrawn. That is a reason to keep the first version of the gate modest and testable, not a reason to wait for a perfect standard. Keep a versioned list of material components, note why each is needed and identify how to disable it. A screenshot of settings alone is not enough because it will not show who authorised the decision.

Some buyers will argue that vendors already perform security reviews. Many do, and their assurance can save work. It cannot tell you whether your own integration was given access to the entire CRM when it only needed one pipeline. Vendor diligence and deployment design answer different questions. The former assesses a supplier. The latter assesses what your organisation actually built.

Run a dependency failure drill

The value of a map appears when something breaks. Choose one production workflow and ask three questions. What happens if the model service is unavailable for a day? What happens if a connector starts returning the wrong records? What happens if a plugin's credentials must be revoked immediately? If the answers depend on one employee remembering how the system was assembled, you have a continuity problem as well as a security problem.

Run a short drill with the people who actually operate the workflow. Pause the automation, revoke a test credential, restore from a known configuration and reconcile any records that may have been changed. Check whether alerts identify the affected task and whether logs show which component took each action. The NCSC advice calls for observability, operational monitoring and response procedures across all deployments, and for a way to shut down an agent when needed. A supplier's dashboard may help, but your team still needs an owner and a decision rule.

Measure recovery in business terms. How long did it take to stop outgoing messages? How many customer records needed checking? Could staff continue the service manually? These numbers are more useful to a director than a green status light. Record the result and fix the weakest link before increasing autonomy. If the system can draft but not send, the test is simpler. If it can send, purchase or change records, the consequences and control effort rise.

Do not mistake this for an argument against agents or connected tools. The strongest case for them comes when a business can show a bounded workflow, clear ownership, measurable benefit and a credible recovery route. Build that evidence with one workflow. The next deployment becomes faster because the dependency map, permission model and drill are reusable, while the specific access still gets reviewed afresh.

A practical 30-day starting point

In week one, select the single AI workflow with the most meaningful business impact. Do not start with the largest tool inventory. Write down its purpose, owner, inputs, outputs and the actions it can take. Draw a box for each model, connector, plugin, API, data store and person who approves a consequential step. Include services that run in the background. The exercise should fit on a page before it becomes a spreadsheet.

In week two, test the map against reality. Ask an administrator to export the granted scopes and compare them with the intended task. Review the last ten actions in the audit log. Confirm whether the team can distinguish a draft, an approved action and an automatic send. This is where hidden dependencies tend to surface: a shared mailbox, a generic API key or a monitoring service nobody included in the original procurement discussion.

In week three, narrow one permission and document one change trigger. Avoid a sweeping policy launch. The most valuable first improvement may be replacing an administrator token with a restricted service identity, or limiting a connector to one workspace. Agree that any request for new write access, personal data or an additional third party goes back through a named owner.

In week four, rehearse a failure and write down the result. Time the shutdown, check who notices, and verify that affected work can be recovered or reviewed. Share a short note with leadership: what the workflow delivers, where it depends on others, the main remaining risk and the next decision. That is a better basis for investment than either an unqualified promise of automation or a blanket refusal to connect AI to useful systems. The aim is controlled adoption, not paperwork for its own sake.

Frequently Asked Questions

Do we need to map every AI tool in the business at once?

No. Start with one production workflow where an error would affect customers, records or important decisions, then reuse the method.

Is a vendor security certificate enough?

No. It can help assess the supplier, but it does not show which permissions your own connectors have or how your workflow is configured.

What counts as a material dependency?

A model, service, connector, dataset, person or credential that could expose information, change a record, alter a decision or stop the workflow.

Does the ICO consultation create new legal duties?

No. The October 2026 call for evidence seeks views on how existing data protection law applies to agentic AI. It is not final guidance.

Should an AI agent have its own account?

Where the platform supports it, a dedicated restricted identity makes permissions and audit trails clearer than a shared administrator account.

How often should the map be updated?

Review it when data sources, permissions, processors, hosting regions or consequential actions change, and at a routine operational review.

What if a vendor will not disclose every subcomponent?

Ask for the material data flows, subprocessors, hosting arrangements, permissions and incident route. Record gaps and decide whether the residual risk is acceptable.

What is the quickest useful test?

Export the connector scopes, compare them with the intended task, then time how long it takes to revoke access in a test environment.