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 contextual, tool-level authorization instead of inherited developer permissions.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern action-taking software that can move from reading code to changing systems in a single workflow.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read PermitIO's analysis of coding agent authorization and tool-level access

Context

Coding agents are software that can take actions in development environments, not just generate text. That distinction matters for coding agent identity governance because the security boundary shifts from whether an answer is safe to whether a tool invocation is allowed right now.

The core failure is inherited privilege. When an agent gets a developer's access, or a service account that mirrors one, it can read files, run commands, edit workflows, and reach internal tools that exceed the task. In practice, the agent needs delegated intent and per-tool authorization, not a broad trust handoff.

Repository text becomes an attack surface because comments, docstrings, issue bodies, and dependency files can influence an agent's actions. For teams building around MCP and similar tool connectors, the problem is not connectivity. It is controlling which actions are valid in context.

Key questions

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

A: The agent stops being a bounded helper and becomes a high-trust actor with permissions that outlive the task. That creates excessive privilege, secret exposure, unsafe workflow edits, and poor accountability. The failure is not that the model is clever. The failure is that the authorization model assumes a human pace and human judgment where neither exists.

Q: Why do coding agents complicate least privilege?

A: Because their intent is task-specific and changes as they move through files, commands, and tools. Least privilege cannot be defined once at login if the agent may need different access for reading code, running tests, or opening a pull request. Teams need policy that follows the action, not just the account.

Q: How should security teams control secret access for coding agents?

A: They should deny broad workspace and credential access by default, then grant only the minimum paths required for the current task. Secrets should stay outside the agent's general read surface unless there is a clearly approved need, and every privileged access should be logged with task context and delegating user.

Q: Who is accountable when a coding agent makes an unsafe change?

A: Accountability should sit with the delegating owner of the workflow, the policy administrator who allowed the action, and the platform team that exposed the tool path. If the organisation cannot trace who authorised the task, which tools were available, and why the action was permitted, governance has failed.

Technical breakdown

Indirect prompt injection in coding agents

Indirect prompt injection happens when untrusted repository content is treated as instruction by an agent. A comment, README, issue body, or changelog can tell the agent to ignore prior guidance, inspect the environment, or call a tool. The model is not “hacked” in the classic sense. It is persuaded to treat attacker-controlled text as operational context. That is why prompt hierarchy alone is not a security boundary. In a coding-agent workflow, text inside the repo can influence file reads, shell commands, and pull-request content if the tool layer does not separate instruction from data.

Practical implication: isolate untrusted repository content from action authority and gate every tool call with policy.

Delegated intent is different from workload identity

Workload identity proves which process is running. Delegated intent proves why it is acting and on whose behalf. Coding agents need both, because a service account or workload identity can tell you the process is real, but it cannot tell you whether the action is limited to fixing tests, touching a branch, or accessing sensitive data. That gap is why agentic identity must include the delegating human, the workflow, the allowed tools, and the operating environment. Without that context, authorization collapses into broad account-based access that looks tidy but behaves like shared privilege.

Practical implication: bind agent actions to the user, task, tool, and environment before any tool execution occurs.

MCP expands connectivity, not trust

Model Context Protocol makes it easier to connect agents to tools, data sources, and developer workflows. It does not, by itself, decide which agent may call which tool, for what purpose, or against which resource. That means MCP can expose a large permission surface very quickly if teams wire in repositories, ticketing, cloud actions, and databases one server at a time. The security issue is not that MCP is unsafe. The issue is that tool exposure is not equivalent to authorization. Without an enforcement layer, every new integration widens the blast radius of the agent.

Practical implication: place a policy enforcement layer in front of MCP servers before the tool surface grows beyond manual review.

Threat narrative

Attacker objective: The attacker wants to convert ordinary repository content into unauthorized tool use, secret exposure, or workflow manipulation through the agent.

1. Entry occurs when the agent ingests malicious instructions hidden in code comments, README files, issue text, or dependency metadata while performing a legitimate task.
2. Escalation occurs when the agent follows those instructions into tools it was never meant to reach, such as shell commands, workflow files, secrets stores, or internal APIs.
3. Impact occurs when the agent leaks secrets, weakens controls, edits CI/CD configuration, or propagates poisoned changes into pull requests and automation pipelines.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic identity is not a login event, it is a delegated action chain. A coding agent that can inspect repositories, run commands, and modify workflows is operating as an actor, not as a passive interface. The important question is not whether the process authenticated, but whether each action is bound to a task, a user, and a resource boundary. That is why agentic identity has to be treated as a governance object, not a session token. Practitioners should govern the delegation chain, not just the credential.

Tool-level authorization is the real control plane for coding agents. Broad developer inheritance is the wrong model because it assumes the agent should inherit the human's full account shape. In practice, the safe unit of control is the individual tool invocation, evaluated in context. That aligns naturally with OWASP Agentic AI Top 10 and Zero Trust thinking, where the call itself is the policy decision point. Practitioners should move authorization to the moment of action.

Prompt injection in coding agents is an authority-promotion problem, not just a content problem. The attack works because untrusted repository text is allowed to influence a trusted action path. That means the failure mode is not “bad output,” it is “untrusted text gained execution authority.” The same pattern appears whenever comments, docs, or issues can steer high-trust workflows. Practitioners should separate instruction channels from data channels before the agent can act.

Shared credential models create credential laundering in multi-agent workflows. When one agent hands off to another using the same token or account, accountability gets diluted and scope becomes harder to inspect. The issue is not only privilege breadth, but the disappearance of a clear decision owner at each hop. That matters for NHI governance because AI-assisted delivery stacks are already blending service accounts, workflow bots, and human approvals. Practitioners should treat delegation hops as distinct governance events.

Agentic workflow design now determines whether security reviews remain meaningful. Human review cannot protect a process that has already executed high-risk actions before the reviewer sees the result. That is the structural limit of relying on chat prompts and post-hoc oversight. The NHI governance model has to assume that action can happen inside the same session as reasoning. Practitioners should redesign review points around the tool boundary, not around the conversation.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to the same research.
• For a broader governance frame, see NHI Lifecycle Management Guide for how exposure, rotation, and offboarding should be handled across machine identities and delegated systems.

What this signals

Tool-level governance is becoming the practical control point for AI-assisted delivery. Once a coding agent can read repository content, open pull requests, and reach internal APIs, the issue is no longer model quality. It is whether the policy engine can distinguish safe reads from privileged writes before action occurs. Teams should expect their IAM and PAM patterns to move closer to the tool boundary, with NHI Lifecycle Management Guide becoming more relevant to agent sessions than to static accounts.

Agentic identity will start to look like a composed lifecycle problem. The same actor may appear as a developer assistant, a CI helper, and a workflow bot depending on the task, which means recertification and offboarding can no longer be tied only to a single login record. The programme signal is clear: access review cadences need to shift toward delegated intent, not just entitlement state.

With OWASP Agentic AI Top 10 now centring tool misuse, prompt injection, and identity abuse, teams should treat coding agents as policy-governed actors. The named concept here is delegated tool authority: the point at which a human task becomes a machine-acted decision path, and security has to prove the boundary still exists.

For practitioners

• Define tool-specific policies for coding agents Map every tool the agent can call, then separate read, write, and privileged actions. Require different policy outcomes for source reads, branch edits, workflow changes, package publishing, and secret access.
• Bind agent sessions to delegated intent Record the delegating user, task scope, permitted repositories, and allowed operating environment before the agent begins work. Do not let a shared service account substitute for that context.
• Block untrusted text from becoming instruction Treat comments, issue text, docstrings, and changelogs as data, not commands. If the agent must inspect them, isolate the resulting actions from privileged tool paths until policy evaluates the request.
• Insert an enforcement layer in front of MCP servers Place authorization, consent, and audit decisions between the agent and the tool endpoint. Let the gateway decide whether the call proceeds, is denied, or requires human approval.
• Review multi-agent handoffs as separate governance events Track which identity, token, or context moves from one agent to another and whether the receiving agent inherits more authority than the task requires. Credential reuse across hops should trigger a review.

Key takeaways

• Coding agents break the old assumption that authenticated software should inherit broad developer-style access.
• The material risk is not just bad code generation, but untrusted repository text steering privileged actions and exposing secrets.
• The right control is per-tool authorization tied to delegated intent, with audit and consent decisions enforced before action.

Key terms

• Agentic Identity: Agentic identity is the combined identity of the delegating human, the workflow context, and the intent being executed by an AI agent. It is stronger than a login name or service account because it explains why the action exists and what it is allowed to touch.
• Tool-Level Authorization: Tool-level authorization is the practice of deciding whether a specific tool invocation should be allowed, denied, or escalated for consent. It is the right control model for coding agents because their risk changes from one command or API call to the next.
• Indirect Prompt Injection: Indirect prompt injection is when attacker-controlled content inside a repository or document manipulates an agent's behaviour. In coding-agent settings, the malicious text is not the output itself. It becomes dangerous when the agent treats it as instruction and acts on it.
• Delegated Intent: Delegated intent is the task a human explicitly authorizes an agent to carry out on their behalf. It matters because a machine can hold credentials without understanding purpose, and security only works when the purpose is bound to the permitted actions.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Securing Coding Agents: What You Need to Know. Read the original.