Applying ThreatLocker to agentic AI tools

This article reflects the ThreatLocker product offerings and Community Policies available at publication. Because these tools and workflows are changing quickly, the latest implementation guidance, policy details, and deployment recommendations will be maintained in this Knowledge Base article: [ThreatLocker Community Policies for agentic AI coding tools].

Agentic AI tools are here to stay. Tools like Claude Code, OpenAI Codex, and Google Antigravity are already being used to write and review code, automate workflows, manage files, and connect to external systems 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.

That capability is powerful, but it introduces a new attack surface.

The question is becoming not whether to allow these tools, but how to allow their use without giving them unrestricted access to your environment.

ThreatLocker enforces these boundaries through Allowlisting, Ringfencing™, Endpoint Firewall, and Web Content Control, with Community Policies that govern what agentic AI tools can run, do, access, and reach.

Why agentic AI tools need 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-privilege approach. Both frameworks emphasize restricting AI systems to the minimum capabilities required for their intended purpose. Anthropic describes this as Least Agency: granting an agent only the permissions and capabilities required to complete its intended task.

Agentic systems should be restricted not just in what data they can access, but in what processes they can spawn, where they can write, and where they can reach on the network and internet. Most organizations simply don’t have the capability to block these tools. Those using a Default Deny tool such as ThreatLocker can, and do, but many are under increasing pressure to allow them, but to allow them with guardrails in place.

Applying Least Agency in practice

Rather than relying solely on the AI tool's built-in safeguards, organizations can choose to enforce security policies using ThreatLocker.

ThreatLocker offers multiple layers of control. Allowlisting determines which executables are permitted to run, including what sub-processes AI agents are allowed to execute on a system.

Communication boundaries are just as important as execution boundaries. Agentic AI tools routinely connect to model providers, source code platforms, package repositories, cloud services, websites, and MCP integrations as part of normal operation.

Ringfencing controls what approved applications are allowed to do, including application interaction, what data they are permitted to access and where they are allowed to communicate with on the internet.

Secure Network helps organizations restrict communication between devices to only approved ports and services, while ZTNA can be used to allow remote workers access to local resources without needing to expose ports to the internet.

ThreatLocker’s Zero Trust Cloud Access (ZTCA) helps organizations control access to SaaS applications from trusted, managed devices. When paired with a SaaS conditional access policy, ZTCA can ensure access is routed through ThreatLocker’s secure network so only approved devices can reach the application.

Web Content Control helps prevent users from visiting malicious, inappropriate, or unauthorized websites. For agentic AI environments, this adds a user- and browser-level content filtering layer alongside the application-specific internet restrictions enforced through Ringfencing.

Endpoint Firewall provides host-based network controls that can enforce default-deny communication rules, limiting inbound and outbound traffic to approved ports, protocols, and destinations.

Layered together, these controls help organizations answer four critical questions when deploying agentic AI tools:

• Which programs/executables can the tool invoke?
• Which files and data can it access?
• Which systems can it communicate with?
• Which websites and web resources can it reach?

A fundamental principle of Zero Trust is to grant only the minimum access necessary for a specific task. This applies to AI agents as much as to human operators. Excessive Agency occurs when an agent is granted more capabilities than required for its intended task

ThreatLocker enables Organizations to enforce Least Agency principles in production environments.  This reduces the impact of misused or 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. This policy covers Claude Code and the tools it commonly invokes:

• Git, GitHub Desktop, GitHub CLI
• Python, NodeJS
• 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 controlled through Ringfencing.

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.

Note: Optional browser workflow support: Add Chromium Ext Claude (Built-In) only when users need Claude to support browser workflows, such as reading the current webpage, clicking through a site, filling out forms, or sharing browser context with Claude Code. Basic Claude Code terminal use does not require the extension. Test this in Monitor Only and use Unified Audit to confirm whether the extension is needed in your environment.

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, 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, GitHub CLI, GitHub Desktop
• NodeJS, Python

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.

Each MCP server expands an agent's capabilities by providing access to additional data sources or actions. A GitHub MCP server may enable repository access and code modification. A database MCP server may expose sensitive records. Browser automation MCP servers may interact with web applications on behalf of the user.

Each MCP integration introduces a new trust relationship, increasing the data and actions available to the agent. Organizations should evaluate integrations as trust decisions and grant access only to the data and functionality required for the agent's intended purpose.

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.

Shell tooling can vary by environment. Some Windows developer environments rely on Git Bash, PowerShell, WSL, or other shells as part of normal Git and command-line workflows. Review Unified Audit during Monitor Only testing and add organization-specific rules for any shell or development tools your environment requires.

Containerized development workflows may require additional tooling, such as Docker Desktop or Docker Compose. These tools are not required for every AI coding workflow, so organizations should review Unified Audit during Monitor Only testing and add them only where needed.

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.

‍