What Is the Difference Between Scoping a Token and Scoping an Agent?

A personal access token is scoped once and then works wherever it is carried. An agent is scoped at the moment it acts, against the request it makes and the place the result goes. Those are different objects, and the difference explains a common finding in review: a team can hold a well-scoped credential and still be unable to say what its agent asked for or where an answer landed. This means a review that checks only the token cannot answer for the agent. The record is a repository's token settings page, where a new credential appears in a dialog and its limits are checkboxes rather than code: one repository or all of them, a permission menu, an expiry date. The same token is read twice, once limited only by the scope written on it and once limited by a grant that also names an operation and a destination. GitHub and Firecracker document their own controls in detail, yet a scope on a credential cannot settle what a model reads or where a value may travel, and a grant adds those limits. The distinction is practical: the two controls are enforced by different components, fail in different ways and leave different records, so a team should review both.

Key findings

• A benchmark of attacks and defenses across agent operation stages reports "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," which is the case for scoping the request and not only the credential (Zhang et al., 2025).
• OWASP's non-human identity list separates credential leakage, the "leakage of sensitive NHIs such as API keys, tokens" from overprivileged identities, and a token scope governs the second more directly than the first (OWASP, 2025).
• GitHub's token documentation says to "Treat your access tokens like passwords" and that a fine-grained token can be "limited to only access specific repositories," a limit on where the credential works, not on what a model reading the token page receives (GitHub, Managing, 2026).
• Wiz's review of 50 AI companies concluded that "Almost two-thirds of the AI companies analyzed had a verified secrets leak," the outcome a credential in reach of a model or a log produces (Wiz, 2025).
• A token scope names what the credential may do, while an agent scope names what the agent may ask for and where the result may go, two different questions that one key cannot answer (What Is a Tethered Agent?).
• Replacing values with tokens before any model reads the screen, and resolving real values only at the approved destination, is the pair of properties a token scope cannot express on a rendered page (What Is Least Exposure?).

What is the difference between scoping a token and scoping an agent?

The scope of the environment comes first, because the two words in the title point at different layers. A governed browser environment covers what the agent reads and does on a rendered page: 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 token is usually presented where such an environment does not reach, so the comparison has to be drawn carefully.

A token scope is a property of the credential. It says what the credential may do, on which repositories or resources, and for how long, and it travels with the credential wherever the credential is presented; enforcement belongs to the service that accepts the token. An agent scope is a property of the run. It says what the agent may ask for, which resource the request may touch, which operation it may perform and where the result may go, and it is enforced by the environment the agent works in. The first limits a key. The second limits a request.

The record for this page is one token under two scopes: the same newly issued credential, read once where only the scope written on it applies, and once where a grant also names an operation and a destination. The page is a repository's token settings page, where the new value appears in a dialog and the limits are checkboxes, and an agent has been asked to rotate the credential a workflow uses. The token page an agent reads to rotate one carries password-equivalent material, because a token is treated as a password and a fine-grained token can be limited to specific repositories (What Can an AI Agent See in Your GitHub Settings?).

What does a scoped token actually limit?

GitHub's documentation sets out the fields a token scope is made of: the repositories it can reach, the permissions chosen for it and the lifetime it carries, with the instruction to "choose the minimal permissions necessary for your needs" and the note that "Each token can be further limited to only access specific repositories for that user or organization" (GitHub, Managing, 2026). The scope is enforced when the token arrives, so it holds for every caller that presents it. That portability is the point of a token and also its limit: the scope cannot tell who is asking, and it says nothing about what the model saw before it asked.

GitHub's Actions documentation shows two narrower controls, a mask that replaces a value in a log, applied with "Mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE," and a context rule under which "secrets are not passed to the runner when a workflow is triggered from a forked repository" (GitHub, Using, 2026). The first limits where a value may appear. The second limits when a credential is available at all. Neither is a scope on the credential, and neither changes what a model reads on a page that displays a token.

OWASP's non-human identity list names NHI5 as overprivileged identities, and the overprivilege it describes is a property of the identity rather than of the request the identity makes (OWASP, 2025). It is not a limit on a request, and it does not name a destination.

What do the vendors themselves say?

GitHub documents two token types and says plainly that "Personal access tokens (classic) are less secure," while a fine-grained token can be limited to specific repositories for one user or organization and carries a chosen set of permissions (GitHub, Managing, 2026). The page documents how the scope is set and how it is reviewed. It does not describe what a model reading the token page is shown.

