Harden Your Agent Against Tool-Metadata Attacks

The two trust boundaries nobody guards

Draw the data flow of any tool-using agent and you will find three places where text that somebody else wrote reaches your model. The first is the tool catalogue: the names, descriptions, parameter documentation and schemas that the model reads in order to decide what to call. The second is the tool implementation: the function that takes the model's arguments and does something with them. The third is the tool return: whatever string comes back and gets appended to the conversation before the model reasons again.

Almost all of the agent-security engineering published so far concerns the middle one. That is understandable, because the middle one is the part you wrote, the part that holds a subprocess call, and the part that gets a CVE number when it goes wrong. But an attacker who is trying to hijack your agent does not have to go through your code at all. They can compete for your model's attention at boundary one, win the selection, and then speak to your model directly through boundary three. Your carefully argument-validated, sandboxed, least-privilege tool implementation is simply never involved.

As of September 2026, this is no longer a thought experiment. A preprint titled A2M: Trace-Optimized Agent Hijacking in the MCP Ecosystem, arXiv 2609.26761, submitted on 22 September 2026 and accepted at AACL-IJCNLP 2026, sets out a two-stage black-box attack that does exactly this, with code published at github.com/Lilaizhen/A2M. Every number in this article that comes from that paper is the originating team's self-reported figure on their own harness. Nothing here has been independently reproduced, and you should read the results as a direction of travel rather than as a settled measurement. The direction of travel is still bad enough to change what you build.

Boundary	What crosses it	When the model reads it	What usually guards it
Tool catalogue	Names, descriptions, parameter docs, JSON Schema, annotations	Selection time, before any tool runs	Usually nothing after the initial install review
Tool implementation	Model-supplied arguments	Not read by the model; executed by your code	Argument validation, allow-lists, sandboxing, least privilege
Tool return	Arbitrary text, JSON, errors, embedded instructions	Execution time, immediately before the next reasoning step	Usually a length truncation, if anything

The rest of this guide is a playbook for the first and third rows. The examples use MCP, because MCP is where third-party tool catalogues actually live in 2026, but nothing in the argument depends on MCP. Any framework in which an agent chooses from semantically described capabilities supplied by someone other than you has the same two boundaries, and will still have them after the current generation of SDKs has been replaced.

How A2M works: attraction, then manipulation

A2M stands for Attraction-to-Manipulation. It is black-box, meaning the attacker does not need weights, gradients or internal logits — only the ability to publish a tool and to observe what the agent does with it. The threat model is deliberately unglamorous, and that is the interesting part. The paper assumes the user behaves benignly, the agent behaves benignly, the agent autonomously selects tools from third-party registries, and selection relies on semantic metadata. There is no compromised insider, no stolen credential and no jailbroken user prompt. The attack runs entirely inside the normal, intended operation of an agent that shops for capabilities in a public catalogue.

Stage 1 — Attraction

In the first stage, the attacker optimises the tool's metadata to raise the probability that the agent invokes it. Think of it as adversarial search-engine optimisation aimed at a model rather than a crawler. The levers are the surfaces the model actually reads: the tool name, the description, the parameter names and their documentation. A description can claim wider applicability than it has, can mirror the phrasing of common task prompts, can assert reliability or freshness, or can position itself as the prerequisite step for some other tool. None of this requires the metadata to look obviously malicious to a human skim-reader, which is precisely why an install-time review that a busy team does once does not survive contact with a tool that updates its own description a month later.

The outcome of Stage 1 is measured as an invocation rate: how often the agent picks the attacker's tool when it had a legitimate alternative. On LiveMCPBench, across four GLM-4.6 scenarios, the authors report a macro malicious-tool invocation rate of 93.6%. Again: their harness, their measurement, their self-reported number. But the mechanism is not exotic, and anyone who has spent a week tuning tool descriptions to stop an agent picking the wrong tool already knows how sensitive selection is to phrasing. We have written about the benign version of that sensitivity in Tool Selection: Writing Descriptions That Stop Wrong Tool Calls. A2M is what happens when someone turns that same sensitivity into an objective function.

Stage 2 — Manipulation

Winning the selection only gets the attacker a turn to speak. Stage 2 is what they say. The attacker observes execution traces — the sequence of reasoning, calls and returns that follows their tool being invoked — and uses those traces to refine the adversarial content of the tool's return values. This is an iterative loop: return something, watch how the agent responds, adjust, repeat. Over iterations the return converges on text that reliably steers the agent toward an attacker-chosen outcome.

