Agentic development security is shifting from code to behaviour

At a glance

What this is: This webinar argues that agentic development is moving security risk from static code review into runtime behaviour, especially inside IDEs, assistants, and MCP-connected toolchains.

Why it matters: It matters to IAM and security teams because coding assistants and developer endpoints now behave like high-privilege control planes, where identity, authorization, and tool access need explicit governance.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Knostic's webinar analysis of agentic development security and AI-assisted vulnerability discovery

Context

Agentic development security is the problem of governing AI-assisted coding systems that can take actions, call tools, and alter code with far more speed than traditional review processes can absorb. The article's core finding is that machine-speed discovery and tool use are outpacing human-bounded remediation, which shifts risk from isolated vulnerabilities to systemic behavioural failure.

This matters to identity and access programmes because developer environments are now privileged control planes. IDE extensions, MCP servers, assistant permissions, and destructive actions all create a governance surface where access, approval, and verification need to be managed like high-risk identity activity, not just developer convenience.

Key questions

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. Define which inputs they can read, which tools they can call, and which actions require review. The practical test is whether the assistant can be stopped before it reaches a risky combination of untrusted input, sensitive data, and external communication.

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. That means the assistant is effectively acting as a delegated identity with runtime authority. If the delegation is broad or poorly monitored, the blast radius can exceed what traditional developer controls were designed to contain.

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. A clean inventory only proves that known third-party dependencies are absent or minimal, not that the generated behaviour is safe. Teams still need behavioural testing, adversarial prompts, and policy checks to validate what the code actually does.

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.

Technical breakdown

Why AI-assisted vulnerability discovery changes the security model

AI-assisted research compresses the time between discovering a weakness and publishing it, which turns vulnerability response into a capacity problem as much as a technical one. Open source maintainers and downstream operators cannot match machine-speed finding with human-speed patching, so risk accumulates in the period between disclosure and remediation. That changes the economics of dependency trust: the issue is not only whether a package is vulnerable, but whether the ecosystem can absorb discovery without collapsing under unpatched exposure. Practical implication: measure exposure windows and supplier responsiveness, not just CVE counts.

Practical implication: Prioritise supplier and dependency governance around remediation latency and exposure window, not only vulnerability volume.

The Agent’s Rule of Two and the limits of tool trust

The Article's Rule of Two framing is a useful control model for agentic systems: an AI system should not simultaneously have untrusted inputs, sensitive data access, and external communication. When all three are enabled, the system becomes much harder to reason about because prompt injection, secret leakage, and exfiltration can combine in a single workflow. This is especially relevant in developer tools, where assistants can ingest files, see environment variables, and reach out to services. Practical implication: gate any workflow that reaches the all-three state before the assistant can act.

Practical implication: Apply explicit gating when a coding assistant can read untrusted inputs, touch sensitive data, and communicate externally.

MCP and IDE extensions turn the editor into a high-risk identity surface

MCP servers and IDE extensions extend the editor into a tool-using runtime, which means the IDE now behaves like a narrow but powerful control plane. That makes provenance, trust, and least privilege matter more than usual, because a malicious or sloppy connector can influence code, commands, or data flows with very little friction. In practice, the trust question is no longer whether the IDE is safe by default, but whether each integration has a bounded capability set and observable behaviour. Practical implication: treat extension and MCP approval like privileged access, with allow-lists and continuous monitoring.

Practical implication: Manage IDE extensions and MCP servers as privileged integrations with bounded permissions and reviewable trust.

NHI Mgmt Group analysis

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.

Constructing software has become a trust problem, not just a code quality problem. The article's distinction between runtime zero trust and construction-time trust is the right one. Build systems assume dependencies, assistants, and generated artifacts are safe enough to combine, but that assumption breaks when provenance is opaque and behaviour is non-deterministic. The implication for practitioners is to verify outcomes under test rather than trusting ingredients alone.

