Coding agents need tool-level authorization, not shared developer access

At a glance

What this is: This is a PermitIO analysis of why coding agents need tool-level authorization, with the central finding that shared developer access gives agents far more privilege than their delegated task requires.

Why it matters: IAM and PAM teams need to treat coding agents as delegated actors with per-tool policy and audit, because broad inherited access turns normal development tasks into a high-blast-radius identity problem.

Context

Coding agents are software entities that can take actions inside development workflows, not just generate text. When they can read repositories, run commands, call APIs, and touch CI/CD systems, the question shifts from output quality to authorization boundaries for non-human identities.

The security gap is that many teams still let a coding agent inherit broad access from the developer or a service account. That model breaks once repository content can influence the agent’s next action, because the tool path becomes part of the attack surface.

PermitIO’s article frames this as a delegated access problem rather than a model-safety problem. That is the right starting point for NHI governance, because the control question is what the agent may do in context, not whether the model sounds trustworthy.

Key questions

Q: What breaks when coding agents inherit a developer's full access?

A: Shared developer access breaks the assumption that a task-specific agent only needs the same authority as a human operator. Once the agent can read secrets, edit workflows, and call APIs with one broad credential, indirect prompt injection or simple task drift can turn a normal request into a high-blast-radius identity event.

Q: Why do coding agents need per-tool authorization instead of session-wide permissions?

A: Session-wide permissions ignore that a coding agent may read files, run tests, edit code, and touch CI/CD systems within the same task. Those actions carry very different risk levels, so the decision has to be made at the tool call, using the delegated user, the task, the resource, and the environment.

Q: What are the signs that a coding agent is overprivileged?

A: A coding agent is overprivileged when it can reach high-impact actions that are not required for the task, such as protected branch merges, production deploys, inbox access, package publishing, or secret reads. Another warning sign is when the same credentials persist across tasks instead of being issued and revoked per operation.

Q: How should security teams govern coding agents that can execute repository instructions?

A: Treat repository instruction files as executable input, not documentation. Review AGENTS.md and similar artefacts before unsupervised execution, scan them for shell commands and credential-path access, and enforce allow or block decisions outside the model. The control objective is to prevent untrusted repository content from becoming trusted pre-task execution.

Technical breakdown

Why repository text becomes an instruction channel

Coding agents often ingest README files, comments, issue bodies, docstrings, changelogs, and other repository content as part of their working context. If the agent cannot distinguish untrusted text from task instructions, indirect prompt injection becomes a control bypass rather than a prompt-quality issue. The dangerous part is not that the model is persuaded, but that the agent then acts by invoking tools on the basis of poisoned context. In identity terms, the repository is not just data. It is a potential instruction surface that can redirect delegated action.

Practical implication: Treat repository content as untrusted input and separate read permissions from tool authority.

Why shared developer access creates an over-privilege problem

A coding agent that inherits a developer token or service account can accumulate far more authority than the task requires. That usually means read access to secrets, write access to branches, and reach into cloud or CI/CD systems that should have been out of scope. The core failure is not authentication. It is authorization collapse at the tool boundary, where one broad identity grant is reused for many different actions with very different risk levels. Once that happens, the agent behaves less like a bounded workflow and more like a high-speed proxy for the developer account.

Practical implication: Split agent permissions by tool, resource, and task rather than reusing the human’s full access.

How delegated intent should shape agent authorization

Agentic identity is not just the process identity of the runtime. It is the combination of delegating user, workflow context, task intent, and operating environment. That matters because the same coding agent may be safe to read files, unsafe to modify workflow configuration, and entirely inappropriate for secret access or package publishing. Policy therefore has to evaluate the requested tool call in context, not the session as a whole. This is where per-tool authorization differs from ordinary workload identity: it binds action to intent instead of only binding a process to a machine.

Practical implication: Authorize each tool invocation against the delegated task, not against a generic agent session.

Threat narrative

Attacker objective: The attacker wants the agent to use legitimate developer authority to expose secrets, change code or workflows, and widen the blast radius of a normal coding task.

