From Chatbots to Digital Employees: Why Agentic AI Requires a New Security Playbook

Over the past few years, we have seen an unprecedented rate of innovation in Artificial intelligence. From the launch of ChatGPT in November 2022 to where we are now with Agentic AI models like OpenClaw and even more advanced security models like Mythos, these advancements have shown executives the art of the possible and everyone wants to catch this next wave of innovation. No company wants to be left behind, become the modern-day Blockbuster, or lose out on the competitive edge AI promises. We are in an era of AI-first strategies, which is very similar to the cloud-first strategies of a decade ago. We all know how this ended: unexpected costs and mountains of security misconfigurations. The problem with this new paradigm shift is the risk implications are much worse. AI has moved the technology industry beyond deterministic systems where we can predict behavior and is no longer a simple input and output system which we can guardrail. Agentic AI systems now are much more complex because we simply give them a goal and they figure out how to achieve it by any means necessary. This could be accessing sensitive databases, making API calls to applications, running system commands, escalating their privileges, and much more. Because of this, we can no longer treat AI as a predictable application and must treat them as digital employees. 

Not all AI Agents are Alike

To properly secure AI agents, it is essential to understand what type of AI agents are running in an enterprise. Each type of agent will require a different approach. These types of agents can largely be put into three major categories:

Homegrown: Homegrown agents are the ones being purpose-built in-house. These agents are built on complex stacks of technology such as agent frameworks, AI models, browser automation, memory, inference compute, persistence engines, and application calling. The key question is how we secure and govern the infrastructure engineers use to build these agents, while also securing these agents at scale. Examples of these agents are ones built in Google’s Vertex, Langchain, Crew.AI, and Amazon Bedrock.

SaaS/Cloud: Most organizations today are adopting SaaS AI agents. These are off-the-shelf AI agents existing SaaS providers offer to help optimize workflows. The challenge here is how to manage the identity and permissions of not only human users, but AI users in SaaS environments, and who is responsible for the actions of these AI users? Examples of these agents are Salesforce’s Agentforce and ServiceNow’s AI Control Tower.

Local/Endpoint: Local AI agents are installed onto a user’s machine and can perform actions locally with elevated privileges. How do we gain visibility into these agents and enforce policies if they do not make any network calls or run everything locally? Examples of these would be agents like cursor, Claude code, Claude Cowork and OpenClaw.

One important note is there is some cross-pollination between these agent types as they can be homegrown and deployed locally or managed in the cloud but operated in a browser. The key is understanding the blast radius or exposure of these agents and how to reduce it.

Beyond just looking at how these agents are deployed, the other key consideration is to understand whether an agent is a delegated task agent or fully autonomous. For a delegated task agent, they will typically inherit the identity or responsibility of the owner. But who is responsible for the actions of a fully autonomous agent? This is where it becomes a little trickier because autonomous agents are more ephemeral in nature than a typical employee. The general guidance is to treat each autonomous agent as its own identity and provision just-in-time access based on intent and context as they spin up and down.

Framework for Securing Agentic AI

Now that we understand the complexity of the challenge at hand, regardless of what kind of agents you have, the same core framework exists to secure them. These are long-standing core principles in cybersecurity and part of several cybersecurity frameworks. Though called by many names in the market, it broadly breaks down into gaining visibility, configuration, and runtime protection.

• Visibility, Observability, Discovery, Shadow AI: The first step when securing any type of workload is visibility. Closely related to the saying you can’t measure what you can’t monitor, you can’t secure what you don’t see. The first part of visibility is understanding the inventory of agents you have within your enterprise. This is solving the shadow AI problem. But beyond just identifying all the agents currently operating, the next step in visibility is understanding what they are up to. However, now that we are in the agentic phase of AI, this becomes less of a black box because we can understand the prompts they create, data they access, and actions they perform.

• Configuration, Risk & Exposure, AISPM: After observability has been established, the next step is to identify the risks with each agent. This could be as simple as enabling privacy mode in an agentic code IDE, which removes the ability to train on any new code or context brought into the agent. More extensively, this evaluates the blast radius of each agent’s workload. What type of systems does this agent have access to, what entitlements does this agent have, what data can this agent access, what APIs or MCP servers can this agent connect to, and so forth. The goal of this phase is to ensure agent risk has been identified and reduced through any sort of configuration that can be implemented with what is available based on the agent type.

• Runtime Protection/AIDR: The last phase of this framework is to implement runtime protection for agentic workloads. This is often referred to in the market as AI detection and response. The idea is no agent can be fully hardened through the visibility and configuration phase, and additional control mechanisms must be implemented at runtime. Currently, a lot of this is done with human-in-the-loop action approval, but is not scalable for the long term. Often, the more scalable approach is to start with auditing agentic behavior and gradually implement policies of what an agent can and cannot do. Some of these policies will be deterministic, but there will also be non-deterministic policies that need to be enforced. Beyond just policies, there needs to be response capabilities when policies are broken or when monitored behavior needs to be stopped.  Outside of this, the agent should be subject to data protection controls that define what it is and is not allowed to access or use, including any sensitive information within its reach. It should also be prevented from taking any destructive actions on data. 

