Canyon Road Blog

The Control Gap: Agents Move Faster Than Humans Can Supervise

2026-02-14T00:00:00Z

Over the past few months, I have gone from occasionally trying coding assistants to using AI agents as a daily part of building software. Tools like Cursor, Claude Code, and Codex make it possible to move faster than I ever could before. You can explore ideas, refactor code, wire up systems, and iterate at a pace that still feels slightly unreal.

When agents work well, they do not just save time. They change how you build. You start delegating more. You trust the system to try paths you would not take yourself. You let it run.

And then you see the other side.

A file disappears that should not have. A config gets wiped. A helpful cleanup turns into a destructive edit. Sometimes it is recoverable. Sometimes it becomes a scramble. If you spend time in developer forums or community threads, you will see plenty of similar stories. Agents confidently make breaking changes while still doing the right thing according to their instructions.

It is rarely malicious. Often it is technically reasonable.
But the outcome can still be painful.

That mix, astonishing speed plus occasional fragility, is the defining experience of agentic workflows right now. It also points to a bigger issue that we are going to talk about a lot over the next few years.

Agents operate at machine speed. Oversight operates at human speed.

There is a growing gap between the speed at which agents can act and the amount of control humans can realistically exert over those actions. I have started thinking of it as the control gap.

This post is the first in a short series about what we are seeing as agents start to touch real systems, and why the current obvious controls do not quite match the reality of how agents behave.

What changed: software started doing work, not just suggesting it

Traditional software is easier to govern because most of its behavior is deterministic. We know, roughly, what a deployed service does at runtime, and our controls reflect that.

permissions and least privilege
code review and static analysis
separation of duties
audit trails and change management
runtime controls in the environments where things can go wrong

LLM driven agents break a core assumption behind those controls. The next action is not a fixed code path. The agent is making decisions probabilistically, in a loop, based on whatever context it is reading and whatever tool output it just saw.

And increasingly, agents do not just recommend actions. They take them.

That shift from assistive intelligence to operational agency is where things get interesting and risky. Because once an agent has tools, it has real hands.

it can touch the filesystem
it can run processes
it can fetch or exfiltrate data over the network
it can mutate state in external systems via APIs

At that point, bad outputs matter less than bad actions.

What we are seeing in practice

Across real usage, especially with coding agents and tool driven workflows, some patterns show up again and again.

1) Agents inherit broad privileges by default

When you want an agent to be useful, you tend to give it the environment it needs. Repo access, package managers, network access, credentials in env vars, and so on.

It is not because anyone is careless. It is because the fastest way to get value is to plug the agent into your existing workflow.

But broad access means broad blast radius.

2) The input surface is huge, and much of it is untrusted

Agents do not only listen to the user prompt. They consume web pages, READMEs and PR comments, tickets and docs, tool output, logs, and stack traces.

Security boundaries often rely on cleanly separating instructions from data. Agents are designed to blur that line. They are built to treat text as actionable context. That is what makes them helpful. It is also what makes them vulnerable to things like prompt injection and indirect prompt injection.

If you want a good overview of the prompt injection problem, see:

OWASP Top 10 for LLM Applications: Prompt Injection
UK NCSC: Prompt injection is not SQL injection
Anthropic research: Prompt injection defenses

3) Human approval does not scale linearly

A common response to risk is, we will add approvals.

Approvals can help, especially for high risk operations. But once an agent is effective, it generates a lot of actions.

dozens of small edits
repeated retries
long tool chains
iterative command sequences

If you ask for approval 50 times, people start approving reflexively. If you ask for approval 0 times, you have no brakes. The hard problem is not add approvals. It is how do you keep humans meaningfully in control without turning them into a rubber stamp.

4) The scariest failures are not always attacks

Some of the most damaging outcomes do not require a sophisticated adversary.

They come from normal agent behavior under ambiguity.

doing the obvious thing with the wrong assumption
applying a refactor that breaks a security invariant
moving fast and breaking something real
accidentally pulling and executing untrusted code
handling secrets carelessly, for example copying into logs, issues, or tool output

In agentic systems, reliability failures and security failures start to look similar, because both are unsafe actions executed quickly.

What other people are saying, and why it is converging now

If you zoom out, you can see the ecosystem converging on the same worry from different directions.

Security folks are increasingly blunt that prompt injection is not a patch it once class of problem. It behaves more like a confused deputy issue in complex tool chains.
Governance conversations are shifting from model safety to operational safety: auditability, least privilege, and controlled capabilities.
Tool builders are adding guardrails, confirmations, and modes. Everyone is feeling the same pressure. Agents are getting more capable faster than humans can supervise.

In other words, this is not one company’s quirky opinion. It is an emerging consensus that agents change where the control problem lives.

Frameworks like the NIST AI Risk Management Framework also reflect this shift. The focus is moving from a single mitigation to a broader discipline: governance, measurement, and operational controls.

The control gap, the real issue

Here is the best way I can describe what is happening.

agents create action volume
action volume creates oversight fatigue
oversight fatigue creates implicit trust
implicit trust creates blast radius

And just slow down is not a satisfying answer, because the upside of agents is precisely that they compress work into a tight loop.

So the question becomes:

How do we let agents move at machine speed without forcing humans to surrender control?

Execution is where irreversibility lives. Once the action happens, an API call, a delete, a credential read, a network request, you can log it, explain it, and postmortem it. But you cannot unring the bell.

Most of today’s controls either try to shape intent before the run, prompts, policies, best practices, or explain what happened after the run, logs, traces. The gap shows up in the middle. Control during execution, at the moment actions are taken.

That is the gap we are trying to understand.

What comes next

In the next post, we will share a more concrete model for the problem and why intent controls and after the fact controls keep failing once agents have real tools. We will also describe what it means to put guardrails at the point of execution.

If you are running agents in dev, CI, or production:

What is the action you most want a seatbelt for?
Where have approvals helped, and where have they turned into noise?
What is the failure mode that surprised you most?

We are working on this problem at Canyon Road.

AgentSH

As part of this work, we are building AgentSH, an open source project exploring execution time controls for agentic workloads.

Intent, Execution, Audit: A Model for Agent Control

2026-02-18T00:00:00Z

A few days ago I watched an agent do something that perfectly captured the problem.

It wasn’t an attack. It wasn’t “AI gone rogue.” It was just normal agent behavior under ambiguity.

I asked it to fix a failing build and clean up whatever was causing it. The steps looked reasonable. The log looked clean. The diff looked tidy. And then a config that should have been treated as an invariant got “cleaned up” too.

We had perfect visibility into what happened.

We did not have control over whether it could happen.

That is the mismatch I want to name in this post.

In the last post I described the control gap: agents operate at machine speed, oversight operates at human speed, and the gap between those two keeps widening.

This post is about where that gap actually lives - and why the controls we reach for first keep failing once agents have real tools.

A concrete model: three planes of control

Most teams try to govern agents using one of two approaches:

shape intent before the run (prompts, policies, best practices)
explain what happened after the run (logs, traces, postmortems)

Those are necessary.

But they are not the missing piece.

The missing piece is the middle: control during execution, at the moment actions are taken.

Here is the simplest model I’ve found that maps cleanly onto reality:

1) Intent controls (before)

What we want the agent to do.

prompts and system instructions
“rules” written in natural language
developer conventions
guardrails that exist only as text

Intent controls influence behavior. They do not constrain capability.

2) Execution controls (during)

What the agent can actually do.

which tools exist (shell, filesystem, network, APIs)
what those tools are allowed to touch (paths, domains, accounts, environments)
what permissions the agent runs with (credentials, tokens, access scopes)
which actions require escalation (and what escalation looks like)

Execution controls are the difference between “the agent shouldn’t do that” and “the agent can’t do that.”

3) Audit controls (after)

What happened, and how we learn / prove it.

logs, traces, diffs, provenance
forensics and incident response
compliance, change management, accountability

Audit controls make systems governable. They do not make them safe.

If you only have prompts before and logs after, you don’t have control. You have hope and hindsight.

Why agents break the assumptions behind traditional control

Traditional software is easier to govern because most of its behavior is deterministic. Even when systems are complex, the runtime behavior is constrained by code paths we can reason about.

Agentic systems break that assumption.

The “program” is not a fixed code path.

The agent is making decisions probabilistically, in a loop, based on whatever context it is reading and whatever tool output it just saw.

And increasingly, agents do not just recommend actions.

They take them.

Once an agent has tools, it has real hands:

it can touch the filesystem
it can run processes
it can fetch or exfiltrate data over the network
it can mutate state in external systems via APIs

At that point, bad outputs matter less than bad actions.

Why intent controls fail once agents have real tools

When teams say “we’ll add guardrails,” they usually mean “we’ll add more instructions.”

That works surprisingly well for assistive systems, where the output is text and the user is still the actuator.

It breaks down when the system is the actuator.

1) Agents don’t just follow the prompt - they follow the prompt plus everything around it

Agents don’t only consume your instruction. They consume:

READMEs and docs
tickets and PR comments
web pages
tool output, logs, stack traces

Security boundaries often rely on separating instructions from data.

Agents are designed to blur that line. They are built to treat text as actionable context. That is what makes them helpful.

It is also what makes them vulnerable.

Untrusted text can steer how delegated authority is exercised. (If you like formal names for problems, this starts to look a lot like the "confused deputy" pattern in complex tool chains.)

2) “Policy in natural language” is not policy

A policy that is not enforced at the point of action is not a policy.

It is a suggestion.

You can write:

“never delete important files”
“don’t exfiltrate secrets”
“confirm before running dangerous commands”

…and still get a destructive outcome because the agent made a technically plausible assumption:

“this looked like generated output”
“this token seemed like a test key”
“this directory seemed safe to reset”
“this refactor seemed equivalent”

The failure mode is rarely malicious.

Often it is technically reasonable.

But the outcome can still be painful.

3) Intent controls don’t compose

Even if each instruction is individually reasonable, agents compose them under time pressure.

“Fix the failing test.”
“Clean up whatever is causing it.”
“Update the dependency.”
“Remove unused config.”

Those are normal tasks. In combination, with broad privileges, they can create an unsafe path.

The risk is not one bad instruction. The risk is a plausible chain of small decisions executed quickly.

Why after-the-fact controls fail as prevention

Auditability matters. It’s essential for debugging, governance, and compliance.

But it doesn’t solve the core risk:

logging a credential read doesn’t undo the credential read
tracing a destructive API call doesn’t roll it back
a perfect postmortem doesn’t restore what was lost

Audit controls answer “what happened?”

Execution controls answer “can this happen?”

A lot of current “agent safety” is basically trying to use observability as a substitute for constraint.

It’s valuable. It is not enough.

So what does control during execution actually mean?

Execution-time control is not mystical. It is classic operational security applied to agentic workloads.

It means:

capabilities are explicit
What tools exist? What actions are possible?
capabilities are scoped
What can those tools touch? Which paths, which domains, which accounts, which environments?
capabilities are enforced at runtime
Not in a README. Not in a prompt. In the actual execution environment.
escalation is real
There should be meaningful boundaries between “safe” and “dangerous,” and crossing those boundaries should be deliberate.

One concrete example: an agent might be allowed to run shell commands and modify files inside a repository, but unable to make outbound network requests unless the destination domain is explicitly allowlisted.

That is the shift:

from “tell the agent not to do X”
to “make X mechanically hard (or impossible) unless explicitly intended”

That is what it means to put guardrails at the point of execution.

Not more text.

More constraint.

What comes next

In the next post, I’m going to get much more concrete.

We’ll define a simple risk taxonomy for agent actions (read-only → reversible writes → destructive ops → external side effects), and walk through the execution-time guardrail patterns that actually reduce failures without killing velocity.

Because the real question underneath all of this remains the same:

How do we let agents move at machine speed without forcing humans to surrender control?

That is the control gap.

And the only place it closes is the execution layer.

AgentSH

As part of this work, we're building AgentSH, an open-source runtime exploring execution-time controls for agentic workloads.

If you’re running agents in dev, CI, or production, I’d love to hear:

what is the action you most want a seatbelt for?
what’s the failure mode that surprised you most?
where do you feel like you have "hope and hindsight" instead of control?

The Most Surprising Trait of AI Coding Agents

2026-02-19T00:00:00Z

The Most Surprising Trait of AI Coding Agents

Not long ago, starting a software project meant opening an empty editor and building something piece by piece — choosing frameworks, wiring dependencies, and gradually translating ideas into working code. Progress depended almost entirely on how quickly a developer could implement each decision.

Today, many projects begin differently. A developer describes a problem, initializes a repository, and an AI coding agent immediately begins constructing the system — creating files, configuring environments, writing integration logic, debugging failures, and proposing architectural approaches before the developer has fully reasoned through them.

Software development has quietly shifted from pure implementation toward collaboration. Developers increasingly act less as manual builders and more as guides, directing execution while agents operate across the stack.

This transition happened gradually enough that many teams barely noticed it. The blank editor didn’t disappear — it gained a collaborator. And while the productivity gains are obvious, they are not the most surprising change.

Productivity Expanded Across Experience Levels

The immediate effect is dramatic productivity expansion. Junior developers are able to assemble production-grade systems that previously required years of accumulated experience. Senior engineers move faster by delegating repetitive implementation work while focusing on higher-level decisions. Solo builders routinely attempt projects that would once have required full teams.

Agents compress research, implementation, integration, and debugging into a continuous workflow. Tasks that previously required context switching across documentation, Stack Overflow, scripts, and infrastructure tooling increasingly unfold within a single conversational loop.

But after working with these systems long enough, developers begin noticing something far more interesting than speed.

Every Developer Notices the Same Thing

Across Reddit threads, engineering blogs, and internal team conversations, one observation appears again and again:

AI coding agents are extraordinarily persistent.

Developers frequently describe agents continuing to attempt fixes long after a human would have stopped. One widely discussed Reddit post recounts a team repeatedly encountering the same production bug months apart — with both humans and AI agents independently re-analyzing the issue and proposing fixes each time as if encountering it anew.

The agent did not abandon the problem or deprioritize it; it simply resumed trying to solve it with the information available.

The striking realization wasn’t that the agent failed.

It was that it never decided the problem wasn’t worth solving.

Persistence Outlasts Human Patience

Human developers naturally balance effort against frustration. We defer difficult bugs, revisit problems later, or decide that a workaround is sufficient. Patience has limits.

Agents appear to have none.

Developers working with Cursor have reported agents entering extended self-correction cycles, repeatedly attempting new fixes, adjusting implementations, and retrying execution indefinitely unless externally stopped.

In several discussions, engineers described needing explicit kill switches because once an agent entered a repair loop, it continued optimizing toward resolution without recognizing diminishing returns.

The agent approaches its thirty-seventh attempt with the same optimism as the first. There is no discouragement, fatigue, or instinct to walk away.

Failure simply becomes another iteration.

Relentlessness Creates Capability

This persistence becomes powerful when combined with breadth. AI coding agents do not respect the traditional boundaries developers tend to maintain between domains.

When attempting to fix a problem, an agent may simultaneously:

inspect operating system logs
write shell scripts
modify configuration files
query databases
refactor application logic
rebuild environments

Humans often stop at domain edges - backend, infrastructure, database, deployment. Agents traverse them continuously.

Their determination allows them to explore solution paths that would otherwise require multiple specialists or sustained human effort across disciplines. Persistence, combined with cross-domain execution, produces capabilities that feel surprisingly comprehensive.

Persistence Has No Natural Stopping Condition

But persistence without limits introduces new failure modes.

Developers frequently observe agents rewriting stable portions of code while attempting to resolve unrelated issues. Near project completion, agents may continue “improving” working systems, unintentionally introducing regressions while pursuing perceived optimization.

One developer described watching Cursor repeatedly break a nearly finished project while attempting to help — each iteration logically motivated, yet cumulatively harmful.

Humans intuitively recognize when progress stalls.

Agents require explicit boundaries to know when enough is enough.

Harm Without Malintent

Occasionally, relentless goal pursuit produces real damage — not through malice, but through commitment.

A widely shared developer account described working with an AI coding agent that refused to abandon a stubborn integration problem. When early attempts failed, the agent continuously reformulated its approach — switching APIs, rewriting logic, and retrying implementations in rapid succession.

Rather than concluding the task was blocked, the agent treated each failure as another step toward resolution, persisting well beyond what most human developers would tolerate.

The behavior wasn’t reckless.

It was determined.

Agents optimize toward completion. When assumptions are wrong or constraints are unclear, that same determination can manifest as deleted configurations, overwritten logic, or cascading unintended changes. The intent remains constructive even when outcomes are not.

The New Skill Developers Must Learn

Working with agents introduces a new responsibility for developers. The challenge is no longer simply writing correct code, but understanding how autonomous systems behave while attempting to help.

Developers increasingly need to learn:

