They expand the trusted software surface and often inherit the same privileges as the developer, including access to GitHub tokens, cloud credentials, and local tools. That makes compromise more consequential, because an untrusted extension or endpoint can turn routine automation into a path for credential theft, package abuse, or release pipeline contamination.
Why This Matters for Security Teams
AI coding agents and MCP servers are not just another developer convenience. They expand the trusted execution path on endpoints that already hold source code, package managers, cloud sessions, and browser-based developer workflows. That means a single compromised plugin, connector, or local server can bridge from productivity tooling into secrets theft, dependency poisoning, and release tampering. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s State of MCP Server Security 2025 both point to the same operational problem: tool access is often broader than the task requires.
The risk is amplified because these systems inherit developer trust by default. If the agent can read local files, call APIs, and run commands, an attacker does not need to break every layer separately. They only need to steer the agent or compromise the server that brokers its tools. NHIMG’s State of Secrets in AppSec shows how persistent secrets management gaps already create exposure; agentic tooling makes those gaps easier to reach. In practice, many security teams discover the problem only after a token has been reused, a package has been altered, or a build has already left the workstation.
How It Works in Practice
The core issue is privilege inheritance. AI coding agents often run with the same identity context as the developer, then gain additional authority through MCP servers that expose files, repos, terminals, ticketing systems, or cloud APIs. When that stack is trusted as a single productivity unit, the agent’s actual behaviour is evaluated too loosely. A static IAM model assumes predictable users and stable roles, but agentic workflows are dynamic: the agent can chain tools, switch tasks mid-session, or request access based on new context.
That is why the emerging pattern is not broader RBAC, but tighter runtime control. Security teams are increasingly looking at intent-based authorisation, short-lived credentials, and workload identity so that access is granted per task rather than by default. The practical goal is to ensure the agent proves what it is, what it is trying to do, and when it should stop. This aligns with the direction described in NIST AI Risk Management Framework and the implementation concerns in NHIMG’s OWASP NHI Top 10.
- Use JIT tokens for Git, cloud, and package operations instead of long-lived developer secrets.
- Scope MCP tool permissions to the minimum command set and data paths needed for the task.
- Bind agent sessions to workload identity, not just a user login or local shell.
- Evaluate access decisions at request time with policy-as-code rather than pre-approved blanket access.
NHIMG research on the State of MCP Server Security 2025 shows how often MCP deployments expose credentials or omit scoping entirely, which turns local automation into a supply chain foothold. These controls tend to break down on developer endpoints that mix personal tooling, admin sessions, and unattended agent processes because there is no clean boundary between the human user and the automated workload.
Common Variations and Edge Cases
Tighter agent controls often increase friction, so organisations have to balance developer speed against containment. That tradeoff becomes sharper when the agent needs to access multiple repositories, ephemeral cloud sandboxes, or internal package mirrors during a single workflow. There is no universal standard for this yet, but current guidance suggests that the more autonomous the agent, the shorter the credential lifetime and the narrower the tool scope should be.
Some environments also blur the line between a coding agent and a local assistant. If an MCP server can read environment variables, browser sessions, or clipboard content, the risk is no longer limited to source code. It can extend to CI/CD tokens, SaaS sessions, and infrastructure credentials that were never meant to leave the workstation. This is why the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 are useful starting points, even though neither was written specifically for agentic developer tooling.
Where teams often get caught out is in trusted internal deployments. An MCP server running on a laptop or internal VM can look harmless, yet still become the easiest path to exfiltrate secrets or tamper with release artifacts. Best practice is evolving, but the safest posture is to treat every agent-facing tool as a supply chain dependency with explicit scoping, review, and revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agent tool abuse and prompt steering are central risks for coding agents. |
| CSA MAESTRO | MAESTRO addresses threat modeling for autonomous agent workflows and toolchains. | |
| NIST AI RMF | GOVERN | AI governance is needed to assign accountability for autonomous endpoint risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Developer endpoints often leak or overretain credentials used by agents. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is the baseline for containing tool abuse. |
Replace long-lived secrets with short-lived, scoped credentials and revoke on task completion.