Approaches to Solving the Security Problem of Agentic AI

From the outside looking in, it seems like this challenge can be easily solved with the amount of investment going into the market and the number of startups coming to market. One of the biggest challenges isn’t solving the problem but finding the right solution to meet the needs of different complex enterprise clients. As mentioned above, we moved from simply catching prompts, filtering them, and logging them to a vastly broader scope. This broader scope requires much more to even get visibility into the actions of agentic AI systems. Depending on what an enterprise already has in place and what types of agents they have, each organization may have to take a different approach, and most likely multiple approaches.

API/Platform Connection

The API and platform connection method was one of the first to market, which allows an enterprise to connect to known agent platforms such as AWS Bedrock, embedded SaaS agents like Agentforce, and even Microsoft Copilot. This approach resembles the difference between the cloud access security broker (CASB) approach and the emergence of SaaS Security Posture Management (SSPM), being more closely related to SSPM. The platform connector approach is very good at getting granular information about how an environment was configured, what risks need to be mitigated, what data is accessible, and what tools/APIs can be accessed, very similar to what SSPM did for SaaS. Where this changes is for agentic AI. These platforms have a good amount of runtime protection and guardrails that can be set up as well. This approach is great for the known agents in an environment, but will generally have limited visibility into any sort of shadow AI, what actions happen locally on a device, and agentic ai network traffic.

Gateway and Network Proxy Approaches

The gateway or network proxy approach is one of the most popular approaches to agentic AI security in the market today. The core idea is all AI network traffic would route through a single proxy, LLM gateway, or MCP gateway, creating a single chokepoint where all activity can be monitored and policies enforced. This allows for great visibility into prompt inputs and outputs, tool calls, and data flows, as well as allows for a unified point of enforcement. This approach is generally excellent for visibility into shadow AI, allowing organizations to understand what agents they have in their environments. This also operates well for any sort of data loss prevention use case. There are limitations with the gateway approach, i.e., any network traffic that bypasses the proxy, such as a direct API call and local operations that happen on an end-user device. This leads to loss of visibility and protection of any activity that happens outside the chokepoint. The other downfall is that often, with a single point of enforcement, this leads to performance loss of these workloads.

Endpoint Instrumentation and Aggregation

The endpoint instrumentation approach either leverages an existing endpoint detection and response agent or installs a lightweight sensor onto an endpoint to gain visibility of agentic activity from a distributed approach. This approach arguably has the most visibility and enforcement of the digital workforce, but must overcome the sensor fatigue in the enterprise. These solutions have the ability to see tool calls, file access, system interactions, MCP server connections at the point of execution, and have the ability to enforce policies at the point of execution. Where this approach will have some blind spots would be in any sort of cloud, embedded, or SaaS agent where their activity is happening in which a sensor can not be installed.

Framework Level Hooks/SDK

The framework level hooks or SDK installation is primarily used for homegrown agentic workloads. This will give organizations the most visibility and control over agent activity but requires code-level access to the agents. This allows the most granular control of what an AI agent can and cannot do because no matter where this agent is deployed, the security enforcement and visibility will follow. This is great for any agent builder workloads or fully custom LangChain implementation. The blind spots for this approach would be any sort of agent in which an enterprise does not have access to install an SDK, such as embedded SaaS Agents and proprietary agents. This also requires the SDK to be installed on each agent and loses any visibility or control when not adhered to.

Playbook for Technology Leaders

Overall, for any sort of technology leadership or cybersecurity professional, the first step would be to gain visibility and build an inventory of your digital workforce, audit their behavior, harden these workloads through configuration, and then implement runtime protection. While there are currently multiple approaches in the market, most Agentic AI Security solutions will only support one or two of them. Over time, it is anticipated these solutions will have comprehensive coverage, and even the established large vendors will build these capabilities. The challenge is the innovation has accelerated so fast, organizations cannot wait for these platform solutions to be built and must act now.

1. Build your inventory first: You cannot secure what you cannot see. Discover all AI agents across homegrown, SaaS, and local environments, including shadow AI, before implementing any controls.
2. Treat agents like digital employees: Apply least-privilege access, assign clear ownership, and provision autonomous agents with just-in-time permissions rather than standing access.
3. Reduce blast radius through configuration: For each agent, evaluate and restrict what data, systems, APIs, and MCP servers it can reach. Harden settings before layering on additional controls.
4. Layer your security approach: No single vendor covers every vector. Combine platform connectors, network proxies, endpoint sensors, and SDK hooks based on the agent types in your environment.
5. Act now and start with auditing: The market hasn't consolidated yet, so waiting for a perfect solution is not an option. Begin by auditing agent behavior, then gradually enforce policies and build runtime protection from there.

If you’re curious to learn more or want to stay on top of the latest developments in  Innovation, feel free to reach out to us at innovation@trace3.com.