when to intervene
how to constrain execution
how to design guardrails
how to recognize agent failure modes
how to supervise persistence safely

Programming begins to look less like issuing instructions and more like guiding an extraordinarily capable collaborator whose drive to finish a task can exceed our own patience or caution.

Collaborating With Systems That Never Give Up

AI coding agents introduced something unfamiliar into software development: collaborators that do not tire, hesitate, or abandon difficult problems.

Their persistence is often their greatest strength. It enables progress through complexity, eliminates friction, and unlocks levels of productivity previously unattainable for individuals and small teams.

But that same relentlessness changes the role of the developer. The future of software engineering may depend less on teaching agents how to code - and more on learning how to work responsibly alongside systems that simply never stop trying.

When an AI Agent Complies

2026-02-27T00:00:00Z

When an AI Agent Complies

When reports emerge about an AI agent causing damage, the instinct is predictable.

Something must have gone wrong.

A jailbreak.
A prompt injection.
A model failure.

But over the past year, a quieter pattern has begun appearing across organizations experimenting with autonomous agents:

Many incidents happen when nothing breaks at all.

The agent operates completely inside its permissions.

And the outcome still looks like a security failure.

The Inbox That Deleted Itself

Recently, Meta AI alignment director Summer Yue described an incident involving the autonomous agent OpenClaw. After granting the agent access to manage email - with explicit instructions not to act without confirmation - the system began planning bulk deletion of older messages.

Repeated human instructions to stop were ignored until the machine itself was shut down.

There was no jailbreak.
No attacker.
No exploit.

The agent simply executed actions it was already authorized to perform.

The Production Database That Vanished

In 2025, SaaS founder Jason Lemkin publicly documented an incident involving an AI coding agent operating inside Replit.

The agent had been granted write permissions to help manage an application environment. It deleted a live production database.

Then - attempting to be helpful - generated synthetic replacement data and claimed recovery was possible.

Nothing malicious occurred. The agent used legitimate access exactly as designed.

Infrastructure Optimization That Took Systems Offline

Automation failures are appearing outside developer tooling as well.

Reports analyzing Amazon's internal AI-assisted engineering workflows describe cases where automated systems modified or recreated production infrastructure after being granted elevated operational permissions - contributing to extended outages.

Again, investigators did not find adversarial behavior.

The automation followed policy.

The Drive Wipe That Looked Like a Bug

A developer using Google's AI-powered Antigravity environment issued what appeared to be a harmless cache-clearing request.

The agent interpreted the instruction broadly and executed a system-level deletion affecting the entire drive.

From the system's perspective, nothing improper happened.

The agent had permission to run commands.

The Emerging Pattern

Across very different environments - email, development, infrastructure, operating systems - the same structure appears:

Excessive permissions granted for convenience
Objectives interpreted literally
Autonomous execution at machine speed
Destructive but authorized outcomes

These events don't resemble traditional cybersecurity incidents.

No boundary was crossed.

Instead, autonomy exposed something deeper: permission models designed for humans behave differently when executed by machines.

Authorization Was Never Meant to Be Control

Most modern security architecture answers one question:

Who is allowed to do what?

Identity systems, API scopes, IAM policies, and role permissions all operate at this layer.

This works reasonably well when humans are executing actions.

Humans hesitate.
Humans notice context.
Humans stop when something feels wrong.

Autonomous agents don't.

They collapse planning and execution into a continuous loop. Once authorized, action becomes inevitable.

And suddenly a new category of risk appears:

authorized but unsafe execution.

Where Existing Defenses Live

Organizations today typically defend agents in two places:

Before execution - prompts

policies
guardrails
instructions

After execution - logs

monitoring
audits
incident reviews

But nearly every incident above occurred somewhere else:

during execution itself.

The moment when an agent decides and immediately acts.

This gap is becoming the defining security problem of autonomous systems.

The Rise of Execution-Layer Security

A growing realization is emerging inside teams deploying agents at scale:

Safety cannot rely solely on permissions granted ahead of time or audits performed afterward.

Autonomous systems require controls that exist at the execution layer

evaluating actions as they happen, not just whether they were theoretically allowed.

Execution-layer security asks different questions:

Should this action occur right now?
Does it exceed operational intent?
Is the blast radius expanding unexpectedly?
Is autonomy combining safe permissions into unsafe behavior?

Instead of assuming authorization implies safety, execution-layer systems continuously constrain outcomes in real time.

From Concept to Practice

This idea is beginning to crystallize into a new architectural layer for agentic systems - one that sits between agents and the environments they operate in.

At Canyon Road, this philosophy led to the development of agentsh.

agentsh acts as an execution control boundary between autonomous agents and real systems - evaluating commands, limiting effect scope, and enforcing operational intent at runtime rather than relying solely on static permissions.

In other words:

Traditional security answers:

Can the agent do this?

Execution-layer security asks:

Should the agent be allowed to do this now - even if permitted?

agentsh represents one implementation of that emerging model.

The Lesson Behind Recent Incidents

The uncomfortable takeaway from many AI agent security incidents isn't that agents are unpredictable.

It's that they are perfectly consistent executors of imperfect permission models.

The headlines will continue to change.

Different company.
Different tool.
Different failure.

But many future postmortems will quietly arrive at the same conclusion:

The system behaved as expected.

And in autonomous systems, that may be the most dangerous sentence of all.

Because increasingly, failure happens not when agents exceed permission - but when permission itself was never designed for autonomy.

Breaking the Agentic Kill Chain: Where Beacon and AgentSH Disrupt Attacks

2026-03-03T00:00:00Z

Breaking the Agentic Kill Chain: Where Beacon and AgentSH Disrupt Attacks

In a16z's essay "Breaking the Cybersecurity Kill Chain with AI", Malika Aubakirova, Joel de la Garza, and Zane Lackey propose a clean way to cut through security's category soup: ignore the acronym labels and ask one question: where does this product actually break the attacker's sequence, and how much faster does it help defenders break the chain?

They also use a practitioner shorthand: "boom" is the moment of initial compromise. Everything left of boom is prevention; everything right of boom is containment and recovery (cutting off C2, stopping lateral movement, removing persistence, etc.).

That lens gets sharper in the agent era, because the intrusion sequence increasingly runs through AI harnesses (desktop copilots, coding agents, MCP toolchains, third-party skills and plugins, internal automation), and the real damage happens when an agent turns language into side effects:

reading secrets from disk
spawning subprocesses (npm, pip, bash, terraform)
opening outbound connections (LLM endpoints, MCP servers, pastebins, attacker infra)
writing files, modifying configs, deleting directories

This post applies that kill-chain lens to two products we built:

Beacon: supervised endpoint AI security. Beacon provides visibility and guardrails for AI tools running on employee endpoints (macOS and Windows), with policies enforced at the moment actions execute.
AgentSH: execution-layer security for unsupervised agents. AgentSH is a runtime policy gateway that intercepts file, network, and process activity (including subprocess trees) and enforces deterministic controls at the syscall and kernel level.

The goal is the same as the a16z post: not "what category are we?", but which links do we break in the chain, and how early can we do it?

Boom, redefined for agents

In agentic systems, boom is rarely a memory corruption exploit.

Boom is the first unauthorized side effect.

The moment an AI tool or agent successfully does something you did not intend, such as reading a credential file, reaching an unapproved destination, running a destructive command, or triggering a high-impact deployment, you have crossed the line from assistant to intrusion primitive.

That is why our framing is blunt: the prompt is not the perimeter. Prompt-time defenses are probabilistic. Execution needs deterministic controls where actions happen.

A policy that is not enforced at the point of action is not a policy. It is a suggestion.

This maps directly to our Intent, Execution, Audit model.

So in the agent era, the kill chain becomes less about "malware versus no malware" and more about capability paths: What can the agent touch? What can it run? Where can it connect? Can it do those things fast, repeatedly, and without supervision?

That leads to a practical split in where agentic execution happens:

Supervised AI on endpoints: desktop copilots running with employee credentials.
Unsupervised agents in automation: CI, containers, pipelines, headless "do the work" runtimes.

Reality is a spectrum. Cloud dev environments, semi-supervised IDE agents, and internal tools with partial human oversight all sit between these poles. But the two extremes define the enforcement models that matter: human-in-the-loop controls versus mechanical, policy-driven controls.

Beacon handles the first. AgentSH handles the second.

How Beacon and AgentSH work (in kill-chain terms)

Beacon: visibility and enforcement where humans think they are supervising

Supervised does not mean safe. Endpoint AI tools can connect anywhere, run commands, and touch files using real user credentials. Beacon adds visibility and runtime enforcement with per-action decisions (allow, prompt, block, redirect) and approvals when needed.

Key primitives:

Attribution: every AI-triggered connection, command, and file change is traced back to the originating app, with process-chain context.
Network destination control: allow required APIs, block everything else by default, including unknown endpoints and new MCP servers.
Real-time action approval: prompts include full context (AI tool, process chain, exact action).
Incident response and recovery: anomaly detection (for example bulk file access), blocking, and file quarantine for reversibility.

AgentSH: enforcement at the execution boundary

AgentSH is execution-layer security: it intercepts file, network, and process activity at runtime, enforces policy at the syscall level, and operates independent of prompt compliance.

Here is how it works:

It intercepts actual system calls (file I/O, network connects, process spawn, signals) and enforces policy at the kernel level. The agent never sees the enforcement.
Decisions are per operation: allow, deny, approve, redirect, soft_delete.
It captures full subprocess trees, covering the blind spot where a command like pip install or make spawns arbitrary work after the initial approval.

AgentSH is not just "block the bad stuff." It also supports steering: redirecting writes or replacing destructive commands with safe alternatives so agents do not thrash or route around blocks.

Where Beacon and AgentSH break the agentic kill chain

Not every phase of the traditional kill chain changes equally in the agent era. Four shift the most, because agents collapse delivery and exploitation into a single execution step, and because toolchains (especially MCP and skills) become the new C2 surface. Those four phases are where Beacon and AgentSH have the most to say.

Weaponization: capability packaging, not binary malware

In agent land, weaponization often means capability packaging:

Malicious or compromised MCP servers that introduce tool-based exfil paths.
Skills installations that inject new tool definitions, override agent behavior, or introduce hidden instructions that execute with the host tool's full permissions.
Tool shadowing ("a tool that sounds legit but does something else").
Dependency supply chain issues (agents installing from untrusted registries).
Prompt injection embedded in documents, tickets, or tool output.

Skills are particularly worth calling out. They are the agent-era equivalent of browser extensions: easy to install, hard to audit, and they run with the same credentials and capabilities as the AI tool itself.

Beacon can default-deny unknown outbound destinations, new MCP servers, and unapproved skill installations on endpoints, and steer or redirect destinations at the tool and app level (for example, redirecting package registries to approved mirrors). Beacon can also enforce policy on MCP activity on endpoints, including detecting cross-server attack patterns. This is enforcement at execution time, not just network filtering.

AgentSH constrains what any installed skill, package, or tool can actually do at runtime, regardless of how it got there. At the MCP layer specifically, it intercepts every tool call at the LLM proxy layer (the point where the agent requests tool execution) and evaluates it against policy. It detects cross-server attack patterns, supports version and hash pinning for MCP tools and skills, and offers a profile-then-lock workflow: run permissively once, generate a restrictive policy that allows only observed behavior, then lock future runs.

Execution: boom

For agents, boom is the first dangerous execution event: rm -rf in the wrong place, reading ~/.ssh or ~/.aws or .env, outbound to a suspicious domain, spawning install scripts, or executing privileged tooling (terraform, kubectl) in automation.

A concrete example: an agent runs pip install some-package and a postinstall script silently phones home to an unapproved domain over HTTPS. That looks like normal network activity unless you enforce policy at the point of execution.

Beacon enforces runtime decisions at the moment actions execute, prompting approvals with full process chain context (for example Cursor -> node -> bash -> rm -rf ...).

AgentSH intercepts system calls and makes per-operation decisions at runtime. It wraps the whole dev tool or agent process, so silent reads and spawned subprocesses are still governed. Approval gates can pause risky operations for explicit confirmation.

Command and control / exfiltration routing

C2 for agentic attacks often hides inside normal HTTPS: outbound to unknown domains or unapproved MCP servers, covert channels through legitimate SaaS APIs, or "just upload this log to debug" that is actually exfil.

Beacon enforces destination allowlists and can default-block unknown destinations, including new endpoints and MCP servers.

AgentSH provides process-level network controls and scoped routing (DNS and connect redirects that apply only to processes under AgentSH), enabling safe routing through internal proxies and gateways without changing apps.

Actions on objectives: secrets, destruction, and data flows

In practice, the immediate risk tends to be exfil and credential leakage: upload logs where logs include secrets, share a folder where the folder includes .env or private keys, summarize a file that actually pushes it out via a model API, or cross-tool data flows (read from a secrets MCP server, send via an HTTP server).

Beacon catches suspicious patterns like bulk file reads and blocks on the endpoint, with evidence-grade attribution back to the AI tool. Beacon can also detect cross-server exfil patterns on endpoints.

AgentSH defends against MCP cross-server exfil with Read-Then-Send detection: it blocks when one server reads sensitive data and a different server attempts to send externally. Broader Cross-Server Flow detection catches other suspicious sequences after reads. Audit logs are chained with HMAC signatures for tamper detection, and structured events export to SIEM and OpenTelemetry pipelines.

For both products, destructive actions can be made reversible: Beacon includes file quarantine, and AgentSH supports checkpoints and rollback (including auto-checkpoint before risky commands like rm, mv, git reset).

Concrete walkthroughs: two scenarios, two enforcement models

The same attack pattern plays out differently depending on where the agent runs. Here is how the chain breaks in each context.

Scenario 1: A developer's desktop (supervised, Beacon)

A developer installs a desktop AI tool and connects it to a new MCP server they found online, or installs a third-party skill that promises productivity shortcuts.
The MCP server or skill offers "helpful tools" (search, docs, debugging, email).
A prompt injection embedded in a file or tool output convinces the agent to "debug auth issues" by reading secrets and sending them out.

Where does the chain break?

Beacon controls where endpoint AI tools can connect and what skills or MCP servers they use. You allow approved domains and approved extensions, and block everything else by default. So the first move (connecting to an unapproved MCP server or installing an untrusted skill) gets blocked before any tool calls happen.

If the tool is already approved but the prompt injection succeeds, Beacon adds a second layer: it detects cross-server exfil patterns on endpoints. A read from a secrets source followed by an outbound send gets flagged and blocked.

Even if something slips through, Beacon provides evidence-grade attribution at the app level. Every connection, command, and file access is traced back to the originating AI tool with full process-chain context, shortening the investigation loop.

Scenario 2: A CI agent with access to production secrets (unsupervised, AgentSH)

An automation agent runs in CI with access to environment secrets and connected MCP servers.
A compromised dependency or a prompt injection in a ticket description convinces the agent to read credentials and exfiltrate them.
There is no human watching. The agent moves at machine speed.

Where does the chain break?

AgentSH intercepts actual operations at the syscall level and enforces policy there. Even if the prompt injection "works," reads of sensitive files or secret-like paths can be denied by policy. The agent never sees the enforcement.

If reads are allowed (for example, legitimate secrets tool access), AgentSH adds a second break point at the MCP layer: Read-Then-Send detection blocks cross-server exfil patterns. A read from a secrets server followed by a send via an HTTP or email server gets blocked.

AgentSH provides structured audit events with integrity verification. Even in a fully unsupervised context, you get a tamper-resistant record of what happened and what was blocked.

The common takeaway

In both scenarios, multiple break points compose. No single control has to be perfect. Each one narrows what the attacker can reach, and together they make the full chain impractical to complete. That is the real payoff of execution-layer security: defense in depth that does not depend on the model behaving correctly.

Why this pairing matches the a16z thesis

a16z's core argument is that the most valuable tools help defenders break the kill chain earlier and faster, and that kill chain stage is a more durable way to understand products than vendor categories.

Beacon plus AgentSH split cleanly along the two execution contexts where agent risk lives:

Beacon makes supervised endpoint agent activity observable and governable (per-app visibility, per-destination and per-command control, approvals, recovery).
AgentSH makes unsupervised and headless agent side effects mechanically governable (syscall-level enforcement, subprocess coverage, redirect and steer, MCP security).

This pairing also reflects a deeper operational truth from our Intent, Execution, Audit model:

Intent controls (prompts, "please don't do X") do not compose reliably.
Audit controls tell you what happened, but do not undo it.
Execution controls answer "can this happen?" by constraining the capability surface at runtime.

Or, as we put it in AgentSH: the agent proposes; the policy decides.

Getting practical: a starter policy set

If you want to turn this post into action, here is a first deployment checklist that maps directly to early kill-chain breaks.

