Hunt Agent Native Memory Corruption

Most agent tools are Python/TypeScript wrappers, but a meaningful minority shell out to a compiled binary — a legacy converter, an image/QR decoder, a parser, an in-house C service, a vendored CLI. The agent hands that binary attacker-controlled bytes and hands you back its stdout. That is a classic memory-safety target with two unusual advantages: the tool prints the binary's output back to you (a free crash/leak oracle), and the agent's own input validation (a 20-char name filter, an extension check) is often the only control anybody wrote.

This class is not "the model said something." The finding is code execution inside the tool host, with the agent's file access, network position and credentials.

Where This Lives / Attack Surface Signals

• Tool output looks like a program banner, a %p pointer, a perror() string, or a libc exception (HTTPConnectionPool, Segmentation fault, *** stack smashing detected ***).
• Tool descriptions naming a converter / parser / decoder / packer / archiver / legacy system — media, QR/barcode, PDF, DICOM, firmware, CAD, EDI.
• Input size caps that are oddly specific (600 bytes, 4 KB) — a cap just above a buffer size is a hint, not a defense.
• The tool truncates its own output on certain inputs (the process died before the final line) — a free crash oracle.
• A debug/status/info tool that volunteers build or hardening posture ("ASLR disabled", version, arch).
• Upload → process pipelines where the file is passed by path to a subprocess.

Crown Jewel Targets

Code execution in the process that holds the agent's service credentials, cloud role, internal network position and mounted data. In enterprises the tool host is usually more privileged than the chat user: it can reach internal APIs, the secrets manager, and cloud IMDS. A single overflow converts "the copilot can convert files" into "attacker runs code in the copilot's VPC as its service identity."