Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is a Permission Grant for an AI Agent?

A permission grant for an AI agent is a verifiable statement naming one agent, one credential, one service and resource, one operation and one lifetime. Ask to see the grant rather than the token, and check that the service receiving the request is the thing that enforces it.

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

Access arrives as a token. A token says that a credential exists and that something holds it, and it says little about which operation the holder may perform, on which resource, for how long. A permission grant answers those questions in one place: it is the smallest unit of authority an agent can be given, and the one artifact a reviewer can read without ever holding the credential it describes. The definition matters because the alternative, a credential carrying every permission its account happens to have, is still the common case. A token can be inspected for what it is; a grant for what it permits. This page sets out the five parts of a grant, reads the vendor documentation that comes closest to the idea, examines the research on why a credential in an agent's hands is the risk, and ends with the questions a reviewer should answer before approving one. It follows a single record type throughout, a grant for one repository, read, for this run, as it appears on a repository access page. Two neighboring questions, who draws the grant up and why the service rather than the agent enforces it, have their own pages.

Key findings

  • GitHub's Actions security reference states that "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents," which is the narrowest default a repository credential can carry (GitHub, 2026).
  • HashiCorp's Vault documentation states that "A new single-use token is generated with the TTL supplied by the client," which makes a credential's lifetime a value the requester sets before use (HashiCorp, 2026).
  • Cognition's Devin guide describes session secrets as "scoped purely to the current session and are not saved for any future sessions," so the session is the documented unit nearest to a single run (Cognition, 2026).
  • The Agent Security Bench authors report "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," which is why the check belongs at the service rather than inside the agent (Zhang et al., 2025).
  • Least privilege governs the actions and credentials an agent may use, and it does not govern the content of the screen the agent reads, so a grant leaves exposure open by design (What Is Least Exposure?).
  • Before any model reads the screen, values chosen by policy are replaced with consistent tokens, and real values resolve only at the approved destination at the moment of an approved action (What Is a Tethered Agent?).

What are the five parts of a permission grant?

Two boundaries come before the parts. The first is scope: a governed browser environment covers what an agent reads and does on a rendered page, such as a dashboard, console, repository access page or settings page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that calls a repository API from a shell is outside this page; an agent that opens the repository access page to check its own grant is inside it. The second is that a grant is a record and not a mechanism: it states terms, and something else has to check them.

A grant names five things, and a missing part is not a detail. The agent, meaning which identity is acting, not which team and not which model. The credential, meaning which credential may be presented, or which credential the agent may never see. The service and the resource within it, since a grant to one service is not a grant to the account that spans several. The operation, one of them: read, write, deploy, delete, send. The lifetime, the moment the grant stops being valid, which most teams leave to a revocation someone must remember to perform.

Part What it names What a reviewer checks
Agent One identity, not a team and not a model That the identity on the grant is the one in the run's log
Credential The credential that may be presented Whether the agent ever holds it, or only a placeholder
Service and resource One service, and one resource inside it That the resource is the one the task needs, not the account around it
Operation One verb: read, write, deploy, delete, send That a second verb would be refused
Lifetime The moment the grant expires That expiry, not a person's memory, ends the access

The nearest published relative is smaller than a grant and points the same way. GitHub's Actions reference states "Pin references to actions to a commit SHA in your workflow files," a rule that fixes one version for one operation, which is the shape a grant takes when it names what may run (GitHub, 2026).

The worked record is a grant for one repository, read, for this run. It appears as a row on the repository access page: one identity, a role of Read, one repository named, and an expiry that falls at the end of the run. The row is the grant; the token the agent never holds is what it replaces.

Why is the lifetime the part that stays open?

A lifetime is a design decision, and the documentation that comes nearest treats it as one. Vault's documentation adds that "Vault currently does not provide signed response-wrapping tokens, as it provides little extra protection," so the wrapping token itself carries no signature a receiver can check (HashiCorp, 2026). What the token carries instead is a life, and the page puts that number in the requester's hands rather than in the service's defaults.

The research measures a different axis. Liu and colleagues report "we conduct a systematic evaluation on 5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," a benchmark built for attacks and defenses rather than for the lifetime of the credential an agent holds (Liu et al., Formalizing, 2024). A defense is scored on whether an attack succeeds within one task. None of the seven tasks asks whether the credential was still valid after the task ended, which is the question a lifetime answers.

That gap has a practical shape. A grant that outlives the run is a standing credential with extra steps: the operation is written down once and the access stays. Revocation becomes an action someone has to remember, and the record shows the grant being created rather than the moment it stopped mattering.

