AI-native coding security exposes the new NHI governance gap

At a glance

What this is: Backslash Security’s award-related post argues that AI-native development creates new security blind spots across coding agents, MCP servers, and LLM workflows.

Why it matters: It matters because IAM, NHI, and developer-security teams now have to govern machine-driven software creation as an identity and access problem, not just a code quality problem.

By the numbers:

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

👉 Read Backslash Security's analysis of AI-native coding security and MCP risk

Context

AI-native coding has changed the security problem from protecting code after it exists to governing how code is created in the first place. When AI coding agents, MCP servers, and LLM-powered workflows can influence application behaviour during development, the old model of catching issues later in testing is no longer enough for AI agent governance or workload identity controls.

That matters for NHI and identity teams because the development toolchain now behaves like a chain of non-human identities with delegated access, prompt-driven actions, and machine-to-machine trust. Backslash Security is positioning the problem as one of real-time governance across the software lifecycle, which is where IAM, NHI, and developer security increasingly overlap.

Key questions

Q: How should security teams govern AI coding agents in development pipelines?

A: Security teams should govern AI coding agents as non-human identities with defined access, ownership, and approval boundaries. That means mapping the tools they can reach, restricting the actions they can initiate, and treating agent activity as identity telemetry. The goal is to control who or what can influence code before it reaches testing or production.

Q: Why do MCP servers create new identity risk for AI-native development?

A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools. If the trust path is too broad, the agent can act with capabilities that were never intended for that task. Teams should review those connections as access paths, not just as integration plumbing.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How can organisations tell whether AI developer guardrails are working?

A: Look for fewer unapproved tool calls, narrower MCP access paths, and reduced reliance on post-build remediation. If the same unsafe behaviours keep appearing in the pipeline, the guardrails are advisory rather than enforceable. Effective controls change what the agent is allowed to do at runtime.

Technical breakdown

AI coding agents as non-human identities in the development stack

AI coding agents are not just helper tools when they can generate code, select actions, and interact with surrounding services inside the development environment. In that setup, the agent becomes part of the trust boundary, because it can influence source code, configuration, and automated workflow outcomes. The security challenge is less about code completion and more about identity-backed execution paths that now exist before code is merged. That shifts governance from reviewing output only to governing the actor that produced it.

Practical implication: treat AI coding agents and their connected services as governed identities, not as passive developer tooling.

MCP server risk and runtime trust in AI-native development

Model Context Protocol servers extend an AI system’s reach into tools and data sources, which makes them a high-value control point in AI-native development. If an MCP server is misconfigured or over-trusted, the agent can inherit access it should never have had, and the resulting action may look like normal developer activity. That creates a runtime governance problem, because the risk is introduced at the moment the toolchain is used, not only when code is shipped. Security controls therefore need to validate the trust relationship continuously.

Practical implication: inventory MCP connections and verify the trust model before allowing them into production developer flows.

Secure prompt rules and code generation guardrails

Secure prompt rules are effectively policy controls for AI-generated actions. They shape what the model is allowed to propose or execute in the development workflow, which makes them a governance layer rather than just a content filter. The important point is that AI-native coding risk appears during creation, not after compilation, so controls must constrain risky actions before they become code artifacts. That is why preemptive checks matter more than retrospective review in this environment.

Practical implication: enforce prompt and policy guardrails that block insecure AI-driven actions before code is written.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-native coding is turning the developer toolchain into an identity perimeter. Once coding agents, MCP servers, and LLM workflows can act inside the build process, the security question becomes who or what is allowed to initiate those actions. That is a different governance problem from classic code scanning because the risky decision happens before a vulnerable line ever reaches testing. Practitioners should treat the development pipeline as an access-controlled execution environment, not a neutral productivity layer.

Real-time validation matters because AI-generated risk is created at source, not discovered later. Backslash Security’s framing is directionally correct: waiting for testing to find the issue leaves too much time for insecure code paths and risky automation to propagate. This is the same failure pattern seen in other identity problems where review happens after the act. Practitioners need to reframe developer-security controls around initiation, not just inspection.

