Notifications
Clear all
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.
NHIMG editorial — based on content published by Knostic: What security leaders need to know from our recent webinar with Knostic CTO Sounil Yu
Questions worth separating out
Q: How should security teams govern coding assistants that can take actions inside the IDE?
A: Treat coding assistants as privileged systems with bounded capabilities, not as neutral productivity tools.
Q: Why do coding assistants create new identity and access risks?
A: Because they operate inside a high-trust environment and can inherit access to files, secrets, tools, and services.
Q: What breaks when teams rely on SBOMs and SCA alone for generated code?
A: They can create false confidence if the code is bespoke but still risky.
Practitioner guidance
- Instrument the IDE as a security endpoint Log assistant actions, file context, tool calls, and destructive commands from the IDE so you can detect unsafe behaviour before code is committed.
- Gate all-three agent states Block or require approval when an assistant has untrusted inputs, access to sensitive data, and external communication in the same workflow.
- Curate MCP servers and extensions Maintain allow-lists for approved extensions and MCP endpoints, then review exceptions like privileged access requests.
What's in the full article
Knostic's full webinar covers the operational detail this post intentionally leaves for the source:
- The live walkthrough of the Agent’s Rule of Two and how to operationalise it in developer environments.
- The OODA lens for distinguishing tools, AI agents, and agentic AI in practical workflows.
- The Kirin approach to instrumenting IDE actions, MCP calls, and extension behaviour.
- The specific examples of dangerous actions, prompt injection paths, and control points discussed in the session.
Coding assistants, MCP, and the governance gap teams are missing?
Explore further
09/07/2026 12:40 pm
Agentic development creates governance debt faster than traditional security teams can absorb. The article shows that coding assistants, toolchains, and generated code are now introducing new control points faster than organisations can adapt their review and approval models. That is not simply a tooling issue, it is a governance problem because the control surface is expanding inside the development process itself. Security leaders should treat this as an identity and authorization redesign problem, not a training issue.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: What should organisations do when an IDE extension or MCP server becomes suspicious?
A: Revoke it like a privileged integration. Remove its access, review the commands and data it touched, and check whether it had access to secrets, production systems, or destructive actions. Suspicious connectors should be handled through the same governance path used for high-risk identities and elevated access.
👉 Read our full editorial: Agentic development security is shifting from code to behaviour
