Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is a Permission Slip for an AI Agent?

A permission slip is the reviewable form of an agent grant: the service, resource, operation, destination and lifetime written down, with the name of the person who approved it and never the credential itself. Ask to see the slip behind an agent's access and check what the agent holding it can still read.

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

An agent's access usually exists twice, and only one of the two copies is readable by a person. The first is the token, session or role a service issues, whose scope lives in a settings page and a policy document. The second is the slip: the same grant written in the words of the task, with the limits spelled out and a signature at the bottom. A developer who holds only the first copy cannot answer a reviewer's question about why the agent could reach a second repository, and a reviewer who holds only the first copy cannot tell whether anyone decided the access was appropriate or whether it accumulated one setting at a time.

The word matters because it is used for three different things: an OAuth consent screen, a scoped token, and a document a person signs before a run. Only the third can be reviewed by someone other than the person who requested it, and only the third names an owner. That makes the slip the record a reviewer should ask for, and its fields can be read against what HashiCorp, AWS and GitHub document about leases, sessions and default permissions, with the credential kept off the paper and a named person signing it. The worked record throughout is a request to give a coding agent read access to one repository, written as a slip.

Key findings

  • A permission slip is the reviewable form of a grant: service, resource, operation, destination, lifetime and approver on one page, with no credential in the text (What Is an AI Control Record?).
  • HashiCorp's Vault documentation states that "all dynamic secrets in Vault are required to have a lease" and that revoking one "invalidates that secret immediately and prevents any further renewals," so a lifetime is a property of the credential (HashiCorp, Lease, 2026).
  • AWS's AssumeRole reference states that "the resulting session's permissions are the intersection of the role's identity-based policy and the session policies," so a session policy narrows a grant but does not widen it (AWS, 2026).
  • GitHub's Actions documentation calls it "good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents" (GitHub, 2026).
  • A governed environment renders consistent tokens before any model reads the screen, 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?).
  • Wiz reports that "we looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub" (Wiz, 2025).

What does a permission slip for an AI agent record?

A slip records one grant for one task, in a form a person can read without opening the system that enforces it. The slip is the document; the token, session or role that carries the grant is the mechanism. Six things belong on it: the service, the resource, the operation, the destination, the lifetime, and the name of the person who approved it, with the date. The task itself is written at the top in the requester's own words, so a reviewer can compare the sentence with the fields below it.

The worked record for this page is a request a developer types: "Give my coding agent read access to this repository." Written as a slip, it reads: service, GitHub; resource, one repository named by owner and name; operation, read of contents and pull request metadata, with no write; destination, the repository pages the agent may read and the pull request it may open; lifetime, until the run ends; approver, the developer who signed, with the date. Nothing on the slip is a credential. The repository name is metadata, and the credential the agent will use is named by the record that holds it.

Where the control applies matters before the fields do. A governed browser environment covers what the agent reads and does on a rendered page: a repository page, a 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. The same sentence typed into a shell, where an agent clones a repository with a token in its environment, sits outside that boundary; what governs there is the token's lease and the service's policy.

Which fields make a slip reviewable, and where do they come from?

A slip is written from two inputs, and neither of them is the credential. The first is the sentence the requester typed. The second is metadata: the names of accounts, repositories, environments and credential records, taken from the systems that hold them, not the values those records protect. A reviewer can check the first against the second, which is what makes the review possible rather than ceremonial.

Field What the worked example records What a reviewer checks
Service GitHub, the system that will accept the request That no second service is implied by the task
Resource One repository, named by owner and name, never a wildcard That the name matches the repository in front of them
Operation Read of contents and pull request metadata; write excluded That every verb on the slip is a verb the task needs
Destination The repository pages the agent may read and the pull request it may open That no other host or page appears
Lifetime Until the run ends That the enforcement point expires the credential, not a reminder
Approver A named person, with a date and the task sentence That the signer answers for this run
Record Where the slip, the approval and the run's actions are kept That the record exports to the organization's own monitoring

A missing field does not narrow a grant; the mechanism fills the gap with its own default. Each field moves a choice from that default to a named person's signature.

The destination field is the one reviewers skip. A page is not a fixed address: a form that accepts a URL, a redirect that follows a query parameter, or an agent that opens a second tab all move where a value can land, 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, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? sets out.

Read in order, the fields answer three questions: what may the agent touch, where may the result go, and how long does the permission live. A slip that answers all three can be reviewed by someone who was not in the room.

What do the vendors themselves say?

