AI coding governance now has to follow the tool, not the user

At a glance

What this is: OXSecurity argues that AI coding governance now has to follow the tool, because non-developers and autonomous agents can create software risk outside traditional AppSec assumptions.

Why it matters: This matters because IAM, security engineering, and AppSec teams need controls that govern models, agents, dependencies, and permissions consistently across every AI coding workflow.

Context

AI coding governance is the set of controls that decides who can use coding assistants, which models and dependencies are allowed, and what autonomous actions are permitted. The problem in this article is that those controls are still often tied to the user or the IDE, while the real risk now travels with the toolchain, the model, and the agent.

That shift creates an identity and access governance problem as much as a software delivery problem. When product managers, QA analysts, and business analysts can generate code, the organisation has to govern non-human and human actors together, across model approval, dependency policy, secret handling, and action boundaries.

The article’s starting position is increasingly typical, not exceptional, in organisations where AI-assisted building has outgrown the controls designed for conventional developer workflows.

Key questions

Q: What breaks when AI governance is built only around approved tools?

A: Tool-only governance fails when employees shift to new or personal AI services faster than policy can update. It also misses the bigger issue that the same sensitive data can travel through multiple interfaces. Without data-aware enforcement, organisations end up policing names of tools instead of controlling exposure.

Q: Why do autonomous coding agents create more risk than traditional code assistants?

A: Autonomous coding agents can read codebases, run commands, edit files, and call tools, which makes them active execution paths rather than passive suggestion systems. That expands exposure to secrets, unintended file changes, uncontrolled spend, and compliance gaps because the agent can move sensitive context and actions through external services at machine speed.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: How should organisations govern AI tools that analyse source code?

A: Set evidence thresholds, require secondary validation for high-impact findings, and define who owns the final decision. Governance should cover prompt scope, output format, reviewer sign-off, and auditability. That keeps AI in an advisory role and prevents noisy model output from becoming an unreviewed security decision.

Technical breakdown

Why AI coding governance cannot stay inside one IDE

AI coding environments are no longer single-purpose editors. They now combine prompts, models, plugins, MCP-style integrations, dependency retrieval, and agent actions, which means risk is distributed across the stack rather than inside one application boundary. If controls only live inside one IDE, they are easy to bypass the moment a user shifts to another tool. That is why governance must sit above the interface and treat the coding workflow as a policy domain, not a product feature. This is especially important when non-developers can create software artefacts without understanding approved models, secret-handling rules, or dependency standards.

Practical implication: define policy at the workflow layer, not only inside one coding assistant.

How autonomous coding agents turn intent into operational risk

AI coding agents compress the time between instruction and execution. A human developer usually notices when a request is heading toward a destructive change, but an agent can carry out the action directly if the guardrails are weak or ambiguous. That creates a governance problem around authority, not just code quality. The core issue is whether the system can delete, publish, expose, or install something without a separate boundary check. In governance terms, the risk is not that the model is clever enough to help, but that it is action-capable enough to create damage before a human review step appears.

Practical implication: require explicit control points before agents can act on production-adjacent assets.

Why AI supply chain visibility is now part of AppSec

AI coding stacks pull in models, skills, hooks, and dependencies that are often invisible to standard application security reviews. That matters because the attack surface is no longer only source code. It now includes embedded components, tool integrations, and the behaviours those components enable. Inventory is therefore a governance control, not an administrative nice-to-have. Without it, teams cannot tell whether a risky component, a shadow integration, or a non-compliant dependency entered through one toolchain and then propagated through another. This makes the AI bill of materials concept central to AI coding governance.

Practical implication: maintain an inventory of models, tools, skills, and integrations before you approve outputs.

Threat narrative

Attacker objective: The objective is not necessarily malicious intent but the same end state as an attack: uncontrolled action that changes data, exposure, or software state beyond approved boundaries.

1. Entry begins when a user opens an AI coding tool and asks it to generate code, automate a workflow, or connect to a dependency the organisation has not explicitly governed.
2. Credential access and exposure occur when the tool or agent handles secrets, tokens, or embedded access paths without a policy layer that can block or redact them.
3. Escalation happens when the generated code, agent action, or dependency chain is allowed to proceed into a repository, pipeline, or production-connected environment without a boundary check.
4. Impact follows when the system deletes data, publishes code or secrets publicly, or introduces unapproved components into the software estate.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

AI coding governance has become a tool-layer control problem. The article shows that governance cannot assume the user is the stable unit of control when the same person may move between multiple assistants, models, and IDEs. The real control plane is the coding workflow itself, not the individual application, and that demands consistent policy enforcement across every interface.

AI coding has expanded the identity perimeter beyond developers. Product managers, QA analysts, and business analysts now influence code creation, which means access governance, model approval, and dependency controls have to be understandable and enforceable for mixed technical audiences. That is a governance change, not just a training issue, and it forces IAM teams to think in terms of who can generate, approve, and execute machine-assisted changes.

AI agent behaviour creates a new kind of governance debt. The dangerous gap is not simply secret leakage or vulnerable code, but the absence of clear boundaries on what an autonomous tool can do before human review. That failure mode deserves its own concept: tool-following governance gap: policy that remains attached to one interface while risk moves across the rest of the stack. Practitioners should treat this as a lifecycle problem for permissions, not as a one-time configuration task.

AI supply chain visibility is now part of software assurance. When models, skills, hooks, and agent behaviours are pulled into the build path, traditional AppSec no longer has a complete picture of what is influencing output. This reinforces the need for governance that inventories AI components alongside code dependencies, because a hidden component can change behaviour long before it appears in production. Teams should align this with OWASP-AGENTIC and NIST CSF-style governance and access control thinking.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Tool-following governance gap: AI coding controls that live inside one assistant will keep failing as soon as users move to another interface. Organisations should assume policy portability is now a baseline requirement, because the workflow, not the product, is where risk accumulates.

The strongest operational answer is to treat AI coding environments as governed identity domains for both humans and agents. That means tying access, model approval, dependency inventory, and action boundaries together so policy remains stable even when the front end changes.

This is also where security and IAM teams need to converge. If AI can now generate code for non-developers, then the organisation has to manage who can create, what they can invoke, and what the resulting system is allowed to do before it reaches production.

For practitioners

• Define a tool-level AI coding policy Set approval rules for models, assistants, plugins, and agent actions so the same policy applies across every coding environment.
• Extend access governance beyond developers Include product, QA, and analyst users in the same policy model so non-developers cannot create ungoverned software paths.
• Inventory AI components before approving output Track models, skills, hooks, and integrations as managed assets so hidden dependencies cannot bypass review.

Key takeaways

• AI coding governance now has to follow the toolchain because the same user can create very different risk profiles across different assistants and agents.
• The governance gap is widening as non-developers use AI coding tools, which pushes access control, model approval, and dependency oversight into a broader population.
• The decisive control is policy at the workflow layer, where organisations can govern prompts, tools, agents, and dependencies before they become operational debt.

Key terms

• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.
• Tool-Level Policy: Tool-level policy is permissioning that evaluates a specific action, such as a repository delete or data query, rather than allowing or denying an entire server. This is the right control grain for agentic systems because risk often lives in one tool, not the whole integration.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• Autonomous Coding Agent: A software agent that can decide, sequence, and execute development tasks with minimal human intervention. In practice, it reads code, invokes tools, and changes files in runtime, so governance must focus on its permissions, inputs, and action boundaries rather than only on the resulting code.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect human access, machine access, and AI-driven workflows to a single governance model.