Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Should an AI Agent Permission Include?

Five fields: the service that accepts the request, the resource it reaches, the operation it allows, the destination the result may go to, and the lifetime it runs for. Any field left unwritten becomes a default the mechanism chooses, so ask to see the five fields before the agent starts.

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

For a reviewer approving an agent's access, a grant exists in one of two forms, and the form decides what that reviewer can check. It is either a document a person signs, with every limit in words, or a token whose limits live in a service's scope vocabulary and a settings page. The first can be read by someone who was not in the room when the task was requested. The second is enforced, but only for the fields the service happens to publish, and the rest is left to a default chosen for the platform's convenience. That difference is the subject here, taken as a checklist: five fields, one at a time, with what a complete value says and what fills the space when a field is missing. The answer is a form of words a person can hold against the task, which is why the same five fields serve a browser agent, a token and a signed grant, and why a permission nobody but its author can read is a setting rather than a decision. GitHub and Firecracker document some of the fields, injection research sets limits on what a narrow grant protects, and one request followed through both forms shows where the forms part. The worked record is a request to update the webhook endpoint for one repository, written once as a slip with all five fields and once as a fine-grained token with two.

Key findings

  • A permission carries five fields, the service, the resource, the operation, the destination and the lifetime, and a field left off is filled by the mechanism's default rather than by the task (What Is a Permission Slip for an AI Agent?).
  • GitHub's documentation states that "You should choose the minimal permissions necessary for your needs," which leaves the operation field to whoever creates the token (GitHub, Managing, 2026).
  • The same page states that "Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy set by your organization or enterprise owner," so a token's lifetime defaults to the longest the platform permits (GitHub, Managing, 2026).
  • Firecracker's design document states that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," a destination written by the host (Firecracker, 2026).
  • Wiz reports that "We looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub," the failure a narrow grant limits (Wiz, 2025).
  • Values are replaced with tokens before any model reads the screen, so the model works on placeholders such as REPO_014, and real values resolve only at the approved destination at the moment of an approved action (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What does a browser permission cover, and what does it leave to the token?

The five fields are written against a boundary, and the boundary decides which of them can be enforced at all. A governed browser environment covers what an agent reads and does on a rendered page: a repository settings page, a console, a dashboard, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. On a rendered page there is no scope vocabulary to appeal to: the page shows what it shows, and the only place to say this account and not that one is the permission a person wrote before the run. The tether is a description of authority, not of capability, which is why the authority has to be written where a person can read it (What Is a Tethered Agent?).

On the other side of the line the position is reversed. A fine-grained token carries a resource and an operation in the service's own vocabulary, and the service enforces both when a call arrives. GitHub's page states that "Each token can be further limited to only access specific repositories for that user or organization," so a repository limit is real, checkable, and narrower than the account (GitHub, Managing, 2026). What the token does not carry is a sentence about the task, a destination for the result, or a name against the decision.

The record for this page holds both forms. A developer types a request to update the webhook endpoint for one repository. Written as a slip, it reads: service, GitHub; resource, the repository named by owner and name; operation, read and edit of the webhook settings; destination, that repository's webhook settings page; lifetime, until the run ends. Issued as a token, the same grant reads: service, GitHub; lifetime, ninety days; resource and operation, selected from the pages the service publishes; destination, absent.

Which five fields make a permission complete?

The five fields answer three questions in order: what the agent may touch, where the result may go, and how long the permission lives. Each field has a complete form and a default form, and the default is what the mechanism does when nobody writes the field down.

Field A complete value states What fills the gap when it is missing
Service The one system that will accept the request, named as the page or the API it is The token's audience, which is every service that accepts it
Resource The one object, by name or identifier, never a wildcard The service's default, often every object the account owns
Operation The one verb the task needs, with the others named as excluded The scope's permission list, chosen once and reused
Destination The host and the page where a result may land, and nowhere else Nothing: the value goes wherever the page, form or redirect sends it
Lifetime When the grant expires, as a date or as the end of the run The platform maximum, or no expiry at all

Two of the five are usually written for you. A token is created for one service, and it carries an expiry from the moment it is issued, which is why service and lifetime are the fields most permissions actually state. The other three are where the review work sits, because a platform fills them from a menu or from a default chosen for its own convenience rather than for this task.

Operation is the field that turns into overprivilege. OWASP's non-human identity list names overprivileged identities as its fifth risk, the condition a permission reaches when an operation is chosen once and reused for every later task (OWASP, 2025). A token issued to read build logs and reused to edit releases is a missing field, decided once and never revisited.

Destination is the field that nothing fills. A token is valid from any host that presents it, and a page that accepts a URL, a redirect that follows a query parameter or a second tab moves where a value lands. A permission that omits the destination has not narrowed the result, only the request. Read against the record, the slip states all five and the token states two, so one reviewer compares it with the task and the other with a menu.

What do the vendors themselves say?

Two vendor pages describe the fields their mechanisms enforce, and both enforce fewer than five. GitHub's Actions documentation states that "Mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE," a control over what a log displays rather than over what a grant permits (GitHub, Using, 2026). The same page states that "secrets are not passed to the runner when a workflow is triggered from a forked repository," a destination condition the platform applies on its own, without the grant naming a destination at all (GitHub, Using, 2026).

Firecracker's design document states that "Firecracker is designed to assure secure isolation using multiple layers," and the layers belong to the host, which is where the missing destination field gets written (Firecracker, 2026). The document then treats traffic leaving a guest as untrusted and filters it at the host, the same point in the language of an isolation boundary rather than a permission.

Dimension GitHub, per its documentation What a buyer should verify
Resource Access can be limited to specific repositories at creation That the limit is per repository, not per organization
Operation The creator picks the minimal permissions for the need Which permissions the task needs, written before the token exists
Lifetime Infinite lifetimes are allowed; a policy may cap them That a cap exists, and who owns it
Destination Where the token may be used from is not stated Where the token is allowed to travel, and what the log shows
Approver Not part of the token Who approved this grant, with a date

The platform enforces what it can see at the boundary it owns: the service for a token, the host for a guest. A destination is enforceable only where the enforcing party owns the network or the page, and an approver is not a platform concept at all. A team that wants all five fields has to write the three the platform leaves out and put them where the run happens, which is a different design from choosing a shorter scope from a longer list.

What does a token with two fields leave open?

The record's token is the ordinary case. It names GitHub because it was created there, it expires in ninety days, and its repository and permissions were selected from lists the service publishes. Its destination is not written anywhere, so a reviewer can say which repository it reaches and which verbs it allows, and cannot say where it may be used or who decided that this task needed it.

The destination gap is the largest. A page is not a fixed address, and a measured environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' personal information, which is why the destination field has to name a host and a page (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). A token valid from any host turns that risk into a question about everything else the agent's context holds when the attack lands.

GitGuardian's 2026 report, as reported by CIO Dive, counted "About 29 million secrets leaked on public GitHub in 2025," with AI-service leaks up 81 percent, and its CEO states that "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

A narrow field does not make a token safe, only the damage countable. A token limited to one repository and one operation, expiring with the run, bounds what a hijacked agent can reach, and a token with an organization-wide scope and no expiry does not. The same pattern appears wherever a service offers one account with more reach than the task needs, which is why Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? records that the super admin account should be used only when needed.

Does a narrow permission stop a hijacked agent?

No, and the research record is consistent about why. Liu et al. state that "we conduct a systematic evaluation on 5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," a benchmark built because the defenses do not settle the question (Liu et al., 2024).

The Agent Security Bench authors report that "Our benchmark results reveal critical vulnerabilities in different stages of agent operation," with "limited effectiveness shown in current defenses" (Zhang et al., 2025). A permission does not change that finding. It changes what a successful attack collects: a placeholder in the transcript, or a working credential in it.

What the attack collects depends on what the model was shown. The code completion study found that "two valid credentials were identified during our experiments," evidence that a value the model can read is a value it can repeat (Huang et al., Your, 2024). The direction of the finding is what matters here: a token inside the agent's context is a value the agent can print, summarize or paste into a file it writes.

This is where the five fields show their limit. Least privilege, the standard answer to agent risk, governs actions and credentials. It does not govern the content of the screen an agent reads, as What Is Least Exposure? sets out. An agent can satisfy every field on the slip and still hold every value the page rendered. The destination field is the one that nearly touches this problem, because a value that resolves only at an approved destination is a value the model never holds, and that property belongs to the environment rather than to the grant.

What does a governed environment change?

It changes which of the five fields can be enforced, and it adds the question the fields do not ask. A governed environment renders the page itself, so it knows which value sits in which field, which account the page belongs to and where a submission would go. That makes the resource, the operation and the destination enforceable at the point of the action rather than only at the point of the credential.

Service and resource are the page and the record the task names. Operation is the action the person approved. Destination is the one host and page where a value may resolve. Lifetime is the run, ending when the approval does. Each is written by a named person before the run, not selected from a menu during it.

The question the fields do not ask is what the model reads, and What Should the AI See for This Piece of Work? gives that question an owner. Values chosen by policy are replaced with tokens before any model reads the screen, so the model works on placeholders for the whole run, and real values resolve only at the approved destination at the moment of an approved action. A value the model never read is a value it cannot repeat, which is the only property that survives a hijacked run: the attack succeeds and collects tokens.

What the environment adds is the part a reviewer needs. Every screen as tokens, every action, and the name of the person who approved it go into a record that exports to the organization's own monitoring. What Should an AI Agent Security Review Cover? asks for that record in writing, because a permission never checked against the run is a plan rather than a control.

Methodology and limitations

This page rests on three research preprints on prompt injection and credential memorization, vendor documentation from GitHub and Firecracker, one OWASP standard, a vendor exposure report from Wiz, a GitGuardian press release as carried by CIO Dive, 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, and figures from the research posts are cited as reported rather than independently measured.

RedactSure did not test any named product hands-on. The vendor pages describe tokens, workflow credentials and microvm isolation, and none of them describes a permission written against a task; the five fields are this page's checklist rather than any vendor's schema. Vendor features change, and the page carries its date, so a release after that date is unreviewed until the fields are checked again. Where an abstract gives no result figures, the page says so. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked record describes a record type, a repository settings page and the grant behind one webhook edit, and not an organization.

Determinations about whether a permission meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the organization's own agent, the scopes of the credential it holds and the pages it reads, repeated after each release. The record of what the agent read on each page belongs in that review, beside the fields the permission states and the ones it leaves to a default.

What the record shows

The slip states the service, the resource, the operation, the destination and the lifetime, and a reviewer can hold each one against the task. The token states two of them, carries two more in a menu the service publishes, and leaves the destination to whatever host presents it, which is the gap the research on injection and credentials keeps finding. A token is still useful, but it is a grant without a destination, and the destination is the field that decides whether a stolen value works from anywhere or only at one page. RedactSure's environment is built on the readable form, with the values behind it held as tokens. Which of the five fields the permission states, which one the platform chose, and who signed for the rest are the three questions to test against one named agent and one task.

Frequently asked questions

What should an AI agent permission include?

A complete permission states five things: the service that accepts the request, the resource it reaches, the operation it allows, the destination where a result may land, and the lifetime it runs for. Two of those, service and lifetime, are usually written by the platform when a token is created. The other three are written by a person or filled by a default. Check which are written and which were inherited. A permission that answers only the first two is a token description rather than a permission.

Is a scoped token the same as a permission?

No. A token is the mechanism that carries a grant, and its scopes are the vocabulary the service publishes. A permission is the statement of what this agent may do for this task, in words a reviewer can compare with the request. A fine-grained token can come close on resource and operation, but it does not state a destination, and it names no person who decided the grant was appropriate. Ask for the permission itself when you review a grant, and for the token only after it.

Which field is most often missing?

The destination. Service and lifetime arrive with the token, resource and operation are chosen from a list, and the destination is left to whatever host presents the credential. On a rendered page the gap is wider, because a form that accepts a URL or a redirect can move where a value lands after the permission was written. Naming a host and a page is the cheapest correction a reviewer can ask for. Write it as a host and a path, then check that a second page refuses the value.

How long should the lifetime field be?

As short as the task allows. A lifetime that ends with the run limits what a stolen credential can do, and a ninety-day token issued for a ten-minute task spends the rest of its life as an unused key. GitHub's page notes that infinite lifetimes are allowed but may be capped by a policy, which puts the outer bound with an administrator and the inner bound with the task. For an agent, the run is the natural unit, because the task ends when the run does.

Does a permission stop prompt injection?

No. Benchmarks of injection attacks and defenses report critical vulnerabilities across stages of agent operation and limited effectiveness in current defenses. A permission bounds what a successful attack can reach, which is why a narrow grant matters, but it does not change what the model was shown. When the attack succeeds, the question is whether the context holds a value or a placeholder. A placeholder in the context is worth more than a narrow scope once the attack lands.

Who should sign the permission?

The person accountable for the workflow, named on the grant with a date, not a central team and not the vendor. That person can compare the five fields with the task and answer for the result. A signature from someone who cannot see the task is a formality, and a permission with no signature is a default wearing a document's clothes. Put the signature beside the five fields, so a reader sees the decision and the name together.

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 Writes All Five Fields Before the Agent Starts

A grant naming two fields leaves three to a mechanism with no view of the task, so the narrow token could not say where its value would go.

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

Before: the model reads the repository's webhook settings page with the signing key in full, under a token that says nothing about where the value may go. Inside: the page renders REPO_014 for the repository and WEBHOOK_SECRET_001 for the key, and the named person's approval resolves the real key to that page alone.

RedactSure is deploying now with enterprise and government customers. The memorization study above found that "two valid credentials were identified during our experiments."

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

See it on your own workflow

A permission that leaves out where a value may go is missing the field that prevents a leak. Bring a webhook task and see, with test values, all five fields written before the agent starts. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.