Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Give a Coding Agent Read-Only Access to One Repository?

Scope a fine-grained token or app installation to that repository with contents read, hand it to an adapter rather than the model, and write the grant as this repository, read only, for this run. Then check what the repository page renders, because read-only access still shows the model the values on it.

A credential reference travels from a browser record through a bounded route to a separate API destination.

For the people who approve agent access, a coding agent that can change a repository is a different risk from one that can only read it, and most teams stop at that distinction. Read-only access to one repository is a permission enforced by the code host: a fine-grained token or an app installation, limited to a single repository, carrying the contents read scope, issued for a named run and closed when the run ends. What that permission does not decide is what the model receives when the agent opens a repository page, a file view or an access settings screen, and a read-only run can still expose far more than the team intended. The grant comes first here, because it is the part a developer can configure today in a code host's settings; what it leaves open is the credentials already committed to the repository, the pages the agent renders while it works, and the routes by which what it read can leave the run. The worked example is a record type rather than an organization, a contents read grant on a single repository, used for one task and closed at the end. The decision a team faces is which token to issue, scoped to what, held by which component, and readable by whom.

Key findings

  • GitHub's token documentation states that "Each token can be further limited to only access specific repositories for that user or organization," and advises that "You should choose the minimal permissions necessary for your needs" (GitHub, Managing, 2026).
  • OWASP's non-human identity list names NHI2 as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," with NHI5 covering overprivileged identities (OWASP, 2025).
  • SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," which is the population a repository read grant reaches (Basak et al., 2023).
  • Wiz reported that "We looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub," so a repository that looks clean is not a safe assumption (Wiz, 2025).
  • A read grant limits what an agent may change, not what it reads, because the model receives whatever the repository page shows (What Is Least Exposure?).
  • Tokens before any model reads the screen, with real values resolving only at the approved destination, keep a read of one repository from becoming a read of everything it holds (How Do You Limit Data Exposure When Deploying AI Agents?).

What does read-only access to one repository actually cover?

A read-only grant is three controls that are usually described as one. The first is the scope the code host enforces: a repository selection plus an operation, contents read. The second is custody, meaning which component holds the credential, whether that is the agent's runtime, an adapter outside it, or the developer's shell profile. The third is what the model receives once the agent is working, which depends on the pages the agent renders rather than on the token.

The record type for this page is a contents read grant on one repository. The token settings page shows the repository selected and the operation set to read. The repository page the agent renders shows the tree, the latest commit and the file it was asked about. The access page shows the token's scope and expiry. Those pages are where a grant becomes visible to a reviewer, and they are worth capturing in a change record.

The layers are not interchangeable. A governed browser environment covers what an agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A clone that runs in a shell sits outside a browser control, and a token pasted into a shell profile sits outside it too. What a governed run provides is a description of authority rather than of capability: it says where the agent may go and what it may do there, and it cannot slip the line back to the person who set it up (What Is a Tethered Agent?).

The answer therefore has two halves. The grant is enforceable at the code host today. The page is where the token stops.

How do you write a grant that names one repository and one operation?

A grant is a record with five fields: holder, repository, operation, lifetime and closure. The holder is the component that uses the credential, not the model's context. The repository field names one repository in full. The operation is contents read, with issues, pull requests, packages and actions left off unless the task needs them. Lifetime is the shortest window the task tolerates, and closure names who revokes it.

GitHub's documentation describes the lifetime field directly: "Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy set by your organization or enterprise owner" (GitHub, Managing, 2026), a default an organization's policy should correct for an agent run. The same page is blunt about the credential itself: "Treat your access tokens like passwords" (GitHub, Managing, 2026), which for a run means issue, use and revoke.

An app installation carries the same fields under a different mechanism: the permission set is chosen per installation, so the grant appears as a page in the organization's settings rather than as a string in a developer's environment. Agent identities follow that shape, starting with limited permissions and governed across their lifecycle, as How Do You Restrict an AI Agent to One Workflow With Microsoft Entra, ServiceNow AI Passport or SailPoint? describes.

A repository read grant is not an access key, and advice about the broadest credentials still applies to the agent's other routes into infrastructure, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? sets out.

What do the vendors themselves say?

GitHub's documentation answers the scope question and is explicit about where a workflow control needs the author to act.

