Applying ThreatLocker to agentic AI tools

AI tools are becoming standard across organizations of all sizes, and their capabilities are quickly expanding. The likes of Claude Code, OpenAI Codex, and Google Antigravity are being used to write and review code, automate workflows, manage files, and connect to external services through MCP integrations.

Newer agentic variants go further: They browse the web, execute commands, spin up local processes, and take actions on behalf of users across multiple systems.

While that’s all genuinely useful, it also presents a new attack surface.

The question we hear most often is how do you allow these tools without giving them free rein over your environment?  

The Allowlisting and Ringfencing™ capabilities available on the ThreatLocker platform answer this problem, and there is a published set of Community Policies that put them into practice for the most widely deployed agentic AI tools.

Why agentic AI tools need additional controls

Traditional software is designed for a specific purpose. A word processor opens documents. A browser renders pages. The scope of what each application does is well defined, and an application control policy can reflect that.

Agentic AI tools are different. When a developer asks an AI coding assistant to build a feature, the tool might spawn a local development server, run a linter against the codebase, invoke an MCP server to interact with GitHub or a database, write files across multiple project directories, and make outbound calls to model APIs during a single session, without a human approving each step.

That execution profile looks less like a traditional application and more like a user with broad system access. OWASP's Top 10 for Agentic Applications identifies Excessive Agency as a key risk category, while Anthropic's Zero Trust for AI Agents framework advocates a least-agency approach. Agentic systems should be restricted not just in what they can access, but in what they can do, where they can write, and what they can reach on the network. Without a dedicated policy, organizations are left with two undesirable options: Block the tool entirely or grant permissions broad enough to undermine the purpose of application control. A scoped, deliberate policy makes least agency enforceable.

ThreatLocker Allowlisting ensures that only explicitly permitted executables can run regardless of what an AI tool requests. Ringfencing adds a second layer by implementing capability restrictions, limiting what permitted applications are allowed to do. This includes controlling which files they can access, which applications they can interact with, and which network destinations they can reach.  

Allowlisting and Ringfencing provide complementary controls that enforce capability restrictions and containment while ensuring only approved tools can execute. Rather than relying solely on the AI tool's built-in safeguards, organizations can enforce security policies through ThreatLocker. This reduces the impact of compromised agents, vulnerable tools, or overly permissive configurations without requiring modifications to the AI tool itself.

ThreatLocker Community policies

ThreatLocker has published the following policies to cover the major AI tools currently in wide use. Each is available in the ThreatLocker Community and can be added to your organization in seconds.

Note: When Ringfencing internet access, entering a parent domain automatically includes its subdomains. For example, openai.com also covers api.openai.com, while googleapis.com covers storage.googleapis.com. During Monitor Only testing, Unified Audit can help identify the specific subdomains required by your environment if you prefer to use narrower domain exclusions instead of the parent domain.

Claude Code and Child Processes

Claude Code is Anthropic's terminal-based agentic coding tool. It can run as a command-line process, spawning child processes to execute tasks, interact with version control, run package managers, and call MCP servers. It also runs inside of the Claude desktop app with a graphical interface. This policy covers Claude Code and the tools it commonly invokes:

• Git, GitHub Desktop, GitHub CLI, Git Bash
• Python, NodeJS
• Docker Desktop
• Bruno (API client)
• Azure CLI

Ringfencing restricts Claude Code from accessing monitored files and paths except where explicit read/write exceptions are defined. The policy allows access to Claude Code’s local .claude configuration files, shell-script files used by Claude Code workflows, and .git metadata used during Git operations.  Application interaction is also restricted to approved tools listed in the policy.

Internet access is also limited to required services and supporting infrastructure, including anthropic.com, claude.ai, claude.com, claudemcpcontent.com, claudeusercontent.com, github.com, githubusercontent.com, storage.googleapis.com, and intercom.io.

Claude Cowork and Hyper-V

Claude Cowork is Claude's task delegation mode in the desktop app, designed for multi-step work across files, tools, and applications. Unlike Claude Code, Cowork runs directly in your environment and requires Hyper-V for certain sandboxed operations. The policy permits both Claude and Hyper-V to cover the full range of tasks Cowork may perform.

This policy is intentionally minimal: It allows Claude and Hyper-V, applies file access restrictions, and runs in Monitor Only mode while organizations assess their Cowork usage. File access exceptions can be added as needed based on the audit log.

