Agent discovery security
Protect the process by which agents discover peers and tools
A registry or dynamic discovery service influences agent routing. The decision is how to protect the process by which agents discover peers and tools. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to security architects and discovery platform owners. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The interaction contracts relationship
- Registration rules
Establish the basis for published identity.
- Endpoint change
Review updates and destination binding.
- Discovery security assessment
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around published identity
Questions and the evidence they need
- Published identity
- Inspect registration rules for the relevant constraint or observation.
- Endpoint change
- Inspect metadata signatures for the relevant constraint or observation.
- Cached selection
- Inspect endpoint validation for the relevant constraint or observation.
The decision is how to protect the process by which agents discover peers and tools. This is relevant to security architects and discovery platform owners when a registry or dynamic discovery service influences agent routing. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that an untrusted entry replaces a legitimate endpoint or advertises a privileged role. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Discovery security continues after registration
Relationships within interaction contracts
- Published identity
- Validate origin and ownership of metadata.
- Endpoint change
- Review updates and destination binding.
- Cached selection
- Inspect stale or misleading entries at lookup.
What this specialty examines
Discovery security covers who can publish or modify entries and how consumers validate them. Inspect registry access, endpoint binding, metadata provenance and cache refresh. A trusted-looking description may be copied while its endpoint or ownership differs.
The review should review publication, update, lookup and cache behaviour using controlled misleading entries. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, open discovery improves reach while registration and verification determine who can influence routing. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for published identity
Illustrative working format
- Registration rules
- Confirm the applicable revision and who resolves disputed interpretation.
- Metadata signatures
- Establish permitted access, provenance, and which task conditions it represents.
- Endpoint validation
- Name the custodian and the conditions requiring a refreshed version.
- Cache policy
- Confirm the applicable revision and who resolves disputed interpretation.
Start with registration rules, metadata signatures, endpoint validation and cache policy. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the integration owner, agreed expectations for a representative interaction case, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which an untrusted entry replaces a legitimate endpoint or advertises a privileged role from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry published identity through to an accountable finding
From the scoped material to a decision record
- Registration rules
Agree the task meaning at the sending boundary.
- Endpoint change
Apply the scoped check to cached selection.
- Discovery security assessment
Record the evidence, open dependencies, and the owner’s next decision.
Fix the interaction contract and versions
Assemble registration rules, metadata signatures, endpoint validation and cache policy with security architects and discovery platform owners. Identify the participating implementations, interface revisions, authority assumptions and intended business result. Prepare messages and task-state examples from both sides, including an interrupted exchange and a disputed or incomplete outcome. The preparation output is a paired contract fixture showing what each participant expects and which differences would prevent the workflow from completing correctly.
Run and compare both sides of the exchange
Use controlled misleading entries to test selection and verification. Examine updates and stale caches as well as first registration. A previously accepted peer may change location or authority, so the design needs a defined refresh and withdrawal behaviour.
Choose the contract or integration change
Summarise the comparison in a discovery security assessment with provenance and selection-control findings. Classify each mismatch as interface validation, business meaning, identity, task state or operating behaviour. Decide whether to change a participant, add an explicit adapter rule, narrow supported combinations or defer the connection. Validate the affected pair again and preserve limitations that translation cannot resolve, especially around cancellation, authority and partial completion.
Indicative artefact
Make the discovery security assessment usable by its owner
Discovery security assessment
Illustrative working format
- Discovery security assessment
- Identify the assessed workflow, revision, and decision boundary.
- Provenance
- Link supporting and contrary observations to inspectable evidence.
- Selection-control findings
- Link observations and counterevidence to the case, configuration, and conclusion limit.
A useful decision artefact is a discovery security assessment with provenance and selection-control findings. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine cached selection through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Published identity
A cached discovery entry points to an endpoint changed after approval.
- Endpoint change
Compare cached endpoint metadata with its approved identity and update path.
- Cached selection
Refresh or reject entries whose endpoint authority is no longer established.
Consider a fictional situation: a synthetic registry entry copies a trusted agent’s description but points to an unapproved endpoint. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the copied description, verify identity and approved endpoint independently. The coordinator may display the metadata while refusing task delegation until trust conditions are satisfied. Discovery should supply candidates, not silently complete the authorisation decision.
Scope and next action
Keep the conclusion within named implementations and revisions
Confirm fit before the next commitment
- Published identity
- This review is limited to named implementations and revisions.
- Registration rules
- The relevant owner must confirm access and the intended operating conditions.
- Discovery security assessment
- Untested peers require their own compatibility evidence.
Compatibility is assessed for named implementations, versions, features and workflows. It does not establish universal conformance, vendor endorsement or interoperability with untested peers. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which a registry or dynamic discovery service influences agent routing; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
AI Agent Protocol Interoperability Lab
Find where connected agents disagree. Exercise message contracts, identity propagation and failure recovery across your selected integrations.
Continue exploring
Related insights and resources
How to design a joint AI evaluation lab
A joint lab should be a governed way to create decision evidence across organisations, with shared methods but explicit ownership of systems, data and conclusions.
Agent protocols are creating a new control surface
Protocols make tools and agents interoperable, but they also standardise discovery, delegation and context exchange. Those interfaces need explicit trust and policy controls.
A practical security review for an MCP server
Review an MCP server as a privileged protocol adapter: verify tool semantics, OAuth boundaries, token audience, downstream delegation, input handling, isolation, logging and consent.