Configure Data Access

Control who can view AI Gateway request traces and metrics using data access rules scoped to users, teams, team applications, or roles.

Data access rules control who can view request traces and metrics in the AI Gateway. Each rule grants a set of subjects (users, teams, or roles) access to a scope of data (their own, their team’s, their team’s applications, or everything) for one or both data types (Traces, Metrics).

Manage rules from Access > Gateway Metrics/Traces > Access Rules.

Access Rules page with the three default rules

How rules are evaluated

• A user can see a record if any enabled rule matches them for that data type. Access is the union of all matching rules, so adding a rule can only widen access.
• Rules are evaluated separately for Traces and Metrics. A rule that grants only Metrics does not expose any traces.
• Disabled rules are ignored.

Because access is additive, restricting what a group can see means narrowing or disabling the broader rule that currently grants it, not adding a new one.

Default rules

Every tenant starts with three rules. They are regular rules, so you can edit, disable, or delete them.

Rule ID	Subjects	Scope	Data types	Effect
default-everyone-own-data	team:everyone	own_data	Traces, Metrics	Every user sees the requests they made.
default-everyone-team-data	team:everyone	team_data	Traces, Metrics	Every user sees requests made by their teammates and by virtual accounts owned by their teams.
default-tenant-admin-all-data	role:tenant-admin	all_data	Traces, Metrics	Tenant admins see everything.

team:everyone is used to match all users, but it is never treated as a team for data scoping. A team_data rule gives access only to the real teams a user belongs to, not to the whole organization.

Data scopes

Scope options when adding a rule

Scope (UI)	YAML value	What the subject can see
Own Data	own_data	Requests made by the user themselves (with their personal access token or UI session).
Team Applications Data	team_virtual_account_data	Only requests made by virtual accounts owned by the user’s teams.
Team Data	team_data	Requests made by teammates and by virtual accounts owned by the user’s teams.
All Data	all_data	All requests in the tenant, optionally narrowed with filters.

Team data vs team applications data

Both scopes are resolved from the teams the user belongs to. The difference is whose requests they include:

• Team Applications Data covers only traffic from applications, meaning virtual accounts whose owner is the team. Teammates’ personal requests (for example, prompts sent from the Playground or with a personal access token) stay private.
• Team Data covers the same application traffic plus every teammate’s personal requests.

Use Team Applications Data when members need to debug and monitor their team’s services but should not read each other’s prompts. Use Team Data when the team is comfortable sharing all activity, or for people who oversee the team, such as team managers.

Team scopes depend on virtual account ownership. When you create a virtual account, set Owner of the Virtual Account to the team that runs the application. See Virtual Account management.

Create a rule

1. Open the form

   Go to Access > Gateway Metrics/Traces > Access Rules and click Add Rule.

2. Name the rule

   Enter a Rule ID (for example, team-managers-team-data) and an optional description. The ID must be unique and start with a letter. It can contain letters, digits, ., _, and -.

3. Select subjects

   Pick one or more users, teams, or roles. Use the Roles tab to target roles such as tenant-admin or team-manager.

   

   Selecting a role as the rule subject

4. Choose data types and scope

   Select Traces, Metrics, or both, then pick a scope. For All Data, you can turn on Set Advanced Filters to narrow access.

5. Save

   Click Save. The rule takes effect immediately.

Filters for all data

With the all_data scope, you can add filters to limit access to a slice of traffic. Multiple filters must all match.

Filter	Matches on	Operators	Example
Metadata	A key sent in the X-TFY-METADATA request header	IN, NOT_IN	application_name IN [support-agent, customer-chat]
Created By	The user, team, or virtual account that made the request	IN, NOT_IN	created_by IN [team:support]

All Data scope restricted to two applications with a metadata filter

SaaS gateway location metadata (tfy_gateway_region, tfy_gateway_zone) can also be used in metadata filters. See Metadata Keys.

Common use cases

Give team managers access to their team data

To let team managers review everything their team sends through the gateway, create a rule with the team-manager role as the subject and Team Data as the scope.

Rule granting team managers access to their teams' data

- id: team-managers-team-data
  description: Team managers can access traces and metrics of the teams they manage
  subjects:
    - role:team-manager
  data_types: [traces, metrics]
  scope: team_data
  enabled: true