1. Entry occurs when a coding agent is given repository access and reads untrusted content such as README files, comments, issue bodies, or docstrings during a legitimate task. The attacker’s instructions ride inside the normal workflow.
2. Credential access or abuse follows when the agent is allowed to use broad developer permissions, which may expose secrets, cloud credentials, CI/CD settings, or other sensitive resources to the delegated task.
3. Escalation happens when the poisoned instructions cause the agent to call tools it should not have reached, modify workflow files, or route credentials into actions beyond the user’s intent.
4. Impact is achieved when the agent performs unsafe code changes, leaks secrets, or alters build and deployment systems with the authority of a trusted developer workflow.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool-level authorization is now the decisive control plane for coding agents: the old assumption that a developer’s access can safely be inherited by an agent no longer holds. A coding agent executes actions, not just suggestions, so the security boundary must move to the tool call itself. The implication is that authorization has to become contextual, not session-based.

Delegated intent is part of identity, not a human-safety overlay: a service account alone does not describe who asked for the work, what task is being performed, or which tools are in scope. That missing context is why shared access produces mushy policy decisions and unnecessary privilege. Practitioners need to treat the delegating user and workflow as part of the identity claim.

Repository content has become an attack surface for authority promotion: comments, docs, issue text, and changelogs can now influence an agent that has real execution power. That is not a model hallucination problem; it is a governance problem where untrusted text can redirect privileged action. Teams should read this as a change in how software repositories must be governed.

Code assistants are collapsing the boundary between development tooling and production-adjacent control planes: once an agent can touch CI/CD, packages, cloud APIs, or protected branches, it belongs in the same policy conversation as automation runners and privileged service accounts. The implication is that access reviews must cover agent paths separately from human developer entitlements.

Per-tool consent and audit are becoming the minimum defensible pattern: the article shows that broad approval at login is too coarse for mixed-risk sessions. Fine-grained policy, human approval for sensitive operations, and durable logs are not optional extras; they are the only way to preserve accountability when an agent can act on behalf of a user.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Authority now sits at the tool boundary: coding agents force security teams to stop treating identity as a login event and start treating it as a sequence of delegated actions. If the agent can inspect code, run commands, and reach CI/CD systems, the authorization decision has to travel with each invocation, not with the session.

Instruction surfaces are the new trust boundary: code comments, READMEs, issue text, and docstrings can steer agent behaviour unless they are treated as untrusted input. The practical change for programmes is to assume that repository content can promote authority if the tool layer is permissive.

Credential reuse is where the blast radius expands fastest: Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026. That is a control signal, not an anomaly, and it argues for separating agent permissions from human developer access.

For practitioners

• Separate agent authority from developer authority Give coding agents permissions that match the delegated task, not the human’s full repository, cloud, or CI/CD access. Keep read, write, and execution rights distinct so a task that only needs file inspection cannot touch deployment or secret-bearing paths.
• Enforce tool-call authorization in front of MCP and similar integrations Authorize each invocation using the delegating user, task scope, target resource, and requested action before the tool executes. The decision should happen at the enforcement point, not inside the agent prompt or inside each downstream tool.
• Classify repository text as untrusted input Treat README files, comments, issue bodies, docstrings, and changelogs as possible instruction carriers when an agent is reading a codebase. Do not let repository text imply permission to call tools outside the assigned task.
• Require human consent for sensitive tool paths Force approval for actions such as reading secrets, modifying CI/CD workflows, publishing packages, accessing production-adjacent APIs, or pushing to protected branches. Keep low-risk read-only or sandboxed actions automatic where policy allows it.
• Log delegated intent with every agent action Record who authorized the task, what the agent tried to do, which tool it invoked, what resource was affected, and whether policy allowed, denied, or escalated the request. Generic agent logs are not enough for investigations.

Key takeaways

• Coding agents create an authorization problem because they can act inside repositories, terminals, APIs, and CI/CD workflows, not just generate suggestions.
• Broad inherited access turns indirect prompt injection and routine task drift into a high-blast-radius identity risk.
• The control shift is from shared developer credentials to per-tool policy, human consent where needed, and auditable delegated intent.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Delegated Intent: Delegated intent is the machine-verifiable statement of what a human authorised an agent to do, for which purpose, and within which scope. It becomes a governance boundary when linked to the principal, the resource, the trust level, and the policy version active at the time of execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.