> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Telemetry access controls

> Control which teams can manage each telemetry data source, and who can query it.

Some telemetry holds sensitive data: production databases, security logs, customer records. Access controls let you decide, per data source, who can change its configuration and who can query it, so you can connect a sensitive source without opening it up to your whole organization.

Each data source has two separate controls:

* **Who can manage it**: change its configuration and credentials, edit its access settings, or delete it.
* **Who can query it**: ask questions of it through [the agent](/ai/at-incident) or MCP.

## Who can manage a data source

Managing telemetry data sources requires the **Manage telemetry data sources** permission. By default this is granted to Admins and Owners, and you can grant it to other roles at [**Settings → Permissions → Account-level**](https://app.incident.io/~/settings/permissions). Anyone who holds it account-wide can manage every data source.

You can also hand management of a specific data source to the teams that own it:

1. Assign one or more managing teams on the data source (see [Configuring access](#configuring-access) below).
2. Create a [team role](/admin/team-roles) granting the **Manage telemetry data sources** permission at [**Settings → Permissions → Team-level**](https://app.incident.io/~/settings/permissions/team).

Members of a managing team who hold that team role can then edit or delete that data source, but not anyone else's. Because managing a data source includes changing its access settings, a managing team always has query access too.

## Who can query a data source

Every data source is in one of two query modes:

* **Anyone**: anyone who can query telemetry can query this data source. This is the default, and querying telemetry is part of the **View telemetry** permission that all users hold out of the box.
* **Restricted**: only people with the **Query restricted telemetry** permission can query it. You can grant that permission account-wide through a role, or to specific teams by choosing query teams on the data source and granting the permission through a [team role](/admin/team-roles).

Marking a data source restricted takes effect on every surface a query can come from: questions to the agent (from Slack, the dashboard, or the mobile app), MCP tool calls, and dashboard links the agent is asked to fetch. Someone without access who asks the agent to query a restricted source is told they don't have permission to query it.

<Note>
  Investigations always have access. An investigation runs as the system, not as any one user, so restricting a data
  source doesn't stop investigations from querying it to diagnose an incident. The access settings show this alongside
  your chosen teams and roles.
</Note>

## Configuring access

Open your [telemetry settings](https://app.incident.io/~/nexus/telemetry), select a data source, and click **Update** in the **Access** section. From the drawer you can:

* **Choose teams that manage this data source.** These teams can edit the data source, including its access settings.
* **Choose who can query this data source**: **Anyone**, or **Restricted**.
* **Choose teams with query access**, when restricted. Managing teams are always included and can't be removed.

The section also shows who already has access through account-level roles, so you can see the full picture before you save.

Every data source has its own access settings, and nothing is inherited. If you connect a provider like Grafana or AWS, the data sources discovered behind it are configured individually: restricting the provider doesn't restrict the data sources behind it, and vice versa. Restrict each source you care about directly.

<Note>
  The team settings only appear if your plan includes team roles. The restricted query mode works on its own: you can
  restrict a data source and control access purely through account-level roles.
</Note>

## Permissions reference

| Permission                        | What it allows                                                                                                          |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **View telemetry**                | View and query unrestricted telemetry data sources. Granted to everyone by default.                                     |
| **Query restricted telemetry**    | Query restricted telemetry data sources. Supports team roles.                                                           |
| **Manage telemetry data sources** | View, query, create, update and delete telemetry data sources, including querying restricted ones. Supports team roles. |

For API access, the equivalent [API key permissions](/admin/api-keys#permissions-reference) are **Query restricted telemetry** and **Update telemetry data sources**, both of which can be scoped to teams.

## Audit log

On plans with [audit logs](/admin/audit-logs), what happens to each telemetry data source is recorded alongside your other configuration changes:

* **Connection changes**: connecting or removing a data source, and granting or revoking write access.
* **Access changes**: marking a data source restricted, or moving it back to open querying.
* **Queries**: who queried which data source, one entry per session per data source, plus a complete record with one entry per request we send.
* **Denied queries**: attempts against a restricted data source by someone without access, one entry per attempt, so you can see who tried to access what.

## Related

<CardGroup cols={2}>
  <Card title="Team roles" icon="users" href="/admin/team-roles">
    How team-based permissions work across incident.io.
  </Card>

  <Card title="User roles and permissions" icon="lock" href="/admin/user-permissions">
    Base roles, custom roles, and granting permissions.
  </Card>
</CardGroup>