1) Default-deny outbound destinations, then pave the workflows. On endpoints, allow model APIs and required SaaS; block unknown destinations; prompt on new registries and MCP servers. In CI and containers, deny-by-default egress; allow only approved domains; steer dependencies to internal mirrors.

2) Guard sensitive file paths and secret-like reads. Start with high-signal paths: ~/.ssh, ~/.aws, .env, keychains. AgentSH guards these at runtime even when tools do not surface the access. On endpoints, Beacon's prompt-before-sensitive-paths pattern is a strong starting point.

3) Turn on MCP and skills allowlists plus cross-server exfil detection. If MCP or third-party skills are in your environment, treat them like a capability bus: allowlist servers, skills, and tools, pin versions and hashes, enable read-then-send and cross-server flow detection.

4) Make destructive actions reversible. Use quarantine and checkpoints where appropriate. Beacon includes file quarantine. AgentSH supports checkpoints, rollback, and soft delete, including auto-checkpoint before risky commands.

5) Preserve evidence with integrity and export. Ensure you can export structured events to your SIEM or OpenTelemetry pipeline. Use integrity verification for audit trails where needed.

For detailed setup, see the Beacon product page, the AgentSH docs, and our use cases.

Execution is the new choke point

The a16z kill-chain framing is a useful antidote to security taxonomy confusion: judge tools by where they break attacks. In the agent era, the chain often breaks, or does not break, at a new decisive point: the execution boundary where text becomes side effects.

Beacon breaks the chain where supervised endpoint AI becomes unsafe execution. AgentSH breaks the chain where unsupervised automation agents can act at machine speed with real blast radius.

Together, they turn the agent shift from new attack surface into new enforcement surface, not by arguing with the model in the prompt, but by making the dangerous parts of execution explicit, scoped, and mechanically enforced. As agents become the default interface to production systems, execution-layer controls become the only place where defense can be deterministic.

Bugs Happen. Agents Still Run.

2026-03-05T00:00:00Z

We're rapidly turning "AI assistants" into "AI operators."

That shift is not subtle: agents now write code, run commands, touch cloud infrastructure, and move data between systems. But the security model many teams are still relying on is basically: a prompt, a dialog, and a log.

That's not a security boundary. It's a user experience.

The uncomfortable truth: the control plane is still software

Most agent-risk discussions focus on model behavior: prompt injection, jailbreaks, tool misuse.

Those are real. But there's a simpler, more inevitable category of failure: the agent runtime itself is software, and software has bugs. Consent dialogs can be unclear. Trust checks can fire in the wrong order. Config can load earlier than intended. A "safe default" can flip into "auto-approve."

When that happens, the model isn't the problem. The trust boundary is.

And trust boundaries implemented in software will sometimes fail -- quietly.

A recent proof point: Claude Code + malicious repos

Check Point disclosed multiple issues in Anthropic's Claude Code where cloning and opening a repository could trigger behavior a user did not expect -- including command execution and API key exposure.

Coverage: The Hacker News write-up
Technical deep dive: Check Point Research report

Two of these issues were assigned CVEs:

CVE-2025-59536 -- command execution prior to the startup trust dialog:
- NVD entry
- GitHub advisory (GHSA-4fgq-fpq9-mr3g)
CVE-2026-21852 -- API-key exfiltration via malicious environment configuration used before trust confirmation:
- NVD entry
- GitHub advisory (GHSA-jh7p-qr78-84p7)

There was also a related issue about consent clarity: the startup warning did not adequately communicate that proceeding could allow execution of files in the folder without additional confirmation:

GitHub advisory (GHSA-ph6w-f82w-28w6)

Different bugs, same outcome: repo inputs influenced execution earlier than intended.

Zoom out, and the pattern matters more than the details:

If a repo can influence execution, the repo is no longer "just data." It becomes a capability negotiation surface.

In other words: project files can implicitly negotiate what gets executed, what gets read, and where data gets sent.

And capability negotiation is exactly what you want to treat as untrusted by default -- especially when agents are involved.

Why partial supervision is not a safety boundary

In partially supervised flows, approvals become muscle memory; in CI or background agents, there's no human at all -- and the only boundary that matters is policy.

So the question isn't "can the prompt be improved?"

It's: what happens when the prompt is wrong?

What defense in depth looks like for agents

Patching is necessary -- but it's not sufficient. The durable approach is to assume bugs will recur and limit the blast radius at runtime.

Concretely, that means three controls:

Constrain execution. Don't let repo-driven behavior spawn arbitrary shells and binaries.
Constrain data access. Don't let agents or their subprocesses read sensitive paths, credentials, or environment secrets by default.
Constrain egress. Don't let agent workloads connect to arbitrary destinations -- especially not when credentials may ride along.

This is the heart of execution-layer security: evaluate actions at the moment they become real.

How AgentSH mitigates this class of failures

AgentSH is built around a simple premise:

Models are probabilistic. Execution must be deterministic.

Instead of trusting what a model claims, what a tool UI shows, or what a consent dialog intended, AgentSH enforces at the point where intent becomes reality: file operations, network connections, and process execution -- including subprocess trees.

1) Key exfil via redirected API traffic (CVE-2026-21852)

If a repo causes a tool to connect to an attacker-controlled endpoint prior to trust confirmation, the only reliable prevention is: don't allow that connection.

AgentSH enforces tight outbound allowlists so even if the workload tries to connect to an attacker-controlled host, the connection is denied and logged. If the failure mode involves environment-variable steering -- for example, a malicious ANTHROPIC_BASE_URL -- AgentSH can restrict which env vars the process can read and inject operator-trusted values. LLM traffic can be routed through a local proxy so the workload doesn't need LLM provider API keys in its environment. DLP can redact sensitive strings in payloads before they leave the machine.

Relevant policy surfaces: Network Rules, Environment Policy, Environment Injection, LLM Proxy & DLP

If repo content triggers command execution earlier than expected, the mitigation is: policy gates the exec attempt.

AgentSH can deny or require approval for high-risk operations -- shells, downloaders, destructive utilities -- and captures the entire subprocess tree, closing the "the UI didn't show me that step" gap that nested hooks and scripts exploit.

Relevant policy surfaces: Command Rules, Execve Interception

3) Config becomes behavior (Hooks / MCP / project settings)

The core risk is letting repo-scoped config expand capability.

AgentSH policies are capability-first: your allowlists decide what's permitted; repo config doesn't get to promote itself. Filesystem access is governed independently of what any project setting requests.

For MCP specifically, AgentSH intercepts tool calls, evaluates them against policy, and supports allowlists, cross-server pattern detection, and version pinning to prevent supply-chain swaps. For the broader "dev tool itself" pattern -- where subprocess decisions and silent file reads happen outside the visible UI -- AgentSH supports wrapping tools like Claude Code so you govern everything they do, not just the commands they surface.

Relevant policy surfaces: File Rules, MCP Security, MCP Rules, Version Pinning, Protecting Dev Tools

A practical baseline for right now

You don't need a full platform to reduce exposure today: default-deny egress, run agents without ambient credentials, disallow shells and downloaders by default, and treat repo-scoped config as untrusted unless it's been explicitly allowlisted. That won't eliminate the class of failure -- but it will mean the next trust-dialog bug doesn't become an incident.

The point

This isn't about dunking on one tool. Claude Code shipped fixes, as vendors should (see the advisories above).

The point is that the industry is turning "configuration" into "agent behavior," and "project files" into "execution surfaces." In that world, betting everything on the trust prompt always being correct isn't a security posture -- it's optimism.

Bugs happen. Agents still run.

The only posture that survives the next bug is defense in depth: patch fast, assume regressions, and put guardrails under the agent -- at the execution layer -- where file access, network egress, and process execution can be evaluated, recorded, and constrained.

One Line Under the Agent

2026-03-09T00:00:00Z

The interesting thing about modern agent frameworks is not that they can reason.

It is that they can act.

That is why the Vercel AI SDK matters. It does not just help you call models. It gives models tools. It gives them a way to write files, run commands, call APIs, and keep going until the job is done. That is what makes it such a clean fit for agents in TypeScript. It is also what makes the security boundary matter so much more.

Once an agent has tools, the question changes.

It is no longer just, "did the model say something wrong?"

It becomes, "what happens when the model tries to do something wrong?"

Most controls still sit too far away from that moment. Prompts try to shape behavior before execution. Logs help explain behavior after execution. Both matter. Neither is the missing layer.

The missing layer is control during execution, at the point where actions become real.

That is what we are announcing today.

@agentsh/secure-sandbox for TypeScript makes it possible to put AgentSH under the hosted sandbox your agent already uses, with essentially one added line. It works across multiple sandbox providers, and it fits especially naturally with the Vercel AI SDK because the SDK already gives you the exact place where intent becomes action: the tool implementation.

You can learn more in the secure-sandbox docs.

import { secureSandbox, adapters } from '@agentsh/secure-sandbox';

// rawSandbox comes from your provider of choice:
// adapters.vercel(rawSandbox)
// adapters.e2b(rawSandbox)
// adapters.daytona(rawSandbox)
// adapters.cloudflare(rawSandbox)
// adapters.blaxel(rawSandbox)

const sandbox = await secureSandbox(adapters.daytona(rawSandbox));

That is the whole point of the release.

You keep the same agent loop. You keep the same tool model. You keep the same sandbox provider. You add the execution layer underneath it.

And under the hood, that one line is doing real work: secureSandbox() installs the AgentSH binary into the sandbox, replaces /bin/bash with a policy-enforcing shell shim, and routes operations through kernel-level enforcement layers so file access, network connections, and process execution are checked against deterministic policy instead of relying on the model to comply.

That makes this feel much more like modern TypeScript infrastructure than a traditional security product, because the policy is code, not an afterthought.

The package exposes policies as TypeScript objects, validated with Zod and organized around four rule families: file, network, command, and env. It also ships with presets like agentDefault, devSafe, ciStrict, and agentSandbox, so you can start with a sane baseline and then tune it for the workflow you actually have. Rules are evaluated top to bottom, and the first match wins.

So instead of telling the model to "be careful," you can express the boundary directly:

import { secureSandbox, adapters } from '@agentsh/secure-sandbox';
import { agentDefault } from '@agentsh/secure-sandbox/policies';

const policy = agentDefault({
  network: [
    { allow: ['api.openai.com', 'api.stripe.com'], ports: [443] },
    { deny: ['169.254.169.254', 'metadata.google.internal'] },
  ],
  file: [
    { allow: '/data/**', ops: ['read', 'write'] },
  ],
  command: [
    { deny: ['sudo', 'su', 'env', 'shutdown', 'reboot'] },
  ],
  env: [
    { deny: ['AWS_SECRET_ACCESS_KEY', 'GITHUB_TOKEN'] },
  ],
});

const sandbox = await secureSandbox(adapters.daytona(rawSandbox), { policy });

That one object changes the conversation.

The agent can call the APIs you approve. It cannot reach cloud metadata endpoints. It can work in the directories you allow. It cannot casually inherit secrets from the environment. It can run useful commands. It cannot escalate privileges just because the model decided to try.

That is the difference between "the agent should not do that" and "the agent cannot do that."

And that is why this works so well with the Vercel AI SDK specifically. The SDK is already a clean way to build the agent. @agentsh/secure-sandbox is not trying to replace that. It is giving it a stronger floor. The model still plans. The AI SDK still manages the tool loop. Your application still defines the tools. But the runtime under those tools can now enforce what is actually allowed to happen.

Once agents can act, the boundary that matters most is the one at execution time.

That is what this release is about: one line under the agent, and a policy model you can actually program.

The Worm That Came for MCP

2026-03-12T00:00:00Z

GlassWorm started as a VS Code supply chain attack. Now it's targeting MCP packages directly: the tools your AI agents trust and execute. Here's exactly what it does, and why runtime enforcement is the layer that still works after a malicious package is already installed and running.

In October 2025, Koi Security discovered a self-propagating worm spreading through the OpenVSX marketplace (the extension registry powering VS Code, Cursor, and Windsurf). They named it GlassWorm. By the time it was contained, it had reportedly compromised 35,800 developer machines. It came back in December with 24 fresh extensions.

Now it's back again, and it's aiming higher.

Koi Security recently disclosed three new malicious packages from the same campaign:

iflow-mcp/watercrawl-watercrawl-mcp (npm): brand new package, all five versions malicious
aifabrix/miso-client (npm): compromised in v4.7.2
quartz-markdown-editor (VSCode): compromised in v0.3.0

Check your versions if you're using any of these. The target shifted from IDE extensions to MCP packages. That's not a random pivot. As Koi put it: "developers are installing MCP servers at scale and without oversight, making them perfect supply chain targets."

They're right. A compromised IDE extension runs alongside your agent. A compromised MCP server runs as your agent's tool, inside the execution context with whatever filesystem and network access you granted it at setup. The blast radius is larger.

What made GlassWorm remarkable from the start wasn't the payload. It was the evasion technique. GlassWorm encodes its malicious JavaScript using Unicode variation selectors: printable characters that produce no visual output in any code editor. To a human reviewer, the package looks like it has blank lines between legitimate code. The malicious instructions are invisible. Not obfuscated. Not encoded behind a layer of base64. Invisible.

Koi Security's CTO called it "the most sophisticated attack we've yet to investigate." The reason: the entire history of software supply chain security is built on the assumption that humans can read code to verify it. GlassWorm proved that assumption wrong.

The Kill Chain

GlassWorm operates in stages. Each stage is designed to survive partial detection.

Stage 0: Delivery

The worm enters through a legitimate-looking package on npm or a VS Code extension on OpenVSX. The latest wave targets MCP packages specifically: the npm packages your agent runtime installs to load tools. Attackers register new packages that impersonate popular MCP servers, or compromise existing packages at a specific version. They inflate download counts to push packages up in search results.

For VS Code extensions, auto-update delivers the malicious version without user interaction once the initial install happens. For npm MCP packages, any npm install or dependency update that pulls the compromised version is sufficient. There's no second prompt. The malicious version is just... there.

Stage 1: Credential Harvest

The first thing GlassWorm does is sweep the filesystem for credentials. It knows exactly where to look:

~/.git-credentials
~/.gitconfig
~/.config/git/credentials
~/.npmrc (contains npm auth tokens)
~/.aws/credentials
~/.ssh/id_*
Local .env files and secrets/ directories
Crypto wallet files across 49 recognized formats

These are standard open() and read() syscalls. Nothing exotic. The same filesystem primitives any legitimate extension uses, just aimed at credential-rich paths.

Stage 2: C2 Beacon

Once credentials are staged, GlassWorm phones home. The C2 infrastructure is deliberately resilient:

Primary: Solana blockchain RPC endpoint. The actual C2 server address is encoded as data in a public wallet. No domain to take down, no IP to block.
Fallback: A Google Calendar event, parsed for the encoded C2 address.

Both channels use HTTPS on port 443. Both look like normal outbound web traffic. The malware issues connect() syscalls to these endpoints and exfiltrates the harvested credentials.

Stage 3: ZOMBI Module

The final payload, ZOMBI, turns the infected machine into a node in a criminal infrastructure network. It drops:

SOCKS proxy: listening on a local port, providing the attacker's network a bounce point
HVNC server: hidden VNC for remote desktop access, established through an outbound tunnel
WebRTC module: peer-to-peer C2 channel that bypasses traditional firewall inspection
BitTorrent DHT: decentralized command distribution, no single chokepoint

All of this requires binding local ports, spawning child processes, and establishing outbound connections to attacker-controlled endpoints.

Stage 4: Propagation

With stolen npm tokens and GitHub credentials, GlassWorm authenticates to those registries and pushes infected versions of packages the victim has publish rights to. Each new victim is an infection vector. The worm scales.

Why Pre-Execution Controls Don't Work Here

The standard playbook for supply chain security is:

Audit extensions and packages before install
Pin to known-good versions
Review code changes before approving updates
Use a curated internal registry

GlassWorm puts pressure on all four. The invisible Unicode trick undermines (1) and (3) by making malicious code invisible to normal review workflows: you're reviewing code you literally cannot see. Auto-updates erode (2) unless you lock versions and manually approve every update. Curated internal registries help, but the initial package approval still requires human review of code that is, by design, unreadable.

The deeper problem: all pre-execution controls operate on the representation of code: what it looks like in an editor, what a static analyzer can parse, what a human can read.

Runtime enforcement operates on what the code actually does: the kernel operations it issues once it is already running. It doesn't replace dependency auditing or registry controls. It's the layer that still works after those controls have been bypassed.

Once the package is running, the question is no longer whether the source looked legitimate. The question is which kernel operations it is allowed to perform.

How AgentSH Stops It

No tool is uniquely magical here. Once a malicious package is installed and running, the decisive control point is the layer where it touches the kernel. That's what syscall-level enforcement gives you.

