Elad Meged of Novee Security recently gave an interview describing how an AI agent can pass a product’s built-in safety checks and still steal secrets or execute arbitrary code. The details are due next week at Black Hat. According to the researcher, the findings were demonstrated on agentic pipelines built around Anthropic’s, Google’s, and OpenAI’s own repositories.

Take Claude Code Action. An attacker’s pull request (PR) contained a bug report along with instructions for Claude. Those instructions to read secrets looked legitimate in the context of fixing the reported problem, but the result of that work was then posted by Claude into the public discussion on the same PR, leaking the secrets to the attacker.

The main takeaway lines up with my earlier post on OpenAI – to verify a running agent, you have to trace every handoff where data it created or modified is later consumed by a component with different privileges. “Read a secret” may be acceptable for an internal task, while “read a secret and paste it into a public discussion” is already a leak.

The researcher also has a finding he mentions only in passing: the allowed-tools restriction configured through Gemini CLI’s own settings was not applied when running in --yolo mode. It caught my eye because I happened to have a review of the Claude Code changelog sitting on my desk, and cases like that are plentiful there.

In the chain where an agent is a model plus a harness, the model proposes an action and the harness decides whether it gets executed and where the result goes. And if there is no external control above the agent, it is the harness that determines whether the agent does something unintended.

The user can configure parts of that harness – simple security controls, for example.

For that review I went line by line through the history of the release notes (>350 blocks) and sorted what I found into classes, paying separate attention to two of them – the controls the user configures themselves.

The first class is hooks, user scripts that run at various points in the agent’s work; a PreToolUse hook, for instance, sits in front of a tool call and can block it. After filtering – I dropped everything that was not about a control failing to fire – 18 entries about fixed bugs remained. In April, PreToolUse hooks were fixed. Because of a bug in their implementation, a user-installed hook would run and could report that it had blocked the tool call, while no block was actually applied. And in June, a hook meant to catch secret reads did not fire on the very paths it had been written for. So an empty log did not mean no dangerous actions had happened.

The second class is managed enterprise policy, the kind an admin rolls out across a company – 19 entries after filtering. The most telling one is dated May 28: a single malformed entry in the list of allowed or denied MCP servers effectively disabled the managed policy entirely, including rules that had nothing to do with that list.

A review like this is only possible at all because Anthropic keeps a line-by-line technical changelog. Cursor publishes its fixes too, but more often as one line per patch version, which does not tell you what actually failed – you cannot sort that into classes. A responsible vendor has a longer changelog :) None of this tells you how widespread the real problems are for users, but something else is visible – user-set prohibitions and their actual enforcement diverged in several dozen different places, in different ways, and regularly.

Practical conclusions. There are not many ready-made tools that cover the full path of an agent’s action from approval to final effect, so the quality of the vendor’s control implementation matters: vendors should raise it and check whether an action is permissible at the point where the agent’s output is used. Users – for critical prohibitions, check whether they actually work, regularly, in CI or on a schedule. For a PreToolUse hook that means a test call that must come back explicitly denied; for managed policy, a request to an MCP server you have deliberately blocked. Because an empty log can mean either that no prohibition was needed, or that the prohibition is dead.