When Context Itself Becomes the Attack Surface

Claude-Red’s AI-security skill turns the project’s central idea inward. It asks what happens when a model receives context from users, documents, retrieval systems, memory, or other agents, and when its response can reach a tool or downstream application. This chapter focuses on that boundary. The reader will learn why instruction and data must be separated, why tool permissions matter more than model fluency, and how provenance, schema checks, egress controls, and human approval keep useful context from becoming unintended authority.

Context has roles and sources

A language model does not receive one undifferentiated stream of meaning. An AI application may combine system policy, developer instructions, a user request, retrieved documents, conversation memory, tool results, and content from a web page or uploaded file. To a human reader, these sources may be visually distinct. To a model, all of them arrive as text or other model-readable signals that can influence the next response.

Claude-Red’s AI-security material treats that mixture as a trust-boundary problem. It asks an assessor to identify which inputs are user-supplied, which are system-supplied, and which come from third parties. For retrieval-augmented generation—often shortened to RAG—it asks about document sources, preprocessing, chunking, embeddings, retrieval policy, tenant isolation, and the way retrieved content is labeled. The purpose is to establish provenance: where did this piece of context come from, who controls it, and what authority should it have?

This distinction explains the difference between direct and indirect prompt injection. A direct injection comes from a user who tries to steer the model away from its intended instructions. An indirect injection is carried inside content the application asks the model to read, summarize, search, or transform. The attacker may not address the model directly. They place instruction-like text in a document, page, message, image, or metadata field and rely on the application to insert that material into context.

The security failure is not simply that a model followed an unpleasant sentence. It is that data crossed a role boundary and was treated as an instruction. A retrieved document should normally be evidence to analyze. If its text can redefine the system’s behavior, it has acquired authority it was not supposed to possess. Claude-Red’s guidance therefore emphasizes “data-only” treatment for external content, provenance tags, and checks that prevent instruction-like material from changing policy.

The same issue appears in the repository itself, although at a different layer. Claude-Red supplies documents intended to influence Claude’s behavior for a selected security surface. That is useful only when the document is trusted, its scope is understood, and its intended role is clear. The fact that a file is formatted as a skill does not make every sentence universally correct, and a document copied into a runtime does not automatically gain permission to use tools or reach systems. Context can guide reasoning without becoming authority.

From a response to an action

Model output becomes more consequential when an application does something with it. A response may be displayed in a web page, inserted into a database query, used to form a file path, passed as an argument to a shell tool, or sent to another API.