Skip to content
Mastering Claude

Home / Security and data

Security and data9 minApplication

What an agent can leak without being asked to

An indirect prompt injection hides an instruction inside content the agent reads rather than in what you typed, a generated file has no author who stands behind its content, and a configuration rule that targets a file path is accepted without error while blocking nothing for the tool that runs direct commands, whereas a rule that targets that tool's name blocks it for real.

A hidden instruction inside content that Claude reads, a web page fetched by a tool, an attached file, a comment line in a repository, can make it execute something other than what you typed. This is the same prompt injection the previous lesson describes in relation to a third-party skill, but in its indirect form: the source is no longer an installed package, it is any content fetched during the conversation.

The documented protections, and their stated limit

Claude Code's official documentation names several active protections against this risk: a permission system, contextual analysis, context window isolation for the tool that fetches a web page, and a trust check the first time a repository is opened. The same page states its own limit: these protections significantly reduce the risk, without any system remaining fully immune to every attack.

A rule that reads like a protection and is not one

A setting in the personal configuration file lets you deny access to specific paths for the tools that read or write a file. A publicly documented confusion shows why this setting alone is not enough: the tool that runs direct commands only checks, within the permission rules, for the presence of that tool's name, not the paths actually contained inside the typed command.

{
  "deniedPaths": ["/Users/exemple/documents-prives/**"]
}

This file saves without any syntax error. It does effectively block a file read or write going through the dedicated tools for that. It blocks nothing at all when the same data is reached by a direct command, because the rule targets a path and not the tool's name. This finding, made public, is still classed as a design limitation rather than a flaw to be fixed.

What a generated file never signs

A file produced automatically by a tool, a summary, a knowledge graph, a report assembled from several sources, has no author in the sense of a person standing behind its content. No one feels responsible for checking what it republishes, including a sensitive sentence a tool skimmed through without distinguishing its confidentiality level from the rest. This risk is not specific to one particular product: it is the general flaw of any tool that assembles content without indicating its provenance line by line.

Figure 1

A rule by file path, a rule by tool name

Targets a file path
Rule: deniedPaths contains the private folder.
Command typed: cat documents-prives/contrat.txt
Result: the file's content is displayed.
Targets the tool's name
Rule: the name of the tool that runs commands is denied.
Command typed: cat documents-prives/contrat.txt
Result: command denied, no output.
The difference does not lie in how sensitive the targeted path is but in what the permission check actually verifies: the name of the tool used, never the paths contained inside the typed command.
Calibrate it yourself

A manager adds, in their Claude workspace's configuration file, a rule that targets the path of their private documents folder. The file saves and Claude restarts with this configuration. The next day, they ask Claude to list this folder's content through a direct command sent to the tool that runs commands.

Write in one sentence what this situation establishes, and in one sentence what it does not establish.

What to remember
  • A hidden instruction inside content fetched during the conversation, a web page, an attached file, a comment in a repository, acts like a directive that Claude does not automatically distinguish from a request typed directly.
  • The official documentation itself states that its protections reduce the risk of prompt injection without eliminating it.
  • A configuration rule that targets a file path is accepted without a syntax error and yet blocks nothing for the tool that runs direct commands, only a rule that targets that tool's name blocks it for real.
  • This flaw in the path-based rule is still classed as a known design limitation rather than a fixed flaw, which makes it apply to any current configuration and not just to an old version.
  • A file assembled automatically by a tool has no author standing behind its content, which explains why no one feels responsible for checking what it republishes before passing it on further.
Do this now

Open your personal configuration file, add a sensitive path to the list of denied paths, then ask Claude to access that same path through a direct command rather than through the read tool. Note whether the command goes through or is blocked: that is the only evidence that counts, never just the file being accepted without error.

What still needs checking

These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.

  • The closed, not-planned status of the GitHub advisory cited in this lesson may change: check the issue's page to see whether a fix has since been announced before relying on a rule that targets a path rather than a tool's name.
Check the source

Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.