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

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)

1. 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.
2. The MCP server or skill offers "helpful tools" (search, docs, debugging, email).
3. 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)

1. An automation agent runs in CI with access to environment secrets and connected MCP servers.
2. A compromised dependency or a prompt injection in a ticket description convinces the agent to read credentials and exfiltrate them.
3. 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.

← All posts