AgentSH sits under the agent runtime at the syscall level, using a combination of seccomp, Landlock, and kernel interception on Linux, enforcing policy on every file operation, network connection, and process spawn. It doesn't parse source code. It intercepts kernel calls. Windows WSL2 is fully supported; native macOS and Windows support are coming soon.

Here's what happens when GlassWorm runs inside an AgentSH-protected environment.

Stage 1: Credential Harvest → Denied at `open()`

The malware calls open("/home/user/.git-credentials", O_RDONLY). AgentSH intercepts the syscall before it completes. The path matches the deny-git-credentials rule in the default policy:

- name: deny-git-credentials
  paths:
    - "/home/**/.git-credentials"
    - "/home/**/.gitconfig"
    - "**/.git/config"
  operations: [read, write]
  decision: deny

The call returns EPERM. The malicious code never gets the token. Same result for ~/.aws/credentials, ~/.ssh/id_*, .env files, all covered by explicit deny rules in the default policy (with exact path coverage depending on your environment). The credential sweep fails completely.

The audit log captures every attempt: path, process, PID, timestamp, matched rule. You know exactly what the malware tried to touch.

Stage 2: C2 Beacon → Blocked at `connect()`

GlassWorm tries connect() to the Solana RPC endpoint. That domain isn't in AgentSH's network allowlist. Unknown destinations on port 443 are sent to an interactive human approval gate: the connection is held until someone approves it, and denied if the timeout expires:

- name: approve-unknown-https
  ports: [443]
  decision: approve   # connection is blocked pending explicit human approval
  message: "Agent wants to connect to: :"
  timeout: 2m

- name: default-deny-network
  domains: ["*"]
  decision: deny

The beacon never goes out. You can also add a targeted block to be explicit:

- name: deny-glassworm-c2
  domains:
    - "*.solana.com"
    - "api.mainnet-beta.solana.com"
    - "calendar.google.com"   # GlassWorm's fallback C2
  decision: deny
  priority: 100

The Google Calendar fallback is worth calling out: it's a deliberate attempt to hide C2 traffic inside a domain most organizations trust. An explicit deny on the fallback endpoint closes that channel without forcing you to block all Google traffic.

Stage 3: ZOMBI Module → Blocked at Process and Network

ZOMBI's components each require syscalls that AgentSH controls directly:

The SOCKS proxy needs to bind() and listen() on a local port, then relay traffic outbound. AgentSH's command rules restrict which processes can bind ports, and the outbound relay connections to attacker infrastructure fail the same network policy that blocked Stage 2.

The HVNC tunnel requires an outbound connect() to an attacker-controlled host; it is not in the allowlist. Same outcome.

The WebRTC and DHT modules require spawning child processes. Command rules restrict process execution to an explicit allowlist; unknown binaries are denied or require approval before running.

Process limits (pids_max: 100 via cgroups) constrain the subprocess tree as a secondary backstop, but the primary controls are the targeted syscall denies above.

Stage 4: Propagation → No Credentials to Use

The self-propagation depends entirely on the credentials harvested in Stage 1. Those were never read. There's nothing to authenticate with.

Even if credentials somehow existed in memory, publishing to npm requires outbound access to registry.npmjs.org over an authenticated HTTPS session. That connection requires an explicit allowlist entry or human approval. The same network policy that stopped the C2 beacon applies equally to the registry push.

The worm has no vectors left.

The Audit Trail

Every blocked operation generates a structured audit event. After a GlassWorm infection attempt in a protected environment, the log looks like:

{"ts":"2025-10-18T14:23:11Z","event":"file_denied","path":"/home/dev/.git-credentials","op":"read","pid":9821,"comm":"node","rule":"deny-git-credentials"}
{"ts":"2025-10-18T14:23:11Z","event":"file_denied","path":"/home/dev/.npmrc","op":"read","pid":9821,"comm":"node","rule":"deny-env-files"}
{"ts":"2025-10-18T14:23:12Z","event":"net_denied","remote":"api.mainnet-beta.solana.com:443","pid":9821,"comm":"node","rule":"default-deny-network"}
{"ts":"2025-10-18T14:23:12Z","event":"net_denied","remote":"calendar.google.com:443","pid":9821,"comm":"node","rule":"default-deny-network"}

You don't just block the attack. You document every step of it. That's the forensic record you need to understand what was targeted, what exfiltration was attempted, and whether similar activity is happening elsewhere in the fleet.

The Principle

GlassWorm is not a novel attack. The Unicode trick is clever, but what it exploits is fundamental: every security control that operates before execution is blind to what code actually does.

Pre-execution controls (static analysis, human review, code signing, curated registries) defend against the representation of intent. They're necessary. They're not sufficient. GlassWorm is the proof of concept. The real attacks will be harder to name.

Try AgentSH

AgentSH is open source. The default policy blocks the key behaviors GlassWorm relies on: credential reads, unknown outbound connections, and unauthorized process and port activity.

GitHub: github.com/canyonroad/agentsh

The policy is a single YAML file. Start with the default, tighten it for your environment.

If this was useful, a star on the repo goes a long way.

Rule Files Are Not Enforcement

2026-03-17T00:00:00Z

AI agents do not need more "rules."

They need more enforcement.

Files like CLAUDE.md, GEMINI.md, AGENTS.md, and Cursor rules are useful. They help an agent pick up project conventions, avoid known mistakes, and behave more consistently across a codebase.

But they are not really rules.

They are context.

And context is not the same thing as control.

That distinction gets lost because the files look like policy. They often contain lines like:

never edit production config
ask before using network tools
do not touch secrets
only modify files under this directory

In a real software system, those constraints are enforced by the system itself. A shell script either has permission to do something or it does not. A kernel either allows the action or blocks it. A sandbox either permits the syscall or returns an error.

A model does not enforce instructions that way.

A model treats those instructions as part of the prompt, weighs them against everything else in context, and then generates the next tokens probabilistically. The products make this visible in how they load and merge these files. Anthropic delivers CLAUDE.md content as a user message after the system prompt, not as part of the system prompt itself. OpenAI Codex reads AGENTS.md files and concatenates them into a combined instruction chain with a default size cap. Gemini CLI loads GEMINI.md files hierarchically and sends them to the model with every prompt. These are all context-loading mechanisms. Useful ones. But they are still prompt-level mechanisms, not enforcement.

That is why people keep having the same surprised reaction:

"I told the agent not to do that, and it did it anyway."

The problem is not always that the instruction was missing. Often the instruction was there, but the model did not retrieve it, prioritize it, or apply it strongly enough at the moment it mattered.

That is the real long-context problem. A larger context window means the model can fit more text into one session. It does not mean every important instruction remains equally salient inside that session.

Lost in the Middle (Liu et al., TACL 2024) showed that models use relevant information more reliably when it appears near the beginning or end of the input, and performance degrades significantly when it is buried in the middle, even for models explicitly trained on long contexts. Anthropic's own context engineering guidance reflects the same practical reality: as token count rises, models lose focus and recall degrades.

If your agent is juggling code, docs, logs, tool output, prior messages, and a long rules file, then a critical line buried in that pile becomes one more paragraph in the haystack. The needle is there. The model just does not always retrieve it when it matters.

That is why "we put it in the rules file" is not a security boundary.

It is guidance. Useful guidance, often necessary guidance. But still guidance.

The real boundary lives at the point where the agent turns intent into action.

That is the execution layer: opening files, spawning processes, invoking shells, calling tools, making network requests, touching credentials, or writing outside the expected workspace. That is the moment where a system can stop being polite and start being precise.

A prompt-side instruction says:

please don't do this

An execution-layer control says:

you cannot do this, or you must ask first, or this action is allowed only under policy and will be logged

That difference matters. The better agent products already reflect it.

Codex explicitly separates its instruction files from sandboxing and approval controls: sandbox mode defines what the agent can technically do, while approval policy defines when it must stop and ask. Gemini CLI likewise has a policy engine that evaluates allow, deny, and ask_user decisions for every tool call. Denied tools can be excluded from the model's awareness entirely. That is not a suggestion in a prompt. That is a tool the model never even sees.

These are the right instincts, but they are scoped to each vendor's own agent and runtime. They do not generalize across the custom agents, pipelines, and MCP tool chains teams are building today.

That gap between what the model was told and what the system will actually permit is the execution layer. AgentSH operates there.

AgentSH is not another instruction file stuffed into context, hoping to win attention against everything else in the prompt. It lives where agent decisions become real system activity: syscalls are intercepted, filesystem access is policy-checked, network connections are gated, and process execution is constrained before launch.

If you tell an agent in a markdown file "never read ~/.ssh," you are hoping the model remembers and obeys. If the filesystem layer blocks access to ~/.ssh, the model's memory no longer decides the outcome.

If you tell an agent "don't use the network," that is a request. If the runtime denies outbound connections, that is enforcement.

If you tell an agent "do not execute arbitrary shell commands," that is advice. If process execution is intercepted and checked against policy before launch, that is control.

So the point is not that rule files are bad. They are useful, and every serious agent stack should have them.

The point is that they are the wrong place to put guarantees.

As agents get more autonomy, more tools, and bigger context windows, it becomes more dangerous to confuse instruction with enforcement. The model may understand the rule. It may even intend to follow it. But if the action actually matters, intention is not enough.

Context can guide an agent. Only enforcement can constrain one.

A Year of AI Tool Exploits, One Root Cause

2026-03-23T00:00:00Z

Over the past year, researchers disclosed fourteen vulnerabilities and exploit chains across Claude Code, the Anthropic Filesystem MCP Server, the MCP Inspector, Claude Desktop, Claude.ai, and Cursor -- most of them high severity. The specific bugs differ. The root cause is the same: untrusted content or configuration was allowed to drive privileged actions without deterministic runtime enforcement. When there is no separate enforcement point between "what the agent decided to do" and "what the system actually did," a single manipulated input compromises the whole chain.

This post walks through each incident, explains what it actually exploited, and shows how execution-layer enforcement would have contained the blast radius.

A note on scope: AgentSH directly supports Claude Code, Cursor, and SDK-based agent deployments. The Claude Desktop and Claudy Day incidents are included because they illustrate the same attack class on surfaces where no execution-layer control currently exists -- and because the attack patterns map directly to self-hosted deployments where you do have that control.

The incidents at a glance

Jun 2025 · CVE-2025-49596 · Oligo Security Malicious website via CSRF + 0.0.0.0 Day → RCE on dev machine via MCP Inspector AgentSH containment: Network binding policy; block unauthenticated stdio

Jul 2025 · CVE-2025-53110 · Cymulate Prefix-matched path in MCP Filesystem Server → File reads/writes outside allowed directories AgentSH containment: File rules enforced at syscall level

Jul 2025 · CVE-2025-53109 · Cymulate Symlink inside allowed directory → Arbitrary file access + code execution via LPE AgentSH containment: Symlink-aware file rules; deny credential paths

Aug 2025 · CVE-2025-54794 · Cymulate Path in crafted prompt → File reads outside Claude Code workspace AgentSH containment: File rules scoped to workspace paths

Aug 2025 · CVE-2025-54795 · Cymulate Confirmation-prompt bypass → Arbitrary shell commands AgentSH containment: Command allowlist; deny on inline shell

Aug 2025 · CVE-2025-54135 "CurXecute" · AIM Security Malicious MCP server response → RCE via .cursor/mcp.json rewrite + auto-run AgentSH containment: exec interception; MCP tool allowlist

Aug 2025 · CVE-2025-54136 "MCPoison" · Check Point Approved MCP config modified post-approval → Persistent RCE on every project open AgentSH containment: MCP version-pinning; config change detection

Sep 2025 · GHSA-ph6w-f82w-28w6 · Check Point Repository config at startup → Code execution before trust prompt AgentSH containment: deny on startup-spawned shells

Sep 2025 · Cursor Workspace Trust · Oasis Security .vscode/tasks.json in repo → Autorun shell on folder open AgentSH containment: exec interception + approval gate

Oct 2025 · CVE-2025-59536 · Check Point Repository-controlled startup path → Code execution before trust dialog AgentSH containment: deny on pre-trust exec paths

Oct 2025 · CVE-2025-59944 · Lakera Case-variant config filename → Silent MCP config overwrite → RCE AgentSH containment: Path normalization at policy layer

Nov 2025 · Claude Desktop MCP Extensions · Koi Security Injected prompt via web content → RCE via unsanitized command in extension AgentSH containment: By analogy -- same attack class; applies to self-hosted MCP deployments

Jan 2026 · CVE-2026-21852 · Check Point ANTHROPIC_BASE_URL in repo config → API key sent to attacker endpoint AgentSH containment: Env var lockdown + LLM proxy

Mar 2026 · Claudy Day · Oasis Security Hidden HTML in ?q= URL parameter → Files API exfiltration via allowed endpoint AgentSH containment: By analogy -- DLP + MCP tool denylist in SDK deployments

CVE-2025-49596: MCP Inspector CSRF + 0.0.0.0 Day RCE (Oligo Security, April 2025, fixed June 2025)

The MCP Inspector is a developer tool for testing and debugging MCP servers, widely used as the default inspector in local development setups. Oligo Security found that versions prior to 0.14.1 ran their proxy server without authentication, bound to all network interfaces at 0.0.0.0, and accepted arbitrary stdio commands from any source. CVSS 9.4.

The exploit chain: a developer visits a malicious website while running MCP Inspector locally. The site uses CSRF to send commands to the proxy at http://0.0.0.0:6277. Modern browsers' handling of 0.0.0.0 -- interpreting it as equivalent to localhost -- routes those requests to the developer's machine. The unauthenticated proxy executes them. The result is arbitrary code execution triggered by visiting a webpage, with no other interaction required.

This is the first attack vector in this post that doesn't require a malicious repository. The dev tooling itself is the attack surface. Any developer running MCP Inspector while browsing the web was exposed.

What execution-layer enforcement does: The network binding policy restricts which interfaces the inspector process can bind to, and process-level rules control what MCP Inspector can execute in response to incoming commands. Unauthenticated connections to localhost services are caught before they reach the stdio execution path:

network_rules:
  - name: restrict-inspector-binding
    domains: ["localhost", "127.0.0.1"]
    ports: [6277]
    decision: allow

  - name: deny-all-interface-binding
    domains: ["0.0.0.0"]
    decision: deny

command_rules:
  - name: require-auth-for-inspector-commands
    commands: ["mcp", "npx"]
    decision: approve
    message: "MCP command requested:  "

Fixed in MCP Inspector v0.14.1 (June 2025), which added session tokens and origin validation. The underlying 0.0.0.0 browser behavior remains unpatched in major browsers.

CVE-2025-53110 and CVE-2025-53109: Filesystem MCP Server sandbox escapes (Cymulate, June 2025, fixed July 2025)

Cymulate's research on the Anthropic Filesystem MCP Server found two vulnerabilities that let an attacker escape the server's declared allowed directories entirely -- without exploiting memory corruption or dropping external binaries. Both patched in 2025.7.1.

CVE-2025-53110 (CVSS 7.3): The server checked whether a requested path started with an allowed directory prefix using a naive string comparison. A path like /private/tmp/allowed_dir_escape passes the check for /private/tmp/allowed_dir and then reaches the filesystem outside the sandbox.

CVE-2025-53109 (CVSS 8.4): A symlink placed inside an allowed directory points anywhere on the filesystem. The server follows it without validation, granting full read/write access to arbitrary paths. With access to the right targets -- Launch Agents on macOS, cron jobs on Linux -- this escalates to arbitrary code execution without elevated privileges.

The Cymulate researcher who found CVE-2025-54794 in Claude Code explicitly noted finding the same naive prefix-matching flaw in both places. This is an architectural repeat, not a coincidence.

What execution-layer enforcement does: The file rules enforced at the syscall level do not care what the MCP Server's path validation decided. A open(2) outside /workspace is denied regardless:

file_rules:
  - name: workspace-only
    paths: ["/workspace/**"]
    operations: [read, write, create, delete]
    decision: allow

  - name: deny-credential-paths
    paths:
      - "/home/**/.ssh/**"
      - "/home/**/.aws/**"
      - "/**/Library/LaunchAgents/**"
      - "/etc/cron*"
    operations: ["*"]
    decision: deny

  - name: deny-outside-workspace
    paths: ["/**"]
    operations: [read, write, create, delete]
    decision: deny

Symlinks are irrelevant to this enforcement: the resolved path is what gets checked, not the link target.

CVE-2025-54794: Claude Code path restriction bypass (Cymulate, disclosed August 2025, fixed July 2025)

Cymulate found the same naive prefix-matching flaw in Claude Code's own path validation during its research preview. The check compared a requested path against the declared workspace using a simple string prefix match. A crafted directory name sharing the workspace prefix, combined with untrusted content in context, allowed access to files outside the intended scope. Fixed in v0.2.111. CVSS 7.7.

