Preventing Prompt Injection in a Shared Google Doc from Directing an Agent to Exfiltrate Client Files

The attack path from a shared document to client file exfiltration

Agents that read shared Google Docs ingest text written by people the organization may not control or fully trust. NIST's attack taxonomy calls the underlying capability resource control: an attacker modifies documents or web pages that the model ingests at runtime, which enables indirect prompt injection. OWASP guidance on retrieval systems names Google Drive among the shared knowledge bases where multiple users or systems can upload documents. It also notes that the injected content can be staged entirely outside the target organization's control.

Once the document is in the agent's context, the model may treat its text as instructions. The text can be visible or concealed, for example with invisible Unicode characters or zero-width spaces. The attacker does not need to exploit software, because the agent already holds legitimate tool access. It can read client files and then move them out through email, link sharing, an outbound HTTP request, or a change to file-sharing permissions.

NIST's taxonomy cites research in which injection forced a model to exfiltrate user-uploaded data by querying an attacker-controlled URL with the sensitive data, and research in which an email-client agent was prompted to forward emails to an attacker-controlled inbox. The practical consequence is that a compromised agent context has the blast radius of the permissions the agent holds.

Scope permissions before writing policy

OWASP identifies privilege minimization as the most effective control. Its example is direct: an agent that cannot send email cannot be used to send phishing messages, whatever it is instructed to do. Apply the same reasoning to exfiltration. Inventory every egress-capable tool the agent can call, including email, Drive sharing changes, outbound HTTP, and tools exposed by MCP servers. For each one, ask whether the task requires it. An agent that summarizes shared documents rarely needs to send messages or alter sharing permissions.

The riskiest design combines three things in one session: untrusted content, access to client files, and a path to external destinations. Remove at least one. A common approach is to split the work, so the agent that reads shared documents has no client file access and no egress tools, and any agent with client file access never ingests untrusted documents directly. The tradeoff is more orchestration and less convenience, which is the cost of a smaller blast radius.

Network isolation is the last backstop. Restricting egress from the agent environment limits what a hijacked agent can reach, but isolation and permission controls can fail silently. Consider tripwires so a failure shows up as a signal rather than as a gap you discover later.

Enforce policy on tool calls at runtime

Permission scoping decides what the agent can attempt. Runtime enforcement decides what happens to each attempt. The decision should rest on the proposed operation, its target, its arguments, and the caller's authority, not on the content of the prompt. For example, an email send to an external recipient with an attachment from a client folder should never be decided by whether the model seems to have been given a good reason.

A workable policy returns one of four outcomes for each call:

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, applying allow, redact, block, rate limit, or escalate for human approval. The scope is individual interactions and tool calls, and enforcement happens at runtime, not after the fact. It complements the permission scoping and network egress controls above rather than replacing them.

• Allow: Calls inside the autonomous allowlist, aimed at approved targets with expected arguments.
• Redact: Calls that are acceptable once sensitive fields are removed from arguments or results.
• Block: Calls to unapproved destinations, calls outside the allowlist, or sharing changes the task never requires.
• Escalate: High-impact actions, especially those triggered by externally retrieved content, routed to a human who approves or rejects.

Evidence to retain for each tool call

After a suspected injection event, an auditor or incident responder needs to know what the agent was permitted to do and what it did. Retain the policy configuration in force, including the tool allowlist and egress rules. For each tool call, retain the timestamp, the agent and caller identity, the tool, the operation, the target, and a summary of arguments. Also keep the policy applied, the decision (allow, redact, block, or escalate), and identifiers for the files or data involved. For escalations, record who approved or rejected the action.

Keep security-relevant metadata and decisions, and leave out credentials, secrets, and sensitive prompt or response content that is not needed. Identifiers and classifications are usually enough to show which client files were touched without copying them into the evidence store. Also document residual risk and the layered controls that bound the agent's actions, since no single control removes injection.

Trussed generates audit-ready evidence as a product of enforcement, mapped to HIPAA, NAIC, NYDFS, EU AI Act, and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency.