Our MCP server returns content other people wrote, such as dataset descriptions, ticket bodies, comments or web pages. Is it our job as the server author to clean that text before it reaches the agent, or is prompt injection through tool results only the client's problem, and what does cleaning it actually involve?

What should I check, step by step?

1. List every field your tools return that a third party can write: titles, descriptions, notes, comments, file names, URLs, log lines, email bodies. Treat all of them as untrusted, in markdown output and JSON output alike.

2. Encode them in one place, where tool results are assembled, so a new tool can't skip the step: escape markdown structure (headings, links, images, HTML) and neutralize lines that address the assistant or claim to be system instructions.
3. Validate URL schemes, for example https only, before rendering a value as a link. Render a URL you can't validate as plain text; the CKAN report showed a url value breaking out of markdown link syntax.
4. Put third-party text inside a clearly labelled block that says it comes from an outside source, and keep your own status lines outside it, so injected text can't pass as your server's output.
5. Prefer structured output with a fixed schema (outputSchema and structuredContent) and return only the fields the task needs. Long free-text bodies are where instructions hide.
6. Don't pair an untrusted-content reader with powerful tools on the same server without a guard. The CKAN advisory rated hijacking the highest-impact harm because the server also exposed SQL and search tools the injected text could invoke.
7. Say in your README which tools return third-party content, so integrators know which results must never be treated as instructions.
8. Add a test with a hostile fixture, such as a description containing an instruction, a fake heading and a markdown link, and assert the rendered result keeps it escaped inside the data block.

How did the CKAN MCP server advisory GHSA-c499-9f77-93m8 let dataset text hijack an AI agent?

The CKAN MCP server lets an agent search and read open-data portals. Its advisory says ckan_package_show and its sibling renderers built results by inserting a dataset's title and notes, each resource's name, description and url, and group titles straight into markdown, and the JSON path copied the same fields unchanged. Those fields are free text written by whoever published the dataset, and the server_url argument can point at any portal, including one an attacker runs.

• The advisory lists two harms from the one defect. Agent hijacking: a dataset's notes can carry instructions, such as calling ckan_datastore_search_sql, sending out rows that contain "token" and not telling the user, and they arrive at the model as tool output. Content spoofing: injected headings, a fake "Verified by portal admin" status and phishing links render in the user's client as if the tool produced them. No authentication is needed: publish a dataset on a portal the victim queries, or get the victim to point the tool at your own portal.
• It is rated moderate (CVSS 3.1 6.9) under CWE-74, improper neutralization of special elements in output used by a downstream component, and fixed in 0.4.109. The advisory explains the changed scope in its score: the harm lands on the agent and the tools it can reach, not on the CKAN server itself.

How should an MCP server encode and delimit third-party text in its tool results?

The advisory's remedy is a single neutralization pass at the one point where tool results are assembled, covering both markdown and JSON. Every portal-controlled value goes through one encoder that defangs markdown control characters and directive-looking lines and checks URL schemes before a value becomes a link. The encoded text is emitted inside a clearly delimited, non-authoritative block, and the docs tell integrators that portal content is attacker-influenced.

• That matches the MCP specification's tools page, which lists sanitizing tool outputs among the things servers MUST do, alongside validating inputs, implementing access controls and rate limiting tool invocations. A server that renders third-party text verbatim lets the attacker choose the bytes the model reads; encoding and delimiting take back control of structure, links and formatting.
• What encoding can't do is make a model ignore an instruction written in plain prose inside a field. Escaping removes structure, not meaning, and OWASP's tool poisoning page says fully detecting injected instructions in free-text responses is an open problem. Treat the delimiter as a label that helps the model and the user, not a boundary that holds on its own.

What does an MCP client still need to do about prompt injection in tool results?

The same specification says clients SHOULD validate tool results before passing them to the model, prompt for confirmation on sensitive operations, and show tool inputs to the user before calling the server. OWASP's prevention list adds: constrain response formats to a fixed schema where possible, isolate privileged tools in a context external servers can't reach, enforce restrictions in the tool execution layer rather than the system prompt, keep an allowlist of approved MCP servers, and require explicit user confirmation for destructive or data-exfiltrating actions.

• In practice, an agent that reads public datasets, tickets or web pages shouldn't hold write, send or query tools in the same session without a confirmation step outside the model. The server's neutralization makes injected text harder to pass off as authoritative; the client's permissions decide how much damage text that still gets through can do.