What should you log and alert on for prompt injection (LLM01)?

Log every input with its source, every tool call with its arguments, every human approval and every refusal. Alert when the model uses a tool the task did not need, touches data outside its scope, or its output stops matching the expected format. You cannot reliably block prompt injection, so you detect and limit it.

What does OWASP say about LLM01?

OWASP's 2025 entry, LLM01 Prompt Injection, says it happens when user prompts alter an LLM's behavior or output in unintended ways, that the input can be invisible to humans, and that retrieval and fine tuning do not fully prevent it. It separates direct injection, where the user's own input changes behavior, from indirect injection, where external content such as a web page or file carries the instructions. It also says severity depends on the business context and how much agency the model has. Its mitigations reduce impact and do not eliminate the risk.

That framing drives logging. If prevention is partial, the record of what happened is what lets you notice and recover.

What belongs in the log?

Inputs, with provenance. For each piece of text the model reads, store where it came from: the user, a file, a web page, a retrieved document. Indirect injection is invisible without this.

Tool calls. Store the tool name, arguments, caller identity and result status. This is where an injection becomes an action.

Approvals. Store who approved a high risk action, when, and what they saw. OWASP recommends human approval for privileged operations.

Output checks. Store whether the output passed the format and groundedness checks you defined. OWASP suggests deterministic code to validate output formats.

Refusals and filter hits. A spike in blocked outputs may mean someone is probing.

Handle the logs as sensitive data. Prompts often contain secrets and personal data, so apply access control and retention limits.

What should trigger an alert?

• A tool call that does not match the declared task, such as an email send during a code review task.
• A first-ever use of a high privilege tool by an agent.
• Data accessed outside the user's normal scope, or unusual volume.
• Output that suddenly fails format validation.
• Instructions found in untrusted content, such as text that tells the model to ignore its rules, when a filter catches them.
• Repeated refusals from one user or one source document.
• Calls to new external destinations.

Start with a few high-signal alerts and tune them. A noisy alert gets ignored.

What to do

1. List every tool each model-backed feature can call, and remove any it does not need.
2. Tag every input with its source and trust level.
3. Log tool calls with arguments, identity and outcome to a store the model cannot edit.
4. Require human approval for privileged actions, and log the approval.
5. Add deterministic output validation and log failures.
6. Define three to five alerts from the list above and assign an owner.
7. Run an adversarial test regularly, treating the model as an untrusted user, as OWASP suggests, and check that the alerts fire.
8. Review retention and access for the logs themselves.

How does Safeguard relate?

Safeguard publishes an MCP server where tenant admins can switch off client types and enable tools per tool, which narrows what an assistant can call. The docs also mention a prompt injection detection setting in the desktop app. Neither replaces your own logging for your own model-backed features.

Quick check

Sources

• OWASP, LLM01:2025 Prompt Injection
• OWASP Top 10 for LLM Applications
• Safeguard docs, MCP
• Safeguard docs, Desktop Application

Last reviewed: 18 October 2026.