When a Document Tries to Give Orders: Layered Protection for AI Agents

An employee asks an AI assistant to summarize a supplier proposal. Inside the document, an attacker has placed instructions telling the assistant to retrieve internal pricing and send it to an external destination.

The employee requested a summary. The document is trying to create a new assignment.

This is a hypothetical example of indirect prompt injection: instructions arrive through content the AI system is processing rather than through the authorized user's request. OWASP identifies this risk and recommends combining controls such as privilege restrictions, output validation, filtering, and oversight. No single filter should be treated as a complete solution. OWASP: Prompt Injection

The practical objective is to prevent untrusted content from acquiring operational authority. Marking a document as untrusted can help the model interpret it, but an instruction to “ignore malicious content” does not replace controls over what the application can execute.

For the supplier workflow, I would make summarization possible without giving the assistant access to internal pricing or an external sending tool. A compromised summary process would then have fewer ways to cause harm. If another workflow requires those capabilities, give it separate permissions and explicit approval conditions.

Runtime protection should follow the actual path of the data and actions. Inspect incoming material before it enters the model context when that boundary needs protection. Validate a proposed tool call before execution. Check returned tool data before passing it to the model where the application requires that safeguard. Review outgoing content before delivery to its destination.

Placement determines what a control can accomplish. An inspection performed after a model has received sensitive information cannot undo that disclosure. A gateway cannot inspect a direct connection that bypasses it. Draw the routes, including local tools, background jobs, and external APIs, before claiming coverage.

Consider an authorized operation that creates a supplier record. The application should validate field types, permitted values, tenant ownership, and the caller's authority. For an external message, inspect the actual recipient and attachment selection. These checks constrain execution even when the proposed action sounds reasonable in natural language.

Content inspection adds another source of evidence. It can identify suspected injection, sensitive information, or policy violations, but requires evaluation for both missed threats and unnecessary blocking. Decide how the workflow behaves if an inspection service is unavailable. For a consequential action, pausing for review may be preferable to proceeding without the required check.

Human approval should bind to a concrete action. Show the recipient, content, data involved, and expected effect. If those details change after approval, require a new decision where the change affects risk. A vague approval to “continue” offers little protection against a materially different operation.

Cisco positions AI Defense as a runtime protection component; DefenseClaw describes itself as an enforcement and evidence layer with scanning and inspection integrations. These tools need deployment-specific coverage and policy validation. Their presence does not establish universal blocking of every attack. Cisco architecture, DefenseClaw

A useful test is to place a harmless simulated malicious instruction in a test document and observe the complete workflow. Success means the intended task remains useful while unauthorized access or execution is prevented and recorded.

The boundary that matters is where a model's suggestion becomes a real-world action.