Docs

Concepts

Action statuses

The five terminal statuses every RenLayer trace ends in, ALLOWED, FLAGGED, DENIED, DLP_BLOCKED, DLP_WARNED, and how to interpret them in the console and the API.

Every action the RenLayer proxy handles ends in one of five statuses. They appear as colored badges in the console, as the status field on every trace in the API, and in the dashboard breakdown chart. Understanding what each one means, and what it does not mean, is the foundation of working with RenLayer effectively.

The five statuses

ALLOWED

The request matched a permissive policy (or no policy at all) and was forwarded to the upstream. The trace records the request, response, latency, and token counts.

This is the expected state for routine traffic. A healthy tenant sees the vast majority of traces as ALLOWED.

FLAGGED

The request matched a FLAG policy. It was forwarded to the upstream, the agent’s behavior is unchanged, but the trace is marked for review and surfaces in the dashboard’s flagged count.

FLAGGED is not a block. Use it for content you want visibility on without disrupting agents (e.g. “flag every prompt that mentions a customer’s name”).

DENIED

The request matched a DENY policy or hit a rate limit. It was not forwarded to the upstream. The agent received a structured 403 (policy) or 429 (rate limit) error.

The trace records the policy or limit that fired. DENIED is the strongest enforcement outcome from the policy engine.

DLP_BLOCKED

A DLP detector matched at a severity that triggers blocking (typically CRITICAL). The request was not forwarded; the agent received a structured 403 with a redacted explanation. The trace records the detector, the matched span (redacted), and the severity.

DLP_BLOCKED is parallel to DENIED but caused by content scanning rather than policy matching.

DLP_WARNED

A DLP detector matched at a non-blocking severity (typically HIGH or MEDIUM). The request was forwarded; the trace records the finding for visibility and tuning.

DLP_WARNED is the equivalent of FLAGGED for content-based detection, informational, not enforcing.

How they combine

A single request is evaluated in this order:

  1. Authentication: fail here returns 401 and no trace is written.
  2. Rate limits: fail here yields DENIED with reason rate_limit_exceeded.
  3. Policies: first matching policy wins (ALLOW, FLAG, DENY).
  4. DLP: runs in parallel with the policy decision; can escalate an ALLOWED to DLP_WARNED or override to DLP_BLOCKED.

The recorded status is the strongest outcome among these stages.

Filtering and querying

In the console:

  • The dashboard breaks all five out as separate series.
  • Sessions can be filtered to any one (or any set) of these statuses.
  • The audit log uses the same vocabulary when describing trace-related events.

In the API:

  • Trace endpoints accept a status filter taking one or more of these values.
  • The status field is stable across API versions.

Where to go next

Last updated: