Read-Only Integration Tokens Explained: Why They Matter for Engineering Analytics Security

TL;DR: A read-only integration token lets an analytics platform read data from version control, project management, CI/CD, and AI coding tools without the ability to create, update, or delete anything. Require read-only access, such as a GitHub fine-grained token with the Contents permission set to Read-only or Jira's read:jira-work scope, and approve write access only when a vendor maps it to a specific, auditable need. minware, an engineering analytics platform, requests read-only permissions for its GitHub app and fine-grained tokens. Where an AI vendor only issues admin-level keys for usage data, an OpenTelemetry integration gives the analytics platform the usage data without any AI vendor credential.

When you connect your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, to an analytics platform, the integration token becomes the security boundary. The same applies to your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, along with CI/CD pipelines and AI coding tools. A write-enabled token can delete repositories, alter tickets, or trigger deployments. A read-only token can read that data but cannot change it.

Engineering analytics platforms read commits, pull requests, tickets, CI/CD runs, and AI usage data. They use it to calculate metrics such as ticket cycle time and deployment frequency. Calculating them never requires writing back to the source system. This piece explains what read-only scopes restrict, which scopes to require for each tool, and how to evaluate a vendor request for write access.

What read-only integration tokens restrict

Read-only integration tokens restrict create, update, and delete operations at the API level, which enforces the principle of least privilege for third-party integrations. The National Institute of Standards and Technology (NIST) defines least privilege in control AC-6. It calls for limiting every user and process to the minimum access needed to perform assigned tasks.

These operations map to specific Hypertext Transfer Protocol (HTTP) methods. A GET request only retrieves data, while POST, PUT, PATCH, and DELETE create, replace, modify, or delete resources. A read-only token permits GET requests and blocks the others.

Enforcement typically happens at the API gateway or authorization layer, which is why the token's scope matters more than what a vendor's interface displays. Scope narrowing is the primary control for third-party integrations. SuperTokens applies the same logic to AI agent credentials with a narrow, never widen rule, where a token can never acquire a permission its parent lacked. An analytics platform that only reads data has no need for write access, so granting it expands the attack surface without a matching benefit.

Why read-only tokens reduce blast radius

Blast radius is the scope of damage a compromised credential can cause. A leaked write-enabled token can delete repositories, rewrite commit history, alter tickets, or trigger deployments to production. Those actions have immediate operational impact, and they can be difficult to detect until the damage is done.

A leaked read-only token exposes data without altering it, which makes the incident easier to contain with rotation and audit logging. It still carries real risk. A read-only repository token can expose source code, including credentials hardcoded in it, so pair read-only scopes with secrets scanning.

Expiration limits the damage further. Token expiration converts an undetected leak from a permanent compromise into a bounded one. Pair read-only scopes with short expiration windows and audit logging that can surface abnormal read patterns.

Which read-only scopes each tool supports

Scope names, expiration defaults, and granularity differ by platform, so verify each tool's current documentation before issuing a token. The table below summarizes the read-only options for the most common engineering tools.

Bitbucket and Azure DevOps, including Azure Boards, have their own token models, so check each vendor's documentation for its read-only options.

Version control scopes

GitHub fine-grained personal access tokens can be limited to specific repositories with the Contents permission set to Read-only. Fine-grained tokens accept an expiration of 1 to 366 days, or no expiration unless an organization sets a maximum lifetime policy. Set the shortest practical window, since a token with no expiry stays valid until someone revokes it. Classic tokens are a poor fit for analytics integrations because the repo scope includes write access to code in every private repository the user can reach.

GitLab's api scope grants complete read and write access to the API. The read_api and read_repository scopes grant read access only. Without a chosen date, GitLab sets token expiry to 365 days from creation. GitLab also offers project access tokens scoped to a single project. Deploy tokens are another option, with scopes chosen at creation, including read-only scopes such as read_repository and read_registry.

Project management scopes

