Notifications
Clear all
Topic starter
22/06/2026 10:13 am
TL;DR: AI coding assistants now influence code, secrets, infrastructure access, and data inside daily developer workflows, while conventional controls miss many interactions across IDEs, CLIs, and MCP connections, according to WitnessAI. The security problem is no longer just insecure code, but unmanaged tool use, prompt injection, data leakage, and agentic abuse that require runtime visibility and policy enforcement.
NHIMG editorial — based on content published by WitnessAI: AI coding assistant security is an enterprise issue
By the numbers:
- The security pass rate has remained flat at approximately 55% since 2024, and larger or newer models have not improved security outcomes.
- More than 15% of commits by each AI coding tool introduce at least one issue.
- With 90% of developers regularly using at least one AI tool at work, policy-only approaches are insufficient.
Questions worth separating out
Q: How should security teams control AI coding assistants in developer workflows?
A: Security teams should control AI coding assistants at the workflow layer, not only at the browser or post-commit layer.
Q: Why do AI coding assistants create new NHI governance risks?
A: AI coding assistants create new NHI governance risks because they interact with code, secrets, and connected systems as part of normal development work.
Q: What do teams get wrong about prompt injection in coding tools?
A: Teams often treat prompt injection as a content problem when it is actually a runtime control problem.
Practitioner guidance
- Extend discovery into IDE and CLI workflows Inventory the coding assistants, plugins, terminal tools, and local agents in use across engineering teams.
- Classify prompts by intent, not keywords Apply policy rules that detect whether a prompt contains source code, API keys, schemas, or infrastructure details even when the text looks conversational.
- Treat every MCP connection as a privileged integration Scope tool permissions to the minimum required, log each tool call, and require clear ownership for the systems exposed through MCP servers.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- The eight-risk breakdown with examples that map specific attack paths to AI coding workflows.
- The tool-by-tool discussion of where IDEs, CLIs, MCP connections, and agents evade conventional inspection.
- The runtime control model for prompt inspection, bidirectional defense, and graduated enforcement.
- The incident and CVE references that show how these weaknesses appear in real deployments.
👉 Read WitnessAI's analysis of AI coding assistant security risks in enterprise workflows →
AI coding assistant security: are your controls keeping up?
Explore further
22/06/2026 11:01 am
AI coding assistants have turned developer workflows into an identity governance problem, not just an AppSec problem. These tools now touch code, secrets, tickets, infrastructure, and external models inside the same runtime path. That means IAM, PAM, and NHI governance all intersect in one place, where the assistant can observe, suggest, and sometimes act. The practitioner conclusion is that governance must be built around the assistant’s real access path, not the developer’s assumed intent.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- In the same research, organisations maintain an average of 6 distinct secrets manager instances, which fragments control and slows containment, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who should own AI coding assistant governance in the enterprise?
A: Ownership should sit with a single accountable function, usually under security or AI governance, with engineering and platform teams responsible for secure configuration and approved integrations. Shared responsibility without a named owner leaves gaps in discovery, policy, and incident response. The control model works only when the approved tool and model inventory is centrally governed.
👉 Read our full editorial: AI coding assistant security exposes new enterprise control gaps
