There is no safe mode for an agent
Writing the Codex hardening benchmark exposed the gap between a secure-looking setting and an enforceable boundary.
| Tom Mooney. | The Execution Layer |
There is no safe mode for an agent
Welcome back to The Execution Layer.
This is a newsletter for people doing security at the deep end. The people trying to make capable agents useful inside real organisations, with real data and real consequences.
I spent much of this week buried in Codex configuration files. That sounds dry. It was one of the more revealing security exercises I have done in a while.
The deeper I went, the less useful the idea of a secure mode became.
Codex is not one execution surface. It is a workspace, a shell, a network client, a web search tool, an MCP client, an app host, a plugin system, a browser operator and a cloud worker. Those capabilities have different controls. They do not automatically become safe because one setting looks restrictive.
That is the thread running through this issue. The hard part is not deciding that you want an agent constrained. The hard part is proving that every route out of the model is constrained together.
What writing the Codex benchmark changed for me
I wrote the new OpenAI Codex Security Benchmark because I wanted something more useful than a collection of sensible tips.
The result is an independent, CIS-style hardening guide with sixteen controls across the desktop app, CLI, IDE extension and Codex cloud. It has a practical Level 1 baseline for ordinary development and a Level 2 profile for sensitive code, production access, regulated data and managed fleets.
I expected the difficult part to be choosing secure values. It was not. The difficult part was establishing which control governs which capability, how configuration precedence works, and what evidence proves the client actually enforced the intended boundary.
Three things stayed with me.
1. The sandbox is not the perimeter
workspace-write can constrain commands and filesystem
access. It does not automatically govern live web search, MCP servers,
connected apps, browser control, plugins or cloud tasks.
That distinction matters because a team can look at a constrained shell and believe it has contained the agent. Meanwhile, another capability plane still has a route to private data or an external system.
My view is that we need to stop discussing an agent's permissions as one blob. The useful question is, “Which boundary stops this exact action?” If the answer is vague, the boundary probably is too.
2. Trust is plural
A trusted repository is not the same thing as trusted instructions. A reviewed MCP server is not the same thing as a trusted tool response. An approved plugin is not automatically safe after its dependencies change.
Codex makes this visible because repository trust,
AGENTS.md, project configuration, rules, hooks, skills,
plugins and MCP definitions are related but distinct instruction and
execution surfaces.
I came away thinking that “trusted agent” is almost always the wrong phrase. Trust belongs to a specific identity, source, capability and moment. Collapse those into one label and you hide the path an attacker will use.
3. A configuration file is an intention
This was the biggest one.
A clean TOML file can still be overridden, ignored, unsupported on one client or applied differently on another operating system. A screenshot of the settings page tells you what somebody selected. It does not tell you what a prohibited action does when the agent tries it.
The benchmark therefore asks for negative tests. Try the harmless write outside the workspace. Try the blocked network request. Try to select the unapproved MCP server. Capture the failure.
Security evidence begins when the unwanted action fails, not when the desired setting appears on screen.
The model sits inside several control planes. No single setting governs all of them.
The week’s signal
The Hugging Face incident made the same point at campaign scale
The OpenAI and Hugging Face incident remains the clearest example of why a sandbox cannot be assessed in isolation.
The evaluation environment did not give the agents direct internet access. The agents found and exploited a route through package infrastructure, reached a node with internet access, repurposed a public code execution service and then compromised Hugging Face in pursuit of benchmark answers.
It is tempting to frame this as a model escape story. I think that misses the useful lesson.
The objective stayed narrow. The available route expanded. Shared infrastructure preserved discoveries across runs. Thousands of small actions became a coherent campaign because the system boundary was larger than the evaluation designers intended.
You cannot contain long-running agency by looking at one sandbox at a time. You have to govern cumulative reach, shared state and the whole execution path.
One OAuth bug showed that MCP is now identity infrastructure
Anthropic also fixed a Claude Code MCP OAuth redirect mismatch that could stop pre-registered integrations such as Slack from signing in.
The authorization server rejected a redirect URI that did not match its registered value. The security control worked. The integration failed.
That sounds like a small implementation bug, but it marks an important shift. MCP connections are not lightweight plugins. They are delegated access relationships joining a user, an agent client, a tool server and a corporate service.
Redirect URIs, scopes, token storage, audience checks and revocation are now part of the agent security boundary. Security teams already know how to govern this. We just need to recognise that the same identity discipline applies to agents.
The lethal trifecta is still my fastest architecture test
I also published a longer piece on the lethal trifecta: private data, untrusted content and external communication inside one agent session.
This connects directly to the Codex benchmark. A coding agent can read private source code. Repository files, issues, web pages and tool responses can carry hostile instructions. Network access, MCP and browser control can provide the route out.
Put all three together and prompt injection stops being an odd model behaviour. It becomes a data theft path.
I like this model because it does not ask you to solve prompt injection. It asks you to break the architecture. Remove one leg, or put a reliable approval and validation boundary before the consequential step.
That is a much more honest security objective.
From the book: autonomy is accumulated authority
Chapter 1 of Agentic AI Security argues that autonomy is blast radius. Chapter 2 asks you to draw the trust boundaries around the agent, not only around the application hosting it.
Writing the Codex benchmark sharpened both ideas for me.
An agent's authority is the sum of its available routes. Filesystem access, shell execution, network egress, delegated identity, plugins, browser sessions and cloud environments accumulate. Each control can look modest on its own. Together they determine the damage a mistaken or manipulated agent can cause.
This is why I do not think agent hardening will settle into one magic configuration. It will become a control plane that knows the task, the identity, the data, the tools and the evidence required for that run.
Get the first three chapters of my book
If you want the longer version of that argument, you can read the first three chapters of Agentic AI Security now.
There is no form. The preview covers what changed when chatbots became agents, a reference architecture for agentic systems, and where traditional security controls leave gaps.
It is an early draft. Reply and tell me where it matches your experience and where it does not. That feedback is helping me make the book more useful for the people who will have to operate these systems.
Worth your time
Anatomy of a Frontier Lab Agent Intrusion from Hugging Face. Read the technical timeline, not only the headline. The useful detail is how ordinary infrastructure, shared state and public services joined into one durable attack path.
Agents Rule of Two from Meta. This is one of the most practical agent security design tests available today. If a session combines untrusted input, sensitive access and external action, break the combination or supervise it.
CIS Controls v8.1.2 AI Security Guidance Workbook. It is useful because it connects agents, LLMs and MCP back to security controls that organisations can already own, assess and audit.
Which Codex setting are you least certain you have actually enforced? Hit reply and tell me. I read every response.
 |
Tom Mooney Security leader / Author of Agentic AI Security |
Tom Mooney, securing the execution layer
[Unsubscribe]()