A team-scoped role only grants data for the teams where the user holds that role. A user who manages payments and is a regular member of platform gets payments team data from this rule, not platform.

Team-scoped roles such as team-manager cannot be combined with the all_data scope. Use team_data, team_virtual_account_data, or own_data.

Keep teammates’ prompts private

The default default-everyone-team-data rule lets every member read their teammates’ traces. To limit members to their team’s application traffic while managers keep full visibility:

1. Edit default-everyone-team-data and change its scope to Team Applications Data (team_virtual_account_data).
2. Add the team manager rule above.

Members still see their own requests through default-everyone-own-data.

Share team dashboards without exposing traces

Grant a team Metrics only. Members can see usage and cost dashboards for the team without reading request or response content.

- id: platform-team-metrics
  subjects:
    - team:platform
  data_types: [metrics]
  scope: team_data
  enabled: true

Give a team access to specific applications

Use all_data with a metadata filter, for example so a support team can see all traffic from support applications regardless of who made the request.

- id: support-team-support-apps
  subjects:
    - team:support
  data_types: [traces, metrics]
  scope: all_data
  filters:
    - field: metadata
      key: application_name
      operator: IN
      value: [support-agent, customer-chat]
  enabled: true

Requests must send the key in the X-TFY-METADATA header, for example X-TFY-METADATA: {"application_name": "support-agent"}.

Manage rules as YAML

Click the menu next to Add Rule and select Edit as YAML to view or edit all rules at once. You can also apply the same manifest through the CLI or GitOps.

type: gateway-data-access-config
rules:
  - id: default-everyone-own-data
    description: 'Default rule: Users can access their own data'
    subjects:
      - team:everyone
    data_types: [traces, metrics]
    scope: own_data
    enabled: true
  - id: default-everyone-team-data
    description: 'Default rule: Team members can access their team data'
    subjects:
      - team:everyone
    data_types: [traces, metrics]
    scope: team_data
    enabled: true
  - id: default-tenant-admin-all-data
    description: 'Default rule: Tenant Admins can access all data'
    subjects:
      - role:tenant-admin
    data_types: [traces, metrics]
    scope: all_data
    enabled: true

Field	Required	Description
id	Yes	Unique rule identifier.
description	No	Human-readable purpose of the rule.
subjects	Yes	List of user:<email>, team:<team-name>, or role:<role-name>.
data_types	Yes	traces, metrics, or both. Defaults to both.
scope	Yes	own_data, team_virtual_account_data, team_data, or all_data.
filters	No	Only for all_data. Each filter has field (metadata or created_by), operator (IN or NOT_IN), and value (a list). Metadata filters also need key.
enabled	No	Set to false to keep a rule without applying it. Defaults to true.

Best practices

• Review the defaults first. Out of the box, every member can read their teammates’ traces. If prompts can contain sensitive data, switch default-everyone-team-data to team_virtual_account_data or to Metrics only.
• Assign virtual account owners. Team scopes only include applications whose virtual accounts are owned by the team.
• Use roles instead of individual users. role:tenant-admin and role:team-manager stay correct as people join, leave, or change teams.
• Grant the narrowest scope that works. Prefer own_data, team_virtual_account_data, or team_data over all_data, and always add filters to all_data rules for non-admins.
• Separate Traces from Metrics. Traces contain request and response content, while Metrics do not. Grant Metrics broadly and Traces only where needed.
• Disable before you delete. Toggling a rule off lets you confirm nobody loses needed access, and deleting a rule revokes access immediately.
• Use descriptive IDs and descriptions so the purpose of each rule is clear during audits.

Troubleshooting

A user can't see data they expect

• Confirm a matching rule is enabled and includes the right data type.
• For team scopes, confirm the user is a member of the team and, for application traffic, that the virtual account is owned by that team.
• For role:team-manager rules, confirm the user is a manager of that specific team.
• For all_data with filters, confirm requests actually carry the metadata key and value.

A user can see more than expected

Access is the union of all matching rules. Check the default rules, especially default-everyone-team-data, and narrow or disable the broader rule instead of adding a new one.

Saving a rule with the team-manager role fails

Team-scoped roles cannot be used with all_data. Change the scope to team_data, team_virtual_account_data, or own_data.