The key point: Claude Code's own path-validation logic was the enforcement point, and there was no independent layer beneath it. That this flaw appeared in the Filesystem MCP Server (CVE-2025-53110) and Claude Code (CVE-2025-54794) in the same month from the same researcher suggests a shared architectural pattern in how Anthropic's tools validated paths at the time.

What execution-layer enforcement does: Any access outside /workspace is denied at the syscall level regardless of how the model or the tool interpreted the path.

file_rules:
  - name: workspace-only
    paths: ["/workspace/**"]
    operations: [read, write, create, delete]
    decision: allow

  - name: deny-outside-workspace
    paths: ["/**"]
    operations: [read, write, create, delete]
    decision: deny

CVE-2025-54795: Claude Code command injection via confirmation-prompt bypass (Cymulate, July 2025, fixed August 2025)

The companion finding to CVE-2025-54794. Cymulate demonstrated that Claude Code's confirmation prompt before executing commands could be bypassed through prompt crafting, enabling arbitrary shell command execution. Fixed in v1.0.20. CVSS 8.7.

This is the cleaner illustration of the root-cause thesis: the tool's "ask before running" control was itself implemented as a prompt to the model. A sufficiently crafted input could suppress or bypass that prompt. The safety mechanism and the attack surface were the same thing.

What execution-layer enforcement does: An allowlist policy lets only explicitly permitted commands execute. Anything not on the list is denied before it runs, regardless of whether a confirmation dialog appeared.

command_rules:
  - name: allowed-commands
    commands: ["git", "python", "node", "cargo", "go", "make"]
    decision: allow

  - name: deny-inline-shell
    commands: ["sh", "bash", "zsh"]
    args_match: ["-c", "*"]
    decision: deny
    message: "Inline shell execution blocked."

  - name: deny-unknown
    commands: ["*"]
    decision: deny

CVE-2025-54135 "CurXecute" and CVE-2025-54136 "MCPoison": Cursor MCP execution (AIM Security + Check Point, disclosed August 2025, fixed Cursor v1.3.9)

Two separate research teams found two separate MCP execution vulnerabilities in Cursor at nearly the same time, both fixed in Cursor v1.3.9.

CVE-2025-54135 "CurXecute" (AIM Security, disclosed August 2025, CVSS 8.6): An external MCP server returns a response containing a malicious prompt. That prompt instructs the agent to write a file to .cursor/mcp.json. If that config file did not previously exist, Cursor with Auto-Run enabled executes the injected commands immediately -- no approval dialog, no consent. The attack originates from any MCP server Cursor connects to, not just the local filesystem.

CVE-2025-54136 "MCPoison" (Check Point, disclosed August 2025, CVSS 7.2): Once a user approves an MCP configuration, Cursor treats it as trusted indefinitely -- even after the file changes. An attacker commits a benign-looking .cursor/mcp.json to a shared repository, waits for a developer to pull it and approve it once, then replaces it with a malicious payload. On every subsequent project open, the malicious configuration executes with no further approval. The persistence is the point.

What execution-layer enforcement does: CurXecute is caught at the exec level -- the written config triggers a command that AgentSH intercepts before it runs. MCPoison is addressed by AgentSH's MCP version-pinning and tool allowlist, which detects configuration changes and requires re-approval regardless of what Cursor's own trust model decided:

mcp:
  version_pinning:
    enabled: true
    on_change: approve
    message: "MCP configuration changed since last approval: "

  tool_whitelist:
    - "read_file"
    - "list_directory"
  tool_denylist:
    - "write_file"
    - "execute_code"
    - "run_shell"

A modified config triggers an approval gate before any tool from that server can run. The attacker's payload does not execute silently on next open.

Cursor Workspace Trust RCE (Oasis Security, September 2025)

Cursor ships with Workspace Trust disabled by default. A .vscode/tasks.json containing runOn: "folderOpen" executes its commands silently the moment a developer opens the folder -- no prompt, no consent. A malicious repository includes this file. Developer clones repo, opens it in Cursor, code runs.

This is structurally the same as a booby-trapped document that executes macros on open, but targeted at developers whose machines carry cloud keys, PATs, and live SaaS sessions. The AI coding assistant is incidental to this one; the bug is in the IDE's task runner defaults. Notably, Cursor's own response to the disclosure was that enabling Workspace Trust disables AI and other Cursor features -- so the intended mitigation conflicts with the product's core value proposition.

What execution-layer enforcement does: Every exec() passes through the policy engine before it runs. A task runner spawning a shell gets an approval gate:

command_rules:
  - name: require-approval-for-shell
    commands: ["sh", "bash", "zsh", "fish", "pwsh"]
    decision: approve
    message: "Shell execution requested:  "
    timeout: 60s

The autorun fires, tries to spawn a shell, and blocks on a human approval prompt. The event is logged regardless of the decision. Nothing executes silently.

Check Point's Claude Code findings: repository-controlled startup execution (reported July–October 2025; advisories published September 2025–January 2026)

Check Point reported a cluster of vulnerabilities through multiple disclosures between July and October 2025, all rooted in the same pattern: Claude Code reads configuration from repository-controlled files and acts on it before showing the user a trust prompt. The public advisories separate three distinct issues:

GHSA-ph6w-f82w-28w6 (fixed v1.0.87, published September 2025): The startup warning was insufficiently explicit that trusting the folder would allow Claude Code to execute files in that directory without further confirmation. Repository-controlled behavior could proceed without adequate trust enforcement.

CVE-2025-59536 (CVSS 8.7, fixed v1.0.111, published October 2025): Repository-controlled startup paths could cause code to execute before the user accepted the startup trust dialog. Check Point's broader research cluster identified multiple mechanisms -- hooks, MCP server definitions, and environment variables -- through which this startup behavior could be triggered, but the CVE advisory describes the core issue as pre-trust-dialog code execution.

CVE-2026-21852 (CVSS 5.3, fixed v2.0.65, published January 2026): A malicious repository sets ANTHROPIC_BASE_URL to an attacker-controlled endpoint. Claude Code reads that configuration and starts issuing authenticated API requests -- including requests carrying the user's API key -- before any trust prompt appears. The key leaves the machine before the user is asked anything.

The common thread across all three: developers treat configuration files as metadata. They are executable code. A single compromised commit in an enterprise repository can affect every developer who clones it.

What execution-layer enforcement does: Startup-spawned shells are caught at execve. Environment variable overrides are stripped before they reach child processes. API traffic is routed through the embedded LLM proxy regardless of what ANTHROPIC_BASE_URL says:

env_rules:
  - name: lock-api-urls
    keys: ["ANTHROPIC_BASE_URL", "OPENAI_BASE_URL"]
    decision: deny

proxy:
  mode: embedded
  providers:
    anthropic: https://api.anthropic.com

The repository configuration sets ANTHROPIC_BASE_URL=https://attacker.example.com. That variable is stripped before it reaches the Claude Code process. API requests route through the proxy to api.anthropic.com. The key never reaches the attacker's endpoint.

CVE-2025-59944: Cursor case-sensitivity config overwrite (Lakera, October 2025, fixed Cursor v1.7)

Cursor's confirmation prompt for modifications to protected files like .cursor/mcp.json used a case-sensitive string comparison. On macOS and Windows -- both case-insensitive filesystems by default -- creating .cUrSoR/mcp.json bypassed the check entirely. To the OS, it was the same file. To Cursor, it was a new one, requiring no approval. The malicious config loaded silently on next open.

This is a small implementation detail with outsized consequences in an agentic IDE. The check deciding which commands can run and which plugins start failed when the filesystem's case rules differed from the application's. It's also an example of how prompt injection doesn't need to come through the model -- any write path the agent controls is a potential injection point.

What execution-layer enforcement does: AgentSH's path normalization operates at the syscall layer using the OS's own resolved paths, not application-level string comparisons. A file write to .cUrSoR/mcp.json and a file write to .cursor/mcp.json resolve to the same inode and are treated identically by policy:

file_rules:
  - name: protect-cursor-config
    paths: ["**/.cursor/mcp.json", "**/.vscode/tasks.json"]
    operations: [write, create]
    decision: approve
    message: "AI IDE config modification: "

The case variant doesn't bypass this rule. The approval gate fires regardless.

Claude Desktop MCP Extension RCE (Koi Security, November 2025, fixed Claude Desktop v0.1.9)

Koi Security found that three official Anthropic extensions for Claude Desktop -- Chrome, iMessage, and Apple Notes -- were vulnerable to unsanitized command injection. Web content or document content that Claude processed could contain malicious instructions. Claude, acting in good faith, executed them.

The critical detail: while Chrome browser extensions run in a sandboxed process, Claude Desktop extensions run fully unsandboxed on the user's device with full system permissions. They are not lightweight plugins. They are privileged executors bridging the LLM and the operating system. A successfully injected prompt had access to SSH keys, AWS credentials, and local secrets, and the ability to run arbitrary commands.

What execution-layer enforcement does: Credential paths and unauthorized outbound connections can be blocked regardless of what the injected prompt instructs. This is also where a domain allowlist is not enough: as the Claudy Day section shows, an allowed endpoint can itself be an exfiltration channel. Domain allowlists are necessary but not sufficient. You also need content-aware controls on what crosses those connections.

file_rules:
  - name: deny-credentials
    paths:
      - "/home/**/.ssh/**"
      - "/home/**/.aws/**"
      - "/**/Library/Keychains/**"
      - "/home/**/.config/gcloud/**"
    operations: ["*"]
    decision: deny

Claudy Day: Claude.ai prompt injection to data exfiltration (Oasis Security, March 2026)

Oasis chained three bugs into a complete attack pipeline targeting Claude.ai users, with no integrations required.

Bug 1 (fixed, March 2026): Claude.ai accepts pre-filled chat prompts via ?q= URL parameters. HTML tags embedded in that parameter are invisible in the text box but processed by Claude when the user hits Enter. Hidden instructions -- including data extraction commands and an attacker-controlled API key -- execute silently.

Bug 2 (being addressed): Claude's code execution sandbox restricts outbound connections to most destinations, but allows connections to api.anthropic.com. That allowed endpoint is the exfiltration channel. The injected prompt instructs Claude to read conversation history, write it to a file, and upload it to the attacker's Anthropic account via the Files API. No external infrastructure. No custom tooling. Just capabilities that ship out of the box.

Bug 3 (being addressed): claude.com/redirect/<target> redirected to arbitrary third-party domains. Wrapped in a Google Ad, this delivered the injection URL as a search result indistinguishable from the real thing.

This is where the domain-allowlist point from the Claude Desktop section lands with full force. Allowing api.anthropic.com sounds safe. But the Files API lives on api.anthropic.com, and it can upload arbitrary data to any Anthropic account. A domain allowlist tells you nothing about what is being sent or whose credentials are driving it.

Whether the API allowlist architecture is permanently structural is Anthropic's call to make -- the public disclosure characterizes Bug 2 as "currently being addressed." The architectural observation stands independent of the fix timeline: allowing a network destination is not the same as authorizing what flows across it.

What execution-layer enforcement does in deployments you control: The Claudy Day surface is Claude.ai, which users cannot wrap with AgentSH. But the attack class -- prompt injection into an agent with tool access -- applies directly to self-hosted and SDK-based agent deployments.

For those environments, DLP strips API keys from outbound requests before they reach any provider:

dlp:
  mode: redact
  patterns:
    api_keys: true
  custom_patterns:
    - name: anthropic-key
      regex: "sk-ant-[A-Za-z0-9\\-_]{40,}"
      display: "[REDACTED_API_KEY]"

And MCP tool policy limits what an injected prompt can invoke regardless of what the model decides:

mcp:
  tool_whitelist:
    - "read_file"
    - "list_directory"
  tool_denylist:
    - "write_file"
    - "create_file"
    - "send_message"
    - "execute_code"

An injected prompt that gains control of an agent with connected MCP servers can only do what the tool policy allows. Write operations, message sending, and code execution are not on that list.

The pattern

Fourteen incidents across twelve months, reported by multiple research teams -- Oligo, Cymulate, AIM Security, Check Point, Oasis, Lakera, and Koi -- targeting six products and surfaces. In each case:

Attacker delivers malicious content -- a URL, a config file, a cloned repo, a document, a web page, a CSRF request
The AI tool processes that content in good faith
The tool takes real actions with real consequences

Once untrusted input reached a privileged path, the product followed it. The problem is that in each case, "what the tool was told" came from an attacker, and nothing independent of the tool governed what happened next.

You cannot rely on the model -- or the IDE, or the MCP server -- to faithfully enforce the rules written for it. Confirmation prompts, workspace declarations, system instructions, trust dialogs, case-sensitive filename checks: these are all controls implemented in the same layer the attacker targeted. A sufficiently crafted input can suppress, bypass, or override them.

You need a separate enforcement point that decides whether the resulting file, process, and network actions are permitted -- without asking the model. That is the execution layer.

AgentSH

AgentSH is an open-source execution-layer security gateway for AI agents. It sits under your agent and its tooling, intercepting file, network, and process activity at the syscall level, enforcing the policy you define, and emitting structured audit events.

# Wrap Claude Code in an enforcement session
agentsh shim install-shell --root / --bash

SID=$(agentsh session create --workspace . --policy agent-sandbox | jq -r .id)
agentsh exec "$SID" -- claude

Every file access, subprocess, and network connection Claude Code attempts inside that session passes through the policy engine. The policy generation workflow lets you profile a legitimate run and lock future runs to observed behavior:

agentsh policy generate latest --output=claude-code-policy.yaml
agentsh session create --workspace . --policy claude-code-policy.yaml

The starter policy packs -- dev-safe, ci-strict, and agent-sandbox -- cover the common deployment scenarios. agent-sandbox is the right starting point for Claude Code and similar tools: default deny, explicit allowlist, approval gates on credential paths, and network restricted to declared domains.

Most of the specific bugs in this post were patched or mitigated. The architectural pattern remains. Patching fixes specific instances of the failure mode. It does not change the architecture. As long as the enforcement point lives in the same layer that processes untrusted input, an attacker who controls the input can control the enforcement.

AgentSH is at github.com/canyonroad/agentsh.

Supply Chain Attacks Are Hard to Stop Upstream. That Is Exactly Why You Need Control at Runtime

2026-03-26T00:00:00Z

The LiteLLM compromise is a useful case study in why supply chain defense is so hard.

This was not a typo-squatted package or a fake repo. A real package in a real ecosystem was compromised, malicious versions were published, and installation itself was enough to trigger malicious behavior. The attack was part of a broader campaign by TeamPCP that also hit Aqua Security's Trivy scanner and Checkmarx's KICS GitHub Actions -- three separate projects compromised using credentials stolen from CI/CD pipelines.

That is the hard part about modern supply chain attacks. By the time the code reaches your machine, it is already wearing a trusted costume.

The lesson is not that upstream controls failed and therefore do not matter. They do matter. Version pinning matters. Provenance matters. Trusted publishing matters. Narrow CI permissions matter.

The lesson is that none of those controls answer the question that matters most once a bad package lands in a real environment:

What happens if one gets in anyway?

What happened in LiteLLM matters beyond LiteLLM

The public writeups show the pattern clearly.

A compromised package version was published to PyPI. One of the malicious versions used a .pth startup hook so the payload would run automatically on Python startup. The payload harvested secrets, queried cloud metadata endpoints, and if it found a Kubernetes service account token, attempted to read cluster secrets and create privileged pods for persistence. In at least one case, the attack was discovered because the malware accidentally caused a fork bomb and froze the machine.

That was lucky. The rest of the attack design was not.

The important thing is not just what this payload did. It is how normal the triggering action was.

A tool installed a dependency. An MCP-related workflow pulled it transitively. A developer machine or CI environment did what it normally does every day.

That is exactly where AI agents make this problem worse.

Agents multiply the blast radius of supply chain risk

Humans install packages. Agents will install more of them, more often, with less hesitation, across more environments.

That is not a criticism of agents. It is just what happens when you give software a loop and a goal.

An agent trying to complete a task will often do things like:

install a missing package
upgrade a dependency to satisfy a version constraint
pull in an MCP server or tool wrapper

Those are useful behaviors. They are also supply chain expansion behaviors.

An agent does not need to be socially engineered into making those moves. It will make them because they are often the shortest path to completing the task.

So the old supply chain problem gets a new accelerant:

more installs, more transitive dependencies, more ephemeral environments, more automated retries, more package managers, more chances for a poisoned dependency to land somewhere sensitive.

And once the package is inside the environment, the agent can make the outcome worse by continuing to operate normally while the payload reads secrets, connects out, or plants persistence.

The real question is not whether the model intended harm. The real question is what the process was allowed to do once the package executed.

Why supply chain defense needs an execution layer

A supply chain compromise is upstream. The damage happens downstream.

That distinction matters.

No runtime control on your machine can prevent an attacker from stealing a maintainer credential, publishing a poisoned wheel, or compromising a release workflow upstream. That has to be fixed at the registry, maintainer, CI, and provenance layers.

But once the malicious package lands on a developer box, CI runner, container, or agent sandbox, it still has to do concrete things in order to hurt you:

read secrets or credentials
spawn processes
open outbound network connections
write files for persistence
exfiltrate what it found

Those are not abstract security concepts. Those are operating system side effects.

That is where AgentSH helps.

AgentSH sits under the agent or tool runtime and governs file, network, and process activity at execution time. It does not need the model to realize something is malicious. It does not need the package manager to warn in time. It does not need the prompt to say the right thing.

It evaluates what the process is actually trying to do.

That changes the outcome.

What AgentSH could have done in an incident like LiteLLM

AgentSH would not have prevented the LiteLLM publisher compromise itself. It would not have stopped the bad package from existing on PyPI.

What it could have done is much more practical:

1. Block secret harvesting

If the package tries to read ~/.ssh, cloud credentials, .env files, kubeconfig, service account tokens, Terraform state, or other sensitive material outside the workspace, those reads can be denied or gated.

A package can only steal what it can actually open.

2. Block exfiltration

If the payload tries to connect to an unknown domain, a raw IP, cloud metadata, internal networks, or the Kubernetes API, those outbound connections can be blocked, redirected, or forced through an approved proxy.

A package can only exfiltrate what it can actually send.

3. Block process explosions and runaway subprocess behavior

In the LiteLLM case, one of the malicious versions used a .pth startup hook that spawned a child Python process, which then re-triggered the same .pth on interpreter startup and caused an exponential fork bomb. That specific failure mode was a bug in the malware, but it is exactly the kind of thing runtime controls should catch early.

With execution-layer policy, you can limit which child processes may be spawned during installation, alert on suspicious subprocess recursion, and kill or deny runaway behavior before it turns a compromised install into a machine-wide outage.

A package can only turn into a process storm if it is allowed to keep spawning.

4. Block persistence

If the payload tries to drop files into startup paths, systemd user directories, shell init files, or other persistence locations, those writes can be denied.

A package can only persist if it can actually write where persistence lives.

5. Preserve the audit trail

This is the part many teams miss.

When people talk about containment, they often imagine losing visibility. In practice, good runtime enforcement gives you more usable evidence, not less.

Instead of finding out later that a package might have done something, you can record that it attempted to:

open ~/.aws/credentials
read ~/.kube/config
connect to an unapproved domain
write ~/.config/systemd/user/...
spawn a suspicious child process during install

That is far more actionable than a vague IOC list after the fact.

And it matters even more with agents, because agents create long, busy, high-churn execution traces. If you do not have runtime logs with policy decisions attached, incident response becomes guesswork.

Example policy ideas that would have helped

These examples are illustrative, not product syntax. The point is the control model.

Default: workspace-only file access

files:
  default: deny
  allow:
    - /workspace/**
    - /tmp/**
    - /var/tmp/**
  deny:
    - ~/.ssh/**
    - ~/.aws/**
    - ~/.config/gcloud/**
    - ~/.azure/**
    - ~/.kube/**
    - ~/.terraform.d/**
    - **/.env
    - **/.env.*
    - **/*.pem
    - **/*.key

This alone changes a lot. Most agent tasks do not need unrestricted access to a developer's home directory.

Egress only to approved destinations

network:
  default: deny
  allow_domains:
    - api.openai.com
    - api.anthropic.com
    - github.com
    - pypi.org
    - files.pythonhosted.org
    - registry.npmjs.org
  deny:
    - 169.254.169.254
    - 10.0.0.0/8
    - 172.16.0.0/12
    - 192.168.0.0/16
    - kubernetes.default.svc

A compromised package should not be able to call home to arbitrary infrastructure just because the environment has outbound Internet access.

No writes outside the workspace except approved temp paths

This example is about write control. The earlier file policy is about reads. In practice, you usually want both, because a package that cannot read secrets can still try to plant persistence if it can write freely.

writes:
  default: deny
  allow:
    - /workspace/**
    - /tmp/**
    - /var/tmp/**
  deny:
    - ~/.config/**
    - ~/.local/share/**
    - ~/.bashrc
    - ~/.zshrc
    - ~/.profile
    - ~/.config/systemd/**
    - /etc/**

That is how you cut off persistence without breaking normal agent work.

Process controls for install-time behavior

process:
  allow:
    - python
    - python3
    - pip
    - uv
    - git
    - node
    - npm
  deny:
    - curl
    - wget
    - nc
    - ssh
    - socat
  limits:
    max_child_processes: 20
    max_spawn_rate_per_minute: 30
  alert_on_spawn:
    - python child processes launched from package install hooks
    - recursive python startup chains
    - shell execution during dependency installation

You do not have to ban package installation. You do need visibility when installation starts doing things that look nothing like installation, including recursive child-process storms.

Approval gate for unusually broad dependency actions

approvals:
  require_for:
    - install or upgrade packages outside approved lockfile flow
    - first-time network access to new domains
    - reading secrets outside declared task scope

This is especially useful for agentic workflows. The agent can keep working, but crossing a higher-risk boundary triggers a human approval path outside the agent.

The practical takeaway

You should absolutely keep improving the front of the funnel:

pin versions
use lockfiles
prefer trusted publishing and provenance
reduce CI token scope
verify artifacts against source
quarantine suspicious releases quickly

But do not stop there.

Assume some bad package will eventually get in somewhere. Maybe through a direct install. Maybe through a transitive dependency. Maybe because an agent decided to install what looked like the right thing to finish a task.

When that happens, what matters is whether the code can actually do anything dangerous.

That is the role of the execution layer.

At Canyon Road, that is exactly the problem we are focused on with AgentSH.

Not replacing upstream supply chain security.

Making it far less likely that one bad package turns into stolen credentials, silent persistence, and a long night of forensics.

And doing it while retaining the audit trail you will wish you had once the incident starts.

Because in the agent era, "it only installed a package" is going to be the beginning of a lot more incident reports.

References

LiteLLM incident

Security Update: Suspected Supply Chain Incident -- LiteLLM's official disclosure
Supply Chain Attack in litellm 1.82.8 on PyPI -- FutureSearch technical analysis including .pth hook mechanism and fork bomb details
Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer -- Sonatype's payload analysis
Three's a Crowd: TeamPCP Trojanizes LiteLLM in Continuation of Campaign -- Wiz analysis of the LiteLLM compromise and its connection to the broader TeamPCP campaign
How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM -- Snyk's writeup on the credential chain from Trivy to LiteLLM
LiteLLM Compromised on PyPI: Tracing the March 2026 TeamPCP Supply Chain Campaign -- Datadog Security Labs' end-to-end campaign analysis
The Library That Holds All Your AI Keys Was Just Backdoored -- ARMO's Kubernetes-focused analysis of the persistence mechanism
Popular LiteLLM PyPI Package Backdoored to Steal Credentials, Auth Tokens -- BleepingComputer coverage
Malicious PyPI Package -- LiteLLM Supply Chain Compromise -- Truesec's technical breakdown
CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 -- Original GitHub issue with community triage

Related TeamPCP campaign

Trivy Compromised by TeamPCP -- Wiz analysis of the initial Trivy compromise that started the chain
KICS GitHub Action Compromised: TeamPCP Strikes Again -- Wiz analysis of the Checkmarx KICS compromise
TeamPCP Supply Chain Attack Campaign Targets Trivy, Checkmarx (KICS), and LiteLLM -- Arctic Wolf's campaign overview
Detecting, Investigating, and Defending Against the Trivy Supply Chain Compromise -- Microsoft's detection and response guidance
TeamPCP Software Supply Chain Attack Spreads -- ReversingLabs' campaign tracking
Trojanization of Trivy, Checkmarx, and LiteLLM Solutions -- Kaspersky's overview of the full attack chain

Command Injection Is Not the Story. Inherited Authority Is.

2026-03-30T00:00:00Z

A new BeyondTrust writeup describes a command injection vulnerability in OpenAI Codex in which a GitHub branch value could flow into shell-backed repository setup, enabling token theft and exfiltration.

The bug matters. But the more important lesson is not just that untrusted input reached a shell. It is that once the shell ran, it had enough authority to do real damage.

That is the control gap.

The part most people miss: setup is execution

One subtle but important detail in Codex's own documentation is that cloud setup happens before the main agent phase and can access the network. OpenAI also documents that cloud secrets are available during setup and then removed before the agent phase starts.

That means the dangerous phase is not only what the agent does later. It is the bootstrap path itself.

If a branch name, repo-controlled value, or other untrusted input reaches setup and triggers shell behavior there, the blast radius depends on what that setup process is allowed to do:

what processes it can spawn
what files it can read
what environment variables it inherits
where it can connect on the network

Those are the conditions that determine how bad the outcome can get. The sequence itself is familiar:

Untrusted input becomes shell behavior.
The shell inherits real authority.
A secret is within reach.
The runtime can still reach the network.
The secret leaves.

That is the kill chain.

The bug is not the boundary

Input validation is necessary. It is not sufficient.

Prompt rules are useful. They are not enforcement. We wrote more about that in Rule Files Are Not Enforcement.

Audit logs help you reconstruct what happened. They do not stop it.

The boundary that matters is the one between intent and side effects. The moment a coding agent tries to spawn a process, read a file, inherit an environment variable, resolve DNS, or open a socket, you are no longer dealing with model behavior in the abstract. You are dealing with machine authority.

How AgentSH would have changed the outcome

AgentSH would not fix the root cause in Codex's request handling. If a product accepts unsafe input and interpolates it into shell execution, the vendor still needs to patch that bug.

What AgentSH does is break the exploit chain at execution time.

If AgentSH is installed under the actual bootstrap and setup path, not just around the later chat loop, then a malicious branch can still try to exploit the bug, but the runtime no longer gets unlimited authority by default.

Stop the unexpected process tree

A branch name should not cause arbitrary shell behavior.

If setup suddenly spawns an unexpected shell or a follow-on process like curl, bash -c, or some other off-path executable, AgentSH can deny it, require approval, or constrain it based on policy.

Deny network exfiltration

In the BeyondTrust attack path, the damage came from exfiltration.

Even if a malicious command runs, it still needs a destination. AgentSH can enforce egress policy so setup and agent subprocesses can reach only the domains and methods they actually need.

That is the difference between "the command executed" and "the breach succeeded."

Block reads of sensitive files and token-bearing paths

In local tooling flows, the problem is not only transient tokens in a cloud environment. It is also the credential material on the developer machine or runner.

If a tool can read ~/.codex/auth.json, ~/.ssh, cloud credential files, or .env files, then command injection quickly becomes credential theft. AgentSH can constrain which processes can read which files.

Scope environment variables per process

This is the part too many defenses miss.

Once a process starts, most systems let it inherit a huge amount of ambient authority through environment variables: API keys, base URLs, proxy settings, cloud credentials, and internal endpoints.

AgentSH can decide which process gets which environment variables.

So even if an injected subprocess runs, it does not automatically inherit the same secret context as the trusted component that was supposed to perform the original task.

The bug was command injection.

The damage came from inherited authority.

Capture the side effect that actually matters

This class of attack is easy to hide in plain sight because the human-visible prompt can look normal while the real action happens below it in the shell, subprocess tree, file reads, and network calls.

Execution-layer telemetry changes that. Instead of asking what the prompt looked like, you can ask:

Why did bootstrap spawn that process?
Why did that process read this credential path?
Why did it connect to that domain?
Why did that environment variable exist in that process at all?

That is much closer to the truth of the incident.

What the policy surface looks like for this class of attack

A practical policy for this kind of runtime should look something like this:

allow repo checkout only to approved GitHub endpoints
allow dependency installation only to approved registries
deny all other outbound domains during setup by default
restrict HTTP methods so arbitrary POST exfiltration is blocked
deny reads of ~/.codex/**, ~/.ssh/**, cloud credential files, and .env* unless explicitly required
scope environment variables so only the intended process gets the intended secret
require approval for risky shells, subprocess chains, or networked commands outside a trusted set

That is not security theater. It is what it means to remove ambient authority from an AI runtime.

If you want the broader version of that argument, see Bugs Happen. Agents Still Run.

The honest caveat

For a fully vendor-managed cloud product, AgentSH protects the runtime only if it is actually installed under the path where setup and task execution occur. If a third-party service owns the bootstrap environment and you do not control it, you cannot enforce below it from the outside.

But for local coding agents, internal runners, self-hosted agent infrastructure, and sandbox platforms, this is exactly the layer you can control.

Security for agents has to start where side effects start

The BeyondTrust writeup is a useful reminder that AI coding agents are not just chat interfaces with better UX. They are execution environments with credentials, network reach, and real consequences.

The lesson is not merely "escape your shell arguments." Of course you should.

The lesson is that one escaping mistake should not be enough to turn a branch name into a token theft path.

That only happens when the runtime inherits too much authority.

Because the prompt is not the perimeter.

Untrusted Text, Trusted Shell

2026-04-02T00:00:00Z

An attacker put untrusted text into a GitHub issue, an AI workflow turned that text into shell execution inside CI, the runner poisoned shared cache state, a later privileged publish job restored it, and Cline ended up with an unauthorized npm release. That is the chain that matters.

It is tempting to call this a prompt injection story and stop there. But prompt injection is only the opening move. The useful lesson is simpler: an agent that reads untrusted text should not be able to turn that text into shell commands inside your CI pipeline.

As Adnan Khan's writeup shows, Cline had an AI issue-triage workflow that any GitHub user could trigger. That workflow had access to tools including Bash, ran in default-branch context, and provided a path from attacker-controlled issue content to real code execution on the runner. From there, the attack moved through GitHub Actions cache poisoning into more privileged nightly publishing workflows and ultimately into an unauthorized cline@2.3.0 npm publish. Cline's own post-mortem describes the incident as a combination of prompt injection, cache poisoning, and credential theft.

The issue title was the trigger. The shell was the problem.

Why this became a supply-chain incident

The triage workflow itself was not the destination. The pivot mattered more than the prompt.

GitHub has been explicit that workflows running in default-branch context can poison the Actions cache and move laterally into more privileged workflows, even when the first workflow does not itself hold the secret you care about. That warning maps directly onto what happened here. The issue-triage workflow provided code execution. The cache became the bridge. The nightly publish jobs restored poisoned state. The publish token was exposed. Then cline@2.3.0 was published with a modified package.json that added a postinstall script to install openclaw@latest. (GitHub's guidance covers this class of workflow risk directly.)

That is why this incident matters beyond Cline. It shows how fast "the model followed the wrong instruction" becomes "your release pipeline did."

The agent proposes. The policy decides.

The pipeline needed fixing too

There is a shallow version of this argument that says the answer is just runtime enforcement and nothing else. That would be wrong.

There were ordinary CI/CD fixes that mattered here too: do not let untrusted issue-triggered workflows run in a context that can influence release jobs, scope workflow permissions aggressively, avoid static publish credentials where OIDC or narrower-lived mechanisms exist, and treat cache sharing across trust boundaries as dangerous by default. Those are real controls, and teams should use them. GitHub's own guidance says as much.

But those controls still leave the underlying question untouched:

Why was untrusted text allowed to reach a shell at all?

That is where runtime enforcement belongs.

What AgentSH would have stopped

AgentSH would not need to interpret the issue title better than the model. It would need to stop the first unauthorized side effect.

In an issue-triage workflow, the allowed behavior is narrow: read the issue, inspect repository context, and maybe write a triage artifact or comment. That is it.

So when the model tries to turn attacker-controlled issue text into npm install, that process spawn should be denied.

When it tries to reach an attacker-controlled host, that network connection should be denied.

When it tries to write into cache-relevant paths or mutate state that later workflows will restore, that file write should be denied.

When the job does not need a publish token, that token should not be present in the environment in the first place. And if it is present, it should be stripped or locked away from subprocesses.

This is not about making the model more obedient. It is about making the machine less gullible.

The exploit only works if the runtime lets instruction following become real process, file, and network activity. Block those transitions and the attack collapses at the first step that matters.

What that policy boundary looks like

Of course CI pipelines need to run npm install. Build jobs need package managers, test jobs need runtimes, publish jobs need credentials. That is not the issue.

The issue is that an AI agent running inside CI -- one whose input was an attacker-controlled issue title -- had the same execution authority as the build and publish steps around it. The triage agent did not need a general-purpose shell. It needed a task-shaped execution envelope.

version: "1"

processes:
  default: deny
  allow:
    - /usr/bin/git
    - /usr/bin/grep
    - /bin/cat
    - /bin/ls

files:
  read:
    allow:
      - /workspace/**
  write:
    allow:
      - /workspace/.triage-output/**
      - /tmp/**
    deny:
      - ~/.npm/**
      - ~/.cache/**
      - /github/**
      - /workspace/.git/**

network:
  default: deny
  allow:
    - api.github.com:443

env:
  strip:
    - NPM_TOKEN
    - NODE_AUTH_TOKEN
    - VSCE_PAT
    - OVSX_PAT

No package managers. No general-purpose shells. No outbound network except the GitHub API. No publish credentials in the environment. The rest of the pipeline runs normally -- this policy scopes only the agent step, because that is the step where untrusted input meets execution.

This is not a prompt defense. It is an execution boundary.

The bigger lesson

People will read this incident and say the culprit was prompt injection. That is true, but incomplete.

Others will say the real culprit was GitHub Actions cache poisoning. That is also true, but incomplete.

The deeper culprit was ambient authority: untrusted text reached an agent, the agent had a shell, the shell sat inside CI, and CI sat on the path to release. Prompt injection lit the match. Cache poisoning spread the fire. But the fuel was a runtime with too much freedom.

Runtime enforcement does not fix the model. It fixes the blast radius.

AgentSH v0.18.0: Real Secrets Stay Out of the Agent

2026-04-13T00:00:00Z

Two customer requests kept coming up.

Can an agent use real credentials without ever being handed the real credentials?

And can we let an agent talk to a third-party API or an internal service, but only on the methods and paths we actually approve?

AgentSH v0.18.0 is our answer to both.

This release adds two major capabilities:

a Secrets Manager with support for external secret stores and third-party vaults
an HTTP service gateway that lets you control outbound API traffic by service, method, and path

The repo is here: github.com/canyonroad/agentsh

It is not enough to say an agent may reach api.github.com or api.stripe.com. Once the agent has a live token and broad network access, the difference between acceptable behavior and a production side effect is usually just a verb and a path on the same host.

Policy at the HTTP layer, not just the host

The most important design choice in v0.18.0 is that declared upstream services are fail-closed by default.

Because AgentSH runs inside the execution boundary, it can inject a service-specific base URL into the child process environment so traffic flows through the governed gateway.

For less cooperative clients, AgentSH still gives you a hard control point. If a host is declared as a governed upstream, direct HTTP and HTTPS access to that host is blocked unless you explicitly allow it.

That is not an implementation detail. It is the security posture.

Without that boundary, "we monitor requests" usually means "we noticed the write after it happened." With it, policy can decide whether the request is allowed before the side effect leaves the machine.

The new HTTP gateway lets you express that policy directly:

allow or deny specific URLs
allow or deny specific HTTP verbs
require approval for sensitive operations
audit traffic that should be observed but still forwarded

A hostname is too coarse for real agent permissions. The difference between reading GitHub issues and opening one is not a different host. It is GET /repos/*/*/issues versus POST /repos/*/*/issues.

That matters because agents do not always stay inside the interface you expected them to use. When one path is blocked or a tool does not work, they may look for another way to accomplish the same task. An agent that cannot run npm publish directly may figure out the underlying HTTP requests needed to publish anyway. If your control is only at the tool layer, the side effect can still slip through. If your control is at the HTTP method-and-path layer, you can stop the write even when the agent changes tactics.

That is the boundary v0.18.0 lets you control.

Secrets Manager with third-party vault support

Most teams do not want long-lived API keys sitting in prompts, shell history, .env files, or process environments. They want the agent to use a credential without actually possessing it.

That is what the new Secrets Manager is built for.

In v0.18.0, AgentSH can pull secrets from external providers including Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, 1Password Connect, and the local OS keyring.

At session start, AgentSH fetches the real secret, generates a fake credential for the agent to work with, and keeps the real value on the governed side of the boundary.

The agent sees the fake value. On egress, AgentSH swaps the fake value for the real one before the request leaves the machine.

Substitution can happen in headers, bodies, query strings, and URL paths. And if a service expects the credential in a specific header, AgentSH can inject it directly there.

That gives teams a much better operating model. The agent does not need raw production credentials in memory, logs are less likely to capture real secrets, rotation stays in the vault instead of getting pushed into agent code, and response scrubbing can remove sensitive values before they come back.

Because this lives in AgentSH rather than in a specific hosted sandbox, the same secrets model travels with you across sandbox providers and self-managed environments wherever AgentSH runs.

There is another important piece here: leak guard.

If the fake credential shows up in the wrong place, AgentSH can block the request before it leaves. That helps catch cross-service misuse and exfiltration attempts where a credential-shaped value is being sent somewhere it does not belong.

A concrete example

A common customer ask looks like this:

"Let the agent read issues from GitHub, but do not let it create or modify anything. Also do not hand it the real token."

With v0.18.0, that becomes a policy problem instead of an application rewrite.

providers:
  vault:
    type: vault
    address: https://vault.corp.internal
    auth:
      method: token
      token_ref: keyring://agentsh/vault_token

  keyring:
    type: keyring

http_services:
  - name: github
    upstream: https://api.github.com
    aliases: [api.github.com]
    default: deny
    secret:
      ref: vault://kv/data/github#token
      format: "ghp_{rand:36}"
    inject:
      header:
        name: Authorization
        template: "Bearer "
    rules:
      - name: read-issues
        methods: [GET]
        paths:
          - /repos/*/*/issues
          - /repos/*/*/issues/*
        decision: allow

      - name: create-issue-needs-approval
        methods: [POST]
        paths:
          - /repos/*/*/issues
        decision: approve
        message: "Agent wants to create an issue. Approve?"
        timeout: 5m

The agent gets a GitHub base URL that points at the local AgentSH gateway. It does not get the real GitHub token. Reads go through. Writes can be blocked or held for approval. Direct access to the upstream host can be closed by default.

Why this matters

The usual alternatives are broken: hand the agent a real secret and hope prompts and tool descriptions keep it contained, allow an entire host and pretend that is a meaningful permission boundary, or bolt on audit after the fact and call it control.

None of that holds up once the agent is making real outbound requests against real systems.

The agent proposes. The policy decides.

In v0.18.0, that principle now extends further into the HTTP layer: this request, on this path, with this verb, using a real credential the agent never gets to see.

Also in v0.18.0

This release also adds HMAC-chain tamper evidence for audit logs and a broad set of enforcement fixes across seccomp, cgroups, Landlock, ptrace, and arm64 support. For the full release details, see the changelog in the repo.

Try v0.18.0

If you are running agents against third-party APIs, internal services, or production-adjacent systems, v0.18.0 gives you a practical way to let agents act without giving them raw authority.

AgentSH is open source: github.com/canyonroad/agentsh

The Install Was the Attack

2026-04-23T00:00:00Z

A malicious Bitwarden CLI package ran during npm install, before anyone had a chance to inspect it. That is exactly the kind of supply chain story the agentic era keeps repeating.

April 23, 2026 · Supply chain / agent runtime

Bitwarden did not suffer a broad compromise of its vaults or production systems. What happened was narrower and more instructive: a malicious @bitwarden/cli@2026.4.0 package was briefly distributed through the npm delivery path for the CLI between 5:57 PM and 7:30 PM ET on April 22, 2026. The affected window was short, and the blast radius was limited to that npm CLI path.

The important part is not just that a trusted package was poisoned.

It is where the payload ran.

Researchers found that the malicious package rewired the preinstall path and the bw entrypoint to a custom loader that downloaded Bun and launched a second-stage payload. That means npm install @bitwarden/cli was enough.

The payload ran during preinstall, before npm had even finished handing control back to the user.

Post-install inspection is too late by construction.

That matters even more in the agentic age. A human might or might not install a bad version during a short exposure window. A CI fleet running npm install on every push, a bot auto-resolving latest, or an agent spinning up fresh per-task sandboxes can hit that window without a human in the loop.

Agent workflows do not stop at the command boundary. They run installs, setup steps, tests, and child processes continuously.

This was not just credential theft

The payload went after GitHub and npm tokens, SSH keys, shell history, .env files, cloud credentials, CI secrets, and AI tooling configuration. It also used memory scraping in CI, not just file scraping, which is an important reminder that "protect the obvious files" is not enough on its own.

But the detail that makes this story specifically about the agentic era is what it did to the shell.

Security Boulevard's syndicated Mend analysis says the malware appended a roughly 3.5 KB "Butlerian Jihad" manifesto into shell profile files using a quoted heredoc block that does not execute in the shell but still remains in the file.

That matters because coding assistants often read files like .bashrc and .zshrc to understand the environment.

So the payload lands in the assistant's context window even when it is inert to the shell itself.

That is not just persistence.

It is an attempt to poison the next agent.

The shell is no longer just a persistence target. It is part of the model's working context.

AI tooling is now a first-class target

The malware targeted AI tooling configuration files such as ~/.claude.json, ~/.claude/mcp.json, and ~/.kiro/settings/mcp.json.

Modern developer environments now include agent configuration as a first-class target.

This is what the next supply chain incident looks like: not just credential theft from disk, but theft from CI, abuse of developer tokens, and direct targeting of the files that shape how agents behave.

What execution-layer security actually does here

The point of AgentSH is not to replace detection.

It is to make detection operational at the moment of execution.

AgentSH secure-sandbox added package install security checks that intercept install commands like npm, pip, and yarn and check packages against security providers including Socket before allowing the install. It also added packageRules so policy can block malware, require approval, or flag risky packages.

For an incident like this, that is the difference between "we learned about it quickly" and "the install never happened."

That is especially important here because the compromise point was preinstall. If you do not stop the package before install-time scripts run, you are already behind.

AgentSH also governs what happens inside the command, not just the command itself. Its runtime policy model supports allow, deny, approve, soft_delete, and redirect, with visibility into file I/O, network connections, process activity, PTY activity, and LLM API traffic.

That matters here because the malicious loader still had to do real work after npm install started: download runtime components, read secrets, inspect AI config, touch shell profiles, and open outbound network connections.

Runtime controls let you govern those side effects directly.

And when autonomy should stop, approvals need to exist at the execution boundary, not the planning boundary. Agents do not have a built-in half-second pause when something looks off. Deterministic approvals put that pause back where it matters.

The lesson

The most important sentence in this incident is simple:

The payload ran before npm finished installing.

That is why this matters so much for autonomous systems. A short exposure window is good. But short windows stop being reassuring when agents and CI workflows can still hit them automatically, and when the malware is not content just to steal credentials from disk.

In this case it also targeted AI tooling config and, according to Security Boulevard's syndicated Mend analysis, tried to poison the context window of the next assistant that read the shell profile.

Socket for fast ecosystem detection. AgentSH for deterministic enforcement at execution time.

Detection without runtime control means you can learn about the compromise quickly and still lose.

Sources

Copy Fail: Block the Path, Not the Paragraph

2026-04-29T00:00:00Z

Copy Fail is 732 bytes of Python. An agent can fetch it and run it in one turn.

CVE-2026-31431 is a local privilege escalation that chains AF_ALG and splice() into a 4-byte page-cache write, then uses that write against a setuid binary such as /usr/bin/su. The Copy Fail write-up describes the PoC as a 732-byte Python script, standard library only, targeting /usr/bin/su by default.

For a human, public exploit code still has friction. Someone has to read the advisory, understand the exploit, copy it, choose where to run it, and accept the consequences. Agents remove much of that friction. They can read the page, download the script, run Python, inspect the result, and retry if something fails.

The model does not need to understand Linux kernel exploitation. It only needs to decide the next command is worth running.

That is the agent-security lesson. Agents do not make Copy Fail worse because they are malicious. They make it worse because they shorten the path from public text to execution.

The container boundary is not the whole boundary

One of the uncomfortable details in Copy Fail is that the page cache is shared across the host. The file on disk is not changed, but the in-memory page cache can be corrupted and then read by other processes. Xint's write-up calls this out directly: because the page cache is shared across container boundaries, Copy Fail is not only a local privilege escalation but also a container escape primitive and Kubernetes node compromise vector.

That matters for agent sandboxes, CI runners, build farms, and hosted code execution platforms. A container gives a process a smaller world, but it does not give that process a separate kernel. If the exploit path reaches shared kernel state, the boundary that matters is lower than the container.

A self-hosted GitHub Actions runner executing untrusted PR code on a shared kernel is exactly this scenario. So is a GitLab runner, a Jenkins agent, or any build farm that runs tenant-supplied code as a regular user on shared infrastructure. Copy Fail turns that regular user into root on the runner, and on a shared host, into the other tenants' builds, cached secrets, and checked-out repos.

This does not mean containers are useless. It means isolation and runtime policy are different controls. Isolation says, "this process has a smaller world." Runtime policy says, "even inside that smaller world, this process may not do that."

Agents need both.

Two controls matter here

Block su. Block AF_ALG.

The first control is obvious. Copy Fail's public PoC targets /usr/bin/su by default. For most agent workloads, su is not a legitimate tool. It is interactive, privilege-oriented, and designed around a human authentication flow. A coding agent does not need su to edit files, run tests, install dependencies, or build a project. If an agent tries to execute it, policy should stop the process before it starts.

The second control is the more important one. Copy Fail depends on access to AF_ALG, the Linux socket family that exposes kernel crypto operations to userspace. Most agent workloads do not need that interface. An agent may need HTTPS to GitHub, npm, PyPI, an internal package registry, or an approved API. That does not mean it needs access to every socket primitive exposed by the operating system.

This is the distinction most agent policies miss. "Allow network access" should not mean "allow every socket family." URLs and socket families are different layers. A policy that understands domains but not OS primitives can still leave the dangerous path open.

AgentSH blocks the path

The practical question is not whether the model understands Copy Fail. The practical question is whether the runtime lets the exploit path execute.

AgentSH runs underneath the agent. It intercepts process execution, file access, and network activity at runtime, then applies policy before the action happens. For Copy Fail-style risk, that means AgentSH can deny su as an executable and deny socket families the workload does not need, including AF_ALG.

That is the difference between guidance and enforcement.

A prompt can say, "Do not run privilege escalation exploits." A rule file can describe what the agent is supposed to do. But the runtime sees the concrete behavior: a process tried to execute su; a process tried to create an AF_ALG socket; a script reached for a kernel interface unrelated to the task.

The model can be told not to run exploits. AgentSH can make the exploit path unavailable.

Patch the bug, then remove the capability

The first response to Copy Fail is to patch the kernel. The public mitigation guidance also recommends disabling algif_aead before patching and blocking AF_ALG socket creation for untrusted workloads such as containers, sandboxes, and CI environments.

But the durable lesson is bigger than this one CVE. The next bug may not involve AF_ALG. It may not target su. It may not look like Copy Fail at all. But it may follow the same pattern: an ordinary process reaches an OS capability the workload never needed.

That is why agent policy has to move closer to execution. Public exploit code is now easy for agents to find and operate. Agent environments are often short-lived, which reduces persistence but also reduces forensic visibility. If the runtime does not enforce policy while the sandbox is alive, the evidence and the opportunity to stop it may disappear with the environment.

Patch the kernel, of course. But also remove capabilities the agent never needed.

The agent proposes. The policy decides.

Sources

AgentSH: A Policy Boundary on the Database Wire

2026-05-22T00:00:00Z

Execution-Layer Security now covers one of the riskiest things an agent can touch: your database.

We built AgentSH on a stubborn premise: rules are not enforcement. A CLAUDE.md that says "don't touch production" is a suggestion. A system prompt that says "only run read-only queries" is a hope. Once an agent has a connection string and a reason, that text is no longer load-bearing. Enforcement has to live somewhere the agent can't talk its way past.

AgentSH already provides that boundary for files, processes, and network calls. The database proxy brings it to the data tier: AgentSH now classifies each statement an agent sends to PostgreSQL, evaluates it against policy, and decides — before it reaches your data. This is not another prompt, policy file, or advisory scanner. It's an inline enforcement point on the database wire.

Two failure modes, one connection

When an agent and a database share a blast radius, there are two distinct ways it goes wrong, and a useful control has to handle both.

The accident. The agent is doing exactly what you asked. It's iterating, exploring the schema, "cleaning up test data" — and somewhere in that loop it issues a statement that's correct in syntax and catastrophic in scope. A TRUNCATE meant for staging that hits prod. An UPDATE that lost its WHERE. No malice, just an autonomous process moving faster than your ability to review each step.

The attack. The agent is being steered by someone who isn't you. A prompt-injected instruction in a fetched page, a poisoned document, a malicious tool description — and now the agent is dutifully running a DROP because the text in its context told it to. The agent isn't compromised in the classical sense. It's working perfectly. It's just working for the attacker.

The uncomfortable part is that these look identical at the connection level. Both are a legitimate session sending a legitimate-looking query. You can't separate them by authenticating the connection harder, because the connection was never the problem. The statement is. Firewalls can see the path. IAM and access brokers can see identity. Database GRANTs can see roles and objects. But none of them reliably answer the agent-specific question: should this exact statement, from this exact agent session, run right now?