Jira OAuth 2.0 integrations use scopes such as read:jira-work for issue data and read:jira-user for user data. The write:jira-work scope allows creating, editing, and deleting issues, so leave it out of analytics integrations. Jira API tokens expire after 1 to 365 days, with 1 year as the default.

Linear's OAuth flow grants the read scope by default, so decline any additional scopes like write during authorization. Linear migrated all OAuth2 applications to refresh tokens on April 1, 2026, and access tokens now expire after 24 hours. Personal API keys are also available, created in each user's security settings. GitHub Issues data comes through the same GitHub token, with the Issues permission set to Read-only.

CI/CD scopes

CI/CD read-only access covers pipeline runs, deployment history, and job logs without the ability to trigger pipelines, modify configurations, or cancel jobs. Write access here is high-risk because a compromised workflow step can read every secret configured on the repository and may use the GITHUB_TOKEN to write to the repository. An analytics integration usually reads GitHub Actions data through the same GitHub token, with the Actions permission set to Read-only. GitLab pipeline and job data comes through the same read_api scope listed above, so no separate CI/CD token is needed.

AI coding tool usage data

AI coding tools expose usage and token spend data through vendor APIs or OpenTelemetry integrations. Analytics platforms can track AI usage from these tools, then connect it to commit and ticket data.

Read-only support for usage data varies by AI vendor. GitHub Copilot metrics need only a read permission, and Claude Enterprise Analytics API keys carry a read:analytics scope. Claude Console Admin API keys have no selectable scopes, so the key used for the Claude Code Analytics API can also manage members, workspaces, and API keys. Cursor's Admin API separates read:* from admin:* scopes on some endpoints. An admin:* key can also set spend limits or remove team members.

Where a vendor only issues admin-level keys, OpenTelemetry is the alternative. The AI tool sends telemetry to a collector the customer configures, so the analytics platform holds no credential for the AI tool at all. OpenTelemetry is available for tools such as Claude Code and Codex. The tradeoff is that it reports usage only from the point it's configured, so connect it as early as you can.

How to govern integration tokens

Use this checklist to audit current integration tokens and set up ongoing governance.

Token issuance:

• Confirm every integration uses read-only scopes wherever the vendor offers them

• Document the scope names granted to each integration

• Set token expiration to the shortest practical window, for example 30 to 90 days

• Issue tokens from a dedicated service account where the platform supports one, such as Jira service accounts or GitLab project access tokens

• Assign each token to a named owner

Ongoing audit and blast radius assessment:

• Review audit logs on a regular schedule, with real-time alerts for high-risk events

• Revoke tokens immediately after personnel changes or a suspected compromise

• Keep an inventory of active integration tokens with their scopes

• Map which repositories, projects, and pipelines each token can access

• Estimate the impact if each token were compromised

• Prioritize rotation and scope reduction for the highest-impact tokens

How to evaluate vendor requests for write access

Vendors sometimes request write access for setup, webhooks, or status updates. Some of these requests are legitimate, such as creating webhooks to automate incident response, updating pull request statuses for CI/CD feedback, or triggering pipelines for automated deployments. Each maps to a specific, auditable action.

Evaluate every write-access request with three questions:

1. What specific action requires write access?

2. Does a read-only alternative exist?

3. How does the vendor log and audit that access?

If the vendor can't name the action, reject the request. If a read-only alternative exists, require it. For any write scope you do approve, require audit logging and a time-bounded review period.

The scopes that deserve the most scrutiny are the GitHub repo scope, Jira's write:jira-work, GitLab's api scope, and CI/CD pipeline trigger permissions. Audit existing integration tokens for these scopes and replace them with read-only alternatives where possible. Apply the same test to admin-level AI vendor keys. When the vendor's API offers no read-only key, ask whether an OpenTelemetry integration can supply the same data instead.

How minware handles integration credentials

