How does Guard know which workspace an agent is working in?

Guard uses the project root directory and the workspace configuration (pnpm-workspace.yaml, lerna.json, or turbo.json) to determine workspace boundaries. Files outside the current workspace root are flagged for review.

What if my agent legitimately needs to read files from another workspace?

Guard can be configured with an allowlist of directories the agent can read across workspace boundaries. This is useful for shared config files or type definitions, while still blocking reads of .env and credentials.

medium severityCurated advisory

Cross-workspace credential leak via monorepo traversal

AI agents in monorepo environments can read credentials, configs, and secrets from adjacent workspaces — leaking data across team boundaries.

Protect my harness Protect a team

Affected surfacesmonorepo workspacesshared config filesteam credentialsadjacent project directories

The attack

What happens

In a monorepo, an agent working on one workspace can read files from adjacent workspaces — including .env files, service account keys, and proprietary code belonging to other teams.

Step by step

How the attack unfolds

1Developer asks agent to work on a file in packages/api-service/.

2Agent reads the target file, but also traverses to packages/auth-service/.env to "understand the auth configuration".

3The .env file in the auth-service workspace contains secrets for a different team.

4Those secrets enter the context window and may be sent to the model API or logged in telemetry.

Example

What it looks like in practice

Scenario

A developer working in packages/web-app/ asks Claude Code to fix a routing bug. Claude reads the routing file, then reads packages/api-service/.env to understand the API endpoint configuration. The .env file contains the production database URL and API keys for the API team — data the web app team should not have access to.

Detection

How Guard catches this

Guard enforces workspace boundaries by flagging reads of files outside the current workspace root.

Guard alerts when an agent reads .env files in directories outside its workspace.

Guard Cloud maintains an inventory of workspace boundaries and alerts on traversal attempts.

Mitigation

How to stop it

Recommended action

Configure Guard to enforce workspace boundaries. Block reads of files outside the current workspace root. Use per-workspace .env files instead of shared root-level credentials.

Guard configuration

Enable "Workspace boundary enforcement" to block reads of files outside the current workspace.

Enable "Cross-workspace .env detection" to alert when an agent reads .env files from other workspaces.

Enable "Monorepo traversal tracking" to flag when an agent reads files from more than one workspace.

FAQ

Common questions

Related advisories

More threats to know about

critical

Environment file exfiltration via webhook

AI agents can be tricked into reading .env files and sending their contents to external endpoints through tool calls, webhook integrations, or HTTP requests that appear legitimate.

Read advisory

medium

Context window scraping via long file reads

AI agents that read large files can leak proprietary code, internal documentation, and customer data into their context window — which may then be sent to external LLM APIs or logged in cloud telemetry.

Read advisory

Stop this threat before it reaches your agent

Install HOL Guard to get real-time protection against this attack and others like it.

Install HOL Guard See team plans