Imagine a developer asks a coding agent to investigate a failed deployment.

The agent can read the project directory, inspect source code and configuration files, search the web for troubleshooting guidance, and use the developer’s approved tools. While researching the error, it retrieves a compromised documentation page that tells the agent to collect the project’s configuration files and environment variables, then send them to a “diagnostic endpoint” to validate the deployment setup.

The agent treats that instruction as part of the troubleshooting task. It reads the configuration files, includes sensitive values such as API keys or deployment credentials, and attempts to send them to the external service.

Nothing in this scenario is inherently unusual. The agent is approved. Directory access is required for the task. Web search is a normal part of troubleshooting. The risk doesn’t come from mere access to data and tools, it comes from how those capabilities combine, and from the fact that the agent can act on them without a person reviewing every step.

Why securing local agents is difficult

The scenario above shows exactly why local AI agents such as Claude Code, Codex, and Microsoft 365 Copilot are difficult to secure. They work close to the user, often using the same files, permissions, and tools that make people productive. But traditional controls were built for a human decision-maker who applies judgment before using a permission. Agents can combine access, context, and actions at machine speed.

• The environment is decentralized: The coding agent in this example may be approved, but security may not see every component that shapes its behavior. That includes the directories it can access, the skills it has loaded, the MCP servers it connects to, and the tools it can use. 

• Risk is created by combinations: Each component may be legitimate on its own. The agent needs access to the project directory. Web search helps it troubleshoot. An external diagnostics service may appear useful. The risk appears when the agent combines external instructions with access to sensitive configuration files and an outbound tool. 

• An agent can act without human review: The developer asked the agent to investigate a deployment failure, not to share configuration data. But the agent can interpret the compromised page as part of the task, collect the files, and attempt the external action before the developer sees each step. 

This is not theoretical. In DuneSlide, Cato AI Labs showed how a zero-click prompt injection delivered through an MCP server or poisoned web result could break out of Cursor’s sandbox and lead to full compromise of a developer’s machine. In a separate 2025 incident, a Replit coding agent deleted a production database during an explicitly declared code freeze.

These incidents show why agentic security requires more than a one-time permissions review. Teams need to understand what agents can access, what they can do, and how their capabilities change as users add skills, connect MCP servers, and grant new permissions.

Cato’s three-part framework for securing local agents

An effective local-agent security program begins with three connected questions:

Each stage informs the next. Visibility establishes the inventory. Posture puts the inventory into context by mapping access, permissions, and blast radius. Runtime controls use that context to detect and prevent unsafe behavior in live interactions.

The developer’s failed-deployment scenario creates three security questions.

1. Visibility: What’s in the Environment?

Start with the agent itself. Who is using it? What files can it reach? Which MCP servers, tools, and skills extend its behavior?

In the example, security might know the developer uses a coding agent but not know that it can search the web, access a project directory containing configuration files, or use a connected deployment tool. An inventory of installed applications is not enough. Teams need visibility into the agent’s working environment and the components that define its actual reach.

With this view, the security team can move from asking, “Do we allow this agent?” to asking, “What does this agent connect to, and what capabilities does it bring into the environment?”

2. Posture: What risk does it create?

Next, map the agent’s effective access and potential blast radius.

For the failed-deployment investigation, the agent needs some access to the codebase. But does it also have access to secrets, production credentials, source repositories, or tools that can send data externally? Can an installed skill extend its behavior beyond the task at hand? Can an MCP server introduce untrusted content into the agent’s context?

For every local agent, teams should be able to answer:

• Which directories and files can it access? 

• Which tools and MCP servers can it call? 

• What permissions does it have, and what actions can those permissions enable? 

• Which skills or MCP servers is it using, where did they come from, and what risks do they introduce? 

Each component may be legitimate on its own. The risk emerges when they work together. An agent that can read local text presents a different risk from one that can read configuration files, call external tools, and modify deployment settings.

Posture helps teams decide where additional controls are required before an agent encounters a risky interaction.

3. Runtime control: Can we stop unsafe behavior?

Visibility and posture reduce uncertainty. Runtime control determines what happens when the agent retrieves that compromised documentation page and attempts to act on it.

