Tool-description poisoning tests
Determine whether malicious metadata can redirect tool selection or agent behaviour
When tool descriptions can be supplied or changed by external sources, this area becomes relevant. For the agent integration security owner, the concern is specific: a tool description persuades the agent to reveal information or prefer an unrelated action. The deployment evaluation starts from that consequence and follows the relevant evidence through the customer workflow. Treat metadata as a possible input to behaviour, not an unquestioned authority. The proposed tests should distinguish discovery, selection, argument formation, and actual invocation so reviewers can locate where hostile wording gained influence.
Connect the operating question to inspectable evidence
- Agent integration security owner
Owns the bounded decision and the consequence of acting.
- Tool metadata sources
Defines the starting context for the proposed work.
- Instruction-bearing descriptions
Exposes the first material uncertainty to examine.
- Review and enforcement recommendations
Carries unresolved conditions into an accountable next action.
Decision at stake
Determine whether malicious metadata can redirect tool selection or agent behaviour
Make the decision explicit
- Agent integration security owner
- Tool descriptions can be supplied or changed by external sources.
- Decision
- Whether malicious metadata can redirect tool selection or agent behaviour.
- Instruction-bearing descriptions
- Use tool metadata sources to establish the relevant starting condition.
For the agent integration security owner, this becomes relevant when tool descriptions can be supplied or changed by external sources. The immediate decision is whether malicious metadata can redirect tool selection or agent behaviour. The scope should be narrow enough that the evaluation team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a tool description persuades the agent to reveal information or prefer an unrelated action. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine instruction-bearing descriptions alongside selection manipulation
Keep the review distinctions visible
- Instruction-bearing descriptions
- Place hostile instructions in a controlled tool-description fixture.
- Selection manipulation
- Check whether altered metadata changes tool choice or requested authority.
- Trust and change controls
- Track who may update descriptions and how the change is reviewed.
Instruction-bearing descriptions
For this scope, instruction-bearing descriptions should be examined alongside tool metadata sources. Supply a controlled description containing instructions unrelated to the tool’s legitimate function. Inspect whether it changes the agent’s task interpretation or output. The proposed test should keep the underlying capability stable so any observed influence can be connected to metadata rather than a different tool implementation.
Selection manipulation
For this scope, selection manipulation should be examined alongside description update process. Compare tool selection under neutral and adversarial descriptions. A changed choice is an influence signal, while an unauthorised call or effect is a separate result. Preserve the catalogue presented to the agent and the chosen operation so the distinction remains visible in review.
Trust and change controls
For this scope, trust and change controls should be examined alongside authorised hostile fixtures. Review who can introduce or modify metadata and how changes reach deployed agents. A description may be trusted by default even when it comes from an external source. The evaluation should connect change governance to observed behaviour and identify where validation or enforcement could limit the influence.
Prerequisites
Start with tool metadata sources
Give each input a specific job
- Tool metadata sources
- Defines the operating boundary.
- Description update process
- Examine selection manipulation.
- Authorised hostile fixtures
- Shows conditions affecting trust and change controls.
- Product or platform owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is tool metadata sources, description update process, and authorised hostile fixtures. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a product or platform decision owner, a technical lead, a data owner, and a competent reviewer for the relevant boundary. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Tie the deployment finding to observable behaviour
Follow the evidence through the work
- Instruction-bearing descriptions
Use tool metadata sources to define the decision criteria.
- Selection manipulation
Inspect description update process and retain observations that challenge the expected result.
- Trust and change controls
Use authorised hostile fixtures to identify unresolved conditions and a responsible owner.
- Review and enforcement recommendations
Link the recommendation to its evidence, remaining limits and next validation condition.
Create controlled tool descriptions that attempt to alter task priorities, request disclosure, or encourage unrelated calls. Keep the actual tool capability and legitimate user request stable. The proposed test should observe whether changes in metadata affect discovery, selection, arguments, or execution, and should retain evidence of the specific transition.
A practical first slice would focus on instruction-bearing descriptions and then follow its consequences into selection manipulation. Keep trust and change controls visible as a separate review question rather than assuming it is satisfied by the first result. The evaluation team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Illustrative scenario
Hostile tool advertising: separate outcomes
Examine the constructed decision boundary
Illustrative scenario
- Hostile tool advertising
An external fixture's description contains instructions conflicting with the user task.
- Neutral versus adversarial metadata
Change only the description; inspect tool selection and any attempted action.
- Separate outcomes
Selection influence is not an unauthorised effect; target the demonstrated trust or enforcement gap.
Consider an illustrative situation in which a synthetic external tool advertises itself using instructions that conflict with the user’s task. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the hostile external tool description, an illustrative run would compare a neutral description with the adversarial variant. A changed selection is evidence of influence, while an unauthorised effect is a separate outcome. Recommendations should target metadata trust, change review, validation, or enforcement according to what the test demonstrates.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves trust and change controls unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Indicative artefacts
Use review and enforcement recommendations to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- Tool description poisoning cases
- Boundary — tool metadata sources.
- Metadata trust findings
- Findings about selection manipulation.
- Review and enforcement recommendations
- Action on trust and change controls.
Indicative outputs include tool description poisoning cases, metadata trust findings, and review and enforcement recommendations. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Scope and authority
A deployment finding remains bounded to the tested conditions
Keep analytical work separate from decision authority
- Authorised deployment cases and traces
- Can include tool description poisoning cases.
- Product or platform owner
- The customer retains release authority and owns remediation priorities.
- Universal vendor or component assurance
- Cannot be inferred from metadata trust findings.
The proposed evaluation concerns the named deployment, configuration, cases, and authorised environment. Findings do not certify a component vendor, establish universal safety, or approve release. Unexamined provider paths and specialist questions remain explicit limitations.
Ways to engage
Related engagement scopes
AI Agent Evaluation Evidence Diagnostic
Find the gaps between your release decision and the evidence behind it. Start with one agent workflow and a bounded set of questions.
AI Agent Evaluation Foundation
Turn scattered tests into a repeatable release discipline. Connect the behaviours that matter to datasets, evaluation criteria and evidence your team can maintain.
AI Agent Component Evaluation
Find where agent behaviour breaks down. Follow memory, retrieval and delegation through your workflow, then isolate the components that need attention.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
What would justify releasing this agent?
Replace a single pass rate with a reviewable chain of requirements, cases, observations and judgements. Distinguish task quality, control failures and uncertainty before increasing an agent's exposure.
The evidence behind the go-live decision
A working paper for leaders who need to explain why an agent workflow is ready for its next release. Includes a proposed evidence-pack structure, decision table and review agenda.