Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Turn a Plain-English Request Into an Agent Permission?

Write the grant as a slip: a planner turns the sentence into a service, a resource, an operation, a destination and a lifetime, resolves each one against account and resource metadata, and puts the result in front of a person to sign. Ask what the planner read, what it never read, and who signed.

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

For the leads who approve agent access, the distance between a sentence and a grant is where most of that access goes wrong. Someone writes six words about reading a repository, and what gets issued is whatever the console offers by default: an account-wide token, a role that also carries write and delete, a credential with no end date. The translation is the part worth designing, because it is the last moment when the request is still cheap to change and still small enough for a person to read.

A planner does that translation. It takes the actor, the action and the object out of the sentence, resolves them against the directory, the repository list and the grants already in force, and emits a slip with five fields: service, resource, operation, destination and lifetime. That work happens before the run, on descriptions rather than values, which is why the planner never needs the credential the grant will later unlock.

The page follows that route through one record type, a sentence typed into a repository access page that returns one slip, inside the scope a browser control covers: the rendered pages, and not the terminal. On that record, a plain request widens into an over-broad grant at a few predictable points, and vendor documentation on scoping credentials to an agent leaves the translation to the team. The slip is worth trusting once a named person has signed the version that takes effect.

Key findings

  • Progent, a privilege control layer for agents that the authors evaluated on AgentDojo and ASB, is reported to cut attack success rates while holding utility, which is the trade every grant has to make (Shi et al., 2026).
  • In agentic coding editors, injection tests reached an attack success rate "as high as 84%" for executing malicious commands, so a sentence an agent writes after reading a page is not a safe input to a grant (Liu et al., 2026).
  • GitHub calls it "good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents," a default a reviewer can apply before reading the fields of any slip (GitHub, Secure, 2026).
  • OWASP names NHI2 Secret Leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," the population a narrow slip limits rather than removes (OWASP, 2025).
  • A grant a model can read safely carries tokens where values would sit: the page renders REPO_004 before any model reads it, and real values resolve only at the approved destination (What Is Supervised Delegation?).
  • Because the planner works from descriptions, the credential a grant unlocks stays out of the model's context, and the review turns on the shape of the access rather than on the value behind it (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What does a browser control cover when the request is typed on a repository page?

A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages, sign-up forms and the access request form on a repository settings page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The line belongs at the start because the sentence that becomes a permission is often written elsewhere: an agent that read a file, ran a command or called an API has already acted before any page renders.

The distinction is not administrative. Devin's product guide says that for shell commands it "binds secrets as environment variables whenever needed" (Cognition, 2026), a mechanism on the machine rather than on the page, and a control that governs rendered pages has nothing to say about a variable inside a shell session. What it does govern is the form where a person or an agent states what access is wanted, and that form is also where a request becomes words someone can review.

The record type for this page is that form: a repository access page with a text box, a review card and a sign button. One sentence goes in, "give my coding agent read access to this repository," and one slip comes out. The slip is the object the rest of the page examines. The page is rendered and the repository the slip names is a row in a list the page shows, which lets the translation happen without touching the value the grant unlocks. The token pages on that site are the reason to care: they carry material GitHub tells users to treat like a password (What Can an AI Agent See in Your GitHub Settings?).

What does a planner read to turn one sentence into five fields?

Four steps, in order. Parse: pull the actor, the action, the object and any qualifier out of the sentence, so that "give my coding agent read access to this repository" becomes an agent, a read, one repository and an end at the close of the task. Resolve: look each term up in metadata the account already holds, the repository list, the directory, the roles attached to the person, the credential names and scopes configured for the agent, the environments that exist. Draft: write the five fields, service, resource, operation, destination and lifetime, in the vocabulary of the system that will enforce them. Review: render the slip where a person can read it, and issue nothing until someone signs.

What the planner reads matters as much as what it writes. A repository name, a role label, a scope name and an environment name are descriptions, and all of them can be resolved without holding the value that the grant unlocks. Devin's guide shows how far a vendor's scoping vocabulary already goes: a value can be scoped to an organization, a person, a repository or a session, and a session credential is "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026). That is a label on a credential, and a planner can read the label without reading the credential.

The step that needs care is the one before drafting. When a term does not resolve, the planner has to stop rather than widen: "this repository" resolves if the workspace holds one, and it does not if the agent has been handed an organization with two hundred, where the safe output is a question and not a grant. The page can also carry the token: a repository rendered as REPO_004 is enough to draft a slip and for a person to review one.

What do the vendors themselves say?

The vendor pages reviewed describe how a credential is scoped and how a value is handled once issued. None documents the step that converts a sentence into a grant, and each supplies vocabulary a planner would have to write into.