Effective controls inspect the full interaction in real time: the user’s prompt, the model’s response, tool inputs and outputs, and the action the agent attempts to take. They should recognize when untrusted content is trying to redirect the agent and prevent the unsafe follow-on action.

The response should match the risk. A team may choose to monitor a low-risk interaction, redact sensitive data, block a tool call, or stop the action entirely.

Cato AI Security applies policies across prompts, responses, tool calls, and tool actions. It gives teams one control point, with deployment options across the network, endpoint, APIs, and integrations.

This is particularly important for prompt injection. A malicious instruction can be embedded in content an agent is asked to summarize or retrieve; it does not need to appear in the user’s original request. Runtime controls need to identify that instruction as it enters the agent’s context and prevent the agent from carrying out the unsafe follow-on action.

Shared Context Makes it Operational

Local-agent risk spans users, devices, applications, agents, data sources, and the network. When those views are disconnected, it becomes harder to understand how a risky interaction developed, and slower to investigate or respond.

Security teams need shared context: a way to connect an agent’s activity to its owner, the tools and data it accessed, the permissions behind those actions, and the policy decision that followed. This lets teams move from discovery to investigation to response without rebuilding the story across separate systems.

Cato brings agent security into a single control point, with deployment options across the network, endpoint, APIs, and integrations. This gives security teams the context to see how agents, users, data, and tools interact, and to apply consistent controls before risky activity becomes action. By combining an AI-first security framework with AI-native controls, Cato secures local agents today and the next generation of AI tools tomorrow.

Learn more about securing agentic AI at enterprise scale.

We told everyone to adopt AI, and they did. Almost anyone can now produce polished, professional work in seconds. The newest shortcut behind that speed is skills: small files that hand an AI agent a new ability.

Skills are also where the risk now sits. One file can hold dozens of instructions and actions, so anything buried inside travels with it, and the agent follows all of it without asking. Most of those agents run unwatched, so the speed you gained is now exposure nobody in the business is measuring.

What a skill really is

A skill is a set of written instructions, sometimes with code attached, that gives an AI agent a capability it didn’t have. You install skills to automate steps the agent couldn’t handle before and to shape how it works. Skills are an open standard, and more than 40 agent products already support the format.

Once a skill is installed, the agent pulls it in whenever a task looks like a match, and all you ever see is a name and a one-line description behind a slash command. The instructions themselves load later, on demand, at the moment nobody is looking at them.

Once it runs, a skill has the same privileged space as the agent: your files, your credentials, the services you’ve connected. You installed it to speed up your own work, and it can reach anything your account can reach, including company systems, using instructions you never reviewed.

Inside the malicious skills

One study, “Do Not Mention This to the User”, went through 98,380 skills on public marketplaces and found 157 that were built to do damage, each with capabilities the description never mentioned, including remote script execution, behavior manipulation, and credential harvesting. Installing them takes minutes, and when nothing in the process reads what’s inside the file, the attack enters the business, sight unseen.

The productivity and the risk arrived in the same file.

Where the visibility stops

Most AI security today grades agentic posture: which model an agent runs on, which tools it connects to, and what it’s allowed to touch. That gives you an inventory of what exists. It won’t tell you which skill an agent loaded on Tuesday afternoon, or what that skill told it to do once it was running, and that gap is where discovery stops being enough.

You can secure the model and still never see the skills shaping what it does.

So, has security taken a back seat?

Largely, yes. The fastest-moving part of AI adoption is also the least watched: the skills and tool connections an agent picks up day to day, usually without anyone filing a ticket for them. Adoption outpaced the controls, and that gap is where attackers operate.

Three stages for you to plan

Agents act through tools: an MCP connection to a service, or a skill that hands them a capability they were missing. Every one of those widens what an agent can do inside your business, and adoption keeps adding more. Secure it in three stages: visibility, posture, and runtime protection. Each one is a control you can’t skip, and each is worth more with Cato behind it.

Where you can see it, and stop it

Some of the skills already sitting on your machines do more than they advertise. A skill can execute commands on the device and reach files, credentials, anything that the machine connects to, driven by instructions buried in the file that nobody sanity-checked before it went in. It does the job it promised, and in the same run, it can copy a credential file or call out to a server you’ve never heard of.

