Why do AI coding assistants become riskier when they can reach enterprise systems through MCP?

Why This Matters for Security Teams

MCP changes the security problem from “can the assistant write good code?” to “what can that assistant do once it is allowed to act?” A coding assistant with tool access can move from suggestion to execution by querying repositories, touching cloud resources, or triggering workflows. That creates a higher-risk trust boundary than a normal IDE plugin, because the agent is now operating with enterprise reach, not just local context. Current guidance suggests treating tool access as an identity and authorisation problem, not a prompt-quality problem.

This is why agentic risk frameworks such as the OWASP Agentic AI Top 10 and NIST’s broader control model in the NIST Cybersecurity Framework 2.0 matter here: they force teams to ask whether the agent should ever have the authority to retrieve, transform, or execute beyond the user’s intended task. NHI governance becomes relevant the moment MCP credentials, tokens, or delegated sessions are introduced, because those secrets are the mechanism that turns a model into an operator. In practice, many security teams encounter misuse only after an assistant has already touched production data or issued an unsafe command, rather than through intentional policy design.

How It Works in Practice

The practical control model is to separate the assistant’s reasoning layer from its execution layer. The model may propose an action, but MCP should only expose narrowly scoped tools, runtime checks, and short-lived authorisation for the specific task. That means using workload identity for the agent, not shared secrets, and issuing credentials only when a request is approved. Best practice is evolving toward intent-based authorisation, where policy is evaluated at runtime based on what the agent is trying to do, what data it wants, and which environment it is in.

In operational terms, teams should expect to combine:

• Per-tool allowlists for database reads, repository writes, and deployment actions.
• Just-in-time, ephemeral credentials with tight TTLs and automatic revocation.
• Policy-as-code checks at request time, rather than static role mappings alone.
• Separate identities for the user, the agent, and the backing service account.
• Logging that records both the natural-language request and the exact MCP action.

This aligns with the direction of the OWASP NHI Top 10 and NHIMG’s coverage of the Analysis of Claude Code Security, both of which show that agentic tools become materially riskier when execution authority is not tightly bounded. A useful reference point is the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access enforcement, auditability, and system integrity. These controls tend to break down when MCP is connected to broad service accounts or legacy integrations that cannot enforce task-level scoping because the agent inherits ambient privilege.

Common Variations and Edge Cases

Tighter MCP controls often increase integration overhead, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff is especially visible in fast-moving engineering teams, where broad access is tempting because it makes the assistant “just work.” Current guidance suggests resisting that shortcut, but there is no universal standard for exactly how granular every tool permission must be.

Edge cases appear when assistants are allowed to chain tools across systems, such as reading a ticket, querying a database, and then writing code or triggering a deployment. In those environments, a single overly permissive token can turn a harmless autocomplete feature into a cross-system operator. NHIMG research on the State of Secrets in AppSec highlights why this matters: 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases, which becomes more dangerous when MCP exposes live systems. The same concern applies when secret sprawl, stale tokens, or shared service credentials exist behind the tool layer.

Teams should treat remote MCP servers, internal plugins, and vendor-hosted assistants differently. A remote server may be trustworthy for retrieval but not for execution, while a local assistant may still need strong egress restrictions and approval gates. The practical failure mode is not always exfiltration; it is often unintended operational impact, such as mass edits, destructive queries, or workflows triggered at the wrong scope.

Related resources from NHI Mgmt Group

• How should organisations govern AI assistants that retrieve enterprise context through MCP?
• How should security teams govern MCP servers used by AI coding assistants?
• Why do coding assistants become risky when they lack internal context?
• Why do shared credentials become riskier when AI systems are in the workflow?