AI agents load tools, connectors and skills at runtime. Each one is a dependency with access to your data. What to add to vendor intake before the next one is installed.
A connector nobody reviewed
A finance team starts using an AI assistant approved last quarter. The vendor passed review: a DPA, a SOC 2 report, a sub-processor list. This month an analyst adds two connectors so the assistant can read the shared drive and file tickets. One comes from the assistant's vendor. The other is an open-source MCP server found in a public directory.
Neither connector went through intake. The second has no contract, no named supplier and no support commitment, yet it now reads documents and writes to a production system with the analyst's credentials. From a risk point of view, the organisation just onboarded a new third party without noticing.
What changes when software acts on its own
Traditional vendor reviews assume a fixed product: you assess what it does, then it keeps doing that. Agents are different in three ways:
- They assemble their capabilities at runtime. The tools an agent can call depend on which servers, plugins and skills are connected today, not on what was reviewed at purchase.
- They take actions, not just answer questions. A connected tool can send messages, change records or move files.
- They act on text they read. Instructions can arrive inside a document, a web page, an email or a tool's own description, and the model may follow them.
MCP servers, plugins and skills are dependencies
The Model Context Protocol is an open standard that lets AI applications connect to external tools and data sources through MCP servers. It has made integrations much easier to build and install, which is exactly why they spread faster than review processes.
Treat each server, plugin or skill as what it is: software from a supplier, sometimes an individual maintainer, running with access to your data and systems. The OWASP Top 10 for LLM Applications (2025) lists supply chain risk (LLM03) next to prompt injection (LLM01) and excessive agency (LLM06) for this reason.
Four risks to look for
- Tool poisoning: a tool's description, which the model reads but users rarely see, carries hidden instructions such as reading a credentials file. Researchers at Invariant Labs published a demonstration of this against MCP clients in April 2025.
- Prompt injection through content: a document, ticket or web page the agent processes tells it to do something the user never asked for.
- Over-privileged access: a connector gets a broad token (full drive, all repositories, admin scope) when the task needs read access to one folder.
- Missing audit trail: nobody can say afterwards which tool the agent called, with what input, on whose behalf.
Your existing obligations already cover them
No new regulation is needed to bring agent tools into scope. If you are a financial entity under DORA, an MCP server that supports a business process is an ICT service from a third-party provider: Article 28 requires you to manage that risk and keep it in your register of information, and Article 30 sets the contract clauses. Under NIS2, Article 21(2)(d) asks essential and important entities to address security in their supply chain, including the security practices of direct suppliers.
If a connector processes personal data on your behalf, GDPR Article 28 applies: its operator is a processor or sub-processor, and you need a contract and authorisation for it. And under the EU AI Act, Article 4 already requires AI literacy for staff using AI systems, while Article 26 sets duties for deployers of high-risk systems. Our earlier posts, NIS2 asks about your suppliers and The AI Act delay explained, cover those duties in more detail.
What to add to vendor intake for agent tools
- Who publishes and maintains the server, plugin or skill, and is there a contract, licence or support commitment?
- Where does it run (locally, in your cloud, or hosted by the publisher), and where does your data go?
- Which tools does it expose, and what can each one read, write or send?
- What credentials and scopes does it need, and can they be limited to the task?
- Is the version pinned, and how are you told when its tool descriptions or behaviour change?
- Does it log tool calls with inputs, outputs and the user on whose behalf they ran?
- Which AI vendors on your list allow customers to add their own connectors, and who in your organisation approves them?
What to prepare if you publish agent tools
- A short description of each tool and the permissions it needs, in plain language.
- A changelog that flags any change to tool descriptions, not only to code.
- Your position on data handling: what is stored, where, and for how long.
- Logging your customers can export for their own audit trail.
See how a review links findings to the document
The ProcureCortex demo at procurecortex.com/explore (self-serve: email sign-in link, no sales call) shows vendor reviews where each finding points to the document and clause it came from, with a recorded reviewer decision. All vendors and findings in the demo are sample data; applying these agent-tool questions to your own suppliers is your team's analysis.
Sources
- Model Context Protocol, specification and documentation: https://modelcontextprotocol.io/
- OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/
- Invariant Labs, MCP Security Notification: Tool Poisoning Attacks (April 2025): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
- Regulation (EU) 2022/2554 (DORA), Articles 28 and 30: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Directive (EU) 2022/2555 (NIS2), Article 21: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulation (EU) 2016/679 (GDPR), Article 28: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Regulation (EU) 2024/1689 (AI Act), Articles 4 and 26: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
Get the vendor review guide
One email a month with a worked example like this one. Nothing else.