This is where Cato helps. Cato AI Security shows which skills your agents have picked up, where each one came from, and what each one does once it runs, so a harmful step gets stopped even when the person who installed it never spotted it. It’s the same dashboard where the rest of your AI usage is already secured.

AI usage inside your business is going to keep climbing, and nobody wants to slow it down. What you need is a live view of which agents are running, which skills and services they’ve picked up, and a way to shut down the action that shouldn’t happen. You can only govern what you can see. That’s where Cato secures your AI transformation.

Claude is moving quickly. Cato is innovating alongside it. With inference hooks, skills posture, and seamless deployment, teams can adopt new AI capabilities with security controls that are ready from day one.

Claude’s rapid innovation is reshaping what everyday employees can do with AI. It is no longer just helping people write faster or summarize information; it is becoming a hands-on work companion that can research, reason, build, and take action across business workflows. But as Claude moves from a chat experience to code, Cowork, skills, MCP servers, and agent workflows, the security question changes too: how can teams adopt those capabilities without creating new blind spots and added risk?

Cato AI Security is innovating alongside Claude. We are building the visibility and inline controls customers need as they put AI to work, so security does not have to catch up after adoption has already moved ahead.

1. Extending AI security to Claude with Inference Hooks

Anthropic Inference Hooks give enterprises a native integration point to inspect and enforce policy before prompts and tool calls reach Claude, regardless which tool is being used. This is important because teams do not work in one environment. They write code in Claude Code, collaborate in Claude Cowork, and use Claude across different workflows and endpoints. Until today, partial solutions have forced security teams to choose where they have controls and where they accept a gap.

Immediately following Anthropic’s recent announcement, Cato AI Security extended its own protection across Claude Enterprise experiences, including Claude Chat, Claude Code, and Claude Cowork, without deploying an endpoint agent or requiring network inline access.

This creates a single point of visibility for prompts, agentic interactions, and tool use, helping security teams monitor activity, apply policies, and maintain an audit trail while preserving a seamless user experience.

Moreover, combining Claude Inference Hooks with Cato’s state-of-the-art AI Engine, battle-tested against AI-native risks such as prompt injection and jailbreaks, brings advanced protection across the Claude ecosystem without disrupting how employees work.

2. Govern the skills, MCPs, and tools that give agents the ability to act

Skills are reusable instruction packages that extend what an agent can do, often by connecting it to tools, data sources, or workflows. Together with MCP servers and tools, they give agents access to data and the ability to take action. However, when employees add these capabilities from the internet, poisoned or malicious MCP servers or skills can influence or manipulate an agent through the instructions or data it returns. This is not only theoretical, in one example, a malicious MCP package impersonated a legitimate Postmark email integration and silently BCC’d emails processed by the agent to an attacker-controlled address.

The risk is not limited to malicious integrations. Vulnerabilities have even been found in Anthropic’s official Git MCP server that, when combined with a legitimate Filesystem MCP, could allow an agent to alter files or execute code following a prompt-injection attack. While Anthropic patched the issues before any reported exploitation, this highlights how individually legitimate tools can create an unsafe path when their combined permissions exceed the agent’s intended task.

To support this new agent risk surface, Cato has added visibility and governance for the capabilities agents use. Security teams can understand the risk each agent introduces, then apply policy across the interaction, not only the first prompt.

• MCP and tool visibility: See the MCP servers and tools available to agents, so security teams can understand the connections and actions that make up each agent’s risk surface.
• Skill visibility and posture: See all the skills in the environment and assess their posture, helping teams identify capabilities that require review before they are used in a business workflow.
• Full-lifecycle policy enforcement: Apply runtime policies to the user prompt, AI response, tool input, and tool output—powered by a state-of-the-art, battle-tested detection engine for AI-native risks such as prompt injection and jailbreaks. Trusted by Fortune 500 companies, it delivers high-fidelity detection at low latency, giving teams one control model for what an agent sees, requests, and does.

Together, these controls help teams govern the information flowing through an agent and the actions it can take, without treating every new tool or skill as a separate security project.

3. Make protection practical to deploy and operate

