THE EXECUTION LAYER // 001

The agent is now on both sides of the attack

Welcome to the first issue of The Execution Layer.

I’m starting this newsletter because agentic security needs a stronger community of people working at the deep end: the security leaders being asked to approve deployments, the engineers building the controls, the architects deciding where trust boundaries sit and the practitioners dealing with what happens when theory meets a real enviroment.

There is plenty of commentary about what AI agents might become. I want this to be a place for the people responsible for what they can do today.

Each week, I’ll share my view on the developments that matter, the research worth reading and the controls that appear to hold up in practice. I also want to hear what your seeing: the difficult design decisions, the controls that create unexpected friction and the risks that look very different inside a live system. If this becomes useful, it will be because that experience flows in both directions.

So please reply, challenge the argument and share what is happening in your environment. My aim is to build a community around the practical work of securing systems that can act.

For this first issue, two stories caught my attention.

Cisco Talos examined AI chat logs and coding sessions left exposed by attackers. The logs included the use of Claude Code, Codex, Cursor and Gemini. They showed attackers using coding agents to turn public vulnerability information into working attack infrastructure, while bypassing model safeguards with techniques as unsophisticated as starting a new session or claiming to be in a capture-the-flag competition.

At almost the same moment, Microsoft put Project Perception into public preview: a system of red, blue and green-team agents intended to find attack paths, judge which risks matter and take corrective action.

One story is about AI helping the attacker. The other is about AI helping the defender.

I think they are the same story.

The important change is not that models can write convincing phishing emails or explain a vulnerability. We crossed that threshold some time ago. The change is that models are being connected to tools, credentials and execution environments. They are trusted to keep working until they reach an outcome.

The agent is now on both sides of the attack.

The guardrail is not the boundary

There is a tempting response to the Talos findings: the models should have refused. Better safeguards would certainly have created more friction. But I would not build a security strategy on the assumption that every model will correctly infer intent from a plausible-looking request.

An attacker only has to find one framing the model accepts. A defender has to make every dangerous action unreachable.

That is why I believe much of the discussion about agent security is still aimed at the wrong layer. We keep asking whether the model can be persuaded to behave badly. The more consequential question is what happens when it does.

A model that produces a harmful answer is a safety problem. A model that can run a command, use a cloud credential, connect to an MCP server or alter production is an execution problem.

Model safeguards matter, but they are probabilistic. Permissions, isolation, credential scope and deterministic policy decide whether a bad decision becomes an incident.

Capability is arriving faster than governance

Microsoft’s announcement makes the tension particularly clear. The company describes a closed loop in which specialist agents perceive risk, reason over it and translate decisions into protection. That is a compelling direction. Security teams do not need another system producing alerts that humans cannot process quickly enough.

But closing the loop also changes the trust model.

The system that recommends a patch is useful. The system that can apply one has authority. Once it can change the environment, we have to ask who delegated that authority, which systems it can touch, what evidence informed the decision and how the action can be stopped or reversed.

This is not an argument against autonomous defence. Attackers will use automation regardless of how cautious defenders are. It is an argument for treating defensive agents as privileged actors rather than clever software features.

The same applies to coding agents. We often introduce them as developer productivity tools, then quietly allow them to inherit the developer’s filesystem, network access and credentials. Their adoption route looks like an IDE extension. Their effective privilege can look more like an administrator.

The plumbing is becoming more powerful too

The new MCP specification landed last week with a stateless core, stronger authorization and enterprise-managed authentication. These are welcome improvements. MCP is rapidly becoming important infrastructure for connecting agents to real systems.

But stronger plumbing does not make every connection trustworthy.

Each tool still expands the set of actions available to the agent. Each server introduces code, schemas, credentials and another supply-chain decision. Better protocol security helps protect the connection; it does not decide whether the agent should have the capability in the first place.

My concern is that organisations will standardise the connection layer before they establish ownership of the authority flowing through it.

My conclusion from this week

The dividing line is no longer between “AI systems” and conventional software. It is between systems that advise and systems that act.

Once a system acts, I want to know five things: its identity, its effective permissions, the provenance of its context, the boundary around its execution and the evidence it leaves behind.

None of those questions can be answered by the model itself.

That is the execution layer. It is where I think the next generation of security architecture has to concentrate.

The Claude Code hardening guide

This week I published the Claude Code Security Benchmark v1.0, an independent, CIS-style hardening baseline for developer workstations, development containers and managed enterprise fleets.

I wrote it because the guidance around coding agents is currently fragmented. There are useful product settings and sensible recommendations, but security teams need something they can assess, evidence and repeat, not another list of optional tips.

The benchmark contains 15 auditable controls covering permissions, sandboxing, secrets, network access, MCP, plugins, hooks, unattended execution, telemetry and governance. Each control includes a rationale, impact, audit procedure and remediation steps.

Read the Claude Code Security Benchmark →

It is not an official CIS Benchmark or an Anthropic certification. It is my attempt to turn the execution-layer argument into a practical standard teams can use now.

Worth your time

• Hackers’ AI chat logs reveal evolving tactics (Axios): the Cisco Talos findings behind this week’s clearest look at how attackers are actually using coding agents.
• Rethinking security for the age of AI (Microsoft): the primary announcement for Project Perception and Microsoft’s case for agentic defence.
• Bringing MCP 2026-07-28 to Claude (Anthropic): a useful overview of the latest protocol changes, particularly authorization and enterprise-managed authentication.

I’m interested in where you draw the line between an agent that recommends and one that acts. Hit reply and tell me. I read every response.

— Tom

Author of Agentic AI Security