Three vendor pages describe how a grant is carried and bounded, and none of them describes the slip a person signs.

HashiCorp's response-wrapping page states that "a new single-use token is generated with the TTL supplied by the client," which puts the lifetime choice with the party asking for access (HashiCorp, Response, 2026). It adds that "Vault currently does not provide signed response-wrapping tokens, as it provides little extra protection," which draws the line this definition needs: a wrapping token carries a grant but records no approver (HashiCorp, Response, 2026).

AWS's AssumeRole reference gives a duration that "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," and notes that "role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, 2026).

GitHub's documentation says to "pin references to actions to a commit SHA in your workflow files" and to "audit how secrets are used, to help ensure they're being handled as expected" (GitHub, 2026).

Centralized credential management removes the need to embed credentials in agent code or configuration files (Does AWS Bedrock Keep Company Credentials Away From Agents?).

Dimension HashiCorp Vault, per its documentation AWS STS, per its documentation GitHub Actions, per its documentation What a buyer should verify
Lifetime A wrapping token's TTL supplied by the client; a lease with a TTL 900 seconds to the role's maximum; one hour when roles are chained Not stated for an agent's run That the slip's lifetime matches the shortest bound
Scope A credential named by policy; a wrapper that works once Intersection of role policy and session policy Default token permission read-only for contents That the scope is narrower than the role, not equal to it
Revocation Lease revocation invalidates the credential immediately Not stated on the AssumeRole page Revoke the workflow token That a run can be stopped mid-flight
Signature Not provided for wrapping tokens Not stated Not stated That a named person approved this run
Record Not stated Not stated Guidance to audit how credentials are used That the record leaves the vendor's console

Read together, the documents cover the mechanics of a grant and leave the accountable document to the buyer. Whether a lease or a session can be tied to a named approver is not described in the pages reviewed, and that is the gap a slip fills.

Why must the slip leave the credential out?

A slip is a document. It gets stored in a repository, attached to a ticket, pasted into a review and read by people who were not part of the run. If the value is written on it, the slip becomes one more place a credential lives.

The research record is the reason to keep the value off it. Huang et al. report that "two valid credentials were identified during our experiments," and that the tools "can not only return the precise piece of their training data," which is why a value that reaches a model-facing document should be assumed repeatable (Huang et al., 2024). SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," which is the population a slip carrying a live value would join (Basak et al., 2023). GitGuardian's State of Secrets Sprawl 2026, reported by CIO Dive, counts about 29 million credentials leaked on public GitHub in 2025 and an 81% rise in AI-service leaks, with its CEO saying "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

What goes on the slip instead is a name. A credential record carries the account, the environment and the credential's own name; the enforcement point resolves the value at the moment of use, and where a page would display it, the environment renders a token. Skyflow describes tokenization as exchanging a sensitive value for a pseudorandom token that carries no exploitable value on its own (RedactSure vs Skyflow: 2026 Comparison & Alternative), a definition written for stored data that does not say what a model reads on a page.

Who signs a slip, and what does signing oblige?

A signature is a name, a date and a task sentence. A team alias is not a signature, and neither is a consent screen or a chat approval that never reaches the record.

What signing obliges is larger than a click. The signer accepts the destination and the lifetime, and the record has to show it. Most enterprise agent deployments cannot name the person accountable for a given action, and after an incident that absence becomes the first audit finding (What Is Supervised Delegation?). The record of agent work is scattered across consoles and logs, and neither says what the model saw (What Is an AI Control Record?).

Two named risks sit on either side of the signature. OWASP's non-human identity list defines NHI2 Secret Leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and its NHI5 is overprivileged identities (OWASP, 2025).

An unsigned, unbounded grant is the risk in practice: a single login that bundles workflow access with value access grants a model more functionality, permission or autonomy than its task requires (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?).

A signature covers the fields on the slip and the task sentence above them, and it ends with the lifetime the slip names.

What does a governed environment change?

A governed environment moves the grant from the agent's context to the screen the agent reads. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works on REPO_014 and PAT_001 for the whole run. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the 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 a slip, that changes what the signature has to cover. On a token-only arrangement, the signer approves a scope and hopes the page shows nothing else; under substitution at the render layer, the signer approves what the model may see. The destination field becomes enforceable rather than descriptive, since the value resolves at the named destination and not at any other page.

It also changes what a reviewer can check afterwards. A grant leaves logs at the service; a governed environment leaves a record of the screens as the model saw them, the actions taken on them, and the name on each approval.

