Indirect Prompt Injection Mitigation: What Security Architecture Prevents AI Agents from Being Tricked?

Indirect Prompt Injection Mitigation for Secure AI Agents

Overview

The critical security architecture required to prevent AI agents from executing malicious code is the Least Privilege Workspace. This architecture is built on the strict decoupling of procedural logic (Skills), data connectivity (Model Context Protocol, MCP), and contextual containment (Hooks). By enforcing minimal permissions through explicit path allowlisting and Skill-Level Permission Scoping, this design neutralises the Confused Deputy vulnerability, which is the primary vector for successful Indirect Prompt Injection Mitigation. This strategy ensures that even if an agent is tricked by hostile external data, it physically lacks the authority to corrupt core systems or critical brand truths.

Short Answer

• The foundation is a Least Privilege Architecture (LPA), which assumes all external input is hostile and segments the agent's workspace into restricted zones (e.g., Read-Only for configurations).

• Security relies on two key architectural controls: explicit Filesystem MCP allowlisting to control data access and Skill-Level Permission Scoping to restrict tool usage.

• For remote resources, adopt the OAuth 2.1 flow and use short-lived, Read-Only service accounts to prevent a compromised agent from corrupting source data.

Understanding the Confused Deputy Problem in Decoupled AI Architectures

The shift to decoupled agentic systems introduces the "Confused Deputy" vulnerability.

Confused Deputy:

This scenario occurs when an external attacker—who lacks direct permissions—manages to manipulate the AI agent (the Deputy) into misusing its legitimate, high-level privileges. For instance, a malicious website, accessed by an agent with file write permissions, might inject instructions commanding the agent to overwrite a configuration file.

Because the agent has legitimate write permissions and struggles to distinguish between user instruction and data, it executes the payload on behalf of the attacker, compromising the local environment.

The Mechanics of Indirect Prompt Injection from Untrusted Data Sources

Indirect Prompt Injection (IPI): 

This is the method an attacker uses to trigger the Confused Deputy problem. IPI payloads are instructions embedded in external, untrusted data that the agent is tasked to read or process. The agent fetches the data and, lacking the mechanism to fully isolate the data from code, encounters and executes the malicious instruction.

Indirect Prompt Injection Mitigation 

Effective mitigation requires creating logical and physical barriers to ensure the agent's tools are insufficient to carry out destructive commands, regardless of the prompt it receives.

How Do We Implement a Least Privilege Workspace via Filesystem Controls?

Implementing a Least Privilege Architecture (LPA) starts with rigidly segmenting the project workspace into zones of trust:

• Config Zone (READ ONLY): This folder, typically .claude/, should contain critical files like config.json and must be set to read-only access to prevent unauthorized modification.

• Code Zone (READ/WRITE): Contains local scripts and source code (src/).

• Quarantine Zone (WRITE ONLY): Used for initial ingestion of incoming, untrusted external data.

• Artifact Zone (WRITE ONLY): Used exclusively for output files and generated reports (vault-output/).

What is the Filesystem MCP Security Configuration for Explicit Path Allowlisting?

The Filesystem MCP (Model Context Protocol) manages the agent’s interaction with the local file system. Rather than defaulting to broad file access, a secure implementation must explicitly define allowed file paths in its configuration (.mcp.json).

Filesystem MCP: 

This is the tool abstraction layer used by the Claude Code environment for uniform data access across systems.

By omitting sensitive directories, such as the Config Zone (.claude/), from the allowlist, the underlying MCP server rejects any write request to those paths. This hard security boundary ensures that a malicious command attempting Indirect Prompt Injection Mitigation bypasses is blocked at the tool level, regardless of the agent’s internal reasoning.

How Does Skill-Level Permission Scoping Create Sandboxed Execution Contexts?

Skill-Level Permission Scoping: 

This provides the second layer of defence by restricting the execution context of the agent at the procedural logic level (Skills).

In the SKILL.md definition, the allowed-tools directive lists precisely which tools the agent can use when executing that specific skill.

For example:

• A safe-summarizer skill should only be allowed fetch_url and Read.

• The tool list must explicitly omit powerful actions such as Bash, mcp__filesystem__write_file, or Edit.

This mechanism effectively "sandboxes" the skill. If a skill lacks the necessary tool privilege, a command attempting to write a file, even one induced by an Indirect Prompt Injection Mitigation failure, will be rejected by the system because the tool is unavailable in that specific context.

Securing Remote Connections with OAuth 2.1 and Read-Only Service Accounts

For remote data sources—such as accessing the master brand guidelines on a GitHub MCP server—secure architecture mandates leveraging the OAuth 2.1 flow.

OAuth 2.1: This specification ensures that access tokens granted to the AI agent are short-lived and narrowly scoped. This is superior to using long-lived API keys ("God Tokens").

Furthermore, the agent should only be granted Read-Only access to immutable resources, such as the master "Truth Source" repository. This ensures that even if an agent is fully compromised by an IPI attack, it cannot modify the source of brand logic or intellectual property.

FAQ

1. How do I secure Anthropic agents from prompt injection?

   Implement a Least Privilege Architecture that segments your workspace into strict zones of trust. Treat all external data as hostile and isolate configurations and logic from untrusted input. Use explicit tool allowlists (Skill-Level Permission Scoping) to restrict what each agent or skill is capable of executing.

2. What is the primary function of the allowed-tools directive in Skill-Level Permission Scoping?

   The allowed-tools directive explicitly defines the list of tools—such as read, write, or Bash—that a specific skill is permitted to use. This acts as a sandbox, ensuring that a skill designed only for reading and summarising cannot execute file modification tools, even if manipulated by an indirect prompt injection payload.

3. Why is OAuth 2.1 mandated for remote MCP connections?

   OAuth 2.1 ensures that the AI agent uses short-lived, scoped access tokens instead of persistent API keys or "God Tokens". This greatly reduces the security risk, as a compromised agent would only gain temporary, limited access to remote resources, protecting the "Truth Source" repositories.

4. Why is CLAUDE.md considered unsafe for critical governance rules?

   CLAUDE.md content is often treated as part of the initial context and is vulnerable to "lossy compressing" during Claude Code’s context compression cycles. This summarisation can cause immutable truths (like specific brand rules) to be lost, making hooks and external truth sources superior for resilience.

Action steps

1. Mandate the adoption of the Least Privilege Architecture (LPA) blueprint across all AI agent development environments within the organisation.

2. Work with security and engineering teams to audit all custom Skill definitions and enforce Skill-Level Permission Scoping. Ensure no skill has unnecessary write or execution privileges, regardless of its function.

3. Configure the Filesystem MCP for explicit path allowlisting, making the configuration and skill directories (.claude/) strictly read-only to prevent tampering via injected commands.

4. Require all agent connections to immutable brand truth repositories (e.g., GitHub) to use OAuth 2.1 authentication and strictly scoped, Read-Only service accounts.

This analysis is based on the features and capabilities of Claude as documented in late 2025. Please refer to official Claude website for full details as the model continues to evolve.