Topic starter
09/07/2026 12:35 pm
TL;DR: AI-assisted software development is accelerating vulnerability discovery, expanding the attack surface in IDEs and toolchains, and creating governance pressure around dependency use, generated code, and autonomous tool actions, according to Knostic's webinar with CTO Sounil Yu. The critical issue is no longer just what code ships, but whether security teams can constrain agent behaviour, verify outcomes, and recover when non-deterministic workflows go wrong.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “AI Supply Chain Risks: MCP, Extensions, & Coding Assistants”.
Key questions
Q: Where does agentic development fail when assistants can act inside the IDE?
A: It fails when the IDE becomes a privileged execution layer without a clear boundary between observation and action.
Q: Why do coding assistants increase secret exposure risk in development workflows?
A: Coding assistants increase secret exposure risk because they operate inside environments where credentials already exist and can be combined with file, shell, and network capabilities.
Q: What are the signs that assistant-driven development is becoming unsafe?
A: Look for workflows that mix broad file access, unchecked tool invocation, hidden prompt material, and destructive operations without human review.
Practitioner guidance
- Instrument the IDE as a security control point Monitor assistant actions, file access, tool calls, and extension behaviour inside developer environments, not just network or endpoint telemetry.
- Gate dangerous combinations of agent capability Block or require review when a workflow combines untrusted input, sensitive data access, and external communication in the same assistant session.
- Curate extensions and MCP endpoints with allow-lists Approve only trusted extensions and MCP servers, then review exceptions for hidden instructions, risky permissions, and unexpected data flows.
Bottom line: AI-assisted development is turning the IDE into a privileged security boundary, so code review alone no longer describes the full risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 12:40 pm
Behavioral assurance is becoming the missing control layer in software construction: static code provenance no longer captures the full risk created by assistants that can reason, act, and call tools. If the control point is the IDE, then security governance has to observe behaviour at execution time, not only inspect artefacts after the fact. Practitioners should treat runtime validation as a first-class control, not a supplemental check.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should security teams do after an AI assistant or extension is compromised?
A: Contain the affected IDE, revoke exposed credentials, inspect recent tool calls and file changes, and assume the workflow may have executed unsafe commands. Then review the assistant and extension trust chain before restoring access.
👉 Read our full editorial: Agentic development security is shifting from code to behaviour