On GitHub secrets in workflows, the page instructs the author to "Mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE" (GitHub, Using, 2026). That is a step a person adds, not a default the platform applies, and an unlisted value in a log line stays in the log. The same page states that "secrets are not passed to the runner when a workflow is triggered from a forked repository" (GitHub, Using, 2026), a boundary set by which repository triggers the workflow.

Push protection sits on the write path, and the page says so: "Push protection acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026). A read-only grant removes the push from the run, so the control has nothing to scan and the credential remains in the history the agent can read.

Dimension GitHub, per its documentation What a buyer should verify
Repository scope Fine-grained tokens can be limited to specific repositories That the agent's token names one repository, not all of them
Operation scope Minimal permissions are advised; classic tokens are called less secure That contents read is the only permission on the token
Lifetime Infinite lifetimes allowed unless a maximum lifetime policy applies That a policy caps the token and the run revokes it
Workflow secrets Masking takes an explicit ::add-mask:: step; fork workflows receive no repository secrets Which workflow steps the agent reads and what they contain
Push path Push protection scans at the time of the push That the read grant has removed the push and left the history readable

What the pages reviewed do not describe is an approver for the token's use or a record of what the token holder read. That is a gap in the documentation, not a finding about the product.

What can a read-only grant still read?

A repository is a store of values as well as code. The first tree an agent reads includes workflow definitions, deploy scripts and the sample credentials inside them, and the grant has no opinion about any of it.

The exposure is common enough to plan for. Wiz reported that "We looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub," and added that "Almost two-thirds of the AI companies analyzed had a verified secrets leak" (Wiz, 2025). The report does not state how many of the 50 lacked a GitHub presence, so the share is a lower bound.

GitGuardian's 2026 report, as carried by CIO Dive, counted about 29 million credentials leaked on public GitHub in 2025, with "AI-service secret leaks rose 81% year over year" (GitGuardian, 2026). Its chief executive said "AI agents need local credentials to connect across systems" (GitGuardian, 2026). The credential is local, so the agent that reads it holds it.

Least privilege does not answer this. The standard answer governs actions and credentials, not the content of the screen an agent reads; an agent can satisfy least privilege in full and still hold every record it was shown (What Is Least Exposure?). Commits co-authored by a coding agent leaked credentials at roughly double the baseline rate, and one count found 24,008 unique credentials in MCP configuration files, as recorded in How Do You Let an AI Agent Manage API Keys Without Reading Them?.

Does a read-only grant stop a hijacked agent from sending out what it read?

No. Read scope limits what the agent may change and says nothing about where content goes after the model has read it. The code host sees a client reading a repository, not the model's next request or the host it chooses.

LlamaFirewall's authors describe "PromptGuard 2, a universal jailbreak detector" and claim it "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches" (Chennabasappa et al., 2025). The abstract gives no quantitative results, so the claim is a direction rather than a rate, and a detector reviews what reaches the model without deciding what it may read.

Egress is a separate boundary. Firecracker's design document states that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026). That is the right posture for a sandbox and a host-level filter, not a permission on the repository: a sandbox that filters egress still lets the model read the rendered page, and the document says nothing about credentials inside the guest.

The controls that bind the action are worth having and are not the same as binding what the model sees. OWASP's excessive agency entry covers a model given more functionality, permission or autonomy than its task requires, which a single login that bundles workflow access with value access produces (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?). A web agent can also be walked into using more of a page than the task needs, as the research on sign-up and checkout flows records (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. For a repository read, the screens are the repository page, the file view and the access settings page the agent opens while it works.

Four properties define it. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works on TOKEN_001 where a credential would sit and the placeholder is stable for the whole run. Real values resolve only at approved destinations, at the moment of an approved action, so a submitted value reaches the page a named person approved and does not travel through the transcript. A named person confirms the tokenization policy and approves each consequential action, which for a read-only run is the grant itself. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

The grant still names the repository and the read operation, because that remains the code host's job. The repository page renders with tokens where the policy put them, so a credential committed inside a workflow block arrives as a placeholder and the question about that workflow still gets answered. The record then answers what a reviewer asks after the token is checked, which is what the model saw while the grant was live.

The limit is stated as plainly as the control. Its scope is the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a clone in a shell and a token in a profile stay with the rules the team sets around that shell.

Methodology and limitations