GitHub's Actions documentation concerns credentials inside a workflow, and it says to "Mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE" (GitHub, Using, 2026). Masking hides a value in a log, and it does not record what a job was allowed to touch, which is what a slip states.

Doppler's page for coding agents comes closest to the planner's output: "Give every coding agent its own scoped, read-only, expiring set of credentials," it says, and it recommends a branch config used to "only hold secrets a given agent needs" (Doppler, 2026). Read-only, scoped and expiring are three of the five fields. The page does not say who approves the scope, or how it is written down before it is applied.

Teleport argues that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," and it lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure" (Teleport, 2026). It marks most capabilities on that page "In-progress" or "Not started," so the identity and audit trail are a stated direction rather than something a buyer can run today.

Dimension What the vendor documents What a buyer should verify
Unit of scope Doppler scopes a credential per agent, with a branch config holding only that agent's credentials Whether the scope is enforced by the platform or only by the injection step
Lifetime Doppler recommends expiring credentials What the default lifetime is, and who can extend it
Identity Teleport argues for a per-agent cryptographic identity, marked in progress Whether the identity exists in production or on a roadmap
Record Teleport lists audit trails and behavior analysis, marked in progress Whether the record shows the grant as approved or only the action as performed

The pattern is a vocabulary for scoping and no procedure for drafting. A team that wants the procedure has to own it, which is why the fields on the slip are the thing to standardize.

Where does a plain request turn into an over-broad grant?

Three places, none of them malicious.

The first is the verb. "Access" usually means reading, and the role that grants reading in most consoles also carries write, delete and administration. A planner that maps the word to that role has widened the request before anyone reads it; the mapping runs from the operation to the smallest permission, not from the word to a role.

The second is the object. "This repository" is one row in a list, and the inherited default is the organization, how access accumulates without a decision (How Do AI Agents End Up With Full Access to Sensitive Company Records?). The third is the missing field: a slip without a destination or lifetime is a standing grant, the kind a sprawl count measures. GitGuardian put 2025 at about 29 million credentials on public GitHub, with AI-service leaks up 81%, and its chief executive gave the reason: "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

Then there is where the sentence came from. An agent that composed the request after reading a page inherited whatever that page wanted. Injection tests in agentic coding editors reached success rates "as high as 84%" for malicious commands (Liu et al., 2026), a hidden instruction in a submitted PDF steered the models asked to review it (How Do Malicious Documents Take Control of AI Agent Behavior?), and an injected element can redirect what the agent does (How Do Websites Manipulate AI Agents?). A planner is not a detector; it turns the sentence into a narrow, signed grant rather than an instruction the agent carries out on its own authority.

Who should sign the slip, and what should it say?

A named person, on the rendered slip, before anything is issued. The slip carries the five fields, the identity of the requester, the run it applies to and an expiry, and it fits on one screen. A reviewer who cannot see the destination and the lifetime in the same view is approving a shape rather than a permission.

The checks are short. Refuse a blank field, because a blank destination is any destination and a blank lifetime is forever. Start from the narrow default: GitHub's secure use reference calls it "good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents" (GitHub, Secure, 2026), and a team that sets the same default for its agent grants begins every review at read-only. Read the verb against the operation rather than against the role name, and ask what the grant can still reach after the task ends.

The signature is the control, and it needs a record beside it. GitHub's advice to "Audit how secrets are used, to help ensure they're being handled as expected" (GitHub, Secure, 2026) is an after-the-fact check: it can show that a value was used, not that its use was approved. A signed slip that lands in a record with the approver's name is the other half, and it makes the next request faster, because the reviewer can read what was granted before (What Is an AI Control Record?).

Two failures are worth naming. One is the rubber stamp: a queue of slips signed without a read produces a record asserting that a person approved. The other is the unreviewable slip, accurate and forty lines long. Both yield to one fix, a short slip ordered the way a reviewer checks it: operation, resource, destination, lifetime, requester, signature.

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 an agent working an access request sees REPO_004 and TEAM_002 where names would sit. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, a grant of access included. 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 it changes what the translation is allowed to use. A planner reading a page that renders tokens drafts the slip in tokens, which means the slip can be reviewed, enforced and audited without the model ever holding a repository name, an account number or a credential. The approver sees the same tokens on the same screen, and real values are resolved only where the action lands, so the review and the enforcement are made against one description rather than two.

It is also where a request stops being an instruction. A sentence typed into a page, by a person or by an agent, becomes a drafted slip, then a reviewed slip, then an entry in a record with the name of the person who signed. The model can propose, and it cannot issue. That separation is the whole answer to the title question, and it asks the planner to be trusted with a description rather than with a value.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a grant an agent requests from a shell prompt stays with whatever that shell's policy allows, and a control that governs pages should say so plainly.

