Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Plan Agent Permissions Without Exposing the Credentials?

Plan from metadata: which accounts exist, which credentials exist by name and scope, and which service each belongs to, so the planner never reads a value. Ask which of those fields a tool gives its planner, and who approves the grant the plan produces.

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

Whoever approves an agent's permissions needs a plan that can be reviewed, and the safest version of that plan never contains the thing it protects. It can name the account, the credential, the service the credential belongs to, the scope and the expiry, and the person who approves the grant, and still be complete enough to review, because a planner works from descriptions rather than from values. The difficulty is that most tools describe a grant and then need the value to test it, and a test that reads a credential has moved it into the model's context. The surface matters too, because a plan made on a rendered settings page and a plan for a shell command fail differently. The vendor pages reviewed describe scoped credentials, and the fields of a plan belong on paper before any value does. A plan can also be complete and exposed at once: it can name every credential a repository holds, pass review, and still put a value in front of the model on the page where the credential is displayed. The reference example throughout is a plan built from credential names only, taken from a repository's settings page where names, scopes and dates are rendered and values are not. An approver should review the page a plan was built on as well as the plan.

Key findings

  • Agent Security Bench reports "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," and no single step of the run is where a plan can safely put its trust (Zhang et al., 2025).
  • A study of neural code completion tools found that "two valid credentials were identified during our experiments," evidence that a value which reaches model-facing text can return in later output (Huang et al., Your, 2024).
  • Anthropic's documentation writes a permission rule against a path rather than a value and states that "If your project has a .claudeignore file, it has no effect, so move its entries into Read deny rules" (Anthropic, 2026).
  • Doppler tells teams to "Give every coding agent its own scoped, read-only, expiring set of credentials," a grant described by scope and lifetime rather than by value (Doppler, 2026).
  • A governed environment replaces a value with a consistent token such as ACCT_001 at the render layer, before any model reads the screen, so a planner working from tokens never holds the credentials behind them (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, which keeps the planning step from becoming a second copy of the credential store (What Happens When an AI Agent Can See API Keys in a Console or Settings Page?).

What does a governed browser environment cover when an agent plans permissions?

A governed browser environment covers what an agent reads and does on a rendered page: a repository's settings page, a cloud console, a dashboard, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The boundary matters here because the values a plan must avoid often sit in those other places, in an environment file, a shell profile or a local keychain.

On a page, the plan is built from what the page renders. A repository settings page lists workflow credentials by name and environment, deploy keys by title and fingerprint, and tokens by scope and expiry. None of those fields is a value.

The record for this page is a plan built from credential names only: an agent asked to prepare a permission review reads that page, records the name, environment, scope and last-updated date for each entry, and returns a table. The question that follows is who may read the table, and whether a page the agent never opened would have shown a value.

A tether describes authority rather than capability, and a plan should be read the same way: a tethered agent goes where its supervisor could go, so the plan has to say which pages that is (What Is a Tethered Agent?). Two limits follow. The plan governs the rendered page and says nothing about a shell command that reads the same credential from a file, which belongs to a sandbox and a credential store. And a page is not a store: if the settings page renders the last four characters of a token for identification, those characters are on the page and in the model's context, so the rule has to cover what is rendered as well as what is stored.

Which fields belong in a permission plan before any value does?

A plan that never holds a value still needs enough detail to be approved, audited and tested. Seven fields carry most of that weight: the identity the agent acts under, the credential by name, the service it belongs to, the scope of the grant, the expiry or rotation date, the person who approves, and the destination where a real value may resolve.

The order matters. Identity comes first, because a plan that begins with a shared credential has already lost the argument, and reach comes second. 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," a risk about where a value sits rather than about what a page shows (OWASP, 2025). The same list names overprivileged identities as NHI5, so a plan has to govern reach as well as values (OWASP, 2025).

Scope is the field teams leave coarse most often: a scope written as a service and an environment can be checked against a page that lists the same two fields, and a scope written as an account name cannot.

What the plan should not hold is a value, a partial value or a screenshot. A fingerprint is metadata, because it identifies a key without reproducing it. The last four characters of a token are not metadata. They are a fragment of the credential, and a page that renders them has already put part of the value in the model's context. The design rule that follows is narrow and testable: the planning step reads the index of names and scopes, and every value stays behind a destination the plan does not contain.

What do the vendors themselves say?

Teleport's Agentic Identity Framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," while the same page marks most of its listed capabilities "In-progress" or "Not started" (Teleport, 2026). It also documents "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," a record of what an agent did rather than of what it read on a page (Teleport, 2026).

Anthropic's page writes the rule as a path: "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path, such as Read(./.env) or Read(./secrets/**)," which governs the file tools and not the value a rendered page shows (Anthropic, 2026). The same page adds that deny rules "don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file," so a recursive search can still return what the rule was meant to hide (Anthropic, 2026).

Cognition's Devin guide says "In the browser, Devin types the value directly," and whether the model sees that value is not described in the pages reviewed (Cognition, 2026). For commands, it "binds secrets as environment variables whenever needed," which places the value in the process and does not change what a page renders (Cognition, 2026).

Vendor What its documentation states What a buyer should verify
Teleport An agent needs a cryptographic identity tied to where it runs, with audit trails for agent actions Most listed capabilities are marked "In-progress" or "Not started"; certificate lifetime is not given
Anthropic A Read deny rule blocks the file tools by path; a .claudeignore file has no effect Deny rules do not apply to a command that reads files without naming them
Cognition Credentials scoped to organization, person, repository or session; browser typing and shell environment binding Whether the model sees a value typed in the browser is not described
Doppler Scoped, read-only, expiring credentials per agent, injected at runtime rather than written to a .env The page does not say whether the agent can read variables injected into its own process

Why can a complete permission plan still expose a credential?

A plan can list every credential correctly and still be exposed, because the plan governs what the agent may do and not what the screen it reads contains. An agent reviewing a console's API keys page reads the key table the way a person does, and the table is rendered to the model with whatever values the page shows.

The research record explains why one reading is enough. Hidden prompts embedded in submitted documents steered the models asked to review them, with the authors concluding that "adversarial prompts can reliably mislead the LLM" (How Do Malicious Documents Take Control of AI Agent Behavior?).

The volume behind the risk is large. GitGuardian's count of "28,649,024 new secrets exposed in public GitHub commits across 2025," recorded in How Do You Let an AI Agent Manage API Keys Without Reading Them?, is the set of values a page-level control keeps out of the model. Truffle Security reported "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," though the post does not establish that the training data behind it included those pages (Truffle Security, 2025).

A plan built from names is necessary and not sufficient. It closes the planning step, where an agent could read a value while checking a grant, and leaves the operational step, where the agent opens the page the credential lives on. Two routes bypass both: a shell command that prints a value, and a recursive search that returns a file the rule never named.

How do you test a plan built from credential names only?

Give one agent one planning task, a permission review of a repository's settings page, and capture what the model received at each step: the table it built, the pages it opened and the fields it read.

A plan built from names passes if the transcript holds names, scopes, dates and destinations, and no value, no prefix and no last-four fragment. It fails if the agent opened a page that renders a credential, even when the task never asked for it. Run the same test on a sign-up or checkout form, where Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? records a measured attack on generalist web agents.

A shell command that prints a value is outside a browser control. Microsoft's managed identity documentation states that "Managed identities eliminate the need for developers to manage these credentials," a design for Azure workloads rather than for a page an agent renders (Microsoft, 2026). The same page says "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," which keeps a credential out of a file and leaves the question of what a page renders open (Microsoft, 2026).

The AWS guidance against root access keys, in Is It Safe to Let an AI Agent Set Up Your Cloud Environment?, makes the same point about the durable credential: the key that must never exist is the one no plan has to protect.

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 ACCT_001, PATIENT_001 or CARD_001. 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. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For a permission plan, the control class changes two things. The plan can be built, reviewed and tested with tokens in place, so the planning step no longer carries a value. And the work that follows the plan runs on the same tokens, so the page an agent opens during the run shows placeholders rather than credentials, and the record states what the model saw.

The order is deliberate: tokens before any model reads the screen, because a control that acts after the read has to recover a value rather than prevent its exposure; destination next, because a token that resolves anywhere resolves too early; approver and record last, because a consequential action needs a name and a record behind it.

What the control class does not do is part of the definition. It governs the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a plan that covers a browser and a shell needs a second control for the shell. It governs what the model sees rather than what the agent may do: a grant can be too broad while every screen is tokenized, which is why a permission plan and a render-layer control are complements rather than substitutes.

Methodology and limitations

This page rests on nine recorded sources: two research preprints, including a benchmark of agent attacks and defenses, one vendor research post on live credentials in web data, vendor documentation from Teleport, Anthropic, Cognition, Doppler and Microsoft, OWASP's non-human identity list, and three existing 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 the study figures are cited as their publishers reported them, not as measurements made here. A vendor behavior the page mentions is one its documentation states, and a behavior the documentation leaves out is not claimed here.

RedactSure did not test any of the named products hands-on. Where this page says a behavior is not described, it means the vendor pages reviewed for it do not describe it, not that the vendor does not do it. Vendor features change and the page carries its date, so a release after that date should be treated as 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, a plan built from credential names only on a repository settings page, and not an organization.

A permission plan is also an organizational decision. Determinations about whether a plan or a 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 review of the organization's own agent against its own pages, repeated after each change to the tools it uses.

What the record shows

The record on this question is consistent across the sources. A credential scoped by name, duration and destination is the design vendors document and the design a plan can hold without reading a value. A rule written against a path, a scope applied to an agent and a credential bound into a process each govern what an agent may do, and none of them states what a model received on the screen where the plan was made. The research adds the reason to care about that gap: defenses show limited effectiveness, models return values they were shown, and live credentials already sit in data outside any store. A plan built from names closes the planning step and leaves the page. The practical next step is a test: run one agent on one planning task against a repository settings page that holds at least one credential and write down every field the model received.

Frequently asked questions

Can an agent plan permissions without reading the credentials?

Yes, if the plan is built from fields the page already renders: the account, the credential's name, its scope, the service it belongs to and the date it was last changed. None of those is a value, and a reviewer can check all of them without opening the credential. The exception is a page that renders a prefix or the last few characters, which is a partial value. Confirm which of the two a settings page shows, and name the field the plan will read, before calling the plan value-free.

What counts as metadata in a permission plan?

The identity the agent acts under, the credential by name, the service, the scope of the grant, the expiry date, the approver and the destination where a real value may resolve. A fingerprint usually counts, because it identifies a key without reproducing it. A prefix or a last-four fragment does not, because it is part of the value. The distinction is what the field lets a reader do: identify a credential, or use one. That is the question to put to the page before the plan is written.

Is a deny rule enough to keep a credential out of the model?

No. A rule written against a path blocks the agent's file tools from opening that path, and the documentation reviewed here says such rules do not apply to a command that reads files without naming them. A rule also says nothing about the page where a credential is rendered. Treat a deny rule as one layer, and ask separately what the model receives on each screen. Ask what the page shows, not only what the rule blocks.

Why does the settings page matter if the plan never opens a credential?

Because the plan is not the only thing the agent reads. A planning run often opens the page to confirm a name, an environment or a date, and the page renders whatever the page holds. If a value appears beside the name, the model received it during a task that never needed it. Check the transcript for the planning run, not the plan. The page is the part of the run the plan cannot see, and a screenshot of it carries the same exposure.

Do scoped and expiring credentials solve the problem?

Partly. A scoped, expiring credential limits what a leaked value can do and how long it works, which is worth having. It does not change what a page shows while the credential is valid, and it does not tell a reviewer what the model read. Scope and expiry govern the lifetime of a grant; what the page shows while the grant lives is a separate question. Both questions belong in the same review, asked in that order before the first planning run.

What should a security team ask for in writing before approving a plan?

Ask which fields the planner receives, whether any page it opens renders a value or a fragment, who approves the grant and what that person saw, where real values resolve, and what record shows the model's view screen by screen. Ask for those answers beside a test run. A plan that cannot produce that record is a description of intent, not evidence of control. Name the record before the plan is approved, then test the record against it.

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 Builds a Permission Plan From Names, Not Values

A plan built without values is still exposed when its source page shows one, and the approaches reviewed never record what the model received on screen.

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

Before: the agent opens a repository's settings page to plan a grant and the deploy key's value renders beside its name. Inside the governed environment the page shows DEPLOY_KEY_001, the plan is built from names and scopes, and the real key resolves only into the approved destination.

RedactSure is deploying now with enterprise and government customers. Agent Security Bench found every stage of an agent run exploitable, with limited effectiveness from the defenses tested.

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

See it on your own workflow

A permission plan built from names can be reviewed without exposing anything. Bring a task you want to delegate and see, with test values, the plan built from names and scopes. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.