Introducing Beacon: Endpoint Telemetry for AI Agents

Second Derivative

SubscribeSign in

Introducing Beacon: Endpoint Telemetry for AI Agents<br>Making local AI agent activity observable, understandable, and governable.

Justin D'Souza<br>May 14, 2026

Share

The first generation of AI security centered on the model gateway. The next will move to the endpoint, where agents actually do the work.<br>Gateways made sense when AI systems mostly answered questions. A security team could put a control point between the user and the model, inspect prompts and outputs, enforce DLP, mediate model access, and log the exchange.<br>Thanks for reading Second Derivative! Subscribe for free to receive new posts and support my work.

Subscribe

Agents force that architecture to evolve. The security problem is no longer just what a model says or sees. It’s what an agent can do: use the user’s tools, inherit their permissions, and change state inside sensitive environments.<br>The clearest example is the developer machine. Coding agents like Claude Code, Codex, and Cursor run alongside source code, terminals, package managers, cloud CLIs, local credentials, and production-adjacent systems. A single natural-language request can turn into file reads, shell commands, dependency changes, credentialed actions, and code modifications.<br>That same pattern is now expanding beyond developers to knowledge workers. Desktop-connected agents are beginning to operate across SaaS apps, local tools, and internal systems. Agent workspaces like Claude Cowork and OpenClaw point to the next phase of enterprise AI: the user’s laptop becomes the runtime for delegated work across enterprise applications.<br>The hard reality today is that security teams may only see the blast radius after an agent has executed commands, modified files, installed dependencies, or exfiltrated data. The failure modes are already severe: remote code execution through Claude Code project configuration, private code exposure through Copilot Chat prompt injection, and credential theft through malicious npm packages that turn local coding agents into attack paths.<br>That is the endpoint visibility gap Beacon is built to close.<br>Beacon is Asymptote’s open-source endpoint telemetry layer for AI agents. It is our first step toward making local agent activity observable, understandable, and eventually governable across the enterprise.<br>Beacon Github Repo : https://github.com/Asymptote-Labs/agent-beacon<br>What This Means for Security Teams

For security teams, this matters because the existing stack was not designed to explain delegated work. Gateways, EDR, and agent-native telemetry all remain important, but each sees only part of what an agent is doing. To govern agents safely, teams need to see how an agent moves from intent to action on the endpoint.<br>Three gaps stand out:<br>Endpoint logs show effects, not workflows. They can capture commands, file changes, and process activity, but they rarely connect those events back to the agent request, tool decision, approval path, or final diff.

Agent telemetry needs a common layer. AI coding agents like Claude Code, Cursor, Codex, and Claude Cowork all expose different telemetry signals. Security teams a unified endpoint-level record across them.

Visibility comes before control. Teams cannot enforce configurations, gate sensitive actions, govern MCP access, or protect secrets until they know which agents are running, what permissions they have, and what actions they are taking.

Endpoint Logs Don’t Capture Agent Workflows

Traditional endpoint telemetry is necessary, but insufficient for understanding agent behavior.<br>It can show that commands ran, files changed, processes spawned, or connections opened. What it usually cannot show is the workflow behind the event: what the agent was asked to do, what it decided to do, and whether the action made sense for the task.<br>The same agent action can be safe or risky depending on the task around it. For example:<br>A kubectl command may be appropriate during an infrastructure incident, but inappropriate for a coding agent asked to update a unit test.

A .env read may be expected during local debugging, but suspicious during a documentation edit.

A Terraform change may be normal in an infrastructure repo, but dangerous when introduced as a side effect of a dependency update.

In each case, the raw event is not enough. The security meaning depends on the workflow around it: the prompt, the plan, the context accessed, the tools invoked, the files touched, the credentials used, and the approvals granted.<br>Consider a coding agent asked to make a narrow test change: The user request might look something like: “Update the unit test for the billing retry logic.”<br>Traditional telemetry might show:<br>10:42:11 grep -R “retry” src/ tests/

10:42:24 modified tests/billing/retry.test.ts

10:42:39 read .env

10:42:52 modified terraform/production.tf

10:43:08 ran kubectl apply -f deployment.yaml

Those events are useful, but they are...