Why AI Coding Agents Keep Writing Broken Access Control

What it claims

Broken access control is A01 in the OWASP Top 10:2025. Every application tested showed some form of it, and the category recorded 1,839,701 occurrences, the most of any entry. A01 maps 40 CWEs. Static analysis handles several of them well: path traversal, open redirect and SSRF. Semantic engines can also flag a route that lacks an authorization decorator or middleware, but only when the codebase applies one consistently. The gap the post points to is narrower than "authorization": it is object-level checks (CWE-639/862/863). The scanner can see that a check exists but cannot tell whether it is the correct check.

How it works

The worked example is an agent asked to "add an endpoint that returns an invoice by ID." The agent produces code that:

• authenticates the caller,
• looks up the invoice by the URL ID,
• returns 404 on a miss,
• returns the record.

That endpoint is correct as specified, yet any logged-in user can read any invoice. The fix is a single extra condition: match on invoice ID and the caller's organization. It depends on three product facts:

1. Invoices belong to organizations.
2. Users are scoped to the organizations they belong to.
3. Cross-org reads are never legitimate.

The third fact varies by product. Auditors, resellers or parent accounts may be allowed to read across tenants by design.

Two review details the summary omits:

• Return 404, not 403, on another tenant's object. Folding the ownership condition into the lookup does this automatically. A 403 confirms the record exists and enables ID enumeration.
• Returning the stored record unmodified sends every field. The same handler often carries a data-exposure bug alongside the authorization bug.

For the proposed "application-context graph" approach, the post sets three trust conditions:

• Reasoning must be grounded in an assembled model of the app. Otherwise the findings describe a partly imagined codebase and waste tokens.
• Findings must be confirmed by something other than the system that produced them. An agent should not validate its own fix.
• Fixes must be proven against the app's rules and must keep holding as the code changes, not just proposed.

How to use it

The checklist needs no new tooling. Specifics beyond the summary:

• Inventory: include every route that takes an ID, filename or key from the URL or body.
• PR review: ask a specific question rather than "review carefully": does the endpoint verify entitlement to the object, and against which field?
• Cross-tenant tests: write one test per resource type, asserting that a valid session from tenant A gets a 404 on tenant B's object. This follows OWASP's prevention guidance to put functional access control in unit and integration tests.
• Control points: the post splits checking into three places:
• real-time checks inside the agent's loop,
• deterministic scans on every change in CI, which are stable enough to gate a pipeline,
• periodic deep analysis of the whole codebase, where object-level flaws surface.
• Testing methods, by increasing coverage: manual attempts with a valid session against another account's objects, then automated functional tests, then continuous dynamic testing of running APIs.

Limits

• The post concedes that evidence AI code has more authorization flaws is thin. Most published studies of AI-generated code test injection, XSS and crypto misuse, because those categories have automatable ground truth. The authors call the direction well-supported but say per-category figures are still emerging.
• This is a vendor post. Evo Agentic AppSec, first previewed in August, is described only as a direction, with no detection results. Runtime confirmation is assigned to a separate product, Evo Continuous Offensive Security.
• The context-graph approach is presented with no benchmark, false-positive rate or cost figures.