Guard writes every request it evaluates to an append-only audit trail, whether the decision was allow, deny or monitor. Each event records the method, tool, matching rule, three scores and timing. Events are kept for 90 days by default on a self hosted proxy deployment. Alert rules exist but are described as not wired up yet.
What each event holds
| Group | Fields |
|---|---|
| Identity | Event, organization, agent, server and proxy URL IDs |
| Request | Request ID, method, tool name |
| Decision | Action, rule ID, rule name, deny reason |
| Scores | Risk, jailbreak and anomaly scores |
| Payload | Input parameters and output result as JSON |
| Data handling | PII types detected, fields redacted |
| Outcome | Latency, status code, error message, time |
Because allowed requests are logged too, filtering for denies is a query on a complete record, not a separate log.
Why the three scores matter
The jailbreak score and anomaly score come from request content. The risk score is a weighted blend of the two, 60 percent jailbreak and 40 percent anomaly, capped at 1.0, according to the documentation. Looking at them over time for one agent shows drift that a single block would not.
Querying
The management API offers a list of events, newest first, with filters for action, method and date range, and paging with a default page size of 50 and a cap of 200. There is also an aggregated view built from hourly and daily rollups.
Performance and delay
Audit writes are asynchronous. Guard puts each event on a queue and returns, and a worker batches events into the database, by default every 100 events or every second. A slow audit store does not slow the decision. The cost is that an event can take up to about a second to appear.
Retention
Old events age out through a daily job, with a default of 90 days on a self hosted deployment. If your obligations need longer records, export before they expire. Check with your own compliance owner what retention applies to you.
Privacy of the log itself
The log can hold input parameters and tool output. Those may contain sensitive content. The documentation says stored output is subject to the output filters your policy applies before the response reaches the audit trail. Even so, limit who can read the audit API, and treat the store like any other place sensitive data can land.
Alerts: what is and is not live
The documentation describes alert rule types, such as jailbreak score, anomaly score, blocked ratio and server down, delivered by signed webhook. It also says that no route creates alert rules yet and no running process evaluates traffic against them. Do not plan on alerts until Safeguard says otherwise. Until then, query the audit trail on a schedule.
A weekly review routine
- List denies for the past week and group by rule.
- List monitor events and decide which should become denies.
- Look at the agents with the highest anomaly scores.
- Confirm that deny reasons make sense to the person who sees them.
Pair this with the order of rules in how Guard rules are evaluated.
Quick check
Are allowed calls logged?
Yes. Every evaluated request is logged regardless of the action.
Can I rely on Guard alerts today?
The documentation says evaluation is not wired up yet, so do not rely on them yet.
Sources
Last reviewed: 19 October 2026.
