> ## Documentation Index
> Fetch the complete documentation index at: https://anthale.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Investigate Anthale Policy Hits in Production

> Investigate Anthale detect, redact, and block events using boundary metadata and guardrail evidence to separate attacks, bugs, and tuning issues.

Use this guide when Anthale returns `detect`, `redact`, or `block` and the team needs to decide whether the event was
an expected catch, a false positive, a workflow bug, or a sign that the policy still needs tuning.

The point of investigation is not only to explain one event. It is to make the next policy decision better.

## Investigate the event

<Steps>
  <Step title="Confirm the returned action and boundary">
    Start with the Anthale action and the boundary where it happened. A `block` on final output means something
    different from a `detect` on retrieved context.
  </Step>

  <Step title="Check which guardrail triggered">
    Identify whether the hit came from prompt injection, data leakage, content moderation, topic control, or link
    control. That narrows the remediation path quickly.
  </Step>

  <Step title="Use metadata to locate the source">
    Pull the request, feature, tenant, session, document, or tool identifiers that explain where the content came from.
    This is where good metadata saves investigation time.
  </Step>

  <Step title="Decide whether the event was expected">
    Classify the event as expected malicious content, expected business-policy enforcement, false positive, false
    negative on a neighboring boundary, or an application wiring bug.
  </Step>

  <Step title="Check what the application did next">
    Confirm that your application enforced the returned Anthale action. For `redact`, confirm downstream systems used
    sanitized content rather than the original content.
  </Step>

  <Step title="Record the outcome as a tuning case">
    Save the example if it taught the team something new. The best investigations turn into regression tests, rollout
    decisions, or better boundary metadata.
  </Step>
</Steps>

## Decision feedback and message handling

After each policy enforcement decision, operators can rate the returned action with `like` or `dislike` and add an
optional comment.

Anthale shares the related message content with Anthale employees only when an operator explicitly submits that
evaluation. If no evaluation is submitted, the message is not shared for employee review.

Anthale does not use customer message data from policy enforcement to improve Anthale models. User information remains
encrypted, and employee access is limited to explicit evaluation submissions that include the rating, optional comment,
and related messages.

## Fast triage table

| What you find                                                   | What it usually means                                      | Common next step                                                                     |
| --------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Clear prompt injection or exfiltration attempt                  | The policy caught the right thing                          | Keep the example in the regression set                                               |
| Legitimate user request blocked on the right boundary           | Likely false positive or over-tight policy                 | Tune the policy and retest                                                           |
| Anthale returned `redact`, but raw content continued downstream | Application enforcement bug                                | Fix the boundary handling in code                                                    |
| Hits cluster around one feature, tool, or source                | Boundary-specific risk or noisy integration                | Tighten the workflow or split the policy                                             |
| Team disagrees with a returned action                           | The decision may need policy tuning or boundary refinement | Submit `dislike` with an optional comment and include the case in tuning review      |
| Team wants Anthale employee review of one decision              | Internal review is opt-in through explicit feedback        | Submit `like` or `dislike` for that decision so the related messages can be reviewed |

## Common mistakes

* Looking only at the model prompt and ignoring retrieved context, tool output, or memory.
* Treating `detect` as low priority even when the same pattern repeats.
* Updating one policy immediately without preserving the example for later regression testing.
* Investigating the Anthale hit without checking whether the application mis-handled `redact` or `block`.

## Related pages

* [What Metadata to Send with Anthale Enforcement Requests](/docs/learn/metadata-and-logs/what-metadata-to-send-with-enforcement-requests)
* [Test Anthale Policies Before Production](/docs/learn/policies/test-a-policy-before-production)
* [Roll Out Anthale Guardrails with Detect, Redact, Then Block](/docs/learn/policies/roll-out-detect-then-block)

## Next steps

Continue with [What Metadata to Send with Anthale Enforcement Requests](/docs/learn/metadata-and-logs/what-metadata-to-send-with-enforcement-requests) or [Test Anthale Policies Before Production](/docs/learn/policies/test-a-policy-before-production).