Injection audit

The injection audit is the Observability view of the Agent Prompts panel. It lists the requests whose system prompt did not come from a published version, so staff can check that published prompts are reaching the callers they were written for.

Open the audit

  1. Open Agent Prompts.
  2. Select the Observability tab. The address carries ?view=observability, so the view can be linked directly.

Switching to Observability drops any selected agent: the audit is global. The panel's other view, Agents, and the publishing flow are covered on Agent Prompts and Agent prompt versions.

What the audit lists

The view states its scope in its intro line: "Requests whose system prompt did not come from a published version - the caller sent no agent, an unknown one, or the proxy fell back to its bundled prompt."

Every row is a finding of one of two kinds:

Embedding requests are left out: they never carry an injected system prompt, so they are exempt rather than listed as findings.

Read the table

Rows load newest first.

ColumnWhat it shows
TimeWhen the request arrived.
CompanyThe company the request belongs to, by name; its id when a name is not available.
Requested agentThe agent the caller asked for; not specified when it sent none.
Resolved agentThe agent the request was resolved to.
OutcomeWhich prompt source served the request.
External IDThe caller-supplied end-user identifier.

While a page loads, the rows already on screen stay visible.

What the outcomes mean

OutcomeMeaning
Stored versionA published version served the request.
Bundled fallbackThe built-in prompt served the request instead.
Not injectedNothing was injected; the request went without an added prompt.

The outcome badge is colour-coded: Stored version as a success, Bundled fallback as a warning and Not injected as an error.

A Bundled fallback row's recorded prompt weight may match no stored version; a mismatch of that kind is one of the things this audit is for.

Filter the audit

Changing either filter starts the list again from the first page. The list pages 100 rows at a time.

Under the Stored version filter you see the callers that sent no agent and were still served a published prompt: the finding is the missing agent, not the prompt.

Questions, answered

Which requests appear in the injection audit?

Two kinds of findings: requests that were not served a published prompt (the built-in prompt served, or nothing was injected), and requests whose caller sent no agent at all. Embedding requests are left out because they never inject a system prompt.

What does "not specified" mean in the Requested agent column?

The caller sent no agent with the request. It reads as its own value on purpose: a missing requested agent is a finding, not a blank.

Why does a request with Stored version appear in the audit?

Because the caller sent no agent. When the request still resolves to an agent whose published prompt serves it, the outcome can read Stored version; the finding is the missing agent, not the prompt. Filter to Stored version to review exactly these rows.

Are embedding requests included?

No. Embedding requests never receive an injected system prompt, so the audit leaves them out instead of flagging every one as a finding.

Does the audit show the prompt text?

No. Each row shows which prompt source served the request, not the prompt's content.

Can a company role be granted access to the audit?

No. The audit is a staff surface: no permission exists that would grant it to a company role.

Why is the list empty?

The table reads No requests missed a stored prompt version. - nothing matched the current filters. Set the filters back to All outcomes and All companies to widen the view. If the read itself failed, the table shows the error message instead; reload the view to try again.

Why does a row show a company id instead of its name?

The audit loads up to 200 companies for the filter and the Company column. A company beyond that list keeps its id in the row.