minware's GitHub app and fine-grained tokens request read-only permissions. Claude Enterprise connections use a key with the read:analytics scope. For Claude Console organizations, the Claude Code Analytics API requires admin-level credentials, such as an Admin API key, so teams that want to avoid admin-level keys can connect Claude Code through OpenTelemetry instead. The Cursor integration uses a workspace API token generated by a team or organization administrator, and its active permission scope only requires read-only access to ingest usage data. minware's documentation also lists a classic GitHub token path that uses the broader repo scope, which makes the GitHub app or a fine-grained token the read-only route.

minware operates other controls itself, which customers can verify through its SOC 2 report. API secrets sit in encrypted vaults that only ingest tasks can read. Source code is hashed during ingest and never stored. minware isolates each customer's data in its own schema. minware maintains SOC 2 Type 2 compliance for the security criterion (System and Organization Controls 2, an industry-standard audit framework for security controls), audited for the most recent year ending in September.

For security-sensitive teams, minware also offers an optional on-premise ingest agent. It runs inside the customer's environment and connects to GitHub and Jira with the customer's own credentials, so those API keys never reach minware. For GitHub, give the agent a fine-grained token with read-only permissions rather than the classic token option, which needs the repo scope. The agent collects the same data as a standard connection, so its benefit is access control.

Why read-only access is the right default

Read-only tokens are the main control for reducing blast radius when connecting engineering tools to an analytics platform. They block destructive operations at the API level regardless of UI restrictions or vendor assurances. Require them wherever a vendor offers them, verify each tool's exact scope names against current vendor documentation, and approve write access only when a vendor maps it to a specific need you can verify in audit logs.

To see how minware connects to your tools, start a 14-day free trial at minware.com, no credit card required, and connect your first data source.

FAQs

Can read-only tokens access private repositories?

Yes, once the token has been granted access to the repository. Private repository access requires an explicit grant, such as selecting the repository when creating a GitHub fine-grained token.

What happens if I accidentally grant write access?

Revoke or rotate the token immediately, then issue a read-only replacement. Check audit logs for any modifications made while the write-enabled token was active.

How often should integration tokens be rotated?

Rotate on a fixed schedule, for example every 90 days, and immediately after a suspected compromise or personnel change. The Open Worldwide Application Security Project (OWASP) recommends that you regularly rotate secrets so stolen credentials only work for a short time.

Do read-only tokens expire automatically?

It depends on the platform. GitHub fine-grained tokens default to 30 days and accept up to 366 days. They can also be set to never expire unless an organization policy blocks it. Jira API tokens expire after 1 to 365 days, with 1 year as the default.

Can analytics platforms function with only read access?

Yes. Calculating metrics from version control, ticketing, CI/CD, and AI tool data never requires writing back to those systems. minware's GitHub integration, for example, requests read-only permissions. The limit sits with some AI vendors, which only issue admin-level keys for usage data.

Key terms glossary

Read-only integration token: A credential that lets an application read data from a system without the ability to create, update, or delete it. Enforced at the API level. Also called a read-only API token.

Blast radius: The scope of damage a compromised credential can cause. A read-only token limits it to data exposure, while a write-enabled token extends it to modification, deletion, and pipeline execution.

Principle of least privilege: A security principle that limits every user and process to the minimum access needed to perform assigned tasks. It covers automated processes and system-level accounts as well as human users.

Scope: A permission set that defines what operations a token can perform. Read-only scopes permit reading data. Write scopes permit creating, updating, or deleting data.

OAuth: An authorization framework that lets third-party applications access resources on a user's behalf through scoped tokens.

Service account: A non-human account used by applications or integrations to access resources, configured with restricted permissions to enforce least privilege.

Token rotation: Replacing tokens on a fixed schedule to limit the exposure window if a token is compromised.

Admin API key: A credential that authenticates administrative endpoints, such as usage and cost reporting, distinct from the standard API key used to call the model.

OpenTelemetry: An open-source observability framework for exporting telemetry, such as prompts and tool-use events, from instrumented applications, including AI coding tools, to a collector. Reports at per-prompt, per-session granularity, with no historical backfill for activity before it was configured.

Audit log: A record of operations performed by a token or user, used to detect abnormal access patterns and unauthorized changes.