Agentic developer workflows need a named control model, not ad hoc guardrails. The article's Rule of Two thinking maps cleanly to the emerging need for capability-based governance in IDEs and agent toolchains. A useful concept here is editor control-plane exposure: the point at which the development environment becomes powerful enough to mutate code, consume secrets, and reach external systems in one flow. Teams that do not name and govern this exposure will keep discovering problems after they are already in production.

Security teams should expect a shift from static assurance to behavioural assurance. The article argues that empty SBOMs, clean SCA reports, and stable package inventories can create false comfort when generated code replaces dependency-heavy assembly. That means the field is moving toward policy simulation, adversarial testing, and runtime observability as first-class assurance methods. Practitioners should prepare for a future where what the system does matters more than what was initially declared.

Agentic AI expands the meaning of privileged access inside software delivery. A coding assistant that can read files, execute tools, and act on prompts is not just a productivity feature, it is a privileged identity with delegated capabilities. That makes IAM, PAM, and NHI concepts directly relevant to developer workflows, especially where MCP servers or other connectors can widen the blast radius. Teams should govern these systems as delegated identities with bounded authority.

What this signals

Editor control-plane exposure: development environments are becoming privileged runtimes where access, tool use, and code mutation converge. That means security programmes should map IDEs, extensions, and MCP servers into existing PAM and NHI governance patterns rather than treating them as peripheral developer tooling.

The near-term operating model will favour behavioural verification over static trust signals. A clean SBOM, a green SCA dashboard, or a trusted package name does not prove safe assistant behaviour, which is why teams should align their assurance model with NIST Cybersecurity Framework 2.0 and the control logic in OWASP Non-Human Identity Top 10.

The practical shift is toward constrained capability and fast rollback. If an assistant can reach secrets, external services, and untrusted inputs in one flow, the governance model is already behind the risk, and the response should be to narrow authority before expanding adoption.

For practitioners

• 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. Treat the editor as a privileged runtime, not a passive text box.
• 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. Use policy checks to force human review before the assistant can progress further.
• Curate MCP servers and extensions Maintain allow-lists for approved extensions and MCP endpoints, then review exceptions like privileged access requests. Include provenance checks, hidden-instruction scanning, and periodic removal of stale integrations.
• Require human approval for destructive actions Make credential access, database schema changes, and destructive file operations explicitly reviewable in the IDE. The goal is to preserve developer speed while preventing a single prompt from causing irreversible damage.
• Test outcomes instead of ingredients Run adversarial prompts, policy simulations, and behavioural tests against generated artifacts rather than relying on an SBOM or SCA result alone. This helps expose hidden variability in assistant-produced code.

Key takeaways

• AI-assisted development is shifting security risk from code alone to the behaviour of tool-using systems inside the IDE.
• The scale problem is governance latency, not just vulnerability count, because machine-speed discovery outruns human remediation.
• The immediate control response is to constrain capabilities, verify outcomes, and treat coding assistants as privileged identities.

Key terms

• Agentic AI: Software that can choose actions and sequence work with limited or no step-by-step human direction. In security analysis, the important question is not whether a model can generate text, but whether the surrounding system can execute decisions, use tools, and change state.
• MCP Server: A Model Context Protocol endpoint that connects AI systems to tools and data sources. In practice, it becomes part of the trust boundary because it can widen what an assistant can read, invoke, or modify, especially when the server has access to sensitive systems or commands.
• Editor Control-Plane Exposure: The condition where the development environment itself becomes a high-risk governance surface because assistants, extensions, and tool calls can mutate code or access secrets. The risk is not the editor interface alone, but the concentration of delegated authority inside it.
• Behavioural Assurance: A security approach that validates what a system actually does under realistic and adversarial conditions rather than trusting inventory or design claims. For agentic workflows, this means testing actions, prompts, and tool use to prove control effectiveness before broad deployment.

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.

👉 The full Knostic webinar covers the Rule of Two, IDE guardrails, and agentic workflow controls in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, identity lifecycle, and secrets management. It helps security practitioners apply identity controls to modern delegated access patterns across complex programmes.