They assume blocking writes closes the problem. In practice, a read-only token can still pull sensitive private content into the agent’s context, and another connected tool or workflow may later move that data outward. Read restrictions reduce one exfiltration path, but they do not remove the underlying trust problem if the session can still ingest private material.
Why read-only tokens still create a trust problem
A read-only GitHub token changes the write path, but it does not change the access path into private material. If a session, agent, or workflow can still read sensitive repositories, issues, or configuration, the token can still feed private content into downstream tooling where later processing, logging, summarization, or handoff may move that data beyond the intended boundary.
That is why “no writes” is an incomplete control objective. The real question is whether the token can be used to ingest anything the caller should not be able to expose, not just whether it can commit, open, or delete anything.
How the failure usually shows up in practice
Teams often scope the token narrowly in one system and assume the rest of the chain inherits that restraint. In reality, the token may be safe in GitHub but unsafe in the connected agent, IDE, chat system, build step, or automation that consumes the content it can retrieve.
This is the same control gap that makes GitHub and GitHub Actions Security Guide valuable reading: repository access, workflow permissions, and downstream tool handling all have to be considered together, not as isolated permission checks. A token that can read private source, secrets-bearing config, or sensitive discussion threads can still become an exfiltration source once another component forwards or transforms what it fetched.
Read-only also creates a false sense of containment when teams look only for direct abuse. A token may never write to GitHub and still expose proprietary code, deployment logic, unreleased roadmap details, or embedded credentials to a connected system that has broader outbound reach than the GitHub session itself.
What teams should verify before they trust a read-only token
First, verify the full data path, not just the GitHub permission set. If the token can reach private content, ask what the consuming system does with that content after retrieval, where it is stored, whether it is indexed or logged, and what other tools can read it later.
Second, separate “can it write back to GitHub?” from “can it expose data elsewhere?” A token with no write privilege can still support data theft, prompt injection, repository reconnaissance, or lateral movement through automation if the surrounding workflow turns retrieved content into new output.
Third, review whether the token is tied to a human workflow or to an autonomous one. When the consumer is an agent or automation, the question is not only access but delegated handling of whatever the token can fetch. That is why the Ultimate Guide to Non-Human Identities matters here: the control problem often sits in the identity and authority attached to the tool chain, not in the token alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Read-only tokens can still expose private content to downstream systems. |
| NHI-05 — Overprivileged NHI | A token with broader read access than needed still increases exposure. | |
| Recommendation — Limit token scope and prevent downstream leakage of retrieved private material. Reduce repository read scope to the minimum required by the workflow. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Connected agents can misuse a token's delegated read authority. |
| Recommendation — Constrain agent access so retrieved content cannot be repurposed beyond intent. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is overbroad access, even when writes are removed. |
| AU-2 — Event Logging | Token use and downstream content handling need auditable visibility. | |
| Recommendation — Apply least privilege to repository read access and connected workflows. Log token access and downstream content transfers for review and response. | ||
Practitioner Guidance
What to prioritise: Treat read scope as only one dimension of exposure. Prioritise the places where private repository content can be copied, cached, summarized, indexed, or forwarded outside GitHub, because that is where the real blast radius usually appears.
What to verify: Confirm whether the token can read any data the downstream system should never see, then inspect every connected tool for logging, memory retention, export paths, and indirect sharing. If those controls are unclear, the token is not meaningfully “safe” just because it is read-only.
Common mistake: Teams stop at permission reduction and skip trust-boundary review. That works only when the token is the final consumer, which is rarely true in agentic or automated workflows.
Practitioner takeaway: Read-only GitHub access reduces one abuse path, but it does not solve the core problem unless you also constrain what the consuming system can retain, transform, and release.