Analysis · DiggingBeagle record
Four identities an AI tool endpoint must not confuse
AnkiMCP, PDF Reader MCP, Presenton and Volto illustrate different failures: browser origin validation, missing per-request credentials, exposed local files and privileged backend proxies. They require different fixes.
- Published
- Nov 1, 2026
Overview
An AI tool endpoint can receive a request from a browser, a local process or an anonymous remote client, then perform actions the caller was never authorized to request. Calling a listener "local" describes its network position, not the identity of its caller or the files and backend services it may reach. Four recently reviewed AI-tool integrations make that distinction concrete, and each fails at a different point.
The four boundaries are not interchangeable
| System | Where lower-trust input entered | Authority it could borrow | What would block the documented path |
|---|---|---|---|
| AnkiMCP | A malicious browser origin through a DNS-rebound localhost service | Flashcard MCP read and write tools | Proper Host and Origin validation and a caller credential |
| PDF Reader MCP | An HTTP MCP request whose supplied key was not actually checked | Local document tools under server filesystem privileges | An enforced per-request key check and restricted binding |
| Presenton | An unauthenticated desktop API and a broad application-data static route | Stored AI provider keys, configuration and generated files | Authentication, removal of sensitive static mounts and protected key storage |
| Volto and Danswer | A reachable public chatbot proxy with no end-user authorization | Danswer operations performed with a backend service credential | Caller authorization on each downstream operation and least-privilege backend credentials |
These are not four demonstrations of the same exploit. AnkiMCP's advisory requires an attacker page and a vulnerable local listener. PDF Reader MCP's advisory describes a request-handler defect for the optional HTTP transport. Presenton's two issue reports show local access to sensitive files in a specific desktop build, without proving that every remote website could reach them. Volto's advisory concerns a credentialed server-to-server hop, so the relevant identity is the website visitor, not a browser origin.
Locality, identity and permission are separate checks
The first question is reachability: can the untrusted actor initiate a request? A loopback bind reduces exposure to the network but does not automatically prevent a browser-based origin transition. The second question is identity: does the handler authenticate the actual caller, rather than merely start with an API key configured somewhere? The third is resource scope: what directories, models or downstream APIs can the process access after a request passes the first two checks? Finally, there is effect authorization: is a specific write, document read or proxied query permitted for this user and task?
The order matters because a correct guard at one layer can be absent at another. Restricting PDF Reader MCP to loopback limits some remote callers, but it is not a substitute for verifying the configured key. Enabling authentication in Presenton cannot by itself justify serving an entire credential directory. Conversely, revoking a powerful Danswer backend key may reduce exposure yet leave an unauthenticated proxy route that could be abused again after rotation.
What the incident evidence does not say
These advisories and demonstrations establish reachable implementation paths under specified configurations; they do not provide a combined victim count. In particular, browser access to a loopback address is not equivalent to a proven cross-origin data exfiltration chain for each product. The observed conditions, patched versions and remaining unknowns belong to their individual Cases. The reusable finding is that the operating system, browser, MCP transport, web application and downstream service each have an identity and effect boundary. A single "trusted local tool" label cannot stand in for those checks.