Skip to content

Back to the catalog

Why AI Coding Agents Keep Writing Broken Access Control
snyk.ioarticle

Why AI Coding Agents Keep Writing Broken Access Control

Snyk explains why AI coding agents reliably ship broken object-level authorization (BOLA/IDOR) bugs: the ownership rule that would prevent them (e.g. "invoices belong to organizations") lives in the product's data model and team knowledge, not in the prompt or surrounding code, so the agent produces code that is correct for the stated task but lets any authenticated user access other tenants' objects. The piece maps the flaw to CWE-639/862/863, contrasts it with pattern-matchable classes like SSRF and path traversal that SAST handles well, and lays out five concrete team actions (endpoint inventory, documented ownership rules, explicit authz review questions, per-resource cross-tenant tests, and periodic deep contextual analysis), while pitching Snyk's "application-context graph" and Evo Agentic AppSec as the tool for the pattern-less gap.

TL;DR AI coding agents keep shipping BOLA/IDOR bugs because the ownership rules that would prevent them live outside the code, and Snyk argues this requires context-graph reasoning instead of pattern-based SAST.
Also seen from another angle🧠 AI →
Document

What it is

The piece centers on one concrete example: an AI-generated "get invoice by ID" endpoint that authenticates, handles the 404 case, and reads cleanly in review, yet lets any logged-in user read any other organization's invoice by changing the ID in the URL — a BOLA/IDOR bug mapped to CWE-639, CWE-862, and CWE-863.

How it works

The fix is one additional condition on the lookup: match the invoice by ID and by the caller's organization — nothing else about the endpoint changes. The three facts needed to know that are absent from the code and prompt entirely: that invoices belong to organizations, that user access is scoped to org membership, and that cross-org reads are never legitimate in this product. The piece stresses these facts can vary by product (some platforms intentionally allow auditors/resellers to read across tenants), so the rule can't be inferred from code shape alone — it lives in the data model and team knowledge.

Two review details the page calls out specifically: a cross-org request should return the same 404 as a missing record (not 403, which would leak existence and enable enumeration), and returning the stored record unmodified often bundles a data-exposure bug alongside the authorization one.

Preconditions / Affected

Applies to any endpoint that accepts an object identifier (ID, filename, key) from a URL or request body — the piece notes this inventory is "usually shorter than teams expect and longer than they hope."

What to do

Five concrete, tool-free steps from the piece:

  1. Inventory every endpoint that accepts an object identifier from the request.
  2. Write down ownership rules per resource type (what it belongs to, who may read/modify it).
  3. Make authorization an explicit PR review question on agent-authored code: "does this endpoint verify the caller is entitled to the object, and against which field?"
  4. Add one cross-tenant test per resource type: a valid session from tenant A must get a 404 on tenant B's object.
  5. Run deep contextual analysis across the whole codebase on a regular cadence, distinct from real-time agent checks and CI scans — the piece states object-level authorization flaws specifically surface at this third layer, not the first two.

Caveats

The piece itself flags that the claim "AI-generated code has more authorization flaws than human-written code" is mechanistically well-supported but thinly measured — most published AI-code-security studies target injection/XSS/crypto misuse, which have automatable ground truth, not BOLA.

Organisations named here

  • Evo Agentic AppSec

Technologies named here

  • Snyk Evo Agentic AppSec
  • AI coding agents
  • Snyk Evo Continuous Offensive Security
  • SAST / semantic static analysis engines
  • Snyk
  • OWASP
  • Evo Continuous Offensive Security

Techniques named here

  • BOLA
  • IDOR
  • CWE-639
  • CWE-862
  • CWE-863
  • Path traversal
  • Open redirect
  • SSRF
  • Injection
  • Authorization bypass through user-controlled key
  • Missing Authorization
  • Incorrect authorization