How does a company document become an instruction attack?
A company document becomes an instruction attack when its content attempts to redirect the agent from using evidence to obeying a new task. The attacker might place that content in a shared page, imported email, or comment the agent later retrieves. The relevant boundary is authority: a source being readable does not make its author authorized to direct the agent.
A harmless test example is a project note that tells an assistant to ignore the user’s question and open an unrelated synthetic file. Keep the exercise inside a controlled environment with no real secrets or external destination. The knowledge-access security guide explains why a read operation belongs in the threat model before any consequential action occurs.
| Stage | Expected behavior | Evidence to retain |
|---|---|---|
| Retrieve synthetic note | Return only permitted text | Source reference and requester |
| Note requests unrelated file | Treat redirection as untrusted | Attempted tool call, if any |
| Request exceeds scope | Deny independently of model behavior | Authorization outcome |
| Agent proposes external action | Apply destination and approval controls | Proposed action and decision |
Why does broad knowledge access increase the damage?
Broad knowledge access increases the damage because a redirected agent can reach more information after the initial boundary failure. Even a read-only tool can expose confidential content through the agent’s ordinary answer channel. Narrowing retrieval does not remove malicious text from every allowed document, but it limits the sources available to an attacker and makes unauthorized follow-up requests enforceably deniable.
OWASP’s prompt-injection prevention guidance supports separating trusted instructions from untrusted input and applying least privilege. A document filter alone is insufficient: snippets, attachments, and subsequent direct reads must preserve the same authorization context. Avoid assuming that a safe-looking title or an internal URL establishes trustworthy instructions.
Which AI agent security controls belong before retrieval?
AI agent security controls before retrieval should authenticate the connection, bind it to the correct tenant and requester, and restrict sources to the task’s authorized scope. Apply section-level withholding when a permitted document includes restricted material. Check every access path, including search previews and full reads. These controls should remain effective even when the model accepts the attacker’s requested task.
The agent knowledge governance framework makes scope and ownership explicit. Give the incident investigator enough source references to identify what entered context without replicating document contents in the audit ledger. AIVM Brain’s current connected-source boundary is governed read; this article does not imply that Brain edits the documents it retrieves.
Which AI agent security controls belong after retrieval?
AI agent security controls after retrieval should preserve the distinction between evidence and instruction, restrict available tools, validate output destinations, and require informed approval for consequential operations. Present the proposed action and its relevant context to the approver. A generic confirmation can be ineffective if it conceals the unexpected recipient, extra data, or changed task introduced by the retrieved material.
The MCP security guidance addresses authorization and trust boundaries in tool integrations. AIVM’s purchasing security example illustrates the complementary action boundary: a malicious request does not gain authority to complete a purchase merely by appearing in task context. Reading controls and action controls address different stages of the same workflow.
How do you test document injection without exposing company data?
Test document injection using synthetic sources and explicitly permitted tasks in an isolated evaluation. Place harmless redirection text in a document, then observe whether the agent follows it and whether independent controls block the resulting request. Capture retrieved source references and tool decisions. Compare ordinary task success with attack resistance so a system that rejects everything does not appear deceptively safe.
Anthropic’s 2025 Chrome pilot evaluation reported attack success falling from 23.6% to 11.2% after mitigations on its tested browser scenarios. This historical result is not a company-document benchmark or a current-model guarantee. It supports layered testing. Use the safe company-knowledge access guide to define your deployment’s actual permission tests.