Skip to content

About this practice

Status
draft
Endorsement
none yet
Last reviewed
2026-07-26

Best practice 3

Register, vet, and manage agent interfaces through trusted channels

Practice

  • An agentAgentA system built around a language model that carries out multi-step work: it plans, calls tools, reads the results, and decides what to do next. The model supplies the reasoning; the surrounding harness does the acting. Distinct from a chat model that answers one prompt at a time. reaches tools, data, and actions outside the model through interfacesInterfaceA component added to an agent's harness so it can reach a tool, data source, or action outside the model, for example an MCP server, a skill, or a plugin. An interface runs code and acts for the user, so it is where much of the risk enters, which is why interfaces are registered and vetted (see Register, vet, and manage agent interfaces). (e.g., MCPMCP (Model Context Protocol)An open standard for connecting an agent to external tools, data, and actions. An MCP server is a common kind of interface: it exposes a set of tools an agent can call. Used throughout this record as the running example of an agent interface, alongside skills and plugins. servers, skills, plugins).
  • Each interface runs code and acts for the user, so each is a point where risk enters.
    For
    AgainstNone recorded
  • Interfaces should be published through a channel that lists and vets them.
    For
    Qualifies
    AgainstNone recorded
  • Listing makes an interface discoverable and records where it comes from and who maintains it.
  • Vetting is a separate step; a discoverable interface is not automatically safe.
    For
    AgainstNone recorded
  • Public interfaces (e.g., public GitHub repositories) are generally vulnerable to prompt injectionPrompt injectionAn attack that hides instructions inside content an agent reads (a web page, a document, a tool description), so the model follows them as if they came from the user. The user never sees the injected text, which is what makes it dangerous. Tool poisoning is one form, where the hidden instructions sit in an interface's tool description. attacks.
    For
    AgainstNone recorded
  • Safety and omnipotence are on a tradeoff; a system that can run arbitrary code (e.g., from web search) is vulnerable to injection – a system that cannot is less autonomous.

Prefer interfaces that have been vetted, not just listed. Before trusting one with your data or actions, check who maintains it, when it was reviewed, and what it is allowed to do. Presence in a registry is not a safety check on its own: an unvetted interface can carry prompt-injection or malware risk you cannot see from its description.

List your interfaces through a channel that records their source and maintainer, and have them vetted (reviewed or signed) before they are trusted. Route agent traffic through an approved, identified channel so you can shape and rate-limit it by identity, which beats blocking addresses that also blocks real users. If you adapt or repurpose someone else's interface, you may take on the duties of its provider.

Treat listing and vetting as two things: an inventory and a safety check. Back a trusted channel, require listed interfaces to record their source and review date, and make vetting (not mere registration) the point where risk is assessed. Keep more than one provider in use so the institution is not locked to a single vendor.

Reasons

An agent interface runs code and acts for the user. A malicious or careless one can carry malware or prompt-injection attacks hidden in a tool description, which the model reads but the user does not see. Prompt injection is the top-ranked risk in the OWASP Top 10 for LLM Applications, and tool poisoning is a documented attack on agent interfaces specifically. This is why listing and vetting are different acts. A registry that only lists (like the official MCP Registry, which records self-reported data and runs no security review) makes interfaces discoverable but guarantees nothing about safety. Vetting, a review or a signed provenance record, is what lets a user trust an interface. The same approved channel also makes traffic manageable: identified agent traffic can be shaped and rate-limited per identity, whereas blocking addresses also blocks real users, and modern bots rotate addresses anyway. Knowing where an interface comes from, and keeping more than one option open, avoids lock-in to a single provider.

Examples

  • A lab installs an MCP server because a public registry lists it and it has many stars, treating the listing as a safety check. The tool description carries instructions the model reads but the user never sees, and the agent leaks data on first use; nothing in the listing had vetted it.
  • A provider publishes its interface through a channel that records source, maintainer, and review date and signs it, so a user can see it was reviewed before trusting it with their data or actions.
  • An agent with web search and code execution reads a public repository issue that contains injected instructions and runs them; a colleague's agent, limited to a fixed set of read-only tools, is unaffected but can do less. The reach that makes an agent useful is the same reach that exposes it, so the safeguard has to match the capability.
  • A resource routes agent calls through an approved, identified channel and rate-limits per identity, instead of blocking address ranges that also lock out real users. It declares what automated clients may do in machine-readable form; the emerging IETF AIPREF vocabulary is one instance.
  • A group fine-tunes and repackages someone else's interface and ships it under their own name, without realising that under the EU AI Act a substantial modification can move the provider's duties onto them (the threshold is defined for high-risk systems and its exact bounds are still being clarified).
  • An institution keeps more than one agent ecosystem in use, so a critical resource is not reachable only through a single vendor's channel.
  • When the approved list is too narrow to do real work, people route around it: in one enterprise survey 40% of organisations bought an official tool while staff at over 90% used personal AI tools unofficially, often to better effect. A vetting process that watches what people actually reach for, and brings the useful cases into the trusted channel, holds up better than one that only blocks.

Sources

Change history

  • 2026-07-27: Added a "what it looks like in practice" example on shadow usage and vetting that learns from observed use, grounded in The GenAI Divide (MIT NANDA 2025) as a qualifier (bp3-a3).
  • 2026-07-27: Renumbered from BP02 to BP03 on inserting the new BP01 (match the method to the task).
  • 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns; kept the labelled instances (IETF AIPREF, EU AI Act Article 25) and cross-references.
  • 2026-07-26: Rewritten to separate listing from vetting (the official MCP Registry lists but does not vet), merge agent-traffic management into this practice, reframe traffic control around identified traffic rather than IP blocking, qualify the Article 25 point, and add OWASP, MITRE-adjacent, and AIPREF grounding.
  • 2026-07-25: Created from the ELIXIR TF distillation (hooks 9, 10), grounded in the HFD paper and the EU Expert Forum entry.

Discussion