Skip to main content
Logging configuration lets you control which AI Gateway requests are logged and redact sensitive content from the logged copy. You define named logging configs that match requests by subject, model, or metadata, and each config decides whether matching requests are logged, and optionally which patterns to redact from the stored request and response.
Logging configuration replaces the global logging settings (Always / Never / Header controlled). See Migrating to logging configs for the mapping from global settings.

​
How logging configs work

Logging configuration consists of a set of independent rules. Each rule defines which requests it applies to and whether those requests are logged. During evaluation:
  1. Every matching rule is checked. The gateway finds all rules whose conditions match the incoming request.
  2. Logging is deny-wins. If any matching rule has Log turned off, the request and response bodies are not logged.
  3. Redactions are merged. When logging is allowed, the redaction patterns from every matching rule are applied to the logged copy.
Think of matching rules as deny-wins for logging: a request body is stored only when every rule it matches allows logging. A single rule with Log off is enough to suppress the body.
Redaction is applied only to the logged copy of the request and response. The live request forwarded to the model provider is never modified.
When no logging config matches a request, the gateway falls back to the per-request X-TFY-LOGGING-CONFIG header behavior. See Request Logging.
Logging Config Rules list showing scope, redactions, and per-rule Log toggle

​
Setting up a logging config

To create a rule, go to AI Gateway → Policies → Logging Config and click Add Rule. The rule form has three parts: a Configuration Name, the Conditions that select matching requests, and the Log and Redaction settings.

​
Configuration name

A unique Rule ID that identifies the logging config within your tenant. Choose a descriptive name like never-log-finance or log-support-with-redaction.

​
Conditions

Conditions define which requests the rule applies to. Add filters with + Add Filters. Filters use AND logic, so a request must match every filter you add.
If you leave conditions empty, the rule matches every request in your tenant. This is useful for a default rule that logs everything.
Logging config rule form showing Configuration Name and Conditions

​
Log decision and redaction

​
Log requests

The Log Requests toggle controls whether requests matched by this rule have their request and response bodies logged. In YAML, this is the log field.
  • ON: matching requests are logged (subject to deny-wins across all matching rules).
  • OFF: matching requests are not logged. The body is suppressed even if another rule would allow it.

​
Redaction

Enable Redaction to remove sensitive values from the logged copy while leaving the live request untouched. You can combine predefined patterns and custom patterns.
  • Predefined Patterns: a catalog of built-in patterns such as email, us_ssn, and credit_card. This is the same catalog used by the Regex Pattern Match guardrail. See the full Preset Patterns reference for every available pattern, its regex, and its default redaction text.
  • Custom Patterns: your own regex patterns with an optional Redaction Text (defaults to [REDACTED]). For example, redact internal customer IDs with pattern cust_[A-Za-z0-9]{12} and redaction text [REDACTED CUSTOMER_ID].
In YAML, backslashes inside a double-quoted regex must be escaped. Write \\d for a digit and \\. for a literal dot. For example, "cust_[A-Za-z0-9]{12}" needs no escaping, but "acct_\\d{10}" does.
Log Requests toggle and Redaction section with predefined and custom patterns

​
Verifying in Request Traces

Logging configuration only controls whether request and response bodies are stored, and redacts sensitive values in the stored copy. Everything else (cost, tokens, latency, and metadata) is always recorded. To confirm a rule is working, open AI Gateway → Request Traces and inspect a matching request. The trace below shows a rule with a custom cust_... pattern and the email preset: the customer ID and email are redacted in both the request and response bodies, while cost, tokens, and latency remain fully visible. Request trace showing redacted customer ID and email with metrics still visible
The root span records tfy.logging.prompt_logging_enabled and tfy.logging.matched_config_names, which lists the rules that matched the request. Use these attributes to trace a logging decision back to the rules that produced it. For programmatic access, see API Access to Logs.

​
Practical examples

Each example shows both the UI configuration and the equivalent YAML. Click Apply as YAML in the rule form to paste or edit YAML directly.
Suppress body logging entirely for a team that handles sensitive data.
How it works: Any request from a member of finance-sensitive matches this rule. Because Log is off, the request and response bodies are never stored.
Log a team’s requests but strip emails and SSNs from the stored copy.
How it works: Support team requests are logged, but any email address or US SSN in the request or response is replaced with its redaction text in the stored copy.
Skip logging for a specific user on an internal model, while a default rule logs everything else. These are two separate rules.
How it works: For that user calling the internal model, both rules match, and deny-wins means the body is not logged. Every other request matches only log-default, so it is logged.
Log production requests and redact internal customer IDs using a custom regex.
Requests must include the header:
Any value matching cust_[A-Za-z0-9]{12} is replaced with [REDACTED CUSTOMER_ID] in the logged copy.

​
YAML configuration reference

Field reference: