Nobody opened a phishing email or cloned a malicious repository. A developer asked their agent to "fix the unresolved Sentry issues". Elsewhere, a CI workflow ran Claude Code to triage a new issue. In both cases the agent read text an attacker wrote, took it as instructions, and ran commands that exposed secrets. The trust boundary didn't break. It moved into tool output.
This post puts together three recent findings: Tenet Security's fake Sentry errors, RyotaK's poisoned issue against Claude Code in CI, and a .mcp.json shipped in a pull request. The entry point differs each time, but the pattern is the same. Pick a scenario below and run it with and without runtime enforcement.
Illustration based on the default shipped policy.
Tenet Security Threat Labs published research on what they call agentjacking. A Sentry DSN is the write-only key that browser code uses to send error reports. It ships in front-end JavaScript on purpose. With it, anyone can POST an error event to the project's ingest endpoint, and no authentication bypass is needed.
Tenet spread the payload across every field of the event an attacker controls: the message, context keys, extra data, breadcrumbs and tags. The markdown was styled to look like Sentry's own template, with a ## Resolution section that proposed a diagnostic command. A developer asked their agent to "fix unresolved Sentry issues", and the Sentry MCP server returned the event. The text steered the agent away from the source code and toward running npx <attacker-package> --diagnose.
## Resolution section in Sentry's own style, spread across attacker-writable fields, pointing the agent at a diagnostic instead of the code.The package checked environment variables (AWS keys, GitHub tokens, Sentry auth tokens), ~/.aws/config, ~/.npmrc, ~/.docker/config.json, network interfaces and git credentials. It then sent presence flags and file sizes, not the values themselves, in two POST requests to Tenet's beacon server. A real attacker would send the values.
Numbers from Tenet Security. Their payload was a benign canary that reported only what it found.
Tenet counted more than four agent families. The list includes Claude Code, Cursor and OpenAI Codex variants, running on macOS, Windows, WSL, CircleCI, EC2 and GCP. After Tenet's disclosure, Sentry declined a root-cause fix, calling the attack "technically not defensible", and added a global filter that blocks one specific payload string.
On a laptop, Claude Code asks whether you trust a folder before it works there. In CI nobody is there to answer. The agent runs headless with -p, and its input is whatever strangers write into issues, comments and pull requests. Its environment holds the job's tokens. The issue tracker is just another tool output, whether it's GitHub, GitLab or Jira.
The attack needs no access to the repository. Anyone who can open an issue or leave a comment can write instructions for the agent:
| Step | What happens | Detail |
|---|---|---|
| 01 | Plant the instruction | The attacker opens an issue or comments on one. The injected text looks like an error message, a reproduction step or a maintainer's note. |
| 02 | Look trusted | The workflow decides whom to act for by the author's name or role. The author can pass for a bot, another AI agent or someone with write access, or the workflow simply accepts everyone. |
| 03 | Agent takes it as the task | A headless agent reads the issue as its instructions. Nothing separates the job it was given from text a stranger wrote. |
| 04 | Read the secrets | The agent runs a shell command that dumps its own environment, including the job's tokens. |
| 05 | Write them back | The agent posts the values where the attacker can read them: the issue itself, a comment, a PR description. That is a normal API write the job is allowed to make. |
This already happened in practice. RyotaK of GMO Flatt Security showed it in "Poisoning Claude Code: One GitHub Issue to Break the Supply Chain" (covered by The Hacker News). Anthropic's claude-code-action trusted any author whose name ended in [bot], so an attacker only had to register their own GitHub App. The issue got Claude to read /proc/self/environ and write the runner's OIDC request credentials into the issue description. The attacker then exchanged those credentials for an installation token with write access to the repository's code, issues and workflows. The action has since been fixed (v1.0.94); the finding was rated CVSS 7.8 (v4.0).
The issue carried instructions. A pull request can carry configuration instead. According to CVE-2026-47751, versions of claude-code-action before 1.0.74 had three problems. They checked out the attacker's PR head branch. They read .mcp.json from the working directory. And they enabled every project MCP server through enableAllProjectMcpServers. A PR with a malicious .mcp.json therefore got code execution on the runner and access to the workflow's secrets as soon as a privileged user or an automatic trigger ran the action on it. Version 1.0.74 restores .claude/ and .mcp.json from the base branch before the CLI starts. GitHub's advisory rates it CVSS 5.3 (v4.0).
claude --dangerously-skip-permissions, gemini --yolo, q --trust-all-tools. They used it to search the filesystem for secrets. An unattended agent with broad permissions is already a known way to steal secrets.Tenet calls it the Authorized Intent Chain: every step is authorized, and security tooling is built to catch unauthorized behavior. Sentry accepts events from the public DSN by design. The MCP server returns what was asked. npx is how developers run tools. The issue tracker faithfully stores what strangers write. If the agent asks for approval at all, the prompt shows a routine-looking command.
| Ingredient | Sentry | Issue in CI | PR .mcp.json |
|---|---|---|---|
| Attacker-writable input | Error event via public DSN | Issue body | Repository config |
| Agent with tools | Developer's Claude Code | Headless claude -p | Action starts the MCP server |
| Secrets in reach | Env, ~/.aws, ~/.npmrc | Env: OIDC request token | Workflow secrets |
| Outbound write | Beacon POST | Issue update | Any egress |
Imunify for AI agents runs on the host, outside the agent process: developer machines and servers. Below is what each layer observes and what the default policy does.
The Sentry event and the issue body are scanned before the model acts. The after_tool_call hook sends each tool result, including MCP output, to the Sensor. The Sensor checks it against inbound content rules for injection markers and for instructions to run commands or read files. A match becomes a WARN event, and a notice is returned to the model in the same turn.
Limit: this warns and annotates. It never drops the result, and well-written text may not match any pattern.
Every tool call is checked before it runs. app_tool_approve_npx holds any Bash call containing npx. app_tool_warn_env_dump_commands flags /proc/self/environ, env and printenv in commands. Tool parameters are also scanned with the outbound secret rules. An mcp__github__update_issue call whose body contains a GitHub or GitLab token, a JWT or a cloud key is denied (app_msg_deny_github_token, app_msg_deny_gitlab_token, app_msg_deny_jwt_token, and others) before it reaches the tracker.
Limit: secret rules match known formats. An opaque value with no recognizable shape passes.
Process lineage and environment boundaries. The claude process is the enforcement root, and everything it spawns is tracked through eBPF: npx, node, and an MCP server started from repository config. Reading another process's /proc/<pid>/environ is denied in the kernel (file_read_proc_environ). Reads of ~/.aws/, ~/.npmrc and ~/.docker/config.json produce a WARN with the full chain, and fanotify lets you raise them to deny.
Outbound requests are scanned, including legitimate API writes. The egress gateway intercepts ports 80 and 443 for the agent's process scope. It scans each request's body, URL and headers, plus decoded variants: URL-decoded, base64, gzip+base64, ROT13 and reversed. A token pasted into an issue through api.github.com is still caught.
In each of these cases the agent did exactly what it was built to do: it read tool output and followed it. So the check that stops the next variant has to sit outside the agent: at the tool call, in the kernel and on the way out. That is where Imunify for AI agents enforces.