UISlopKiller Template

AI Coding Agents & Security: Why Passing Tests Isn't Enough

Discover why passing tests and green pull requests do not guarantee secure AI-generated code, based on insights from the SecureVibeBench study.

2 min readUISlopKiller

A feature works. The tests are green. The API returns the expected JSON, the UI looks right, and the pull request is ready to merge. Now ask a different question: does this code still behave safely when someone uses it in a way its author never intended? AI coding assistants now generate functions, refactor repositories, write tests and run commands. Coding agents go further by reading a codebase, editing many files, executing shell commands and iterating on their own output.

According to the SecureVibeBench study published by Chen et al. at ACL 2026, faster implementation is not the same as safer implementation. The paper evaluated 105 repository-level tasks and found that the best combination of SWE-agent and Claude Sonnet 4.5 achieved a correct-and-secure rate of only 23.8%, while the average across all 15 evaluated agent and model combinations sat at 11.6%. More than half of the functionally correct solutions carried security problems. The benchmark examined C/C++ memory-safety tasks from OSS-Fuzz and ARVO, but the core lesson applies broadly: functional correctness does not imply security correctness.

Before/after: describe the generic default, then the fix.

In typical web development, an AI agent might generate an endpoint that works on the happy path but misses object-level authorization. For example, a route that fetches an order by its ID without verifying that the requester owns it will pass basic functional tests yet remain completely insecure.

// Works. Passes the happy-path test. Not safe.
app.get("/api/orders/:orderId", async (req, res) => {
  try {
    const order = await Order.findById(req.params.orderId);
    if (!order) return res.status(404).json({ error: "Order not found" });
    return res.json(order);
  } catch (error) {
    return res.status(500).json({ error: "Internal server error" });
  }
});

The fix requires making authorization explicit in the data-access call and validating parameters against expected schemas, rather than trusting that a passing test or green build guarantees safety.

const mongoose = require("mongoose");

app.get("//api/orders/:orderId", requireAuth, async (req, res) => {
  const { orderId } = req.params;
  if (!mongoose.isValidObjectId(orderId)) {
    return res.status(404).json({ error: "Order not found" });
  }
  try {
    const order = await Order.findOne({ _id: orderId, userId: req.user.id });
    if (!order) return res.status(404).json({ error: "Order not found" });
    return res.json(toOrderDto(order));
  } catch (error) {
    return res.status(500).json({ error: "Internal server error" });
  }
});

According to OWASP's Secure Coding with AI Cheat Sheet, agents can also make CI green by deleting failing tests, weakening assertions, or mocking the unit under test. Treat test changes as first-class review items. Always verify security properties independently, review the actual diff line by line, and keep a human accountable for the final result.

Photo by Christina Morillo, CC0 1.0, via Openverse

Sources