Security

Violations and alerts

Investigate what your security rules are catching

Every time a security rule matches, whether the action was log, redact, or block, Workforce records a violation. Alerts is where you find out what your rules are actually doing to real employee traffic, which false positives to fix, and what to hand a compliance reviewer.

This page tours that view. For configuring the rules in the first place, see Standard Entity Rules, Custom Regex Rules, and AI Guardrails.

Alerts is not reporting your violations yet

The page reads “Rule violations are not available yet” until Merge connects it to your organization’s violation records. Violations are still written for every detection and are still on the tool call itself, so nothing is lost in the meantime. Ask your Merge contact where your organization stands.

What the page shows

Violations over time, with the total for the window. This is where you spot a spike, confirm that a rule change quieted the noise, or pull a 30-day picture for a security review.

Rule violations breakdown, a share-of-total view by entity type. It tells you which detectors are doing the work, and which one is firing far more than the others, which is usually a false positive rather than a crisis. Click a slice and the whole page filters to it.

The violation table, one row per detection: time, Connector, tool name, entity type, employee, the action that fired, and any tags on the call. Click a row to open the tool call behind it, with its arguments and result, so you can judge in one step whether the match was real.

All three read the same filters, so they cannot disagree about the same window.

Filtering

The filter bar takes date, entity type, tool name, Connector, and employee, and they compose: every entity-type match on one Connector for one employee in the last 24 hours is a single query. Filters set by clicking the breakdown chart land in the same bar, so you can narrow from a chart and then keep going by hand.

The investigation loop

  1. Spot something on the timeseries, a spike or an unexpected baseline.
  2. Read the breakdown to see which entity type is responsible.
  3. Click that slice to filter the table to it.
  4. Open one row to see the underlying tool call.
  5. Read the arguments and the result to decide whether the match was legitimate.
  6. Act. False positive? Tighten the rule. Real? The problem is upstream of the rule.

Most spikes are explainable in two clicks. The page is built for that loop, not for browsing.

Acting on findings

  • Rule too aggressive. Add context keywords on a custom rule, or override the entity on the specific Tool Pack where that data is legitimately allowed, rather than switching the rule off everywhere.
  • Rule too lenient. Broaden the pattern, or move the action from Log to Redact, or Redact to Block.
  • Employee AI misbehaving. A spike is not always a rule problem. If a client is producing tool calls that should not exist, the fix is access rather than detection: narrow the Group in Groups and access, or constrain what the model can produce with a tool description override.

Longer windows and export

Violations are kept for your organization’s data retention window.

For automated forwarding to a SIEM or a warehouse, pull the tool call logs from the log endpoints and filter for redacted and blocked calls. See Stream logs to a SIEM. The log endpoints are an Enterprise feature.

Next

Try a rule against sample input before it meets real traffic with the Guardrail tester.