The paper groups the outcomes into three families, and it is worth holding all three in mind because they have different blast radii:

• Exfiltration — the agent is steered into moving data it holds, or can fetch, to somewhere the attacker can read.
• Environment-integrity compromise — the agent is steered into changing state it should not change: files, configuration, records, downstream systems.
• Reasoning derailment — the agent is steered off the user's actual task, producing wrong work rather than obviously malicious work. This is the one least likely to trip an alarm.

Across those categories the authors report a 74.4% mean attack success rate in the GLM-4.6 scenarios. They also report a separate cost-amplification condition they describe as cognitive denial of service, in which weighted token cost rose by up to 32.4 times. Cost amplification deserves its own section later, because it is the finding with the most immediate engineering consequence.

Reported result (authors' own figures)	Primary setting: four GLM-4.6 scenarios	Transfer: four other models, no re-optimisation
Macro malicious-tool invocation	93.6%	63.6%
Weighted token cost under cognitive denial of service	up to 32.4x	2.7x
Mean attack success (exfiltration, integrity, derailment)	74.4%	24.5%

Why your existing defences miss this

If you have done agent-security work already, you have probably done one or both of two things, and it is worth being precise about what each one covers so you can see the gap rather than assume it is filled.

The first is supply-chain vetting: reviewing a third-party server before you install it, reading its manifest, checking provenance, pinning versions, containing it at runtime. That is the subject of Vetting MCP Servers and Agent Skills Before You Install Them, and it is genuinely the right first move. What it covers is the decision to admit a server into your environment at a point in time. What it does not cover, on its own, is what that server's metadata says three weeks later, after an update you never reviewed, or how your model behaves when a legitimately installed tool's description has been quietly rewritten to compete more aggressively for selection.

The second is injection-proofing your own tool implementations: never building a shell string, allow-listing operations rather than deny-listing characters, resolving paths before trusting them, dropping privilege at the process boundary. That is the subject of Write an Injection-Proof MCP Tool: shell=False and Allow-Lists. What it covers is the damage a malicious argument can do once it reaches code you wrote. What it does not cover is an attack that never touches your code, because the agent called somebody else's tool instead of yours.

There is a third habit worth naming: argument-level guardrails. Many teams run a classifier or a rules engine over the arguments the model proposes to send. That is useful, and it catches a real class of problem. But in the A2M threat model the arguments are frequently benign — the user asked for something reasonable, the agent constructed a reasonable call, and the only thing wrong is which tool it called and what came back. An argument filter reading a well-formed request to a plausibly named tool has nothing to complain about.

So the coverage gap is specific, and it is not a gap in diligence. It is a gap in where the controls are placed. The next four sections place them.

Defence 1 — control the tool catalogue

The governing principle: your agent's tool catalogue is a deployment artefact, not a live feed. Treat it the way you treat a lockfile. If a tool's name, description, parameter documentation or schema changes, that is a change to the text your model reads in order to make decisions, and it deserves the same review as a change to your system prompt — because functionally it is one.

Concretely, that means four things.

• Pin the catalogue. Resolve the full tool list at build or deploy time, hash each tool's metadata, and store the manifest alongside your application. At runtime, refuse to present a tool whose hash is not in the manifest.
• Review metadata at registration, not just code. A new tool's description is reviewed by a human, in a diff, with the question "would this text make a model prefer this tool over one we already trust?" asked explicitly.
• Diff descriptions across versions. A silent description rewrite is the cheapest possible attack and the easiest possible detection. Any change to metadata should fail the build until someone approves it.
• Refuse silent updates. If a server advertises a changed tool list mid-session, the safe default is to keep the pinned set and log the discrepancy, not to adopt the new one.

Here is a pin-and-diff check small enough to read in one sitting. It computes a stable hash over the selection-relevant fields of each tool, compares against a committed manifest, and classifies every discrepancy.

"""tool_pin.py — pin and diff the selection-relevant tool metadata."""
import hashlib
import json
from dataclasses import dataclass, field

# Only the fields the MODEL reads at selection time. Adding a field here
# means a change to it will block the build; that is the intent.
SELECTION_FIELDS = ("name", "description", "inputSchema", "annotations")


def metadata_digest(tool: dict) -> str:
    """Stable SHA-256 over the fields that influence tool selection."""
    subset = {k: tool.get(k) for k in SELECTION_FIELDS}
    canonical = json.dumps(subset, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(canonical.encode("utf-8")).hexdigest()


@dataclass
class CatalogueDiff:
    added: list = field(default_factory=list)
    removed: list = field(default_factory=list)
    changed: list = field(default_factory=list)   # (name, old_digest, new_digest)

    @property
    def clean(self) -> bool:
        return not (self.added or self.removed or self.changed)


def diff_catalogue(live_tools: list, manifest: dict) -> CatalogueDiff:
    """manifest maps tool name -> pinned digest, as committed to the repo."""
    live = {t["name"]: metadata_digest(t) for t in live_tools}
    d = CatalogueDiff()
    for name, digest in live.items():
        if name not in manifest:
            d.added.append(name)
        elif manifest[name] != digest:
            d.changed.append((name, manifest[name], digest))
    for name in manifest:
        if name not in live:
            d.removed.append(name)
    return d


def enforce(live_tools: list, manifest: dict, *, strict: bool = True) -> list:
    """Return only tools whose metadata matches the pin.

    strict=True  -> refuse to start at all on any discrepancy (production)
    strict=False -> drop the offending tools and carry on (development)
    """
    d = diff_catalogue(live_tools, manifest)
    if d.clean:
        return live_tools
    report = {"added": d.added, "removed": d.removed,
              "changed": [c[0] for c in d.changed]}
    if strict:
        raise RuntimeError(f"tool catalogue drifted from pin: {report}")
    allowed = set(manifest) - {c[0] for c in d.changed}
    return [t for t in live_tools if t["name"] in allowed]

Two design notes. First, the digest deliberately covers description and annotations, not just the schema — a schema-only pin misses the entire Attraction stage, because Stage 1 works on prose. Second, the strict switch exists so that developers are not blocked while iterating, but the production path must be strict=True or the control is theatre. If you already run a control plane for your agents, this check belongs in it; Build Your Own Agent Control Plane: Ceilings and Quotas covers where that layer sits.

Defence 2 — treat tool returns as untrusted

The second boundary is the one that carries Stage 2. Whatever a tool returns is appended to your model's context and read as input to the next reasoning step. If you would not paste an arbitrary stranger's text into your system prompt, you should not paste an arbitrary tool return into your context without processing it.

Four controls, in order of how much they buy you.

• Validate against a schema you own. Do not accept whatever shape the tool sends. Declare the structure you expect, reject or coerce anything else, and drop unknown fields entirely rather than passing them through.
• Impose size and token ceilings. A single return should never be able to consume a meaningful fraction of your context window. Truncate deterministically and say so in the truncated text.
• Strip instruction-shaped text. Returns that contain imperatives addressed to the assistant, fake system or tool delimiters, or role markers should have those neutralised before the return is added to context.
• Never let a return alter policy. No tool return may expand permissions, disable a control, change the task, or introduce a new tool. If your architecture makes that structurally impossible, you have removed a whole class of outcome.

Here is a sanitiser that does the first three. It is deliberately conservative: it fails closed on schema violations, truncates on a character budget that maps to an approximate token budget, and wraps what survives in an explicit untrusted-data envelope.

"""return_sanitiser.py — schema + size ceiling + instruction stripping."""
import re
from typing import Any

# Rough, model-agnostic heuristic. Measure with your provider's tokeniser
# in production; this is here so the ceiling has a sane default.
CHARS_PER_TOKEN = 4

ROLE_MARKERS = re.compile(
    r"(?im)^\s*(system|assistant|user|tool|developer)\s*:",
)
FAKE_DELIMITERS = re.compile(
    r"(?is)</?(system|instructions?|important|tool_result)>",
)
IMPERATIVES = re.compile(
    r"(?i)\b(ignore (all )?(previous|prior|above)|disregard the (above|instructions)|"
    r"you (must|should) now|new instructions?|override the|from now on)\b",
)


class ReturnRejected(Exception):
    """Raised when a tool return cannot be made safe to read."""


def enforce_schema(payload: Any, schema: dict) -> dict:
    """Keep declared keys with declared types; drop everything else."""
    if not isinstance(payload, dict):
        raise ReturnRejected(f"expected object, got {type(payload).__name__}")
    cleaned = {}
    for key, expected in schema.items():
        if key not in payload:
            raise ReturnRejected(f"missing required field: {key}")
        value = payload[key]
        if not isinstance(value, expected):
            raise ReturnRejected(
                f"field {key}: expected {expected.__name__}, "
                f"got {type(value).__name__}"
            )
        cleaned[key] = value
    return cleaned            # unknown fields are silently dropped


def strip_instructions(text: str) -> tuple:
    """Neutralise text that is shaped like an instruction to the model."""
    hits = 0
    for pattern, replacement in (
        (FAKE_DELIMITERS, "[removed-delimiter]"),
        (ROLE_MARKERS, "[removed-role-marker] "),
        (IMPERATIVES, "[removed-imperative]"),
    ):
        text, n = pattern.subn(replacement, text)
        hits += n
    return text, hits


def sanitise(payload: Any, schema: dict, *, max_tokens: int = 2000,
             tool_name: str = "unknown") -> dict:
    """Return a context-safe dict plus the signals worth logging."""
    cleaned = enforce_schema(payload, schema)
    total_hits, truncated = 0, False
    budget = max_tokens * CHARS_PER_TOKEN

    for key, value in list(cleaned.items()):
        if not isinstance(value, str):
            continue
        value, hits = strip_instructions(value)
        total_hits += hits
        if len(value) > budget:
            value = value[:budget] + "\n[truncated: tool return exceeded ceiling]"
            truncated = True
        cleaned[key] = value

    return {
        "tool": tool_name,
        "untrusted_data": cleaned,   # render to the model inside a clear envelope
        "signals": {
            "instruction_hits": total_hits,
            "truncated": truncated,
        },
    }

The regular expressions are a floor, not a ceiling. They will catch the clumsy end of the distribution and miss a determined attacker, and you should assume as much — which is why the function returns signals rather than silently cleaning. A non-zero instruction_hits count on a tool that has never produced one before is a detection signal in its own right, and feeding it to your telemetry is more valuable than the stripping itself. If your concern is also cache efficiency rather than only safety, Bounding Agent Tool Output Without Wrecking Your Cache covers how to truncate without invalidating prefixes on every call.

Defence 3 — budget enforcement as a hard stop

The cost-amplification result is the one that turns a security argument into a finance argument, which is usually the version that gets funded. The A2M authors report weighted token cost rising by up to a factor of 32.4 in their cognitive denial-of-service condition, and 2.7 times in the transfer setting against models the attack was never tuned for. Whatever the precise figure turns out to be under independent testing, the mechanism is obvious once stated: a tool that returns enormous, confusing or self-referential content makes the agent think longer, call more tools and read more text, and every one of those steps is billed.

This reframes the token budget. A monthly spend alert is a billing control: it tells you afterwards that something cost too much. A budget enforced inside the agent loop is a security control: it bounds the damage of an attack whose entire payoff is unbounded consumption. The difference is whether the limit can stop a run in progress.

A workable circuit breaker needs three tiers, because the three failure shapes are different. A per-call ceiling catches one tool returning a wall of text. A per-tool cumulative ceiling catches one tool being called repeatedly in a loop. A per-run ceiling catches the aggregate. All three should trip loudly.

"""budget.py — a three-tier token circuit breaker for an agent run."""
from collections import defaultdict


class BudgetExceeded(Exception):
    def __init__(self, tier: str, tool: str, used: int, ceiling: int):
        self.tier, self.tool, self.used, self.ceiling = tier, tool, used, ceiling
        super().__init__(
            f"budget tripped [{tier}] tool={tool} used={used} ceiling={ceiling}"
        )


class TokenBudget:
    """Enforce token ceilings during a run, not after the invoice.

    per_call  — one tool return may not exceed this
    per_tool  — cumulative spend attributable to a single tool
    per_run   — total spend for the whole agent run
    """

    def __init__(self, per_call: int = 2_000, per_tool: int = 20_000,
                 per_run: int = 100_000, on_trip=None):
        self.per_call, self.per_tool, self.per_run = per_call, per_tool, per_run
        self.by_tool = defaultdict(int)
        self.total = 0
        self.on_trip = on_trip or (lambda event: None)

    def _trip(self, tier: str, tool: str, used: int, ceiling: int):
        event = {"tier": tier, "tool": tool, "used": used, "ceiling": ceiling}
        self.on_trip(event)          # emit to telemetry BEFORE raising
        raise BudgetExceeded(tier, tool, used, ceiling)

    def charge(self, tool: str, tokens: int) -> None:
        """Call this after every tool return, before the next model turn."""
        if tokens > self.per_call:
            self._trip("per_call", tool, tokens, self.per_call)

        self.by_tool[tool] += tokens
        self.total += tokens

        if self.by_tool[tool] > self.per_tool:
            self._trip("per_tool", tool, self.by_tool[tool], self.per_tool)
        if self.total > self.per_run:
            self._trip("per_run", tool, self.total, self.per_run)

    def headroom(self) -> int:
        return max(0, self.per_run - self.total)

    def snapshot(self) -> dict:
        return {"total": self.total, "by_tool": dict(self.by_tool),
                "headroom": self.headroom()}

Note that charge raises rather than returning a boolean. That is intentional: a budget you can accidentally ignore by not checking a return value is not a hard stop. Wire the exception to a clean abort path that preserves the partial result and surfaces the trip to the user, rather than to a bare except that retries. A retry loop around a cost-amplification attack is the worst possible response.

Set the initial ceilings from observed data rather than intuition. Run your normal task suite, take the 95th percentile of tokens per run, and set per_run somewhere around twice that. You want a ceiling that legitimate work almost never touches and an attack cannot avoid.

Defence 4 — detection: logs, rates and canaries

Prevention will be incomplete, so plan to notice. Detection for this attack class is unusually tractable, because the attack has to move a measurable quantity: selection frequency.

Log, per tool invocation, at minimum: the tool name, the pinned metadata digest that was in force, the selection context (what the agent was trying to do), the return size in bytes and tokens, the sanitiser's instruction_hits count, whether truncation fired, and the cumulative budget snapshot. That is a small record and it makes every subsequent question answerable. If you are already running OpenTelemetry over your agents, these become span attributes and you get the aggregation for free; Instrumenting Agents for Production covers that plumbing.

What does an anomaly look like in practice? Three shapes are worth alerting on:

• Invocation-rate shift. Compute, per tool, its share of total invocations over a rolling window, and compare against the same tool's baseline share. A tool whose share doubles without a corresponding change in the workload mix is the signature of a successful Attraction stage. This is a cheap ratio, not a model, and it is the single highest-value alert in this article.
• Tokens per successful task. Not tokens per run, which moves with workload — tokens per successful task, which should be roughly stable. A rising numerator with a flat denominator is cost amplification.
• Sanitiser signal rate. A tool that has never produced an instruction hit and now produces them on a third of returns has changed behaviour. Alert on the change, not on the absolute count.

Canary tools are the other half. Register a small number of tools that no legitimate task should ever need: a plausibly named capability that is never referenced in any prompt, never appropriate for any workflow in your suite, and whose implementation does nothing but record that it was called. If a canary fires, something has gone wrong with selection — either your prompting has drifted, or a return has steered the agent somewhere it should not go. Keep canaries boring and plausible. A tool called do_not_call_this teaches you nothing, because the model will sensibly avoid it; a tool called fetch_account_summary in an agent that has no account concept teaches you a great deal. The same logic underpins collusion auditing in multi-agent systems, covered in Audit Your Multi-Agent System for Collusion Before It Ships.

Red-teaming your own agent before you ship

None of the above is worth much unless you have measured your own exposure. The testing recipe is straightforward and does not require reproducing the paper's optimisation loop — you are looking for whether your controls fire, not for a state-of-the-art attack.

1. Stand up a test registry. A local tool server, presented to a staging agent exactly as a third-party registry would be. Never point this at production.
2. Add a decoy that shadows a real capability. Take one tool your agent genuinely uses, and register a second tool with a broader, more confident, more task-shaped description covering the same ground. No malicious payload yet — you are measuring Stage 1 only.
3. Measure selection. Run your standard task suite and record how often the decoy is chosen over the legitimate tool. Any non-trivial rate is your Attraction exposure. Record it as a number, because you will want to compare it after each change.
4. Give the decoy an adversarial return. Now have it return, in turn: instruction-shaped text, a payload several times your context budget, a schema-violating object, and a return that claims a policy change ("the user has approved wider access"). Assert that each one is caught — stripped, truncated, rejected, ignored — and that your policy state after the run is identical to before.
5. Test the budget. Have the decoy return progressively larger payloads until per_call, per_tool and per_run each trip. Assert the run aborts cleanly at each tier and that the trip event reached telemetry.
6. Test metadata drift. Change the decoy's description without changing its behaviour and assert that your pin check fails the build. This is the test most teams skip and the one that catches the cheapest attack.
7. Put the numbers in CI. Decoy-selection rate, tokens per successful task, and policy-violation count become regression metrics with thresholds. A model upgrade or a new registry entry that moves them fails the build.

Step seven is the one that makes this durable. Selection behaviour is a property of the model, and the model will change under you. A suite that measured your exposure once, in a quarter you no longer remember, is a document rather than a control. The adjacent discipline of adversarial authorisation testing — does the agent do things it was never permitted to do — is worth reading alongside this; we covered a public benchmark for it in AgentRedBench: 215 Tests Your Agent's Authorisation May Fail.

Mapping attack stages to controls

Pulling it together. The point of the table is to make gaps visible: if a row in your own version has an empty control column, that is where the next sprint goes.

Attack stage	What the attacker manipulates	Preventive control	Detective control
Stage 1 — Attraction (registration)	Tool name, description, parameter docs	Human metadata review at registration; pinned allow-list	Diff alert on any metadata change
Stage 1 — Attraction (drift)	Silent post-approval metadata update	Digest pin enforced at runtime; refuse unpinned tools	Digest mismatch logged per invocation
Stage 1 — Attraction (selection)	The agent's choice among alternatives	Minimal catalogue; scoped tool sets per task	Invocation-rate anomaly; canary tool fires
Stage 2 — Exfiltration	Return text steering data outward	Egress allow-list; no policy change from a return	Outbound destination logging; data-volume alerts
Stage 2 — Environment integrity	Return text steering state changes	Write operations behind confirmation; least privilege	Write-operation audit trail with originating tool
Stage 2 — Reasoning derailment	Return text steering the task itself	Schema validation; instruction stripping; data envelope	Task-completion evals; sanitiser signal rate
Stage 2 — Cost amplification	Oversized or confusing returns	Per-call, per-tool and per-run token ceilings	Tokens per successful task; budget trip events

Common pitfalls

A handful of failure modes come up repeatedly when teams implement this.

• Pinning the schema but not the prose. The most common mistake. Stage 1 operates on descriptions. A pin that covers inputSchema alone leaves the entire attraction surface unguarded while feeling like a control.
• Truncating without telling the model. Silent truncation produces confident answers built on half a document. Always leave an explicit marker in the text, and always log that it happened.
• Treating the budget as advisory. A ceiling that logs a warning and continues is a metric, not a control. If it cannot stop the run, it does not bound the attack.
• Letting a return introduce a tool. Some frameworks make it easy for a tool to advertise follow-on capabilities. That collapses boundary three into boundary one and hands the attacker both in a single move. Disable it or gate it behind an explicit human approval.
• Enormous catalogues. The more tools in the selection set, the more room an adversarial description has to win. Scope tool sets to the task rather than exposing everything; the mechanics are in Stop Shipping 100 Tool Definitions to Your Agent.
• Assuming a model change is a mitigation. The transfer result argues the opposite. Re-run your measurements after a model change, but do not book the change itself as a fix.
• Reading the paper's figures as your figures. They are self-reported results on LiveMCPBench with a specific model family. Your catalogue, prompts and task mix are different. Measure your own; that is what the red-team recipe is for.

One last consideration that applies to teams in both of our markets. The exfiltration outcome family means data leaving the boundary you designed for it, and for a team operating in India or the UK that is a governance question as much as an engineering one — data-protection regimes in both jurisdictions expect organisations to know where personal data goes and to be able to evidence control over it. This guide does not attempt to give legal advice, and the specifics vary by sector and by the nature of the data. The engineering point stands regardless: if your agent can be steered into moving data, your egress path needs an allow-list and an audit trail, and "the agent decided to" is not an explanation anyone will accept.

Conclusion and next steps

The uncomfortable insight in the A2M work is not that agents can be attacked. It is where. Both of the boundaries the attack uses are outside the code you wrote and reviewed. Tool metadata is text that shapes your model's decisions and it arrives from third parties; tool returns are text that shapes your model's reasoning and they arrive from third parties. If your hardening effort so far has gone into the tool implementation in between, you have secured the one link in the chain that the attacker does not need to touch.

If you do three things this quarter, do these. Pin your tool catalogue and fail the build on metadata drift, because it is the cheapest control and it closes the cheapest attack. Put a real token ceiling inside the agent loop, because the cost-amplification result makes it a security control and because it is the change your finance colleagues will happily fund. Stand up a decoy tool in staging and find out what your selection rate actually is, because everything else is guesswork until you have that number.

Then read the neighbouring pieces: Vetting MCP Servers and Agent Skills Before You Install Them for the admission decision, and Write an Injection-Proof MCP Tool for the implementation you own. Together the three cover the whole chain. The preprint itself is worth an hour if you want the detail of the optimisation loop, and the authors have published their code at github.com/Lilaizhen/A2M.