The count is why a grant is worth more than a policy: Help Net Security's reading of GitGuardian's data records "28,649,024 new secrets exposed in public GitHub commits across 2025" (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A credential that was meant to last is the one that leaks, and a lifetime bounded by the run is the cheapest cut in that count.

What do the vendors themselves say?

The vendor pages reviewed document custody, scope, identity and audit. The ones that come closest to a grant are tokens rather than statements. A statement of one operation on one resource for one lifetime, checked by the receiving service, is not described in the pages reviewed.

Cognition's Devin guide is the clearest on where a value goes. It states "For shell commands, it binds secrets as environment variables whenever needed" and, for pages, "In the browser, Devin types the value directly," two routes that say where a value goes, not what the model holds (Cognition, 2026). The guide also scopes credentials to the organization, the person, the repository or the session, a scope rather than a stated lifetime for the credential itself.

Teleport's documentation states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," an identity a receiver can check before it accepts a grant, and a precondition for a grant rather than a statement of one (Teleport, 2026). The same page advertises "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," and it marks most of the capabilities it lists as "In-progress" or "Not started," which a buyer should read as a direction rather than a shipped control.

GitHub's guidance states "Audit how secrets are used, to help ensure they're being handled as expected," an instruction to read the record of use rather than the credential (GitHub, 2026). The record answers what happened. The grant answers what was allowed to happen, and the two are different documents.

Who checks a grant, and who enforces it?

A grant is checked twice. The issuer verifies it when it is written: identity, credential, resource, operation, expiry, and a person's name on the terms. The service enforces it when a request arrives: the operation asked for is inside the grant, or the request is refused. A grant that only the issuer verifies is a plan. A grant the service does not read is a policy. OWASP's list makes the same split: NHI5, overprivileged identities, beside NHI2, the leakage of credentials to stores nobody sanctioned (OWASP, 2025).

Enforcement matters because the agent can be wrong. A study of agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," which is what a grant narrows: the operation an injected instruction can reach (Liu et al., Your, 2026). The abstract gives no trial counts or tool versions, so read the rate as a reason to bound the operation, not as a measurement of one product.

Identity systems cover the first half and leave the second. Okta's developer documentation says Okta for AI Agents "manages the registration, configuration, and lifecycle of AI agents," which settles who an agent is and not which operation it may perform on one resource (RedactSure vs Okta: 2026 Comparison & Alternative). Microsoft describes Agent 365 as providing "the ability to observe, govern, and secure the growing number of agents within organizations," without stating where it sits relative to the model or the screen (RedactSure vs Microsoft Agent 365: 2026 Comparison & Alternative). Both are necessary; neither is a grant.

What should a reviewer read instead of the token?

A reviewer who reads the token learns that a credential exists. A reviewer who reads the grant learns what the credential may do, where, for how long, and who agreed. The second answers what an approval meeting actually asks: what this agent can do after the meeting ends.

The credential is what gets exposed while nobody reads either document. Wiz's exposure report states that "65% had leaked verified secrets on GitHub," which covers the 50 AI companies it examined (Wiz, 2025). GitGuardian's 2026 report, as carried by CIO Dive, counts about 29 million credentials leaked on public GitHub in 2025 and an 81% year-over-year rise in AI-service leaks (GitGuardian, 2026). The same release quotes a chief executive saying "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

What to read: the operation, because it bounds what a mistaken action can reach; the lifetime, because it bounds how long the mistake stays available; the resource, because a grant to one repository is not a grant to the account; the credential, because a grant the agent cannot use is stronger than one it holds; and the approver, because a grant with no name on it is a policy with a date.

Two checks decide it. The first is the closest documented comparison: AWS states that it strongly recommends not creating access keys for the root user, which rules out the simplest durable top-level credential an agent might be given, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? records. The second is the record. If the run's log cannot show which grant was in force at the moment of an action, the grant was a document and not a control.

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. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as REPO_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, that changes what a grant has to cover. A grant is a statement about an operation; the environment decides what the agent's model is shown while it performs that operation, and neither implies the other. A grant to read one repository can be enforced perfectly while the repository access page renders every account name, the deploy key and the last four digits of a credential to the model. The grant replaces the token in the agent's hands, and render-layer tokenization replaces the account name on the page. Tokenization inside a vault, the pattern Skyflow documents, exchanges a value for a token in a data store, and RedactSure vs Skyflow: 2026 Comparison & Alternative sets out where that sits against a control at the render layer.

The limit belongs in the same breath. The environment governs the rendered page: dashboards, consoles, settings pages and repository access pages. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that holds a repository token and uses it from a shell is a grant question, not a screen question, and it needs its own answer.

Methodology and limitations

This page rests on three research preprints on prompt injection and agent benchmarks, vendor documentation from HashiCorp, Cognition, Teleport and GitHub, OWASP's non-human identity guidance, industry research from Wiz and GitGuardian, and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported rather than independently measured.

RedactSure did not test any of the named products hands-on. Where this page says a mechanism is not described in the pages reviewed, it means the vendor documentation reviewed does not describe it, not that the product lacks it. Vendor features change, and the page carries its date; a release after that date is unreviewed until the check below is repeated. The preprints are cited for what their abstract pages state and not for figures those pages do not give. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a grant for one repository, read, for this run, and not an organization.

Determinations about whether a particular grant 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 repository. A reader who needs a determination on one workflow should take the grant and the run's record to that reviewer, since the same terms can satisfy one requirement and fail another.

What the record shows

The five parts sort the vendor pages into a pattern. Custody designs keep a credential out of the agent's hands, scope designs shorten a session, identity designs give the receiver something to verify, and none of them states in one place what the agent may do, on which resource, for how long. The research explains why the gap matters: injection reaches commands at high rates, and the defenses measured so far show limited effect. A grant does not make those failures impossible; it turns the blast radius into a decision someone signed. Any reviewer can apply this as a test by naming one agent and one task, asking for the grant that covers it, and checking whether the document names one operation, one resource, one lifetime and one approver, and whether the service refuses anything else.

Frequently asked questions

What is a permission grant for an AI agent?

A written statement, held outside the agent, that names one identity, one credential, one service and resource, one operation and one lifetime, and that the receiving service checks before it acts. It is the record a reviewer reads instead of the token, because a token shows that a credential exists and a grant shows what it may do. Ask for the grant in writing, and treat a description of the policy behind it as an answer to a different question. One page, one signature, one expiry.

Does a scoped token count as a permission grant?

Only partly. A token scoped to one repository and one role carries two of the five parts, and it usually carries no operation and no expiry the receiving service checks. The rest lives in the policy that issued it, which the service may never see. A scoped token is the raw material of a grant; the grant is the statement a person can read and a service can enforce. Compare the two documents before you accept either. A grant that cannot be produced on request is a promise.

How long should a grant last?

As long as the task, and no longer. The documented patterns point the same way: a single-use token with a TTL the client supplies, a credential scoped to one session and not saved afterward. A grant that runs for a quarter is a standing credential with a new name. Set the expiry when the grant is written, and treat an extension as a new decision with a new approval and a new signature. The date on the document is part of what makes it a grant.

Who approves a grant?

A named person who can see the task and the resource, not the agent and not the model. The approval is what makes the grant accountable: someone chose this operation on this resource for this run, and their name is on the record before the first action. A team approval, a ticket number or a policy exception spread across people leaves the question of who decided unanswered. One name per grant is the test, and a grant nobody signed is a default. Ask who, by name, and check the record.

What should a reviewer check first?

The operation and the lifetime, because those two decide what a mistaken or injected action can reach. Then the resource, to confirm the grant covers one repository and not the account around it, and the credential, to see whether the agent holds it or only a placeholder. If any of the five parts is missing, what is on the table is a policy statement and not yet a grant. Read the document, not the summary of it. A summary can omit the part that limits the run.

Where does a grant stop?

At the edge of what the service enforces. A grant governs an operation on a resource; it does not decide what the agent's model reads on the screens it opens, and it does not reach the terminal, the IDE, the local filesystem, direct API calls or MCP. A rendered page under a good grant can still show a model every value on it, which is the separate question of exposure. Both documents matter, and neither substitutes for the other. Test both, on one run, before you sign.

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 Turns a Token Into a Grant a Reviewer Can Read

A token proves a credential exists and leaves the operation, the resource and the end of the run to a policy nobody reads, so the grant goes unwritten.

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

Before: the agent opens the repository access page, reads the role column with the real account names and the deploy key. Inside the governed environment: the same page renders REPO_001 and a role token, and the real name resolves only on the approval.

RedactSure is deploying now with enterprise and government customers. Injection against agentic coding editors reaches 84 percent in the study cited above.

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

See it on your own workflow

A grant a reviewer can read is one a security team can sign. Bring a task you want to delegate and see, with test values, the access page as the model reads it and the approval that resolves it. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.