I would not throw away the whole note just because one line is hostile. It may contain the only useful description of the failure. But the note is source data. It can tell the model what happened in a past incident. It cannot tell our runtime what tools to call, which destination is authorized, or whether this user's logs may be transmitted.

The attack crosses a specific boundary. Text from a lower trust source is trying to become an instruction with the user's and platform's privileges. Mark the retrieved content with its source, version, and trust level in context. Tell the model to treat embedded commands as material to analyze, not orders to follow. That reduces the chance of a bad proposal, but it is not where I would place the final control.

Suppose the model still proposes upload_logs(url, bundle). The tool boundary checks the real principal, tenant, purpose, data classification, destination, and approval requirement. A global “site allowed” bit is not enough. The URL being approved for tenant B does not give tenant A permission to send private logs there. The gateway should use tenant-specific destination policy and inspect the exact effect, including redirects and the amount of data. If policy has no basis to permit this transmission, deny it and record the attempted action. The agent can continue with safe diagnostic steps or ask an authorized operator.

I would also limit what the tool can receive. A tool named upload_logs that accepts an arbitrary URL and unbounded blob invites this mistake. A safer interface might accept a case ID and a redacted diagnostic artifact, and send only to an organization-controlled destination under an approved workflow. Network egress enforcement matters because a model or plugin could find another path to the same external host. The prompt and tool schema help, but the destination and data checks must survive a prompt that the model misreads.

There are two kinds of eval here. One tests whether the model identifies the injected instruction and still extracts the valid troubleshooting facts. The other forces the model to request the upload anyway and verifies that the tool layer rejects it. Passing the first does not remove the need for the second. OpenAI's agent safety guidance describes indirect prompt injection through untrusted content and exfiltration via downstream tool calls. Its computer-use guidance is similarly explicit that screen or document text cannot grant permission.

The interviewer moves the sentence into a quoted code example. That makes classification harder, not permission broader. A code example may legitimately show a command that uploads logs. The agent can explain why an old runbook used it or quote the relevant steps to an authorized reader. It still cannot execute the command for this user unless the present workflow authorizes the destination, data, and action. I would avoid a brittle rule that deletes every imperative sentence in retrieved material, because it would erase many useful runbooks. Keep provenance and enforce at action time.

Then the interviewer says the incident note was written by our own SRE team. That may make its technical facts more credible, but it does not make it a live policy grant. It could be old, copied, compromised, or intended for a different tenant. If SRE wants a legitimate upload workflow, encode it in the tool and approval contract with a controlled destination. A line in a document is not that contract.