Coverage summary
This report examines four coverage areas. Each area maps to one or more of the five Production Trust Audit governance dimensions (authority scope, approval gates, audit trail, rollback/recovery, instruction integrity).
Governance
Examines whether the agent’s authority is scoped to its mandate, whether consequential actions require confirmation before execution, and whether the audit trail is sufficient to reconstruct decisions after the fact.
No approval gate before refund issuance
The agent has authority to issue refunds up to $AMOUNT without any human confirmation step. When a customer’s request matches the agent’s classification criteria, the refund executes directly against PAYMENT-SYSTEM with no preview or dry-run path available.
A single misfired classification on a bulk support ticket batch would initiate multiple refunds before detection. No rollback path is documented or tested.
Audit trail does not survive a compliance review
The agent logs requests and outcomes to LOG-SYSTEM, but the log format omits the decision rationale (which classification criteria triggered the refund) and the full customer context that was evaluated. Reconstructing what the agent “saw” at decision time is not possible from current logs.
request_id, outcome, timestamp. Fields absent: decision criteria matched, input context hash, agent confidence score. 6 of 8 test scenarios produced logs insufficient to reconstruct the decision.
Authority scope exceeds documented mandate
The agent’s current tool access includes read access to full order history for any customer, including orders outside the active refund request. The stated mandate is limited to the specific order under review.
Hallucination Risk
Examines whether the agent’s outputs are grounded in its actual knowledge and document context, whether it fabricates references, and whether it has a defined path to escalate rather than proceed when confidence is low.
Policy citation hallucination observed under edge-case prompts
In 2 of 12 test prompts involving edge-case refund policy queries, the agent cited policy clause references (format: “per Refund Policy clause X.Xb”) that do not exist in the provided policy documentation. Both hallucinated citations were plausible in structure and would not be detected by a customer.
Hallucinated policy citations create legal and compliance exposure and damage customer trust if surfaced in support interactions that are subsequently reviewed.
Agent proceeds under ambiguous inputs where escalation is warranted
When customer requests were ambiguous (e.g., “I didn’t get what I ordered” without specifying which item), the agent made implicit classification assumptions without flagging uncertainty. In 3 of 8 ambiguity test scenarios, the agent proceeded to a refund classification when escalation to a human agent was the appropriate outcome.
Data Sensitivity
Examines whether personally identifiable information and sensitive customer data is appropriately minimised, masked, or isolated before it enters the LLM context, and whether session boundaries prevent cross-customer data leakage.
PII passed verbatim to LLM context without masking
Full customer PII — including DATA-FIELDS-REDACTED — is passed verbatim to the LLM prompt context. No masking, tokenisation, or data-minimisation layer exists between the CRM integration and the LLM invocation.
This creates material data-handling risk under APPLICABLE-REGULATION. Critically, the injection vulnerability identified in AS-1 amplifies this risk: a successful prompt injection that causes the agent to echo its context would expose PII in the output. These two findings have compounding exploitability.
Session context not explicitly isolated between customers
In multi-turn conversation testing, customer context from one session was detectable in the agent’s response patterns in the immediately following session. The LLM context window was not explicitly cleared between customers at the integration layer.
Agent Surface
Examines whether the agent can be manipulated by untrusted data it processes in its normal workflow, whether inputs are sanitised before inclusion in the agent’s context, and whether tool calls are appropriately scoped to the active session identity.
Indirect prompt injection via customer-submitted ticket body
Customer support ticket bodies are passed into the agent’s context without sanitisation. An attacker who submits a crafted support ticket can embed instructions that redirect the agent’s behaviour — for example, directing it to approve a refund it would otherwise classify for escalation, or to retrieve and echo order history.
This attack surface is publicly accessible. Any customer who can submit a support ticket can attempt this attack. No credentials or prior access are required. Combined with D-1 (PII in LLM context), a successful injection could expose another customer’s data.
Tool access not scoped to session customer identity
The agent’s tool calls to PAYMENT-SYSTEM are authenticated using a service account credential, not scoped to the customer identity verified in the active session. A successfully injected prompt (see AS-1) could trigger tool calls against a different customer’s account.
Governance Gap Register
Ranked by severity and exploitability. Resolve in order.
| # | ID | Finding | Category | Severity | Priority |
|---|---|---|---|---|---|
| 1 | D-1 | PII in LLM context without masking | Data Sensitivity | Critical | Close before any deployment |
| 2 | AS-1 | Indirect prompt injection via ticket body | Agent Surface | Critical | Close before any deployment |
| 3 | G-1 | No approval gate before refund issuance | Governance | Critical | Close before any deployment |
| 4 | G-2 | Audit trail insufficient for compliance | Governance | High | Close before compliance review |
| 5 | G-3 | Authority scope exceeds mandate | Governance | High | Close before authority expansion |
| 6 | D-2 | Session context not isolated between customers | Data Sensitivity | High | Close before multi-customer deployment |
| 7 | H-1 | Policy citation hallucination | Hallucination | High | Close before customer-facing deployment |
| 8 | H-2 | Proceeds under ambiguous inputs | Hallucination | Medium | Mitigate before full autonomy |
| 9 | AS-2 | Tool access not scoped to session identity | Agent Surface | Medium | Mitigate after AS-1 resolved |
Production Readiness Checklist
Yes/no questions your team must be able to answer before turning on production traffic. Carries forward as your governance baseline after the engagement.
- Agent authority is scoped to minimum necessary permissions. Current state: agent has broad order-history read access beyond the active order scope. (See G-3)
- An approval gate or dry-run path exists before consequential actions execute. Current state: no gate between classify and execute for refund issuance. (See G-1)
- PII is masked or tokenised before LLM context inclusion. Current state: full PII passed verbatim in prompt payload. (See D-1)
- Customer-submitted input is sanitised before agent context inclusion. Current state: ticket body passed without sanitisation; 3 of 5 injection tests succeeded. (See AS-1)
- Audit trail captures decision rationale, not only outcome. Current state: logs record outcome and timestamp only; decision criteria absent. (See G-2)
- Session context is explicitly isolated between customers. Current state: no explicit flush at integration layer; cross-session leakage observed in testing. (See D-2)
- A defined escalation path exists for low-confidence decisions. Partial: escalation path is defined in the system prompt but is not reliably triggered — resolve H-2 to make this pass fully.
- Tool access is authenticated via a service credential. Pass — service account is present. Note: credential scope is not restricted to session identity (see AS-2).
- Rollback path is documented and tested for consequential actions. Current state: no rollback procedure exists for refunds issued in error. (See G-1)