Methodology and limitations

This page rests on two research preprints on privilege control and prompt injection in coding agents, vendor documentation from GitHub, Cognition, Teleport and Doppler, the OWASP non-human identity risk list, one press release reporting GitGuardian's secrets-sprawl figures, 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 the research posts and the press release are cited as reported, not as independently measured.

RedactSure did not test any of the named products hands-on. Where this page says a vendor documents a scope and not a procedure, that means the pages reviewed do not carry one; it is not a statement that the vendor does nothing. The vendor pages concern credentials rather than the drafting of a permission, and the five-field slip is set out here as a design requirement. Vendor features change, and the page carries its date, so a release after that date is unreviewed until the checks above are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a repository access page and the slip it returns, not an organization.

Determinations about whether a grant meets a contractual, regulatory or accreditation 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 on a test repository, with the slip kept beside the record of what the model saw and who signed.

What the record shows

The record answers the title with a procedure rather than a product. A request becomes a slip when four things happen in order: the sentence is parsed into an actor, an action and an object; each term is resolved against metadata rather than against a credential; five fields are written in the vocabulary of the system that will enforce them; and a named person signs the version that takes effect. Each step has a failure mode, and the failures are ordinary: the verb that maps to a role, the object that inherits an organization, the missing lifetime, the request composed from content an agent read. The remedies are open to any team: a narrow default, a refused blank field, an expiry, a signature with a name on it. Write the sentence one agent would send for one task, then test whether the slip you get back names one operation and one destination or a bundle and an organization.

Frequently asked questions

How do I turn a plain-English request into an agent permission?

Write it as five fields and have a person sign them. A planner takes the actor, the action and the object out of the sentence, resolves each against the repository list, the directory and the grants in force, and drafts the service, resource, operation, destination and lifetime. Nothing is issued until someone reads the slip. Most of the work is refusing to widen a term that did not resolve. The signed slip is short; the standing grant it replaces is usually not.

What does a planner need to read before it drafts?

Metadata, not values. Repository names, the directory that says who may reach them, the roles attached to the requester, the scopes already configured for the agent, the environments that exist. Those are descriptions, and every one can be resolved without holding the credential the grant will unlock. When a term is missing from that metadata, the planner has no basis for a field and should return a question. The check to run is whether the planner can name the resource without ever seeing the key.

What should a permission slip contain?

Five fields and three supporting facts. The fields are service, resource, operation, destination and lifetime. The supporting facts are who requested the access, which run it applies to, and who signed it. A slip missing the destination is a grant that reaches anywhere; one missing the lifetime is a grant that never ends. Keep the whole thing on one screen, because a reviewer who has to scroll is reviewing a document rather than a decision. Refuse a slip with a blank field.

Why not grant the role the agent asks for?

Because a role is the console's unit, not the task's. "Access" in a sentence usually means reading, and the role that grants reading in most systems also carries write, delete and administration. A planner that maps the request to that role has granted more than was asked and more than a reviewer would approve if the fields were written out. The narrow mapping takes one more step, from the operation to the smallest permission, and that step is where least privilege is actually decided.

Who should approve a permission slip?

A named person who owns the resource or the system it belongs to, and never the agent that asked. The approver needs to see the five fields, the requester and the expiry in one view, and to be able to refuse without a justification loop. Approval by a queue, a policy engine or a default is a different control and should be labeled as one. The point of the signature is that one person can be asked, afterward, why this access existed.

What should happen when a request is ambiguous?

The planner should return a question, not a grant. "This repository" with two hundred repositories in the workspace is a term that did not resolve, and the safe output is a list of candidates for the requester to choose from. A system that widens instead has turned an ambiguity into an organization-wide grant, and it will do so again on the next request. Ambiguity is cheap to settle before the slip is signed and expensive to find in a log.

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 One-Line Request From Becoming Broad Access

A plain-English request leaves fields blank for the system to fill with defaults, and vendor controls scope a credential while leaving the drafting to the customer.

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

Before: the access page renders the account, every repository in reach and the full role list, and the grant is whatever the console accepts. Inside: the repository renders as REPO_004, the model drafts against that token, and a person signs that page.

RedactSure is deploying now with enterprise and government customers. Injection tests in agentic coding editors reached success rates as high as 84%.

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

See it on your own workflow

A one-line request in plain English is easy to approve and just as easy to over-grant. Bring a request your team makes today and see, with test values, the permission it becomes and the page a person signs. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.