They create access risk because they act with delegated authority across code, build, and runtime paths. If their permissions are broad or poorly logged, they become non-human privileged actors that can change systems faster than human review or monitoring can intervene.
How coding agents and MCP-connected tools turn delegated access into operational risk
Coding agents and MCP-connected tools matter because they are not just “assistants”, they are execution paths. Once they can read repositories, call APIs, write files, trigger builds, or act through connected tools, they inherit the permissions attached to those paths. That changes the question from convenience to delegated authority, blast radius, and control over side effects.
The practical issue is that these systems often operate in the same environments humans trust, but at machine speed and across multiple systems at once. If the access model is too broad, the tool can touch code, secrets, cloud resources, or deployment workflows before a reviewer can intervene. That makes permission design, token scope, and logging part of the core security answer, not an implementation detail.
For coding assistants in particular, the risk increases when the tool is trusted to reason over local context, repository contents, or upstream instructions. A malicious prompt, poisoned tool output, or unsafe configuration can redirect the agent toward actions that look normal from the outside but are materially privileged inside the environment. The same delegated path that makes the agent useful also makes it capable of acting as a high-speed intermediary for misuse. NHIMG’s AI Coding Agents Security Guide covers the way this exposure appears in IDE, terminal, and CI/CD use.
Why MCP multiplies the trust boundary
MCP is useful because it standardises how tools expose capabilities to agents, but that standardisation also concentrates trust. An MCP server may sit between the agent and sensitive resources, so authorization failures, token passthrough mistakes, or weak tool boundaries can give the agent more reach than the human intended. The risk is not the protocol alone, it is the combination of protocol, tool authority, and ambient credentials.
That is why MCP-connected tools are especially sensitive to confused deputy problems and overly broad access delegation. If the tool can act on behalf of the user or environment without strong audience restriction, the agent can inherit access to data or actions that were never meant to be globally reusable. In practice, this means a flaw in one connected tool can become a cross-system access issue rather than a single app bug. The MCP Security Guide and the Model Context Protocol: Authorization specification both reflect that authorization needs to be explicit, scoped, and audience-bound.
In mature deployments, the useful question is not whether an agent “has access”, but whether each tool invocation is narrowly authorised for the task, environment, and data class involved. If the answer is no, then the agent is effectively a general-purpose credential consumer with tool reach, which is much harder to govern than a human user with a browser session.
What actually fails when the permissions are too broad
The failure mode is usually overdelegation combined with weak observability. A coding agent can open files, run commands, post commits, trigger deployments, or use cloud credentials in ways that are individually valid but collectively dangerous. If those actions are not logged at the right granularity, teams discover the impact after systems change, secrets leak, or deployment state shifts.
That is why access risk here is both security risk and operational risk. The agent may not be malicious, but it can still delete data, leak secrets, or propagate bad code faster than a human can notice. In other words, the main exposure is not only compromise, it is high-impact authorised action with insufficient friction. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is useful because it focuses on action logging, attribution, and the kill-switch logic needed when an agent goes wrong.
Risk and Threat Considerations
Coding agents and MCP-connected tools create a real access hazard because attackers do not need to break the whole environment if they can steer the delegated tool path. A poisoned repository, malicious tool output, or over-scoped token can turn normal automation into destructive or exfiltrating action, often using legitimate credentials and approved channels.
Failure mechanism: The tool inherits permissions that are wider than the specific task, then follows untrusted instructions, untrusted context, or compromised tool responses into actions that the human did not explicitly approve.
Impact: The result can be unauthorized code change, secret exposure, cloud or CI/CD abuse, data deletion, or attacker persistence through trusted automation that is hard to distinguish from normal use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Coding agents and MCP tools become dangerous when permissions exceed task needs. |
| NHI-04 — Insecure Authentication | MCP-connected tools rely on scoped authentication and token handling across systems. | |
| NHI-02 — Secret Leakage | Agents can expose or reuse secrets while reading context, repo contents, or tool output. | |
| Recommendation — Restrict agent and tool permissions to the minimum task scope and review all standing access. Use short-lived, audience-bound authentication and avoid reusable bearer credentials. Prevent secret exposure in agent context and rotate any credentials the agent can access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents acting through tools can misuse delegated authority or inherit excessive privilege. |
| ASI02 — Tool Misuse | MCP-connected tools can be steered into unsafe actions through untrusted input or outputs. | |
| Recommendation — Constrain delegated authority and require explicit approval for high-impact actions. Validate tool inputs and limit tool effects to the intended task and environment. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP and connected tools depend on correct auth between clients, servers and resources. |
| Recommendation — Enforce strong authentication for tool-to-resource access and reject weak token handling. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated agent access should be limited to the minimum permissions needed for each task. |
| AU-2 — Event Logging | The question hinges on whether agent actions are logged well enough to detect misuse. | |
| IA-5 — Authenticator Management | Agents and tools often rely on API keys, tokens and other credentials that need lifecycle control. | |
| Recommendation — Apply least privilege to agent and tool accounts and remove excess access paths. Log agent actions at a level that supports attribution, review and incident response. Manage, rotate and revoke agent credentials on a short lifecycle. | ||
Practitioner Guidance
What to prioritise: Treat every agent and MCP connector as a delegated principal with a clearly bounded task scope. Prioritise reducing standing access before adding more safeguards around the workflow, because a well-logged overprivileged agent is still an overprivileged agent.
What to verify: Confirm that the tool can only reach the minimum repository, environment, and API surface needed for the use case. Verify that the token audience, expiry, and revocation path are visible to security and platform teams, and that tool actions are attributable to a specific run or session.
Decision rule: If the agent can write code, trigger builds, or call production-adjacent systems, require task-scoped access and explicit logging before enabling the workflow broadly. If you cannot explain who can revoke the access and how quickly the agent will stop acting, the access model is too loose.
Practitioner takeaway: The safest operating model is not “trust the agent less”, but “delegate less authority, log more precisely, and assume any connected tool can become the fastest path from prompt to impact.”
Related resources from NHI Mgmt Group
- Why do AI agents create more IAM risk than ordinary developer tools?
- Why do AI agents create a different access-risk profile than traditional applications?
- Why do valid OAuth tokens still create risk for AI coding agents and MCP tools?
- Why do AI agents create new risk in non-human identity management?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org