Agentic development security is shifting from code to behaviour

At a glance

What this is: This webinar argues that agentic development is turning software construction into a behaviour-governance problem, with AI-assisted coding, MCP servers, and extensions expanding the attack surface beyond code provenance.

Why it matters: It matters to IAM and NHI practitioners because developer tools now mediate privileged actions, secret access, and delegated trust, so governance has to move from static artefacts to runtime behaviour.

By the numbers:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.

Context

AI-assisted development changes the control problem from code review alone to governance of tool use, privilege, and behaviour. When assistants can invoke tools, read context, and mutate files, the risk surface expands into the development environment itself, not just the repository. That matters because the same patterns that govern privileged access in production now need to apply inside the IDE and adjacent automation.

The article frames a practical security gap: build systems and developer assistants still assume third-party components, prompts, and generated outputs are trustworthy enough to proceed by default. In identity terms, that creates a governance boundary problem around delegated actions, privileged endpoints, and human approval. The article's starting position is increasingly typical for modern software teams.

Generating code without imported dependencies may reduce visible SBOM exposure, but it does not remove supply chain uncertainty from behaviour, provenance, or testing. The broader lesson is that governance has to evaluate what software does under test, not only what components appear in the bill of materials.

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. Once assistants can read secrets, call tools, and mutate code, the workspace needs controls that limit which actions can run automatically and which require explicit review.

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. That creates a larger blast radius than the code task itself. The risk is highest when assistant permissions exceed the minimum needed for the developer's immediate work.

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. When a developer environment can reach secrets, external systems, and code mutation at once, the control boundary is too loose.

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.

Technical breakdown

Why developer tools have become a privileged execution layer

Modern IDEs are no longer passive editors. They are execution environments where assistants can call tools, read files, inspect environment variables, and trigger code changes. That turns the IDE into a privileged control point with its own trust boundaries, especially when MCP servers and extensions can extend what the assistant can reach. The risk is not just malware in a plugin. It is the concentration of decision-making, secret exposure, and destructive capability inside a workspace that was historically under-governed compared with production systems.

Practical implication: Treat the IDE as a high-trust endpoint and govern assistant actions, extensions, and tool calls with the same care as privileged production access.

What the Rule of Two changes for agentic workflows

The Rule of Two is a behavioural constraint for agents: if a system accepts untrusted inputs, accesses sensitive data, and can communicate externally, all three together create an unsafe state. In practice, that means the agent can be manipulated, can see something valuable, and can move it somewhere else. The model is useful because it turns a vague AI safety concern into a concrete governance test. Teams do not need to solve every agentic risk at once; they need to detect when a workflow crosses into the all-three condition and force a control point before action continues.

Practical implication: Use a gating policy that blocks or reviews any assistant workflow combining untrusted input, sensitive data access, and outbound communication.

Why generated code creates a provenance and assurance gap

Generated code can look clean in static reporting while still carrying uncertainty about intent, correctness, and security behaviour. If teams optimise for empty SBOMs or zero known CVEs, they may create incentives to prefer bespoke generated output over dependency reuse without proving that the resulting software is safer. The real issue is assurance. Static ingredients matter, but security teams also need to know whether the output behaves safely under adversarial prompts, bad context, and edge-case inputs. That shifts quality control from composition alone to behavioural verification across the build and test lifecycle.

Practical implication: Add policy tests and adversarial evaluation for generated artifacts instead of relying on SBOM absence or scan results alone.

Threat narrative

Attacker objective: The attacker wants to use trusted developer tooling as an execution path for secret theft, code tampering, or destructive actions.

1. Entry occurs through AI-assisted development tools, IDE extensions, or MCP-connected workflows that can accept untrusted prompts, files, or hidden instructions.
2. Credential access and privilege abuse happen when the assistant can read environment variables, invoke destructive commands, or interact with sensitive developer resources.
3. Impact follows when a manipulated workflow changes code, exfiltrates secrets, or performs unsafe actions that developers did not explicitly authorise.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Developer assistants create a new identity and privilege boundary inside the engineering workflow: the interesting question is no longer just who can commit code, but what delegated actions a tool is allowed to perform on behalf of a developer. That is an identity governance problem as much as a software assurance problem, because the same workstation now hosts human intent, machine action, and privileged context. Practitioners should map assistant permissions to explicit decision boundaries.

Invisible trust in extensions and MCP endpoints is a governance debt: these ecosystems move quickly, but trust signals lag behind adoption. A fast-moving marketplace of connectors and helper tools creates hidden dependency chains that look operationally convenient while widening the blast radius of one compromised package. Practitioners should assume every extension chain is part of the supply chain until proven otherwise.

Behavior under test is the right metric when generated output changes the shape of the build: if organisations reward empty dependency lists without testing actual exploitability, they will optimise for appearances rather than security outcomes. The useful concept here is behavioral verification debt, the gap between what static tooling can certify and what a dynamic agentic workflow can actually do. Practitioners should measure outcomes under adversarial conditions, not component counts.

From our research library:

• 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.
• Read next: NHI Lifecycle Management Guide

What this signals

Behavioral verification debt: teams that optimise for clean SBOMs or low scan counts may still be exposed if generated code and assistant actions are not tested under adversarial conditions. The control question is no longer only what entered the build, but what the system can be induced to do once it runs.

Security leaders should expect developer tooling to keep absorbing more privilege, which means the old boundary between endpoint controls and software supply chain controls is eroding. That makes extension governance, MCP oversight, and just-in-time approval workflows central to modern engineering risk management.

The most practical shift is to measure assistant behaviour directly. If a coding tool can read secrets, talk externally, and alter code in one flow, then the workflow has already crossed into a state where conventional review comes too late.

For practitioners

• 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.
• Test generated artifacts for behaviour, not just composition Use adversarial prompts, policy simulations, and destructive-action tests to verify what generated code and assistant-driven workflows actually do.
• Require explicit approval for privileged operations Demand human confirmation before credential access, schema changes, production data touchpoints, or other high-impact actions can proceed.

Key takeaways

• AI-assisted development is turning the IDE into a privileged security boundary, so code review alone no longer describes the full risk.
• Assistant-driven workflows can combine untrusted inputs, sensitive data, and external communication, which creates a materially different governance problem from traditional software tooling.
• The strongest control response is to verify behaviour under test, limit dangerous tool combinations, and force approval before privileged actions proceed.

Key terms

• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Behavioral Verification: Behavioral verification uses patterns such as normal device use, login habits, and contextual signals to decide whether an access attempt looks legitimate. It strengthens authentication by comparing the current attempt with expected user behaviour, helping detect account takeover attempts that reuse stolen credentials.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Behavioral Verification Debt: The gap between what static security checks can certify and what an AI-driven workflow may actually do once it has tools, context, and privilege. The debt grows when organisations reward clean inventories or scan results without testing the behaviour of the system itself.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that agentic and software delivery programmes now depend on.