# Datadog: CodeGuard rules left an access flaw in agent-built apps

> Pre-written security rules improved some generated code, but every agent in Datadog's test still shipped the same access-control flaw.

- **Severity:** Info: Research, tools, evals or lab claims with no direct exposure. Context, not an alert.
- **Category:** Research, Benchmark
- **Published by:** Datadog Security Labs
- **Disclosed:** 2026-10-19
- **Affects:** Claude Code, Cursor, OpenAI Codex
- **Research by:** Kennedy Toomey
- **Primary source:** https://securitylabs.datadoghq.com/articles/putting-models-to-the-secure-coding-test-security-rules/
- **Page:** https://theinjection.dev/items/datadog-codeguard-security-rules/

Project CodeGuard's security rules did not stop coding agents from shipping an insecure direct object reference, Datadog Security Labs reports. Only GPT 5.5 closed the flaw with rules on, while Sonnet 5 and Composer 2.5 kept it.

## What happened

Datadog Security Labs published the second part of its secure coding series on October 19, 2026. Kennedy Toomey asked three coding agents to build the same document portal twice, once in default mode and once with Project CodeGuard v1.4.0 security rules installed. Claude Code ran Sonnet 5, Cursor ran Composer 2.5 and Codex ran GPT 5.5.

## How it works

Project CodeGuard ships pre-written security rules that an agent reads as instructions before it writes code, covering areas such as cryptography, input validation and authorization. The rules describe general classes of flaw, not the ownership model of one application. Toomey reports that the gaps left behind matched the constraints the prompt never named, which is why an insecure direct object reference, where a logged-in user can open another user's documents, survived in two of the three rule-guided builds.

## Who is affected

Teams that install CodeGuard rules and expect them to cover authorization are the ones exposed, because the effect differed sharply by agent. Cursor Composer 2.5 produced the weakest build in Toomey's rating, with a critical finding where JSON web tokens were validated without any revocation check, so tokens stayed usable after logout or a password reset. Claude Sonnet 5 kept the access flaw alongside three medium-severity gaps.

## What to do

Name the security requirements your application needs in the prompt, including who owns each record, because Toomey found that a generic instruction to build securely was not enough. Review generated authentication and authorization code by hand, and check that revocation applies on every authenticated route rather than some. Datadog also suggests a global agent instruction file that sets a dependency cooldown of about seven days and pins versions.

## Static analysis findings in the generated app

Datadog Code Security SAST findings per build. Lower is better for defenders.

| Result | Score |
|---|---|
| Sonnet 5 | 1findings |
| Composer 2.5 | 17findings |
| GPT 5.5 | 1findings |
| Sonnet 5 with rules | 0findings |
| Composer 2.5 with rules | 4findings |
| GPT 5.5 with rules | 0findings |

Source: https://securitylabs.datadoghq.com/articles/putting-models-to-the-secure-coding-test-security-rules/

## Quick facts

- **Tested:** Claude Code (Sonnet 5), Cursor (Composer 2.5), Codex (GPT 5.5)
- **Rules:** Project CodeGuard v1.4.0, open source
- **Task:** One document portal with login, file upload, search, comments and admin user management
- **Access control:** Every default-mode build had an insecure direct object reference; only GPT 5.5 closed it with rules on
- **Found by:** Kennedy Toomey, Datadog Security Labs
- **Published:** October 19, 2026
- **Limitation:** One run per configuration, so each number is a single nondeterministic sample

## Questions

### Do Project CodeGuard rules make coding agents write secure code?

Project CodeGuard rules helped unevenly in Datadog's test. GPT 5.5 closed the access-control flaw once the rules were installed, while Claude Sonnet 5 and Cursor Composer 2.5 kept it. Datadog Code Security did record fewer static analysis findings with rules on, falling from 17 to 4 for Composer 2.5. Datadog reports the rules did not cover application-specific ownership logic.

### Which agent produced the weakest code with the security rules enabled?

Cursor Composer 2.5 produced the weakest build with rules enabled, in Kennedy Toomey's assessment. Composer 2.5 validated JSON web tokens without checking revocation, so tokens remained usable after logout or a password reset. Both JWT_SECRET and SESSION_SECRET fell back to hardcoded values, and the production check meant to prevent that never ran, because the fallback was applied first.

### How much should I trust a single run of this comparison?

Datadog ran each configuration once, so every number reflects one nondeterministic generation rather than an average, and Toomey states that limitation in the post. The direction of the result still carries: every default-mode build shipped the same access-control flaw. Datadog published the generated code and its findings as a repository and CSV, so the runs can be checked.

## Sources

1. [Datadog Research](https://securitylabs.datadoghq.com/articles/putting-models-to-the-secure-coding-test-security-rules/)
2. [Series Part 1](https://securitylabs.datadoghq.com/articles/putting-models-to-the-secure-coding-test-plan-vs-default-mode/)
3. [Test Repo and Findings](https://github.com/DataDog/putting-models-to-the-secure-coding-test)
4. [CodeGuard Rules](https://project-codeguard.org/getting-started/)