Notifications
Clear all
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.
NHIMG editorial — based on content published by PermitIO: Securing Coding Agents: What You Need to Know
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define tool-specific policies for coding agents Map every tool the agent can call, then separate read, write, and privileged actions.
- Bind agent sessions to delegated intent Record the delegating user, task scope, permitted repositories, and allowed operating environment before the agent begins work.
- Block untrusted text from becoming instruction Treat comments, issue text, docstrings, and changelogs as data, not commands.
What's in the full article
PermitIO's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific examples of coding-agent permission boundaries across repository reads, workflow edits, and privileged tool calls.
- The policy flow for deciding when a coding-agent action should be allowed, blocked, or sent for human approval.
- How MCP routing and enforcement can be inserted in front of internal tools without rewriting the agent.
- Practical examples of audit logging fields needed to reconstruct delegated actions after an incident.
👉 Read PermitIO's analysis of coding agent authorization and tool-level access →
Coding agent permissions: are your controls keeping up?
Explore further
25/06/2026 4:19 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Coding agents need tool-level authorization, not shared developer access
