Agent protocols are creating a new control surface

Protocols are turning agent tools, resources and collaborators into discoverable components. That is useful: teams can connect systems through a common contract rather than build every integration from scratch. It also creates a control surface where descriptions influence decisions, context crosses boundaries, identities are delegated and one component can invoke another.

Traditional API security still applies. Agent protocols add a particular complication: a model often interprets natural-language metadata and results while deciding what to call next. The interface is therefore both a software contract and part of the model’s decision context.

The protocol itself is not the risk. The risk lies in how trust, authority and data move through it.

Model the protocol as a chain of principals

Begin with the actors, not the message format. A typical tool-protocol path includes:

• a person or upstream service requesting an outcome;
• an agent host managing context and the model;
• a protocol client connecting to one or more servers;
• a server exposing tools or resources; and
• downstream systems where data is read or changed.

For every call, ask: who authenticated whom, whose authority is being exercised, which policy made the decision and where is the result recorded? A server using its own broad credential on behalf of many users can become a confused deputy. A host that presents every connected tool as equally trusted can let an untrusted description influence calls to privileged services.

The NIST NCCoE concept paper on software and AI agent identity discusses agent identification and authorisation using standards such as OAuth and policy-based access control. The design goal is not a special “agent permission.” It is verifiable identity, delegated rights and enforceable policy across the chain.

Discovery metadata is executable influence

In conventional APIs, documentation informs developers at design time. In agent protocols, tool names, descriptions and parameter schemas may be loaded into model context at runtime and influence selection. That makes metadata part of the decision surface.

Threats include:

• a tool description containing instructions unrelated to its function;
• a new tool using a similar name to shadow a trusted one;
• a server changing a definition after approval;
• a result embedding instructions that trigger another tool; and
• a registry or package supplying a compromised server.

The OWASP MCP Security Cheat Sheet catalogues risks including tool poisoning, definition changes, cross-server interference, over-scoped tokens and data exfiltration. Academic experiments have also reported model susceptibility to malicious tool descriptions and file-based or chained attacks (systematic MCP security analysis). Results from particular systems should not be assumed to generalise to every host, but they justify testing this interface under adversarial conditions.

Treat tool definitions as reviewed artefacts. Verify source, pin an approved version or digest, detect changes and require renewed review for semantic differences. Separate tools by trust domain so that adding a low-trust server does not silently expand what can influence a high-privilege action.

Identity and authority must survive the hop

A protocol can make a call interoperable without making it authorised. Each server should enforce an operation against a principal and grant it understands. Do not rely on the model to infer that the user is allowed, or on the host’s possession of a powerful shared token.

Record at least:

• requesting user or service identity;
• agent instance and host identity;
• delegated grant, scope, audience and expiry;
• tool server identity and approved version;
• downstream service principal actually used; and
• policy decision and approval bound to the call.

Prefer short-lived, audience-restricted credentials and least-privilege scopes. Bind approval to exact parameters when the action is consequential. If a plan changes, the previous approval should not be reusable. If the protocol does not carry the required identity context safely, place a policy-enforcement gateway before the downstream operation.

Context exchange needs a data-flow policy

Protocols can move prompts, documents, resource contents, tool results and conversation state. The host may combine information from several sources in one model context. That enables useful composition and creates paths for confidential data to reach an unintended server.

Define data classes and permitted flows before connecting servers:

Data class	Example control
Public context	May enter approved tools with normal logging
Internal business data	Restricted to named servers and purposes
Personal or confidential data	Minimised, redacted and retained under explicit policy
Credentials and secrets	Never placed in model-visible context; injected only at execution boundary
Untrusted content	Labelled by provenance and prevented from authorising actions

Validate structured responses before they enter another action. Free text from a remote tool is evidence, not instruction. Where transformation is required, preserve provenance so later components can distinguish user intent, system policy, retrieved content and tool output.

Composition turns local permissions into system risk

A read-only tool can become consequential when combined with a write tool. An agent that reads private files and can make web requests has an exfiltration path even if neither tool is labelled “send sensitive data.” A calendar tool plus a directory service can expose relationships. A code repository plus deployment access can alter production.

NIST’s tool-use taxonomy recommends considering function, access patterns, environment trust, reversibility, reliability and monitoring. Apply those dimensions to combinations, not only individual tools.

Create prohibited compositions and enforce them at runtime. Examples include preventing untrusted web content from directly influencing a high-privilege tool, isolating private retrieval from arbitrary network egress, or requiring approval whenever a workflow crosses from read to write. Test multi-step paths because attackers and accidental failures both exploit composition.

Protocol security includes ordinary engineering

Natural-language attacks should not distract from basic controls. Protocol implementations still need:

• authenticated and encrypted transport;
• message validation, size limits, timeouts and quotas;
• replay protection and idempotency for state-changing calls;
• tenant and session isolation;
• secure credential storage and rotation;
• dependency inventory and vulnerability management;
• network segmentation and egress controls; and
• logs that connect request, decision, call and result.

NIST’s adversarial machine-learning taxonomy provides a broader language for attacks and mitigations across AI lifecycle stages. Use it alongside API, identity, software-supply-chain and cloud threat models. Agent protocols combine these domains; they do not replace them.

Test the boundary as a living interface

Before approving a protocol connection, evaluate five layers:

1. Discovery: Can an unapproved server or changed definition appear?
2. Selection: Can misleading names or descriptions redirect the agent?
3. Authorisation: Are identity, scope and approval enforced per operation?
4. Exchange: Can results inject instructions or leak data across trust zones?
5. Operation: Are updates, incidents, revocation and decommissioning controlled?

Run adverse scenarios: duplicate names, changed descriptions, expired tokens, replayed writes, malformed results, slow servers, cross-tenant sessions, hidden instructions and compromised dependencies. Inspect the external state, not merely the transcript.

Protocols can improve security by making interfaces consistent and observable. That benefit appears only when the organisation standardises trust decisions as carefully as message formats. Treat every new server, tool and collaborator as a change to the authority graph. The protocol is a connection mechanism; governance decides what should be connected.

That governance should remain portable across protocol versions, so an interface upgrade cannot quietly weaken identity, data-flow or approval requirements already accepted by the organisation.

Interoperability creates value by making new connections easier. The assurance decision must make unintended authority harder at the same time.