Application security programs were built around predictable workflows: a person writes a change, a peer reviews it, pipelines scan it. AI coding agents strain each of those assumptions.

• Speed. AI can generate and modify software faster than human review processes can evaluate it.
• Scale. One developer can produce far more code and applications than before, including people outside engineering. Palo Alto Networks' Unit 42 (January 8, 2026) flags citizen developers who may lack the background to review what is generated.
• Opacity. Developers may not fully understand every implementation decision the model made.
• Dependency expansion. Libraries, packages, APIs, SDKs and third-party components arrive along with the code.
• Privileged tool access. Agents may reach Git repositories, CI/CD pipelines, cloud environments, databases, package managers, shell environments, secrets and internal documentation.
• Behavioral unpredictability. The same agent can act differently depending on prompts, context, tools, permissions and the files in front of it.

Static code scanning examines what was produced. It says little about what the agent did along the way. That gap is where governance has to operate.

​

Early AI coding tools generated text. Modern coding agents take actions. That difference changes the risk category.

Compare two requests. First: "Create a login API." The model returns code for a human to read.

The second: "Create the login API, install the authentication package, modify the database schema, run the migration, update the CI pipeline, run tests, and open a pull request." Now the agent is choosing a dependency, altering a schema, changing a pipeline and executing commands, with whatever permissions the developer's session carries.

The first request produces an artifact. The second produces side effects. Security programs are mature at inspecting artifacts. They are far less mature at governing side effects.

​

Some of these risks in enterprise vibe coding are well established. Others are emerging. We flag which is which.

1. Vulnerability acceleration (established)

AI-generated code can contain familiar flaws: insecure authentication, authorization failures, injection vulnerabilities, insecure API implementations, exposed secrets, unsafe defaults and vulnerable dependencies. The argument is not that AI always writes insecure code. It is that velocity can outpace verification, which makes AI-generated code security a throughput problem as much as a quality problem.

Veracode's 2025 GenAI Code Security Report (July 30, 2025) tested more than 100 models on 80 curated coding tasks and found that AI-generated code introduced a vulnerability in 45% of cases. Its 2026 edition (summer 2026) reports an average pass rate of 56%, essentially unchanged from the prior year despite gains in model capability. Benchmarks aren't your codebase, but working code and secure code are clearly different properties.

2. Dependency and software supply-chain risk (partly emerging)

Agents add packages freely: open-source libraries, obscure or outdated components, unnecessary dependencies and long transitive chains. A less visible problem is hallucination. Researchers at the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech analyzed 576,000 code samples from 16 models and found average hallucinated-package rates of at least 5.2% for commercial models and 21.7% for open-source models (arXiv, 2024).

An attacker who registers a commonly hallucinated name could get malicious code installed. This "slopsquatting" path is research-demonstrated, so treat it as emerging rather than a measured, widespread attack. Either way, enterprises need visibility into the supply chain AI creates.

3. Excessive agent permissions (established principle, emerging practice)

If an AI coding agent only needs to modify a repository, why should it be able to access production credentials?

Yet agents routinely inherit the developer's full session: repositories, secrets, cloud credentials, production-like environments, package registries, databases and CI/CD systems. In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI agent deleted a live database during an explicit code freeze (Fortune, July 23, 2025). It was a public experiment, not an enterprise system, and Replit's CEO committed to separating development and production databases. But it makes the point: a code freeze is a human policy, and it does nothing unless the agent's actual permissions enforce it.

The relevant principle is least privilege. OWASP's Top 10 for Agentic Applications (December 9, 2025) extends it to least agency: autonomy should be granted deliberately, scoped to the task, not by default. Unit 42's SHIELD framework makes a similar argument and recommends restricting agents to development and test environments.

4. The review bottleneck (established dynamic)

Generation velocity now exceeds human review capacity. The gap shows up as superficial reviews, approval fatigue, blind acceptance, rubber-stamping, security exceptions and undocumented AI-generated changes.

Unit 42 observes that AI-generated code looks correct and works, which creates a false sense of security and erodes change control. Review sized for human output can't absorb machine output without tiering: deciding which changes need deep human attention and which can be validated automatically.

5. The accountability gap

When AI generates the code, who is accountable for the resulting behavior? "The AI generated it" is not an accountability model. Responsibility must stay explicit across the developer, the engineering manager, security, the application owner, the AI governance team and the organization. If no one can say who approved a change, or whether it was AI-generated at all, the organization can't answer an auditor or an incident responder.

​

None of this makes existing controls obsolete. SAST, DAST, SCA, secrets scanning, code review, dependency scanning, IaC scanning and CI/CD controls remain necessary, and NIST's Secure Software Development Framework (SP 800-218) remains a sound baseline for them.

But these controls inspect artifacts and known security properties. They don't tell you:

• What did the AI agent actually do, and which tools did it call?
• Which files did it access and which repositories did it modify?
• What permissions did it use, and did its behavior match its authorization?
• Did it act outside the intended workflow, or introduce changes no one meaningfully reviewed?

Unit 42 reports that most organizations it assessed allow vibe coding tools because nothing blocks them, yet very few had formally assessed the risk or monitored inputs, outputs and security outcomes. Closing that visibility gap takes a second discipline alongside AppSec: behavioral governance for AI agents.

​

Traditional AppSec asks: "Is this code secure?" AI agent governance asks: "Did the AI agent behave within the boundaries we authorized?"

Answering the second question requires visibility into:

• Agent identity
• Actions and tool calls
• Permissions in use
• Repositories accessed and files modified
• Commands executed and APIs called
• Data accessed
• Policy violations
• Anomalous behavior and behavioral drift

This mirrors the shift in enterprise AI governance generally: from validating an artifact once to continuously assuring behavior in operation. AI agent security for coding is one of the first places it shows up.

​

Step 1: Establish AI coding policies

Define approved AI coding tools, models and repositories, prohibited data, acceptable use and human approval requirements. Policy is the reference against which behavior is later judged, so it must be specific enough to test.

Step 2: Define agent permissions

Apply least privilege and separate read, write, repository, production, cloud, secret and CI/CD access. AI agents should not inherit unrestricted developer privileges by default. A practical starting point is development and test environments only, no standing access to secrets, and gates on destructive commands.

Step 3: Track AI-generated changes

Know where AI was used, which agent generated changes, what was modified, which tools were used and which dependencies were introduced. The goal is an auditable trail: commit and pull request metadata, dependency diffs and agent session logs security can query.

Step 4: Add human approval gates

Human review should stay mandatory for high-risk actions:

• Production changes
• Authentication and authorization logic
• Infrastructure changes
• Secrets handling
• Database migrations
• Security configuration
• External API integrations

Lower-risk changes can rely on automated validation. Tiering keeps review from degrading into rubber-stamping.

Step 5: Continuously monitor agent behavior

Governance doesn't stop at the pull request. AI agent behavioral monitoring should cover tool usage, unusual commands, unexpected repository access, permission escalation, sensitive-data access, unusual API calls, policy violations and behavioral deviations.

It helps to separate two ideas. Pre-deployment validation asks whether this build passed its checks. Runtime behavioral assurance asks whether the agent, and the software it produced, keep behaving within policy after those checks are done.

Step 6: Define automated response controls

Enterprises should be able to block unauthorized actions, revoke permissions, require approval, isolate suspicious activity, stop workflows, raise alerts and preserve audit evidence.

A kill switch shouldn't be the only option. Graduated controls (alert, require approval, block, revoke, isolate, stop) let the response match the risk without halting every developer.

​

Use these as a readiness checklist for your AI coding security program. An honest "we don't know" is itself a finding.

1. Which AI coding tools are approved?
2. Which models can access proprietary source code?
3. What data can coding agents access?
4. What repositories can they modify?
5. Can they execute shell commands?
6. Can they install dependencies?
7. Can they access secrets?
8. Can they interact with cloud infrastructure?
9. Are AI-generated changes identifiable?
10. Is human approval required for high-risk changes?
11. Are agent actions logged?
12. Can security teams investigate agent behavior?
13. Can unauthorized agent actions be blocked?
14. How is behavioral drift detected?
15. Can the organization demonstrate compliance during an audit?

• Level 1, Uncontrolled. Employees use AI coding tools without centralized governance.
• Level 2, Visibility. The organization knows which AI tools are used and where.
• Level 3, Controlled. Policies, permissions, approvals, scanning and monitoring are implemented.
• Level 4, Continuous AI assurance. The organization continuously monitors AI agent behavior, enforces policies dynamically, detects deviations and maintains auditable evidence.

Level 4 is the direction of travel. Know which level you occupy today.

​

Evidence varies by model, language and task, so a blanket claim isn't defensible. Veracode's 2025 GenAI Code Security Report found that AI-generated code introduced a vulnerability in 45% of 80 curated tasks, and its 2026 edition reports an average pass rate of 56%. The practical lesson is that functional code and secure code are different properties, and AI-generated code needs the same verification as any other untrusted input.

​

Separate read, write, repository, production, cloud, secrets and CI/CD access, and grant an agent only what its task requires. A sensible baseline is development and test environments only, no standing access to production credentials, and approval required for destructive or irreversible commands. OWASP's Top 10 for Agentic Applications calls this principle least agency.

​

SAST and SCA inspect artifacts, meaning code and dependencies, for known weaknesses. Behavioral monitoring observes actions: which tools an agent called, which files and repositories it touched, what permissions it used and whether that matched its authorization. The two are complementary, and the second answers questions the first cannot.

​