> ## 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.

# AI Security Logging Guide

> Capture Anthale enforcement decisions, trust-boundary context, and tool activity so AI security incidents can be tuned, investigated, and audited.

Use this guide when you need Anthale results and agent activity to support tuning, investigation, or audit work. The point of logging is not only to store events. It is to keep enough context that you can explain what happened and why.

## Assumptions

* Your application already emits operational logs or events.
* You can attach metadata to Anthale enforcement requests.
* Your team can review or alert on high-impact runtime events.

## Log the right events

<Steps>
  <Step title="Define one event schema for runtime decisions">
    Capture the Anthale action, triggered guardrails, policy identifier, request identifier, feature name, and the
    boundary that was evaluated.
  </Step>

  <Step title="Keep metadata stable and minimal">
    Use stable identifiers, route names, tool names, and workflow labels. Prefer pseudonymous values over raw personal
    data whenever possible.
  </Step>

  <Step title="Log the Anthale decision and your enforcement result separately">
    Record both what Anthale returned and what your application actually did next. That is how you find cases where the
    policy was correct but the enforcement path was inconsistent.
  </Step>

  <Step title="Capture source and tool provenance">
    Include whether the content came from a user, retrieved context, memory, tool output, another agent, or an MCP
    server. Add the tool or server name when one was involved.
  </Step>

  <Step title="Route alerts by impact, not by raw volume">
    `block` events on high-impact tool paths often deserve faster attention than large numbers of low-risk `detect`
    events.
  </Step>

  <Step title="Review trends and retune boundaries">
    Use the logs to find where the same guardrail hits repeatedly, where a boundary is missing, or where a workflow
    needs a different policy action.
  </Step>
</Steps>

## Minimum event fields

| Field                            | Why it matters                                                                                         |
| -------------------------------- | ------------------------------------------------------------------------------------------------------ |
| `request_id` or trace ID         | Correlates Anthale events with application logs and downstream effects.                                |
| `policy_id`                      | Shows which policy produced the runtime decision.                                                      |
| `boundary`                       | Tells you whether the event happened on input, retrieval, memory replay, tool output, or final output. |
| `source_type`                    | Distinguishes user input from retrieved context, tool output, memory, or MCP content.                  |
| `application_enforcement_result` | Confirms whether your code allowed, redacted, blocked, or retried after Anthale responded.             |

## What this looks like in code

<CodeGroup>
  ```text title="Python" theme={null}
  import logging
  from os import environ

  from anthale import Anthale

  logger = logging.getLogger("anthale.security")
  client = Anthale(api_key=environ["ANTHALE_API_KEY"])
  POLICY_ID = environ["ANTHALE_POLICY_ID"]

  def enforce_and_log(messages: list[dict], metadata: dict) -> str:
  response = client.organizations.policies.enforce(
  policy_identifier=POLICY_ID,
  direction="input",
  messages=messages,
  metadata=metadata,
  )

      application_result = "blocked" if response.action == "block" else "continued"
      logger.info(
          "anthale_enforcement",
          extra={
              "request_id": metadata["requestId"],
              "policy_id": POLICY_ID,
              "boundary": metadata["boundary"],
              "source_type": metadata["sourceType"],
              "anthale_action": response.action,
              "application_enforcement_result": application_result,
          },
      )

      return response.action

  ```

  ```text title="TypeScript" theme={null}
  import Anthale from "anthale"

  const client = new Anthale({ apiKey: process.env.ANTHALE_API_KEY })
  const POLICY_ID = process.env.ANTHALE_POLICY_ID!

  type Metadata = {
    boundary: string
    requestId: string
    sourceType: string
  }

  export async function enforceAndLog(
    messages: Array<{ role: "system" | "user" | "assistant"; content: string }>,
    metadata: Metadata,
  ): Promise<string> {
    const response = await client.organizations.policies.enforce(POLICY_ID, {
      direction: "input",
      messages,
      metadata,
    })

    const applicationEnforcementResult = response.action === "block" ? "blocked" : "continued"

    console.info(
      JSON.stringify({
        event: "anthale_enforcement",
        request_id: metadata.requestId,
        policy_id: POLICY_ID,
        boundary: metadata.boundary,
        source_type: metadata.sourceType,
        anthale_action: response.action,
        application_enforcement_result: applicationEnforcementResult,
      }),
    )

    return response.action
  }
  ```
</CodeGroup>

The important point is to log both Anthale's decision and what your application actually did next. That is what makes
later incident review possible.

## Related pages

* [Metadata and Logs Overview](/docs/learn/metadata-and-logs)
* [Actions and Evaluation Flow](/docs/learn/policies/actions-and-evaluation-flow)
* [Secure Agent Workflows](/docs/learn/secure-ai-systems/secure-agent-workflows)

## Next steps

Continue with [Metadata and Logs Overview](/docs/learn/metadata-and-logs) or [Secure AI Systems Overview](/docs/learn/secure-ai-systems).