The boundary is worth stating plainly. This control class governs the rendered page; it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. A slip for a repository page is inside that boundary, and a slip for a command that clones the repository in a shell is outside it.

Methodology and limitations

This page rests on two research preprints on credentials in code and credentials in source, on vendor documentation from HashiCorp, AWS and GitHub, on OWASP's non-human identity list, on one vendor research report from Wiz and one industry analysis from GitGuardian as reported by CIO Dive, and on existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted sentences are cited to the page that states them, and figures from vendor research are cited as the vendor reports them.

RedactSure did not test any of the named products hands-on. Where this page says a behavior is not described in the pages reviewed, it means the pages listed in Sources, read on the dates given. Vendor features change and the page carries its date, so a release after that date is unreviewed until the test below is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked example describes a record type, a request to give a coding agent read access to one repository, and not an organization. The attack-success figure quoted in the destination discussion comes from the page cited there and describes one measured study, not a general rate for web agents.

Determinations about whether a grant, a consent screen or an access review 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 and its own record. A reader who needs a defensible answer for an auditor should take the slip, the log and the record to that reviewer, not this page.

What the record shows

A slip is worth having because it is the only part of an agent's access that a person can read before the run and check after it. The vendor pages reviewed supply the mechanics: a lease that expires, a session that narrows, a default permission that withholds write. None of them records who approved the access, and the research record on credentials in source explains why the value should never be written beside the grant. A slip answers both questions on one page: what the agent may touch, where the result may go, how long the permission lives, and whose name is on it. RedactSure's environment adds the exposure half, the tokens the model sees and the record of what it was shown. To test a slip, write it for one agent and one task, then open the page the agent reads and check whether the value appears on it.

Frequently asked questions

What is a permission slip for an AI agent?

It is the written form of a single grant: the service, the resource, the operation, the destination and the lifetime, with the name of the person who approved it. Unlike a token, it is meant to be read by someone other than the requester. The slip is what a reviewer compares with the request, and it survives the run as the account of what was allowed. Read it before the run and keep it beside the record afterwards. A slip is not a token.

What should a permission slip contain?

Six fields: service, resource, operation, destination, lifetime and approver, with the task sentence at the top and a pointer to the record. Anything less leaves part of the grant to the mechanism's default. The fields are worth arguing about at review time because each one moves a choice from a default to a signature. Write the task sentence first, then the fields, so the slip reads as an answer to the request.

Does a permission slip replace an OAuth scope or an IAM policy?

No. A scope and a policy are enforcement objects, read by a service at request time, and neither is written for a person to review before the run. The slip sits in front of both and names which scope or policy the agent will use, for how long, and on whose authority. The policy still does the enforcing. If a reviewer cannot tell from the slip which scope was granted, the slip is too vague to audit. The two work together, and neither substitutes for the other.

Should the credential appear on the slip?

Not if it can be avoided. A slip is stored, shared and often committed, so a value written on it becomes one more credential in a file that people copy. Name the credential record instead and let the enforcement point resolve the value at the moment of use. Where a page would display the value, a governed environment renders a token such as PAT_001 in its place. Keep the value where enforcement can reach it. A slip that carries the value has failed the test it was written for.

Who should sign a permission slip?

A named person with the authority to accept the destination and the lifetime, not a team alias and not the requester's manager by default. The signer should be able to read the task sentence and the six fields and say what the agent may touch and where the result may go. If no one can answer both questions, the slip is not ready. Ask for the name and date on the slip itself, not in a ticket comment beside it. A slip signed by nobody is a draft.

What does a slip look like for a coding agent that reads one repository?

Service GitHub, resource one repository by owner and name, operation read of contents and pull request metadata, destination the repository pages and the pull request the agent may open, lifetime the run, approver the developer who signed. Nothing on it is a credential. The credential is named by its record, and the pages the agent opens should show tokens rather than values. Read it against the pages the agent actually opens before the first run, and keep the record beside it afterwards.

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 Makes a Signed Slip Match What the Agent Reads

A slip can name a destination and a lifetime, and a lease, a narrowed session or a withheld write still leave unchanged what a page shows the model.

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

Before: the agent opens the repository's token settings page, creates a fine-grained token, reads the value the page shows once, and can paste it into its next pull request. Inside the governed environment: the page renders REPO_014 and PAT_001 in place of the repository name and the value, and the real token resolves only on approval.

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

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

See it on your own workflow

A permission slip is only useful if it matches what the agent actually reads. Bring a token task and compare, with test values, the slip with the page the model receives. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.