DISPATCHES · Summit Cognitive

← All dispatches

InteroperabilityField NotesJuly 27, 20264 min read

The protocol is a new trust boundary

Open agent protocols create useful interoperability by moving instructions, tools, and context across systems—and every crossing creates a boundary that must be governed.

Protocols make systems feel closer than they are. A standard description lets an agent discover a tool, request a resource, or delegate work without a bespoke integration. The friction falls. Capabilities that once required an engineering project become available through configuration. This is the promise of interoperability, and it is real.

The security consequence is equally real. The protocol carries meaning across organizations, products, and policy domains. A tool server describes what it can do. An agent interprets the description. A host decides which context to send. A remote service returns content that may influence the next action. Every message crosses assumptions that were previously contained inside one application.

NIST’s 2026 AI Agent Standards Initiative rightly places open protocols alongside research into identity, authorization, security, and evaluation. These topics cannot be separated. Interoperability is not only agreement about message shape. It is agreement about how much trust a message is entitled to receive.

Discovery is an authority decision

When a protocol lets an agent discover available tools, discovery can look passive. It changes the agent’s action space. A newly visible capability may alter the plan, expose sensitive metadata, or invite the agent to send context beyond the boundary the user imagined. The list of tools is therefore part of the permission model, not merely a convenience catalog.

Descriptions themselves are inputs. NIST’s 2026 analysis of agent-security input reports broad agreement that established cybersecurity practices remain relevant but require adaptation for agents. A malicious or compromised server can give a tool a trustworthy name, place instructions in its documentation, or claim that a write is read-only. The host should bind tools to independently configured identities, consequence classes, and scopes before the model sees them.

A protocol standardizes how a capability is offered; it does not prove that the capability should be trusted.

Context transfer creates the next boundary. An agent may need a document excerpt to use a remote service, but not the entire conversation, system prompt, credential set, or hidden memory. Convenience pushes toward sending more context because larger context reduces integration errors. Security pushes toward purpose-limited disclosure. The protocol host must make that trade explicitly instead of letting the model decide what is safe to reveal.

Returned content deserves the same skepticism. Tool output can contain instructions, links, structured fields, or data that another component will execute. The protocol may authenticate the server and preserve message integrity while still delivering hostile semantics. Authentic content is not necessarily safe content; it is only content whose source is known.

Identity must cross with the request

A remote service needs to know more than which host connected. It may need the agent identity, the principal behind the task, the delegated scope, the purpose, and the expiration of authority. Without those facts, the server either grants broad access to a shared integration or rebuilds authorization from application-specific hints. Both choices weaken the promise of a common protocol.

The information should be selective. A service does not need the user’s full identity when a pseudonymous mandate will do. A tool does not need every upstream instruction when a signed purpose and bounded capability are enough. Protocol design should minimize what crosses while preserving what the recipient needs to enforce its own policy and produce a meaningful record.

Version negotiation is a trust question too. A new protocol revision may add richer tool calls, new content types, or changed defaults. Falling back silently to an older version can remove controls. Upgrading automatically can introduce semantics the host has not reviewed. The negotiated version, enabled extensions, and degraded modes should be visible and recorded for consequential work.

Failure behavior belongs in the boundary. If a server is unavailable, does the agent retry, choose another server, use cached data, or proceed without the tool? Each fallback changes the basis of the result. Interoperability that hides these transitions produces smooth experiences and ambiguous accountability.

Standards need operational profiles

A general protocol must support many uses. Deployments need narrower profiles that state which message types are permitted, which identities are accepted, what context may leave, how tool metadata is verified, which consequences require approval, and how events are logged. Conformance to the protocol is the floor. Conformance to the deployment’s trust profile is what makes the connection usable.

Evaluation should cross implementations. A secure host connected only to friendly test servers proves little about adversarial metadata, oversized responses, confused identities, or mismatched versions. Test suites should place independently built agents and servers at the boundary, vary their assumptions, and examine whether authority and provenance survive the exchange.

Operations teams should maintain an inventory of protocol connections as relationships, not just endpoints. The inventory can identify the owning team, accepted identity method, approved context classes, negotiated versions, enabled capabilities, review date, and shutdown path. When a remote server changes ownership or behavior, the organization can then find every place where its claims are trusted.

Open protocols are worth building because closed silos cannot support the ecosystem agents will need. Their value makes precision more important, not less. Every reduction in integration friction increases the number of systems an agent can reach and the speed at which trust can be misplaced.

The protocol is a new trust boundary because it is where one system’s claims become another system’s inputs. Govern discovery, identity, context, semantics, versions, and fallback at that crossing. Interoperability should let useful capabilities travel. It should not let authority become anonymous on the way.

— Dispatches · Summit Cognitive

Continue from here

Turn the argument into a practice.

Get new dispatches, assess how your organization handles consequential decisions, or explore Summit Cognitive.