Topic starter
24/06/2026 7:09 pm
TL;DR: Coding agents can run commands, edit files, call APIs, and touch CI/CD systems, which turns indirect prompt injection, secret leakage, and runaway automation into authorization problems, according to PermitIO. The security model now has to follow delegated intent and per-tool policy, not developer-style broad access.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “Securing Coding Agents: What You Need to Know”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: Coding agents create an authorization problem because they can act inside repositories, terminals, APIs, and CI/CD workflows, not just generate suggestions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:19 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Coding agents need tool-level authorization, not shared developer access