A security control is not useful if it has to wait for a tenant-wide rollout or leaves the first session on a new device unprotected. Teams also need policy and audit records to show the right client identity, not a subscription identity that obscures who and what acted. And when developers are adopting new agents quickly, security teams need a deployment and troubleshooting path that does not slow them down.

Enforcement has to be practical to deploy, validate, and expand – to enable this, Cato has rolled out the following updates to help teams introduce protection with less friction and more operational control:

• Scoped rollout and accurate attribution: Apply controls to specific users or groups, while using Cato Scout’s client identity to ensure policies and audit records are tied to the correct endpoint user or device.
• Protection before first use: Write hook configuration before a supported agent is detected, reducing the chance that the first session on a new device is outside enforcement.
• Deployment and troubleshooting in the workflow: Push custom Claude Code settings with Scout, install Scout as a native Claude Code plugin, and use scout-debug to verify hook registration inside supported agents.

These improvements turn agent security from a broad switch into a controlled rollout that teams can validate and expand with confidence.

Security controls cannot wait

AI platforms are rolling out features and capabilities quicker than ever before. And employees are adopting these new capabilities – creating blind spots as products are rolled out faster than the controls meant to keep them safe.

Security cannot wait for the next release cycle.

Cato is building and shipping controls right alongside the AI platform development, so security can keep pace as employees and developers put AI to work. Moreover, Cato brings those controls into the same environment teams already use to manage AI security. From a single pane of glass, teams can see AI activity, assess posture, and apply runtime controls across AI usage, applications, and agents. That gives security teams the agility to govern new interactions quickly, with less friction and without adding another tool.

To learn how Cato AI Security secures Claude and the broader AI environment, contact Cato Networks.

Claude is now a part of many employees’ everyday work. But even as a sanctioned application, it creates a visibility problem for security teams. Sensitive data can move into prompts, files, projects, and conversations, and teams need a practical way to see what happened and whether it violates policy.

Today, we’re announcing that Cato AI Security integrates with Claude’s Compliance API, bringing Claude Enterprise activity into Cato for visibility, policy review, investigation, and audit-ready reporting.

The challenge: Approved AI still needs oversight

Many organizations have approved Claude Enterprise for business use, but still face the challenge of governing that usage.

A finance user may ask Claude to analyze an internal forecast. A lending specialist may ask for guidance on whether to approve a loan. A support analyst may summarize customer notes that contain personal information. A product manager may upload an unreleased roadmap to create a presentation.

These normal business workflows are also moments when sensitive data, regulated information, or confidential business plans may be exposed. Security and compliance teams need a consistent way to know what happened, what data was shared, whether it aligns with internal policy, and whether it can be tracked and audited.

What the integration does

Cato connects to Claude Enterprise through the Compliance API and retrieves Claude activity and conversation data for analysis by the Cato AI Security Engine.

The integration is designed to cover Claude Enterprise activity, including chats, projects, users, and activity feed events. Once configured, it helps security teams:

• Monitor how employees use Claude Enterprise
• Collect and retain Claude conversation logs
• Detect policy violations and sensitive data exposure
• Support investigations and compliance reporting
• Clearly attribute events to Claude and Anthropic as the data source

The integration gives teams reviewable security context to understand security events. Instead of treating Claude as a separate workflow, teams can govern its usage from the same place they already manage AI security activity.

Watch the video below to learn how the integration works:

Built into Cato’s broader AI security solution

With this integration, Cato brings Claude activity into a broader AI security model that covers employee AI use, enterprise AI applications, and agentic AI. This allows teams to review Claude activity in the context of user behavior and other AI applications.

The value expands further when Claude activity is combined with Cato’s converged SASE platform. Cato brings together network, security, user, application, and data telemetry in a shared data lake, giving teams richer context for investigation and policy review.

Instead of looking at Claude activity in isolation, teams can connect AI usage to who the user is, what applications they accessed, what data moved, and what other security events occurred around the same time.

How to get started

To connect Claude Enterprise to Cato AI Security:

1. In Claude Enterprise, enable the Compliance API and create a Compliance Access Key.
2. In the Cato Management Application, open Integrations and configure the Compliance API connector.
3. Cato retrieves Claude activity through the Compliance API on a scheduled basis.
4. Cato AI Security analyzes the activity and makes it available for review, investigation, and reporting.

