In most companies the security discussion around AI systems revolves around the organisation own application. What was built internally gets reviewed, what runs in the internal environment gets protected. That view is necessary and by now established in many organisations. It nonetheless falls short, because the greater part of a productive AI system was never built in house. The model comes from one vendor, the vector database from a second, the tool integration from a third, and the connector through which the agent reaches the CRM was contributed by a service provider. The attack surface therefore begins well before your own system boundary, while the risk ends entirely inside your own house.
The attack surface does not end at the system boundary
A productive agent typically has four supplied components that can be compromised independently of one another. The model itself, whose behaviour shifts with every vendor update without the company learning about it. The tools and connectors through which the agent acts, frequently included as open source components and rarely reviewed with the same care as a classic library. The knowledge base, into which content flows from sources nobody fully controls. And the operating platform on which all of this runs, whose logging determines whether an incident can be reconstructed at all.
The difference to the classic software supply chain lies in the mechanism. A compromised library executes code. A compromised knowledge source or a manipulated tool schema introduces language, and language is an instruction inside an agent system. No exploit in the technical sense is required, a text in the right place is enough. This is precisely why review patterns aimed at known vulnerability classes fail completely here. They search for code while the risk sits in the content.
Why standard supplier reviews do not apply here
Almost every corporation runs an established supplier review process. It asks about certifications, about the location of data processing, about data processing agreements and about the financial stability of the vendor. Those questions are right and remain so. They answer not a single one of the questions that actually determine risk with a model or tool vendor. An ISO certification says nothing about whether inputs are used as training material. A server location inside the European Union says nothing about whether the model responds differently to the same input after an update.
There is also a structural difference in the relationship. With classic software the purchased version is stable until the company installs an update. With a model behind an interface, the product changes without the customer intervening or being informed. Behaviour covered by your own review yesterday may deviate today. The one-off approval thereby loses its meaning, because it refers to a state that does not persist. Anyone who fails to address this point documents a review that is long outdated by the time an incident occurs.
Five pieces of evidence needed before signing
Five requirements follow from this situation, and they translate concretely into procurement. First, a contractual commitment on data usage that explicitly governs whether inputs and outputs are used for training, evaluation or quality assurance and how long they are retained. Second, an obligation to give advance notice of model changes and material behavioural shifts, combined with a deadline that permits your own re-examination. Third, access to log data at a depth that allows reconstruction during an incident, because without that access every investigation remains a conjecture.
Fourth, evidence of the provenance of the components the vendor itself supplies, in the form of a bill of materials that also covers models, tool schemas and prompt templates rather than libraries alone. Fifth, the right to run your own adversarial tests against the purchased service, explicitly assured in the contract. This fifth point fails most often in negotiations and is at the same time the most valuable, because without it every review ends at the vendor boundary. Anyone unable to secure it should at least document that limitation and make it visible in the risk assessment.
Red teaming across the vendor boundary
What can be tested in this constellation is not the vendor but the composed system under realistic assumptions. That changes the scope of a red teaming engagement. Instead of asking whether the model withstands a jailbreak, the question becomes what happens when a supplied knowledge source contains manipulated content, when a tool schema describes more permissions than intended, or when a connector returns answers that the agent reads as instructions. These scenarios are not hypothetical, they describe exactly the paths by which purchased components become an entry point in practice.
For steering, a second cadence follows alongside the internal one. Every new supplied component passes a review against these scenarios before approval. Every reported model or interface change triggers a targeted retest of the affected paths. And at least once a year it is verified whether the vendor contractual commitments still match what actually applies, because terms of use change more often than contracts are renegotiated. This second cadence is the part missing from most security programmes to date.
Conclusion and recommendation
An AI system is largely purchased, and security work has to follow that fact. For the next ninety days we recommend three steps. First, an inventory of all external components of productive AI applications, explicitly including tools, connectors and knowledge sources, because this layer is almost never captured in existing registers. Second, add the five pieces of evidence to the standard procurement questionnaire so they do not depend on the negotiating strength of the individual case. Third, define a review scenario for supplied components and run it through completely once against a productive system.
As part of AI Security and Red Teaming, ECODYNAMICS tests exactly these composed systems and helps companies formulate vendor requirements in a way that remains enforceable in procurement. We bring the attacker perspective, document findings in an audit-proof form and translate them into requirements that procurement and the security function can actually work with. If models, agent platforms or connectors are currently being procured at your organisation, talk to us before anything is signed.