Many of the most useful endpoint tools are local, and that is what makes them useful.
For a developer under pressure, agentic AI delivered through tools such as Claude Code, Copilot, and Cursor, can deliver a strong productivity lift. But installed tools come with inherent risk, as their use may grant them broad access when used in a normal local workflow.
A laptop used for development is rarely employed for one single task. It likely also contains sensitive information that AI engines should not be able to access.
Does AI running on a user’s desktop need to reach Secure Shell (SSH) keys, API tokens, or environment files? Should it be able to work with unrelated client repositories, cached credentials, or personal files?
The answer is inevitably no. The user needs these, but if an AI coding tool runs with the same permissions, the boundary between the intended project and everything else can become dangerously thin.
AI coding agents can read untrusted content and act on it. A poisoned or somehow ambiguous instruction can become part of the tool’s working context. One of the tool’s inadvertent hallucinations can become part of the project in perpetuity.
If the agent is also allowed to run commands, call other tools, or make network requests, a bad instruction—malicious or accidental—can inadvertently move from text into action.
AI power must be contained
AI tools present a subtle threat even in everyday operations.
Attacked directly, they can be particularly damaging. Security researchers have repeatedly shown how indirect prompt injection can push agents toward unauthorized behavior.
Recent work on development tools running on the AI-standard Model Context Protocol (MCP) found uneven protection across real-world clients, with risks including hidden parameter abuse and unauthorized tool invocation.
Another recent study of AI agents working in integration and delivery pipelines described prompt-injection attacks against live GitHub workflows, including credential exfiltration, configuration manipulation, and availability attacks.
Not every coding assistant is unsafe, but when powerful assistants inherit permissions, they also inherit risk.
In 2026, PocketOS Founder Jer Crane said an AI coding agent working through Cursor deleted a production database and its backups after misreading its environment and using an overly broad token. There was no malice involved—large language models (LLMs) and other AI tools do not currently have any real sense of intentions, and they are notoriously easy to poison—and in this case the agent was not actively trying to disrupt operations.
It simply used its available access, which was created by unsafe human assumptions, and exploited through unwitting AI assumptions.
Why the traditional approval process isn’t enough for AI
A human might ask an AI assistant to “check the config” or “look at the keys for this project.” The tool may then infer the wrong location, follow a misleading instruction, or extend its search more widely than the user intended or expected.
If it can read everything the user can read, an unintended misdirection may allow it to reach sensitive material. If it is granted permission to write or delete, it becomes significantly more difficult to contain.
Traditional approval processes are poorly suited to this problem. Knowing whether an application is reputable, whether the publisher is recognized, or whether the binary appears clean does not cover this potential activity.
Those are valid questions, but it is not enough. AI-enabled tools do not behave consistently by design, so building security around them means determining what they can do and what they should never be allowed to do.
They must be placed within a sandbox, where they can play safely.
Sandboxing AI tools provides freedom within limits
Traditional sandboxing is the practice of isolating suspicious applications, scripts, code, or processes in a controlled environment to analyze their behavior without putting systems or networks at risk.
AI sandboxing creates a controlled virtual environment where agentic AI and LLMs can operate without having full access to host systems, networks, or sensitive data.
It is reasonable to suggest that AI agents only be allowed to run within virtual machines, to keep them air-gapped from production data, but this vastly limits their usefulness and almost defeats the object of using them.
Given that agents are volatile and cannot offer the reliable visibility of flatter software designs, security teams must approach them with the concept of a sandbox in mind—if not the classic sandbox structure.
They must, in effect, build a sandbox from scratch, using the tools and materials at hand. If a code assistant or AI agent cannot be trusted to stay in its lane, administrators must ensure that lane is the only place it can be.
How to contain AI tools with Zero Trust controls
AI agents do not behave like standard software.
They are variable in their nature, so while it might seem reasonable to determine their limits within a testing environment, those limits may change depending on their prompts.
This begins with Allowlisting, to ensure that only authorized software can run on the endpoint; if an agent heads off to try to download and run an unknown or unapproved tool, it will be stopped in its tracks.
Ringfencing™ restricts the agent’s third-party reach, allowing it to interact only in the way administrators feel is safe. Even if it is employing pre-approved tools, the blast radius of any odd or damaging behavior is limited in the same way that it would be at the user level.
Data Storage Access Control is vital to keep data safe, preventing a tool working on one task from roaming into unrelated client data, credential stores, or shared folders. Limiting an agent’s privilege—giving it its own permissions, away from the user level—helps stop administrative convenience from becoming unchecked power.
This DIY sandboxing approach bucks tradition, but it suits the reality of AI adoption.
Businesses cannot be expected to stop experimenting with new endpoint-based tools, because the productivity case is obvious. For security teams to trust these tools, technical boundaries and enforceable controls must be put in place to make the endpoint a safe place for AI agents to play.
