Building the Control Plane to Secure Agentic Endpoints

A developer asks Claude Code to investigate a production incident and open a vendor support ticket. The user, the credentials, the tools, and the destination are all legitimate. But the ticket includes unredacted customer records - the agent simply did more with the data than the developer intended.

This hypothetical illustrates a defining security challenge of agentic computing: a person authorizes the objective, but an agent determines how to achieve it. Risk can now emerge at any step of agentic workflows.

Traditional security controls were designed to evaluate identities, endpoints, networks, and data independently. Agentic workflows span all of those domains, making it difficult for any single control to understand the complete context behind an action. 

As agents become a routine part of enterprise work, organizations need new controls that move closer to where agent decisions, browser activity, tool calls, and prompts happen.  

Why existing security controls need to evolve

Traditional tools were designed to defend the underlying infrastructure: devices, identities, and networks. Foundational controls like endpoint detection and response (EDR), identity and access management (IAM), and data loss prevention (DLP) excel at detecting malware, locking down access, and stopping unauthorized file transfers.

AI agents operate at a layer where traditional tools lack visibility, exposing these architectural limits:

• EDR secures the operating system, but has limited ability to detect when an agent's reasoning or tool use has been hijacked via prompt injection.
• IAM governs humans logging in or a service account with a fixed key, but has limited visibility into permissions granted to an autonomous actor working on a user’s behalf.
• DLP stops known patterns of sensitive data leaving the perimeter, but cannot stop an agent from synthesizing and leaking information through natural language. 

As agents assume real operational authority in enterprise work, security must evolve to address these gaps. Closing them requires evaluating autonomous activity where it happens before deciding whether a sensitive action should proceed.

The endpoint is becoming the decision point 

An agent may begin with a prompt in a desktop app, retrieve a document from a cloud drive, process it in a local runtime, invoke a tool, and send the result through a team chat. To the agent, this is one workflow, but to most security controls, it reads as a series of unrelated events across different systems.

The endpoint is where those events can be connected before an action takes effect. At that moment, a security decision may need to account for four kinds of context:

• The actor: Which person initiated the task, which agent is acting on their behalf, and what identities and permissions are involved? 
• The data: What information is being accessed, how sensitive is it, and what business context surrounds it? 
• The workflow: What objective is the human or agent pursuing, which applications and tools are they using, and what sequence of actions led to this point? 
• The destination: Where is the data or action going — to another application, an external service, a local process, a peripheral, or a person? 

So how should the control plane evolve to meet this new reality? 

The five principles for building an endpoint control plane 

We’ve found five principles useful when thinking about how endpoint security should evolve. They’re a useful framework for any organization rethinking endpoint security for the agentic era:

1. Start with the data. Security decisions should begin with the sensitivity, ownership, and business context of the information an agent can access, not simply the classification of an isolated file. That context should remain consistent wherever the data resides, from enterprise data stores to the endpoint and into agent workflows.
2. Extend identity beyond humans. Identity should describe not only who initiated a task but also which non-human identities and systems are acting under that person's authority. A model should preserve both human and non-human identities simultaneously. 
3. Continuously evaluate intent. Authorization should not end when execution begins. Agent objectives evolve, tools change, and new information influences decision-making. Policies therefore need to evaluate actions at runtime, not just at session start. 
4. Govern workflows, not individual events. Individual actions rarely reveal the full risk. Opening a document, querying an API, generating a summary, and sending an email may each appear benign in isolation. Their sequence may represent either routine business activity or unintended data disclosure, and the broader context is key to more informed decisions.
5. Keep humans in control. Greater autonomy does not eliminate the need for human oversight. Organizations should retain the ability to explain, interrupt, approve, or stop autonomous workflows whenever risk exceeds acceptable thresholds or business context cannot be inferred reliably by automation alone. 

‍Looking ahead 

Agentic computing is still early, and many architectural questions remain. But one trend is clear: as agents become easier to build and deploy, the enterprise data attack surface will grow with them. 

Organizations will need a runtime control plane for visibility, governance, and trust. That’s the problem we’re focused on solving as we extend our AI trust layer to agentic endpoints.

To see what we are building, join our upcoming webinar or visit us at Black Hat 2026.