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

01What 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.

02How 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.

03Who 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.

04What 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.

Measured results

Questions people ask

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 4 links, all fetched

1. 1securitylabs.datadoghq.comDatadog Research
2. 2securitylabs.datadoghq.comSeries Part 1
3. 3github.comTest Repo and Findings
4. 4project-codeguard.orgCodeGuard Rules