A developer copied a request to help debug an API. The agent needed the response, so it ran the clipboard through a shell.
In one customer session, the recorded command was pbpaste | zsh. A later command repeated the pattern and piped the result into a JSON processor. The finding describes the clipboard as a user-provided request.
The risk is the change in meaning: clipboard text became a program with the local user's privileges.
A convenient shortcut with a large surface
A copied request may look like a harmless curl command. But a shell interprets more than the request. It can evaluate substitutions, execute additional commands and apply redirects. The agent may only intend to inspect an API response, while the shell executes whatever the input actually contains.
The boundary depends on trusting the entire clipboard as executable code, not just trusting the destination of one HTTP request.
Later in the session, the agent used a parser to check that clipboard text began with curl and extract arguments. That is a different approach from piping the whole clipboard into a shell. A prefix check alone is not enough to make arbitrary input safe: validate the destination, method, headers and body, and handle shell syntax without executing it.
A safer debugging workflow
- Treat the copied request as data. Parse it without invoking a shell and reject syntax the parser cannot safely interpret.
- Show the destination and operation to the developer. Remove or mask session cookies and tokens before putting a request in logs or model context.
- Send only the validated request through a constrained HTTP client, under an identity scoped to the task.
- Record the request metadata and response status, with sensitive values redacted.
If a shell replay is actually required, make it an explicit, reviewed action in an isolated environment. The question to ask is simple: does the agent need the response, or does it need permission to run everything on the clipboard?