This page rests on GitHub's token, Actions and push protection documentation, Firecracker's design document, OWASP's non-human identity list, two research preprints, a vendor exposure report from Wiz, a press release carrying GitGuardian's 2026 report, and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them. The Wiz and GitGuardian figures are cited as the companies reported them rather than as independently measured, and the preprints are cited for what their abstract pages state. SecretBench reports no tool evaluation and the LlamaFirewall abstract gives no quantitative results, so neither is cited for a rate.

RedactSure did not test any named product hands-on. A behavior the page calls not described in the pages reviewed is one the reviewed pages did not cover, not a finding that a vendor lacks the feature. Vendor documentation and product behavior change, and the page carries its date, so a reader should treat a release after that date as unreviewed until the grant is tested again. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a contents read grant on one repository, and not an organization.

Determinations about whether a particular grant meets a contractual, regulatory or internal control requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own repository, repeated after each change to the token, the workflow or the code host's permissions model.

What the record shows

For whoever signs off on agent access to a code host, the evidence points one way with a caveat attached. A fine-grained token or app installation limited to one repository with contents read is the smallest grant a code host offers, and the vendor's documentation describes the fields: repository selection, minimal permissions, a lifetime policy. That grant settles what the agent may change. It does not settle what the agent reads, because a repository is a store of values as well as code, and the record on credentials counts true credentials in the tens of thousands and puts a verified leak at almost two-thirds of one AI-company sample. Read scope and read exposure are separate questions, and only the first is answered at the settings page. A single test run shows the gap: name one agent and one repository, issue the narrowest grant the code host allows, then open a repository page in the run and ask what the model was shown in the workflow block, the access page and the file it was asked about.

Frequently asked questions

Can I give a coding agent read-only access to one repository?

Yes. Create a fine-grained token or app installation scoped to that repository with contents read, keep the permission list to that one scope, and give it the shortest lifetime the task allows. Hand the credential to the agent's runtime or an adapter rather than pasting it into a prompt. Then confirm that the token is the only route the run has to the repository, because a second token in a shell profile would make the narrow grant decorative, and the read would not be limited to one repository.

Is a fine-grained token enough on its own?

For actions, usually. It limits the run to one repository and one operation, and the vendor's documentation describes the fields that do it. It does not change what the repository page shows the model, and it does not follow the content afterward. A token in a shell profile is also outside the grant's reach. Treat the token as half the control, test the page separately, and write both results into the same change record, with the date of the run.

What does contents read actually permit?

Reading the code, the history, the workflow definitions and everything else committed to the tree, including credentials that were committed by mistake and never removed. It does not permit a push, a pull request or an issue write, which is why it is the right scope for a review task. The permission is smaller than write access and much larger than the exposure most teams expect when they approve it. A single fixture can hold the keys to a test environment that outlived the test.

Where should the token live?

With the runtime that uses it, or with an adapter outside the agent's process, and not in a prompt, a transcript or a file the agent can open. A token in a file is readable by anything that can read the file, and a token in a prompt is in the model's context for the whole run. Revoke it at the end of the task, then confirm the revocation on the code host's page rather than in a log line.

Does read-only access stop a prompt injection?

No. Injection changes what the agent does with what it has already read, and a read grant is silent on that. Detectors and guardrails can lower the rate at which injected instructions are followed, and the research abstract reviewed here gives no rate at all. The question to settle is what an injection collects when it succeeds, which depends on what the model was shown before it chose an action. A control that limits what the model reads changes that answer.

What should a reviewer ask for before approving the run?

The repository name, the operation, the component that holds the credential, the lifetime and the person who revokes it. Then the page the agent will render and what that page displays. An answer that covers the token and not the page is incomplete, because the token governs what the agent may change while the page governs what the model may read before it proposes anything. Ask for both in the same sentence and see which one the vendor actually answers.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps a Read-Only Grant From Reading Everything

A grant naming one repository and one operation settles what the agent may change, and the controls reviewed never govern what a repository page renders.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent opens the repository page for the deployment workflow, the page renders the registry credential in its environment block, and the model reads the string. Inside the governed environment the same page renders with TOKEN_001, the model answers the question, and the record shows the page as the model saw it.

RedactSure is deploying now with enterprise and government customers. Wiz found verified credential leaks at 65% of the 50 AI companies it examined.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Read-only access still lets the agent read whatever the page displays. Bring a repository question your agent answers and see, with test values, what the model reads and what the record keeps. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.