Govern Claude Enterprise without slowing adoption

Organizations should not have to choose between enabling AI and managing risk.

With Cato AI Security and Claude’s Compliance API, teams can approve Claude Enterprise for productive work while maintaining the visibility, policy context, and audit-ready records required for responsible AI governance.

To learn more about Cato AI Security, visit our solution page. To learn more about the Compliance API, visit the Claude Compliance API documentation.

Zero Trust was built to fix an older assumption: if you were inside the network, you were trusted. Then, Cloud, SaaS and remote work broke that, so security moved toward identity, device checks, MFA, least privilege, and continuous verification.

But now, with agents, the messy bit starts after access. The agent reads a prompt, pulls context, chooses a tool, calls an API, and may trigger a workflow. The login tells you the agent is “trusted”. It does not tell you whether the next action makes sense.

Agents inherit the machine identity problem

Security teams have already seen the quieter version of this with machine identities. Service accounts, API keys, tokens, and certificates are created for a project, granted access, and left running long after the project changes.

That pain is familiar: standing privilege, stale ownership, and logs that only get opened after something breaks.

Agents complicate the old problem with judgment. A service account usually follows code. An agent interprets a goal, reads live context, picks a tool, and decides what to try next.

Security now has to cover every system the agent can reach, and any action it is about to take.

Autonomy decides how much control you need

Gartner’s May 2026 note is useful here because it separates two things that often get blurred: how much autonomy an agent has and how much access it holds.

The combination matters. An agent that summarizes documents needs scoped read access and clean logs. An agent that updates records, writes code, or changes workflows needs approval steps, stronger guardrails, monitoring, ownership, and a rollback path.

Gartner’s autonomy ladder is a good place to start: observe, advise, act with approval, act autonomously. Each step should carry more control because the agent is getting closer to a business action.

That is the Zero Trust shift for agents. Identity tells you who is acting. Runtime context tells you whether the action fits the situation.

The policy decision needs the details security usually loses after login: what data is involved, which tool is being called, what instruction shaped the request, and what system gets touched next.

What security teams should do now

Start with a simple inventory. List the agents already in use, where they run, what they touch, and who owns them.

Group agents by where they show up: coding agents on endpoints, managed agents inside SaaS platforms, custom agents built by internal teams, and personal or third-party agents connected through OAuth.

Classify autonomy. Is the agent observing, advising, acting with approval, or acting on its own? Tie that to data access, tools, allowed actions, owner, and approver.

Use autonomy level as the first control boundary, as suggested below:

Scope privilege by action. Give each action its own policy treatment. Reading a record and deleting a record do very different things to the business.

Put guardrails into the runtime path and treat prompts and retrieved content as untrusted input. Check responses before sensitive data leaves and validate tool-call parameters before execution. Require human approval for high-consequence actions such as record deletion, financial movement, bulk communication, or external API calls.

Make the audit trail useful. You need prompts, responses, tool calls, data touched, policy decisions, to understand the outcome. If the agent behaves unexpectedly, security needs enough evidence to stop the next action and explain what happened.

The architecture has to see the action

Security needs a place to inspect the prompt, response, tool call, data movement, and workflow step while the work is happening.

Cato AI Security for Agents fits that point in the flow. It discovers agent activity, governs tool usage and data flows and keeps audit-ready visibility across tools, APIs, data, and workflows.

The value is in the context around the action. When agent behavior sits next to user, application, network, SaaS, and security telemetry, the investigation starts with evidence. Which agent ran. Who owns the agent. What data moved. Which tool was called.

For leaders, that means cleaner governance across users, applications, and agents. For security teams, it means Zero Trust can follow the agent into the work instead of fading after login.

Start with one workflow

Pick one agent workflow that is already in use or close to production. Map the identity, autonomy level, data access, tools, allowed actions, approval points, logs, and rollback path.

That one exercise will tell you where the gaps are. If you can’t see the action, approve it, stop it, or explain it later, the control is too far away.

Zero Trust for AI agents starts after login because that is where the meaningful decision happens: should this action happen, under these conditions, right now?