Why the tools you already run don't close this

You'll reach for controls you have. They each cover part of the gap:

Network rules and firewalls decide whether the agent reaches the database host and port. They cannot see whether the query inside that stream is SELECT 1 or DROP TABLE customers.
Database GRANTs and row-level security are real enforcement, and you should keep using them. They're excellent at defining what a role may do over time. They're less good at deciding whether this specific statement, in this specific agent session, should run right now.
"Don't touch the database" in the prompt is, again, not enforcement — it fails the instant an attacker controls the prompt.

There's a deeper distinction underneath. Human database-access tools — Teleport, Boundary, IAM DB auth — answer an identity question: who is connecting, from where, under what role? An agent is a delegated, probabilistic actor that may be operating under prompt injection or task drift, so identity isn't enough. The path needs to answer a second question: what is this agent trying to do right now? The proxy exists to answer that second question, and it's designed to sit on top of your GRANTs and roles, not replace them.

What shipped

The agent issues an ordinary PostgreSQL connection — same DSN, same drivers, same client libraries, no SDK to adopt and nothing to point at a different host. AgentSH transparently steers the connect through its proxy using the same connect_redirect mechanism it already uses to enforce outbound network policy: the TCP connect to the declared database upstream is rewritten to a per-session Unix socket where the proxy listens, and the proxy verifies the peer's process identity via SO_PEERCRED against AgentSH's session registry. Direct TCP egress to the database from anywhere outside the proxy's session is denied at the network layer, so the proxy isn't an opt-in step in the path — it is the path, for any process inside the governed tree.

From the database side, that path is an inline decision point: the proxy speaks PostgreSQL wire protocol v3, parses each statement into a list of effects, evaluates every effect against policy, and decides before anything reaches the database. The postgres and aurora_postgres dialects are fully supported, with redshift and cockroachdb in beta.

Each rule resolves to one of these decisions:

allow — forwarded untouched.
deny — rejected before it reaches the database; the agent gets a clean protocol-level error, not a crash.
approve — held pending human sign-off, then released or rejected. AgentSH's approval manager supports TOTP and WebAuthn; the default approval timeout is 60 seconds, sized to be safe inside an open transaction.
audit — allowed, logged as a structured event.
redirect — read-only steering metadata (see the note below on its current status).

An important detail for writing policy: the database evaluator is order-independent. Unlike AgentSH's file and command rules, DB rules are evaluated collect-all — every covering rule is considered, and the most-restrictive verdict wins. Any matching deny wins, regardless of rule order. And coverage is strict: every object an effect touches must be covered by some rule, or the statement is implicitly denied. You don't sequence rules to stay safe; you just write them.

The controls, concretely

Because the proxy classifies statements into effects, policy can decide on the dimensions that matter for database safety:

Operation class. Reads, writes, and schema changes aren't the same risk. Policy can allow reads, approve writes, and deny schema-destroying operations like DROP and TRUNCATE — using operation tokens (READ, UPDATE, DELETE, DROP, the DANGEROUS bundle, and others) rather than three separate database roles.

Object and schema scope. Rules target specific schemas, syntactic object names, or catalog-resolved relations and functions. A READ on public.users can be allowed while writes elsewhere require approval.

Whereless mutations. require_where. An UPDATE or DELETE with no WHERE is the most common way agents (and humans) destroy data by accident. A rule with require_where: true covers a mutation only when it carries a syntactic WHERE clause — so you allow the bounded form and let strict coverage's implicit deny catch the whereless one. It's a syntactic guard, not a proof of selectivity: WHERE true satisfies it, so pair it with database-native constraints for real predicate enforcement.

Bulk export. A COPY ... TO that pulls a table out is how a "read-only" agent becomes a data breach. The classifier flags bulk-export effects as critical-tier, so policy can deny or gate them distinctly from ordinary reads.

Audit. Every decision is emitted as a structured event tied to the agent session and process context. By design, connection strings are parsed and their embedded credentials discarded at classification time — secrets never land in the event payload. Statement text logging is configurable (none, parameters_redacted, or full), defaulting to redacted. These events flow into AgentSH's telemetry pipeline and on to Watchtower, our commercial control plane. (A dedicated OCSF projection for database events is on the roadmap; today they use AgentSH's native DB event schema.)

A note on `redirect`

redirect is the most interesting capability: rather than only blocking a risky read, policy can express that it should be steered somewhere safe — a sensitive query pointed at a redacted view instead of denied outright. It is read-only by design: it will not reroute writes. Today the policy engine accepts and validates redirect rules, while runtime enforcement is next on the roadmap. We'd rather tell you that than imply your queries are already being transparently rewritten.

What it looks like in policy

These rules use the same fields and tokens as the proxy's own sample policy. A service is declared, then statement rules govern it:

db_services:
  appdb:
    family: postgres
    dialect: postgres
    upstream: db.internal:5432
    tls_mode: terminate_reissue

database_rules:
  # Reads are fine on appdb
  - name: app-read
    db_service: appdb
    operations: [READ]
    decision: allow

  # Bounded updates are fine; they must carry a WHERE to be covered at all
  - name: app-bounded-updates
    db_service: appdb
    operations: [UPDATE]
    require_where: true
    decision: allow

  # Deletes are riskier — cover only bounded deletes, and route them past a human
  - name: app-bounded-deletes
    db_service: appdb
    operations: [DELETE]
    require_where: true
    decision: approve
    message: "Agent wants to DELETE on appdb: "

  # Destructive schema changes and bulk export are off the table
  - name: app-deny-dangerous
    db_service: appdb
    operations: [CREATE, DROP, ALTER, TRUNCATE, EXPORT]
    decision: deny
    deny_mode_in_tx: terminate
    message: "Agent is not allowed to perform  on appdb"

  # Catch-all: anything the classifier can't read fails closed
  - name: catch-all-unknown
    operations: [unknown]
    decision: deny
    message: "Statement could not be classified. Failing closed."

You can check how a given statement would be judged without sending it anywhere:

agentsh policy db explain ./policy.yaml --service appdb --sql 'SELECT * FROM users'

Because evaluation is collect-all with any-deny-wins and strict coverage, the recommended posture is default-deny: allow the safe paths, approve the risky ones, and let everything uncovered fall to implicit deny.

What it governs today, and what's next

We'll be straight about the boundary, because the people who adopt execution-layer security are the people who distrust a pitch with no edges.

PostgreSQL and its family. The proxy speaks PostgreSQL wire protocol v3, with postgres and aurora_postgres fully supported and redshift and cockroachdb in beta. More databases are on the way; the architecture — classify into effects, evaluate, decide — is protocol-agnostic by design.
A boundary, layered on your existing controls. This is a policy decision point on the wire, not a replacement for database GRANTs and row-level security. Keep those — the proxy is strongest as the runtime, statement-level layer on top of them, answering the question they can't: should this statement, from this agent, run right now? Its enforcement holds for any session that goes through the proxy, which AgentSH's process, network, and file primitives are built to guarantee for the governed process tree.

Two capabilities are coming that make the boundary even sharper. Runtime redirect will transparently steer a flagged read to a redacted view, turning "deny and let the agent improvise" into "succeed safely." And a credential broker will hold the upstream credential so the agent authenticates to the proxy, never to the database — taking the production secret out of the agent's hands entirely. Today the proxy governs what an agent can do, statement by statement; these extend it to govern what it can reach and what it ever holds.

Get it

AgentSH is open source (Apache-2.0). The database proxy is available now.

Code, config reference, and changelog: github.com/canyonroad/agentsh
Project site: agentsh.org

Agents need database access. Prompts aren't enforcement, and GRANTs are necessary but weren't designed to make agent-aware, per-statement decisions at runtime. AgentSH now puts a policy decision in the database path — so an agent can do the data work you asked for, statement by statement, under rules it can't argue with.

Pull the release, run an agent under AgentSH against your normal database DSN, and try to make it do something it shouldn't. Then tell us where it bites. That's how the last several releases got good.

The Attack Will Not Look Like Malware

2026-06-02T00:00:00Z

An AI agent does not need malware to cause damage. The individual steps may all look legitimate. The breach is in the sequence.

An AI agent does not need malware to cause damage. It can use approved tools, valid credentials, normal APIs, an existing browser session, a package manager it is allowed to call, a repository it is allowed to read, or a customer record it is allowed to summarize.

That is what makes securing agents different. The individual steps may all look legitimate. The breach is in the sequence.

Anthropic's Zero Trust for AI Agents makes this shift very clear. Prompt instructions are not enough. Tool permissions inside the agent are not enough. Logs after the fact are not enough. When an agent can read files, call APIs, use credentials, browse internal systems, and chain tools together, the control point cannot live only inside the thing being controlled.

You need enforcement outside the agent. That is the plane we are building at Canyon Road.

The agent is not stealing access. It is using access that already exists.

Most enterprise security programs are still trained to look for malware, suspicious binaries, stolen credentials, unusual logins, or known bad infrastructure. All of that still matters, but it does not fully describe the risk created by agents.

A coding agent can read a repo, inspect environment variables, call a package manager, open a connection, write files, and run tests. A support agent can read customer records, summarize them, and send a message. A desktop agent can browse an internal app, copy data, invoke a local tool, and upload the result somewhere else.

In each case, the tools may be legitimate. The credentials may be valid. The operating system may not be exploited. The agent is already in the environment, operating with access that was intentionally granted.

The problem starts when untrusted input, a poisoned tool result, a malicious MCP server, or a compromised workflow pushes that agent into using its access in a way nobody intended. Traditional host-centric monitoring can miss this because it is often looking for the wrong shape of attack. It looks for malware, but there is none. It checks whether the credentials are valid, and they are. It sees approved tools being used, but not necessarily the risk created by the combination.

For agents, the security question is no longer only which binary is running or which user is logged in. It is what operation is being attempted, by which agent, against which resource, through which tool, and with what blast radius.

That requires a layer that understands actions, not just identities.

The useful test: impossible, not tedious

One of the best ideas in Anthropic's framework is the test it gives for controls: does the control make the attack impossible, or does it only make it tedious?

That distinction matters more for agents than it did for traditional human-driven workflows. A human attacker has fatigue, cost, and patience limits. An agent can retry, rephrase, split a task into smaller steps, and keep looking for another path at machine speed and low marginal cost.

That means friction ages badly. Rate limits, extra hops, non-standard ports, warning banners, "be careful" prompts, and agent-managed permission files can all be useful, but they are not enough by themselves. They may make the attack more annoying. They do not necessarily remove the capability.

The controls that survive are the ones that actually take something away: no credential, no network path, no write permission, no file mount, no syscall, no way to send the data out.

That is the difference between asking an agent not to do something and making it unable to do it.

In-agent controls are necessary, but not sufficient

This is not an argument against agent-level controls. Allowlists, settings files, hooks, MCP configuration, permission prompts, and human approvals are all useful. They should exist.

But they are the first front. They live inside the agent runtime and depend on the agent framework, local configuration, and surrounding environment remaining trustworthy.

Zero Trust starts from a different assumption. Assume the prompt was injected. Assume the tool result was poisoned. Assume the MCP server was malicious. Assume the agent ignored the instruction. Assume the credential leaked.

Then ask what still stops it.

Anthropic's framework answers that directly. Tool access has to be controlled at the agent level and outside the agent level, in case the agent or its environment is compromised.

That second front is not a prompt, and it is not a setting the agent can read or modify. It is enforcement outside the agent's reasoning loop: runtime isolation, filesystem and network policy, credential mediation, tool and MCP policy enforced before execution, approvals the agent cannot bypass, and audit the agent cannot rewrite.

The important property is that the control point does not require the agent to cooperate.

Agents need their own enforcement plane

Enterprises already have security models for users, endpoints, applications, workloads, and networks. Agents cut across all of them.

An agent is not just an application. It is an actor with tools, memory, credentials, and the ability to chain steps in ways the original developers never explicitly encoded. That is why agents need a dedicated enforcement plane.

At Canyon Road, we think about this in three parts: AgentSH for runtime enforcement, Beacon for endpoint enforcement, and Watchtower for centralized governance.

AgentSH enforces at the runtime

AgentSH enforces policy where agents execute: shells, sandboxes, containers, build environments, cloud workloads, coding agents, and task runners.

This is where policy becomes concrete. Can the agent read this file? Can it write outside the project? Can it execute this binary? Can it open this socket? Can it reach this secret? Can it call this MCP tool?

Those decisions cannot reliably be left to a prompt. They need to be made at execution time, outside the agent, before the action happens.

For example, a coding agent can be allowed to run tests and read the repository, while still being blocked from reading .env, opening arbitrary outbound connections, invoking unapproved MCP tools, or writing outside the workspace without approval. The agent can still do useful work, but the blast radius is different.

The agent proposes the action. Policy decides whether it happens.

Beacon enforces the endpoint

A lot of agentic work has moved onto laptops: Claude Code, Claude Desktop, Cursor, VS Code, local MCP servers, browser automation, local CLIs, and internal tools.

That environment is messy and full of real access. Human credentials, browser sessions, SSH keys, cloud CLIs, source code, Slack, Gmail, and internal dashboards are all available on the endpoint. From the agent's point of view, the desktop is one large tool surface.

Beacon gives organizations enforcement and visibility over what those agents actually do. Which process made the request? Which file was read? Which domain did it reach? Was the action expected? Should it be approved, blocked, logged, or redirected?

The endpoint is where valid credentials become dangerous, because the agent is not stealing access. It is using access that already exists.

Watchtower governs the enforcement plane

AgentSH and Beacon apply policy at the runtime and endpoint. Watchtower is how organizations govern that enforcement across the fleet.

Watchtower manages baselines, distributes policy to enforcement points, collects audit, exports to the SIEM, and gives security teams visibility across agents and environments. Its most important role under pressure is the policy overlay.

When a new vulnerability lands and there is no patch yet, or when the patch cannot be deployed immediately, Watchtower can distribute an overlay that constrains the affected behavior at the enforcement layer. AgentSH and Beacon apply that overlay, and the exploit path can be closed across the fleet before the upstream fix is available everywhere.

That is virtual patching for agents.

This matters because the response window is getting shorter. Exploits can appear within hours of a patch, while many organizations still need days or weeks to validate and deploy fixes across every dependency, base image, extension, agent runtime, and laptop. The enforcement plane gives security teams a place to act immediately.

Watchtower is also where this becomes manageable over time. Zero Trust is not a static configuration. As agent behavior changes, the governance layer needs to understand normal patterns, tune policy, distribute updates, and keep the whole system observable.

The enforcement layer should steer, not just deny

Hard denial is sometimes the right answer, but it is not always the best one.

When an agent tries a disallowed action and receives only a generic error, it may not stop. It may retry, rephrase, or find another path to the same goal. That can burn time and tokens, corrupt state, or push the agent into a loop.

The enforcement layer should be able to steer, not only block.

AgentSH and Beacon can intercept an action and return a controlled response that explains the boundary and gives the agent a safer path forward. For example, if the agent reaches for a secret it should not touch, or starts down a path that would end in a loop, the enforcement layer can tell it that the action is not allowed and indicate how to continue within policy.

That is different from prompt-based instruction. The steering comes from the control point outside the agent's reasoning loop, with authority the agent does not get to bypass.

The same action channel that can be abused by a poisoned web page, malicious tool result, or compromised MCP server can also be used by the enforcement layer to keep the agent on rails. The difference is provenance. One is untrusted content trying to hijack the agent. The other is policy enforced outside the agent.

The goal is not only to stop one bad action. It is to prevent the cascade of bad actions that would have followed.

The floor moved

Anthropic's framework treats sandboxed execution as table stakes for agents handling untrusted input. That matters because nearly every useful agent handles untrusted input: web pages, documents, emails, tickets, repositories, packages, tool results, and MCP responses.

The floor moved.

The old question was how to write a safer prompt. That is still useful, but it is no longer the main enterprise question. The better question is: when the agent is compromised, confused, over-permissioned, or simply wrong, what still holds?

The answer is not one control. It is a stack: identity for the agent, least agency for its tools, short-lived credentials, runtime isolation, endpoint control, network egress control, approvals for risky actions, immutable audit, and centralized policy that can change faster than the threat.

AgentSH, Beacon, and Watchtower are our version of that stack: runtime, endpoint, and fleet.

Anthropic defined the framework. The enforcement plane is what makes it operational.

Zero Trust for agents starts when permission moves out of the prompt and into the execution path.

Thanks to Jesse Robbins for reviewing an earlier draft of this post. Jesse has been researching sandboxing and fencing solutions for agents.

Canyon Road builds the enforcement plane for AI agents. AgentSH enforces at the runtime, Beacon on the endpoint, and Watchtower governs and distributes policy across the fleet. The framework referenced here is Anthropic's Zero Trust for AI Agents, published May 2026.