AI agents are quietly redefining enterprise risk and most security teams are looking in the wrong place. What happens when powerful software acts with full user privileges, but the guardrails we’ve spent decades building for humans are just not enough? The result is a new class of risk that traditional security models weren’t designed to handle.

Workstation agents are AI systems that run on a user’s endpoint under user privileges and can interpret instructions, access local, enterprise and web context, use tools, and take actions across applications and data on the user’s behalf. The two most widely adopted types currently are coding assistants (e.g. Cursor) and personal productivity agents (e.g. Claude Cowork, ChatGPT Desktop).

Endpoints are not always the victim of the agent's risky behavior. They are often just the launchpad. The agent may run on a perfectly healthy endpoint while the actual damage occurs in a code repository, SaaS app, cloud account, ticketing system, customer record, or business workflow. 

Even when the endpoint is the victim, agent driven harm may not resemble traditional endpoint compromise. The agent may corrupt files, expose local secrets, change developer configuration, grant unsafe permissions, install risky tools, or execute unsafe commands using legitimate applications and valid user authority. Endpoint telemetry may capture and alert on fragments of this activity, however without the right real time context of the chain of events in the AI session that led to the action on the endpoint, those fragments often look like normal productivity or developer behavior rather than a high confidence security incident.

Just as importantly, the source that caused the risky agent behavior may never touch the endpoint in a form that traditional endpoint monitoring can see: it may come from a malicious skill, a tool response, a manipulated knowledge base entry, an external webpage (indirect prompt injection), or a remote MCP server that influences the agent’s reasoning before any suspicious endpoint activity occurs. 

Let's look at two examples that have already been demonstrated against popular AI coding agents.

Example 1: Poisoned documentation. A developer's AI agent fetches a README from a public repository for context. Buried in the file, hidden in white text or HTML comments, are instructions the agent can't distinguish from legitimate content. It follows them, quietly adding a backdoor dependency to the project. Your security stack might log the package install or the outbound fetch, but nothing distinguishes it from routine development.

Example 2: A malicious MCP server. A developer connects their agent to a community MCP server for extra tooling. The server returns tool responses with embedded instructions that tell the agent to read local environment files and send their contents to an external endpoint. Your security tools may see fragments - a file read here, an outbound call there. But without knowing what the agent was told and why, there's no signal - just noise that looks like every other agent interaction.

In both cases the attack originates entirely outside the endpoint's field of view. The trigger is a manipulated input to the agent's reasoning layer - a place no EDR, DLP or SASE is watching. By the time anything happens on the endpoint, it looks like normal developer behavior.

Figure 1: Workstation AI Agent - Attack Surface and Blast Radius

That is why agent risk cannot be evaluated only by asking whether the endpoint is compromised. Defenders must also ask what the agent did, why it did it, what influenced it, what system it acted on, and whether the action was in-line for the user’s intent and the agent’s purpose.

EDRs have long been and continue to be a key tool, to protect endpoints from breaches, with a threat model built around catching behavior that is malicious and unauthorized. As we have established, agents break that threat model. Thus, a new approach and solution is needed that will be complementary to the EDR in protecting the enterprise from agentic risk impacting the endpoint and beyond. 

So what is the right approach?

The approach requires a threat model built around the entire agentic footprint and each agent's profile and real-time behavior with the ability to drive action towards risk reduction. Let's get into the details:

First, discover all the assets that make up the agentic footprint. These assets, either running on the endpoint or remotely, are part of the agent's core and its ecosystem, and if compromised can lead to risky agent behavior. This can happen with malicious input into the agent that causes risky behavior or a compromised ecosystem tool whose behavior deviates from the intent of the user and agent action. Example assets associated with workstation agents are sanctioned and shadow agents, MCP servers, skills, plugins, code repos, hooks, identities, actors and models. 

Second, profile the agentic footprint to establish the purpose, intent, capabilities of the agent with respect to the ecosystem it operates in. Gain a deep understanding of its behavior, by inspecting the full session of every AI interaction to understand user intent, historical behavior and session trajectory. 

Third, harden the agentic footprint, by remediating exposures that can be exploited and by configuring the right sized guardrails on agent actions, that balance risk against productivity and adoption. The guardrails are never one size fits all, especially in a technology as dynamic as AI Agents. The deep understanding of intent and session are needed to determine the right size and make them adaptive with risk.

Fourth, enforce automated actions that are proportionate to observed risk. Block user or agent action when risk is critical or high and there is high confidence in the detection signal. Alert in-session or notify via IM to educate end-users when their actions or configuration is introducing risk. Kick off enterprise SOC response playbooks for actions beyond the agent or the endpoint. The key thing is to drive action that reduces overall risk while balancing AI adoption.   

Fifth, educate and collaborate with builders, end-users and business executives on the risks and the design and usage patterns that can balance their goals with risk. Coming up with alternative approaches combined with right-sized guardrails can create a powerful operating model that reduces friction and risk. 

Key Takeaways

Workstation agent risk can start and land beyond the endpoint. The agent may run on the endpoint, but the trigger may originate outside endpoint visibility, and the impact may land in code, SaaS, cloud, data, or business workflows.

EDR and endpoint monitoring are not purpose built to prevent agent driven enterprise risk. Agents use legitimate apps, valid user privileges, approved tools, and normal workflows, making it hard to detect risky actions with high confidence without deep context and understanding of the inputs into the agent and the full session context of every AI interaction. 

Enterprises need an agent-aware control plane for workstation agents. An approach that discovers the agentic footprint, profiles agent purpose, intent, capabilities and behavior, enables the right sized guardrails, and enforces proportionate responses based on actual risk, complementing EDR for endpoint protection and the wider enterprise security stack.