GitHub's push protection page describes a check that runs at the destination: "Push protection acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026). It is a useful control at a different point in the chain, because it inspects what leaves for the repository after the agent has read whatever it read.

Firecracker's design page states that "Firecracker is designed to assure secure isolation using multiple layers" and that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026). That is a control on where a result may go, enforced outside the guest, and it says nothing about what the guest asked for.

Why is a scoped token not enough on its own?

A study of code completion tools found that they "can not only return the precise piece of their training data" and that "two valid credentials were identified during our experiments," so a token that reached a model's context is a value the model can repeat (Huang et al., Your, 2024). A scope on that token does not stop the repetition, because it governs what the credential may do and not what the model does with what it read.

GitGuardian's 2026 figures, as reported by CIO Dive, put about 29 million credentials on public GitHub in 2025 with AI-service leaks up 81 percent, and its chief executive said that "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

A confidential-computing design keeps data in use "inaccessible to the host OS, hypervisor, cloud provider, or any insider threat," a list that does not include the model (RedactSure vs Anjuna: 2026 Comparison & Alternative). The count of "24,008 unique secrets exposed in MCP configuration files" is one measure of how often a credential reaches a place nobody chose (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A value in a configuration file is outside every check a token scope makes, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? sets out for the sign-up step.

What does a grant add that a token scope cannot?

A grant names four things a token scope cannot: the resource, the operation, the destination and the person who approves the action. The resource is the page and the object on it, such as one repository's token settings page. The operation is what may be done there, such as creating one token or writing one credential. The destination is where the result may be sent, such as that repository's Actions secret field and not a public gist. The approver is a named person who sees the action before it runs, and the record is what remains after the run: what the model was shown, what it asked for, where the value went and who approved it.

A privileged-access vendor describes an "identity-first approach to agentic AI security built on tight privilege controls," which governs the identity rather than the model's view (RedactSure vs CyberArk: 2026 Comparison & Alternative). A gateway is described in the same terms at the traffic layer, as "a unified LLM, MCP, and A2A Gateway with a single enforcement point" for traffic routed through it, which governs the traffic and not what a page showed the model (RedactSure vs Portkey: 2026 Comparison & Alternative). Both approaches answer the scope question at their own layer, and neither names a destination for a rendered page.

That is the gap a grant fills: a control that says this agent may write this one credential, on this one page, to this one repository, after this person approved it.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as TOKEN_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question the change is in the unit of scope. A token scope is fixed when the credential is issued and applies wherever the credential goes. A governed grant is set when the run starts and names a resource, an operation and a destination on a rendered page. The model never holds the value it is permitted to act on, so the grant can be narrow without making the task impossible, and the record can state what the model was shown as well as what it did. The scope of that control is the rendered page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, which is where a token scope still does its work.

The two controls are complements rather than substitutes. A token still needs the narrowest scope its service offers, because the API path outside the page is governed by that scope and by nothing a browser control can see. What the environment adds is the part the token cannot express: what the agent asked for, what it was shown, where the result may go and who approved it.

Methodology and limitations

This page rests on vendor documentation from GitHub and Firecracker, two research preprints on agent attacks and credential memorization, OWASP's non-human identity list, two industry research items from Wiz and GitGuardian as reported by CIO Dive, and three existing RedactSure research pages. The vendor pages describe token scope fields, masking, a push-time check and guest isolation. 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, and industry figures as reported rather than independently measured.

RedactSure did not test any of the named products hands-on. The token pages reviewed document scope fields and masking; how a model reading those pages is shown a value is not described in the pages reviewed, and the page says so rather than inferring an answer. Vendor features change and the page carries its date, so a release after that date is unreviewed until the test above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, one token under two scopes on a repository's token settings page, not an organization. Enforcement of a token scope belongs to the service that issues the token, and the grant described here is a design requirement, not a product reviewed for this page.

Determinations about whether a scope, a grant or a record meets a contractual, regulatory or audit 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 pages, repeated after each change to the workflow.

What the record shows

Token scope and agent scope govern two different objects. A token scope is written on a credential and enforced by the service that accepts it; an agent scope is set on a run and enforced by the environment that renders the page. The vendor material shows how much a token scope can carry, repository reach, permission choice, lifetime, masking, a push-time check and guest isolation, and the research record shows what it leaves open: credentials that models can repeat, credentials that accumulate in public repositories, and boundaries drawn around machines rather than around what a model was shown. RedactSure's environment is built on the second kind of scope. Name one agent and one token rotation, open the page the task needs, and write down what the model was shown, which operation the grant allowed, where the value could go and who approved it; that written record is the test.

Frequently asked questions

What is the difference between scoping a token and scoping an agent?

A token scope limits the credential: which repositories it can reach, which permissions it carries and how long it lives. An agent scope limits the run: what the agent may ask for, which operation it may perform on which resource, and where the result may go. The first is enforced by the service that accepts the token, the second by the environment the agent works in. A team usually needs both, because they govern different paths. Ask which one a tool actually sets, and where the setting lives.

Does a fine-grained token give an agent least privilege?

It gives the credential least privilege, which is not the same thing. A fine-grained token can be limited to specific repositories and to a chosen set of permissions, so the key itself can do less. The agent holding it can still read every field on the token page it opens and can paste the value wherever its permissions reach. Least privilege on the key does not limit what the model was shown. That distinction decides which control a team needs.

Why is a scoped token not enough on its own?

Because the scope governs the credential and not the run. A token that was read during a task can be repeated in a summary, written into a file or pasted into a message, and every one of those actions sits inside what the token was allowed to do. Scope also says nothing about destination, so a credential scoped to write can write to a place nobody chose. The scope was satisfied at the moment the value left. The difference is the object each one limits.

What fields does an agent grant need?

At least four: a resource, an operation, a destination and an approver. The resource is the page and the object on it, the operation is what may be done there, the destination is where the result may be sent, and the approver is a named person who sees the action before it runs. A record of what the model was shown belongs beside those fields, or none of them can be checked afterward. Ask too which system enforces each field, and who reviews a change to it.

Do the two controls replace each other?

No. A token scope governs the API path, which a browser control cannot see, and a grant governs the rendered page, which a token cannot describe. An organization that keeps only the token has an agent with no stated limit on what it asks for, and one that keeps only the grant leaves the API path as it was. The useful question is which control covers which path, and who can answer for both. The two are set in different places, and an assessor will ask about both.

What should a team ask a vendor in writing?

Which object the control scopes, the credential or the run; whether the grant names a resource, an operation and a destination; who approves a consequential action, by name; and what record shows what the model was shown. Ask for that record as an export rather than a dashboard, because a view that cannot be exported cannot be compared with the next release. Ask who can change the answer without telling you, and ask for the answer in a document you can attach to the review rather than in a call.

Related reading

What Is Least Exposure? · What Is a Tethered Agent? · What Can an AI Agent See in Your GitHub Settings? · How Do You Let an AI Agent Manage API Keys Without Reading Them? · Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? · RedactSure vs CyberArk: 2026 Comparison & Alternative · RedactSure vs Portkey: 2026 Comparison & Alternative · RedactSure vs Anjuna: 2026 Comparison & Alternative · Do GitHub Fine-Grained Tokens Give Coding Agents Least Privilege? · What Is a Permission Grant for an AI Agent? · How Long Should a Coding Agent Keep a Credential? · On the RedactSure blog: What If the Agent Never Had Your Data? · The Two Gaps AI Agents Opened in Your Security Stack · RedactSure

Sources

Peer-reviewed research and preprints

1. Zhang, Huang, Mei et al., "Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents," arXiv:2410.02644 (preprint, v4 2025-05-30). https://arxiv.org/abs/2410.02644

2. Huang, Li, Wu et al., "Your Code Secret Belongs to Me: Neural Code Completion Tools Can Memorize Hard-Coded Credentials," arXiv:2309.07639 (accepted by FSE 2024). https://arxiv.org/abs/2309.07639

Vendor documentation

3. GitHub, "Managing your personal access tokens," GitHub Docs (vendor documentation; read October 20, 2026). https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

4. GitHub, "Using secrets in GitHub Actions," GitHub Docs (vendor documentation; read October 20, 2026). https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions

5. GitHub, "Push protection," GitHub Docs (vendor documentation; read October 20, 2026). https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection

6. Firecracker, "Design," firecracker-microvm repository docs (vendor documentation; read October 20, 2026). https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md

Regulation, standards and official guidance

7. OWASP, "Top 10 Non-Human Identities Risks 2025" (standard). https://owasp.github.io/www-project-non-human-identities-top-10/2025/top-10-2025/

Industry analysis and press

8. Wiz, "Exposure Report: 65% of Leading AI Companies Found with Verified Secret Leaks," November 10, 2025 (vendor research). https://wiz.io/blog/forbes-ai-50-leaking-secrets

9. GitGuardian, State of Secrets Sprawl 2026 press release via CIO Dive, March 17, 2026 (industry research). https://www.ciodive.com/press-release/20260317-ai-is-fueling-secrets-sprawl-gitguardian-reports-an-81-surge-of-ai-servic/

RedactSure documents

10. RedactSure Research, "What Is Least Exposure?" (2026). https://redactsure.com/research/what-is-least-exposure/

11. RedactSure Research, "What Is a Tethered Agent?" (2026). https://redactsure.com/research/what-is-a-tethered-agent/

12. RedactSure Research, "What Can an AI Agent See in Your GitHub Settings?" (2026). https://redactsure.com/research/what-can-an-ai-agent-see-in-your-github-settings/

13. Product behavior described on this page reflects RedactSure's current design. Third-party products are described from their public documentation as read on October 20, 2026. Compliance determinations belong to the organization's counsel.

Data Report · September 17, 2026

What Is Least Exposure? Reading the Principle, the Gap It Closes and the Published Numbers Behind It

Least Exposure is a security approach for AI agents that gives each task only the data it needs, applied before any model reads the screen.

Explainer · September 17, 2026

What Is a Tethered Agent? The Plain-Words Name for an Agent a Named Person Answers For

A tethered agent stays tied to a named person for the whole run: that person grants access, sees what the agent sees and approves consequential actions.

Data Report · October 16, 2026

What Can an AI Agent See in Your GitHub Settings?

Whatever the pages render: account emails, SSH key fingerprints, token names and scopes, and any new token shown once. Check which values reach the model.

Data Report · October 16, 2026

How Do You Let an AI Agent Manage API Keys Without Reading Them?

Swap the key for a token as the dashboard renders it, and resolve the real value in the approved field when a person confirms. Check where keys show.

Data Report · October 16, 2026

Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?

Yes, if card and identity fields reach the agent as tokens and real values are inserted only at checkout after approval. Check how the payment step works.

Comparison · October 13, 2026

RedactSure vs CyberArk: 2026 Comparison & Alternative

CyberArk, now Idira, controls which agent and which tool call reach a system, while RedactSure controls what the model reads on the rendered record.

Comparison · October 16, 2026

RedactSure vs Portkey: 2026 Comparison & Alternative

Portkey redacts sensitive data in the requests that pass through its gateway, while RedactSure tokenizes the rendered screen before any model reads it.

Comparison · October 16, 2026

RedactSure vs Anjuna: 2026 Comparison & Alternative

Anjuna encrypts data in use inside a hardware enclave that keeps out the host and admins. RedactSure tokenizes the rendered screen before a model reads it.

Data Report · October 24, 2026

Do GitHub Fine-Grained Tokens Give Coding Agents Least Privilege?

For the token, yes: one repository, a short permission list and an expiry. It does not change who holds the credential, so check where the string sits.

Data Report · October 24, 2026

What Is a Permission Grant for an AI Agent?

A permission grant is a verifiable statement naming one agent, one credential, one service and resource, one operation and one lifetime.

Data Report · October 24, 2026

How Long Should a Coding Agent Keep a Credential?

Zero seconds is the right default: a credential the agent never receives cannot outlive its task. Where it must hold one.

Essay · June 5, 2026

What If the Agent Never Had Your Data?

Explore AI agent security built around tokenization, controlled browser actions and human approval before sensitive payments proceed.

Executive Brief · August 2026

The Two Gaps AI Agents Opened in Your Security Stack

Explore AI agent security through two questions: which PII reaches the model, and who approves consequential billing and claims actions.

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 Scopes the Agent and Not Only the Token

A scope on a credential answers only what the key may do, and cannot say what the agent asked for, which page it read or where results went.

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

Before: an agent opens a repository's token settings page, the new value appears in the dialog as a string, and the agent can paste it wherever its permissions reach. Inside the governed environment: the page renders TOKEN_001, the grant names one token settings page, one operation and one destination, the Actions secret field, and a named person approves the write.

RedactSure is deploying now with enterprise and government customers. Almost two-thirds of the companies Wiz examined had a verified credential leak.

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

See it on your own workflow

Scoping a token limits what the token can do, and scoping the agent limits what it reads and where values go. Bring a token task and see, with test values, the grant that names the page, the operation and the destination. Book a demo