Model Context Protocol changes the trust surface for software creation. An MCP connection is not merely an integration, it is a delegated access path into tools and data that can shape code generation and workflow execution. That means the relevant control gap is over-delegation to AI-connected services, especially where tool access is broader than the task requires. The implication is that teams must re-evaluate where delegation ends and where identity governance begins.

Secure prompt rules are becoming policy enforcement for machine-generated change. In AI-native development, prompts can trigger code, configuration, and workflow actions that would otherwise require human review. That makes prompt governance a boundary control, not an advisory practice. Security teams should recognise that the quality of the prompt policy now affects the security of the resulting software supply chain.

AI-native development is pushing NHI governance into the engineering stack. The industry is moving toward a model where agent identity, workload identity, and software supply chain controls have to operate together. The named concept here is development identity governance: the practice of controlling machine-driven actors inside the software lifecycle as if they were part of the identity plane. Practitioners should prepare for a merged governance model across IAM, DevSecOps, and NHI.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access becomes hard to govern when ownership is fragmented.
• For a broader governance lens, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how AI-driven identity sprawl is changing the control model.

What this signals

Development identity governance: AI-native coding is pushing identity controls into the software factory itself, where the relevant question is not just whether code is secure but whether the actor that produced it was allowed to act. Teams that still separate IAM, DevSecOps, and NHI governance will miss the trust relationships now embedded in agentic development.

The programme signal is clear: if your guardrails only appear after code creation, you are already behind the risk. Security and engineering leaders should prepare for a governance model that validates tools, prompts, and runtime access before AI systems can influence source control or build pipelines.

For practitioners

• Classify AI coding agents as governed identities Map every coding agent, IDE integration, and workflow automation that can change source code or configuration. Assign ownership, access scope, and approval boundaries so the toolchain is managed as an identity surface rather than a convenience layer.
• Inventory and validate MCP trust paths Document which MCP servers can reach repositories, secrets, build systems, and ticketing or deployment tools. Remove broad default access and require explicit validation for each server-to-tool relationship, especially where the same path can influence code generation and release activity.
• Enforce prompt and action guardrails before code generation Block insecure requests, risky filesystem actions, and unapproved workflow steps at the point they are requested. Put the control in front of code creation so the organisation prevents bad output instead of relying on later testing to catch it.
• Tie developer-security telemetry to identity governance Feed agent activity, tool calls, and configuration changes into governance review so security teams can see who or what initiated the change. This closes the gap between software delivery telemetry and identity accountability.

Key takeaways

• AI-native development turns coding agents, MCP servers, and LLM workflows into a governed identity surface, not just productivity tooling.
• The practical risk is initiation, because insecure actions are now introduced during code creation rather than discovered only in testing.
• Teams need runtime guardrails, access path validation, and identity accountability for the development stack if they want AI adoption without expanding software supply chain exposure.

Key terms

• AI coding agent: A software system that can generate or modify code within a development workflow. In practice, it becomes security-relevant when it can initiate actions, reach tools, or influence build and release behaviour without a human reviewing every step.
• Model Context Protocol: An open protocol that lets AI systems connect to tools and data sources. In identity terms, it creates a delegated access path, so governance has to cover what the connected system can reach, what it can change, and how that access is monitored.
• AI-native development: A development model where AI systems are part of the creation process, not just assistants around it. Security must therefore account for machine-generated actions, machine-to-machine trust, and controls that operate before code is written, not only after it is scanned.
• Development identity governance: The practice of governing the identities, permissions, and action boundaries inside the software development lifecycle. It extends identity control to coding agents, integrations, and automation that can affect code, configuration, and delivery outcomes.

Deepen your knowledge

AI coding agents, MCP server governance, and secure prompt controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-native development, it is a practical place to start.

This post draws on content published by Backslash Security about securing AI-native software development and the InfoWorld recognition it received. Read the original.