Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Who Should Decide What a Coding Agent Can Access?

The developer who owns the credential and knows the task, because a team policy can set the menu and an administrator can revoke a grant, but only the person who answers for the run knows how narrow the grant should be. Ask who signs, what the policy bounds, and which record shows the two together.

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

Access for a coding agent is settled three times before the agent acts, and the three are easy to confuse. A credential is issued, a team policy names the repositories and operations that may be used at all, and a person hands the agent a grant for one task. The first two are infrastructure choices with a long life. The third is the only one that knows what the task is, and it is the one teams most often leave to whoever launched the agent.

The argument of this page is that the third decision belongs to the developer who owns the credential and understands the work. That person can tell a clone from a push, knows whether a test database holds real customer rows, and will be asked afterwards what the agent was doing. A team policy still bounds the choices, an administrator still holds revocation, and the developer decides inside both limits.

The record used throughout is a developer signing a grant under a team policy: one task, one repository, one operation. The page sets the scope of a governed browser environment, gives the case for the credential's owner as signer, separates what a policy can decide from what it cannot, reads what the vendor pages document about identity, custody and consent, and closes with what a governed environment adds at the moment of action. A team that cannot name the signer of a grant cannot say who chose what its agent may reach.

Key findings

  • Teleport's framework states that agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key," which settles who the agent is and leaves open what this task may reach (Teleport, 2026).
  • Datadog reported that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a durable key in a pipeline where no person decides per run (Datadog, 2025).
  • OWASP's non-human identity list separates secret leakage, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," from overprivileged identities, two failures of a decision made once (OWASP, 2025).
  • Basak et al. present "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," the population a grant decision is drawn against (Basak et al., 2023).
  • A governed environment replaces values with consistent tokens before any model reads the screen, so an agent working a repository settings page holds a placeholder such as TOKEN_004 rather than the credential (Enterprise Browser or Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, and a named person approves each consequential change (What Is Supervised Delegation?).

Where does the decision about a coding agent's access sit?

The decision is made three times before a coding agent acts, and each time by a different hand. A credential is issued: an administrator creates a token, or a platform assigns an identity, and that fixes the widest reach the agent could have. A team policy bounds the menu: which repositories, which cloud accounts, which operations are allowed at all. A grant is signed for one task: this repository, this operation, this run. The first two are decisions about infrastructure that outlive the task. Only the third is a decision about the work in front of the agent.

A governed browser environment covers what the agent reads and does on a rendered page, which is where all three decisions surface: the token settings page, the repository access page, the cloud console, the grant screen. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A grant assembled in a shell is governed by the credential and the code host, not by a browser control, and the browser side is what this page can describe.

The record here is a developer signing a grant under a team policy. The policy has already named the repositories the team allows and the operations it permits, so the grant's job is narrower: one task, one operation, one run, with a name attached to the choice. Guidance for cloud setup says access keys should not be created for a root user, which rules out the simplest way an agent receives durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). When the three decisions are not separated, the widest one quietly becomes the answer to all three.

Why is the developer who owns the credential the right signer?

The case rests on knowledge that sits nowhere else in the organization. The person who asked for the task knows whether the agent needs to read a repository or write to it, whether the test database holds real customer rows, and whether the deploy key is the one that reaches production. An administrator sees a request for a token and a repository name; the developer sees a task and can say which operation it needs and which it does not. Arcade states that "Even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed," a limit the person who knows the task can set and a policy written in advance cannot (Arcade, 2025).

The second qualification is consequence. A grant is a statement that someone will answer for what the agent does under it, and the developer who requested the run is the person a reviewer will ask. A policy cannot hold that answer, because a policy does not know it was applied to this task.

The third is possession. The developer already holds the credential the grant covers, or can see the account it belongs to, which is why the choice can be made at the moment it matters rather than in a quarterly access review. The count of exposed credentials is the scale the decision works against: the review of API-key handling records "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by a coding agent leaking at about double the baseline rate (How Do You Let an AI Agent Manage API Keys Without Reading Them?). Some grants also cover steps that cannot be undone, which is why the person who will answer for the bill is the one who should sign (How to Use AI Agents to Launch an EC2 GPU Instance).

What can a team policy decide, and what must it leave to the developer?

The policy is the part of the decision a team can write down before any task exists, and its virtue is that it does not depend on anyone remembering it. It can name the repositories in scope, the operations permitted on them, the environments an agent may touch, the longest a grant may live, and the identity a grant is issued under. What it cannot do is read the task. A policy that permits writes to a staging repository cannot tell whether this agent needs to write or only to read, and a policy generous enough to cover every task the team runs is generous enough to cover the one task nobody wanted.

Decision The policy can set The grant narrows it to What to verify
Repository The set in scope One repository The settings page shows the same name
Operation Read, write, clone, push, deploy The one this task needs The grant names it, not the token's maximum
Environment Accounts and stages permitted One account and one stage Production is absent, not merely unused
Lifetime A maximum This run The record shows when it closed
Approver Roles allowed to sign One named person The record carries the name
Exceptions Whether any exist Nothing A path around the policy is the finding

Two things sit outside the policy: the narrowest form this task can take, and the moment of use, when the agent finds it needs more than the grant allows. Microsoft's page on managed identities describes a design where the platform decides instead, stating that "Managed identities eliminate the need for developers to manage these credentials," which is a design for Azure resources rather than for a session in a browser and moves the decision to whoever configured the role (Microsoft, 2026). An administrator keeps one lever either way: revocation. The guidance that a super admin account should be used only when needed was written for people and applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

A policy that stops at the menu leaves two questions it cannot answer: which operation this task needs, and whether the agent's reach has grown since the grant was written. Both belong to the person who will answer for the run.

What do the vendors themselves say?

The vendor pages reviewed describe identity, custody, consent and platform assignment, each a real control that decides something else.

Teleport's page also lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," which records what an identity did rather than who chose its scope; the page marks most listed capabilities "In-progress" or "Not started" (Teleport, 2026). Infisical's Agent Vault page puts the custody argument plainly, that "the agent should not be trusted with direct access to any secrets," and adds that its proxy "terminates TLS" (Infisical, 2026). Composio's documentation states that the user "signs in on the hosted link and Composio stores the resulting connected account," which places the decision at a consent screen the user completes, though the page does not describe how the stored credential is encrypted (Composio, 2026). Arcade describes the same pattern at the point of need: "When the agent needs Slack access, that's when you handle the OAuth flow," a consent at first use that says nothing about a second action (Arcade, 2025). Microsoft's page adds "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," so no developer holds a value or signs for the task (Microsoft, 2026).

A per-task grant with a signer is not described in the pages reviewed; what the pages answer is who the agent is, where the credential lives, whether the user agreed, and what the environment allows.

What goes wrong when the decision is made once and never revisited?

The failure is not that the first decision was wrong. It is that the decision is made at issuance and then inherited by every task that follows. A token created for a migration keeps working after the migration, and a grant copied from a template carries permissions nobody chose for this run. The non-human identity list cited above names two of the results: overprivileged identities and credentials leaked to stores nobody sanctioned. Neither needs an attacker in the loop.

The second failure is trusting a detector to make the decision. Chennabasappa et al. report that PromptGuard 2 "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches," an improvement their abstract gives no numbers for, so a detector lowers the odds without deciding what an injection can reach (Chennabasappa et al., 2025). A detector that misses once still leaves the agent holding whatever the grant allowed, which is why the scope has to be small enough that a miss is survivable.

The third is install rights. Spracklen et al. found that "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models," so an install permission lets the agent fetch names it may have invented, though the abstract does not say whether any invented name was registered and exploited (Spracklen et al., 2025). The person who signs the grant is choosing that reach, whether or not they thought about it at the time.

The fourth is revocation. An administrator can withdraw a grant, but only the person who knows the task has ended knows when to ask. The gap between them is the window a stale grant lives in, measured in days.

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_TOKEN_004. 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, which is the operating model described in What Is Supervised Delegation?. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring, which is the artifact the decision leaves behind (What Is an AI Control Record?).

For this page's question it changes where the decision is visible. A credential decision shows up in a settings page and an access review; a grant decision shows up only if someone wrote down who chose it. Under the governed environment the choice is attached to the action: the agent proposes, a named person approves, and the approval lands in the record beside the screen as the model saw it. That is a different artifact from an access review, because it answers a question about a run rather than a question about an account.

The scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a grant exercised in a shell still depends on the credential and the code host. What the governed environment adds is the part a credential cannot express: a name at the moment of the action, and a record of what the model was shown when the action was proposed.

Methodology and limitations

This page rests on three research preprints on package hallucination, credentials in source code and injection detection, vendor documentation from Teleport, Infisical, Composio, Arcade and Microsoft, OWASP's non-human identity list, one vendor research report from Datadog, 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 vendor research are reported as the vendor states them, not as independently measured. Datadog's report is a customer-base sample, and its figure describes the customers in it rather than the population of engineering teams.

RedactSure did not test any of the named products hands-on. The phrase not described in the pages reviewed means the pages reviewed do not record a mechanism, not that a vendor does not offer it, and a per-task grant with a signer is one such case. Vendor features change and the page carries its date, so a release after it should be treated as 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 example describes a record type, a developer signing a grant under a team policy, and not an organization.

Determinations about whether a particular access design meets a contractual, audit or regulatory 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 credential, and a control that is not tested against those remains a claim on paper. Whether a named approver satisfies a particular framework depends on the framework and on the evidence the record can produce.

What the record shows

The answer the record supports is a division of labor rather than a single owner. A team policy sets the menu, an administrator keeps revocation, and the grant for one run belongs to the developer who owns the credential and can judge the task. Only that arrangement puts a name on the narrowest decision, and the names are what an access review cannot supply, because a review asks about an account while an incident asks about a run. RedactSure's environment is built to attach the name at the action rather than at the account. Picking one agent and one task gives a simple test: ask who signed the grant, then read the record and check whether that name appears beside the action it authorized.

Frequently asked questions

Who should decide what a coding agent can access?

The developer who owns the credential and will answer for the run, inside a policy the team writes in advance. That person knows which operation the task needs and which environment it touches, and a policy cannot read the task. An administrator still sets the allowed repositories and can revoke a grant, but revocation is a correction rather than a decision. Put the choice where the knowledge is, then make the choice legible to everyone else who has to live with it.

Can a team policy make the decision instead?

Yes for the outer bound and no for the narrow one. A policy can name the repositories, operations, environments and maximum lifetime that any grant may use, and it applies without anyone remembering it. What it cannot do is tell whether this task needs a read or a write, or whether the agent's reach has grown since the grant was written. Policy text also ages, because the repositories it names change. Use the policy to shrink the menu, and keep the per-task choice with a person.

What should a grant name?

One repository, one operation, one environment, one run, and a named approver. The grant should name the operation explicitly rather than inherit the token's maximum, so a clone grant refuses a push and a read grant refuses a write. It should also carry an end, because a grant with no end is inherited by the next task. Anything the grant cannot name belongs in a separate decision with its own reason. Write it for the task in front of the agent.

Why not let the administrator decide?

Because an administrator sees requests rather than tasks. The request says a token is needed for a repository; it does not say whether the agent will read a customer table or push to production, and the administrator has no way to find out before approving. Administration is better used for the bounds and for revocation, where one person can act quickly and consistently. The exception is a break-glass path, which should be logged and reviewed afterwards. Decisions about a single run belong closer to the work they cover.

What does the developer actually sign?

An identity attached to a specific grant, so the record shows who chose that scope for that run. The vendor pages reviewed describe identity, custody and consent, and none of them records a signature on a per-task grant, so a team should ask how its own tooling records the approver. If the record cannot show a name beside the action, the grant was issued rather than decided, and nobody can be asked about it later.

What should a reviewer check in the record?

Start with the grant rather than the token. Check that it names one repository, one operation and one environment, that its lifetime ended when the run ended, and that the approval carries a person's name. Then check the screens the model read: values or placeholders. A record that answers both questions lets a reviewer separate a scope that was too wide from a control that was never applied to the run. If either answer is missing, what you have is a log rather than an account.

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 Puts a Named Person on the Grant

The pages reviewed put the decision in a vault, an identity platform or a consent screen, each settling custody rather than who chose this scope.

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

Before: the agent opens the token settings page and the value renders in full. Inside: the page renders REPO_TOKEN_004, the grant names one repository and one operation, and a named person approves the first write.

RedactSure is deploying now with enterprise and government customers. Datadog found that 37 percent of the customers who send it CloudTrail logs use IAM users in GitHub Actions.

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

See it on your own workflow

A grant should carry the name of the person who decided it. Bring a task your team would grant and see, with test values, the repository, the operation and the approver it names. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.