Note: Hyper-V is included here specifically because Hyper-V is blocked by default in many ThreatLocker Workstation groups. Removing it from this policy will prevent sandboxed operations from completing, while basic file tools will continue to work.

Codex and Child Processes

OpenAI Codex is a cloud-connected coding assistant with deep Visual Studio Code integration. Its policy reflects a development-tool-heavy profile:

• Git, Git Bash, GitHub CLI, GitHub Desktop
• NodeJS
• Visual Studio Code, Visual Studio Code Codex Extension
• ChatGPT Codex

File access exceptions cover the OpenAI application data directory (appdata\local\openai) and the .codex working directory. Registry access is restricted. Internet access is limited to approved OpenAI and development-related services, including openai.com, chatgpt.com, github.com, and githubusercontent.com. Known OpenAI subdomains used by this policy include api.openai.com, auth.openai.com, and cdn.openai.com.

Antigravity and Child Processes

Google Antigravity is Google's entry into the agentic AI coding space, built on the Gemini platform. Google Antigravity ships as an Electron application with a companion IDE and a CLI (agy). The ThreatLocker Built-In covers these components, including agy.exe, under a single application definition.

The Selected Applications for this policy follow the same pattern as Claude Code and Codex:  

• Git, Git Bash, GitHub CLI, GitHub Desktop
• NodeJS, Python
• Docker Desktop

Ringfencing file access exceptions cover three directories: the .gemini directory where Antigravity stores conversation history and state, the antigravity-updater directory for staged updates, and the Roaming Antigravity directory for app cache and session data. These represent the tool's full data footprint and justify read/write access for app state and cache, conversation persistence, and update staging respectively.  

Internet access is restricted to Google and supporting infrastructure: gemini.google.com, googleapis.com, antigravity-unleash.goog, github.com, githubusercontent.com, googleusercontent.com, gstatic.com, and run.app.

Agentic AI MCP servers

MCP (Model Context Protocol) is an open standard that allows AI to connect to external services, including: databases, cloud platforms, code repositories, communication tools, and more. Agentic AI tools with MCP support will attempt to launch MCP server processes when a connected integration is invoked.

This policy covers 19 MCP server Built-Ins, including:

• Reasoning & data: Sequential Thinking, Context7, Supabase, Sentry, db-mcp
• Cloud & productivity: Azure MCP Server, Microsoft Fabric MCP Server, Google Drive MCP Server, Gmail MCP Server, Notion MCP Server
• Code & files: GitHub MCP Server, Git-MCP Server, Filesystem MCP Server
• Browser & automation: Puppeteer MCP Server, Playwright MCP Server, Chrome DevTools MCP Server
• Search & communication: Brave Search MCP Server, Reddit MCP Server, WhatsApp MCP Server

File access is restricted with no exceptions by default. Organizations should review their MCP usage in Monitor Only Mode before switching to Secured Mode and add file access exceptions as needed based on the audit log.

Note: Not every organization will use every MCP server in this list. The policy is intentionally broad to cover the range of tools in common use. Removing Built-Ins that are not deployed in your environment is a reasonable hardening step.

What is not covered

These policies are designed to be broadly applicable across organizations. They do not try to cover every edge case.

Project-specific tooling is the most common exception. AI coding tools frequently invoke project-local executables, such as Next.js development servers launched through next.cmd or linting tools invoked through eslint.cmd. These binaries are often stored within developer- or project-specific directories, causing paths to vary between users, repositories, and environments. Including those paths in a community policy would either make it too narrow to be broadly useful or too permissive to be safely deployed.

The best starting point is Monitor Only Mode. Review the Unified Audit log for blocked executions and add organization-specific rules as needed. Application Control Learning Mode can help automate discovery during an initial deployment period.

Deploying in your environment

All five policies are available in ThreatLocker Community. The recommended deployment sequence is:

• Add the community policies to your organization from the Community tab.
• Deploy in Monitor Only Mode and let the tools run normally for a period of time.
• Review the Unified Audit log for any executions that would be blocked under Secured Mode.
• Add organization-specific rules to cover any project-local tooling identified in the audit.
• Switch to Secured Mode.

Zero Trust does not mean blocking AI tools. It means knowing exactly what they are allowed to do and enforcing that boundary consistently. These policies give you a starting point that reflects how these tools actually behave in production environments.