- A Datadog Security Labs researcher gave three AI coding agents an open source rulebook. In that single test, the rules fixed different flaws in each build, and not all of them.
- Two of three rule-guided builds still let any user reach others' documents. GPT 5.5 closed that gap for ordinary users. The prompt never said who should access documents.
- State access rules in the requirements for every AI-built feature, and add a cheap test that each safeguard actually fires.
A rulebook can tell a builder to lock every door. Whether it also settles who holds the keys is a different question. A new test from Datadog Security Labs puts that question to three AI coding agents that were given a set of security rules.
The lesson here is that installed rules do not reliably carry the decisions that belong to your business. In this test, two of three builds missed the most basic one. The third got it right, and the test cannot say why.
What the researcher tested
The researcher is Datadog's application security researcher and advocate. The post is the second in a series on how well coding agents write secure code. The test used Project CodeGuard v1.4.0, which the researcher describes as "an open source security framework that provides security rules for coding agents to follow." Once installed, the rules run in the background until someone disables them.
Each of three tools built the same document-upload application from the same prompt, with the same rules. Claude Code used Sonnet 5. Cursor used Composer 2.5. Codex used GPT 5.5. The researcher then compared each build with a build from an earlier run without rules.
The prompt did not say who should be able to see uploaded documents. In the earlier run, all three default builds let any logged-in user reach other people's files. This flaw is called an insecure direct object reference, or IDOR. The app hands over a record when asked for it by ID, without checking who owns it.
How the findings were produced
The findings in this story come from automated tools, not a human penetration test. The researcher used Claude's code_review skill, running Sonnet 5, to audit every build. Datadog Code Security flagged dependency, code and infrastructure-as-code issues.
One consequence is worth stating. Sonnet 5 wrote one build and also reviewed it. The post describes no human audit.
What the rules changed
The results differ by tool. The researcher ran each model once, so they describe three builds, not a ranking.
With rules on, Sonnet 5 proposed a security plan for approval and ran a verification step that found and fixed a bug. The AI code review still found the IDOR. The researcher concluded that the rules produced no meaningful improvement. One regression appeared. The check that blocks revoked sessions ran only on routes with a particular request-forgery protection. A deactivated user kept read access until their access token expired.
The researcher found Composer 2.5 the weakest of the three. The AI review rated one finding critical severity. Login tokens were checked only for a valid signature and expiry. They were kept in the browser's localStorage. A stolen token kept working for up to 24 hours after logout or a password reset. The IDOR also remained.
The GPT 5.5 build broke the pattern. The review found no cross-user document IDOR for ordinary users. The build did set a manager role with broad access to every user's documents. The researcher treated that role and a single shared rate limit as design choices, not vulnerabilities.
Its other findings were narrower. Password-reset requests did not cancel earlier unexpired tokens. The app computed an IP fingerprint for each session but never compared it.
A safeguard that looks real and does nothing
The Composer 2.5 build shows a subtler risk. The app needs two secret values to sign login tokens. The model wrapped them in a helper called requireEnv, which appears to stop the server in production if a secret is missing. But the code set a hardcoded fallback value before the check ran. In the researcher's words, "the check never fires."
The server therefore starts anywhere, production included, using a secret that sits in the source code. The researcher notes that anyone who has seen that code could forge login tokens. The rules prompted the model to add something that looks like a safeguard, but the outcome did not change.
In this test, the AI code review flagged the problem, and the cause was the fallback being applied before the check. It is still easy to miss in a quick skim, because a security check is visibly there. A cheap extra safeguard is to start the app in production mode without its secrets. If it runs, the check does nothing.
The missing sentence, and one exception
The researcher reads the pattern as a prompting problem. Outcomes followed what the instructions spelled out. A general request to build securely does not become a specific requirement to restrict each document lookup to its owner. The researcher's advice is to state that requirement, or leave the model to decide.
GPT 5.5 complicates that view. It ran the same rules and the same prompt, and it closed the gap anyway. Two of the three builds did not. The rules did not reliably supply the ownership decision.
Each model ran once. The test cannot show whether the rules, the model or chance explains the difference. The researcher says that in a perfect world agents would default to restricted access.
Rules can require fire exits. Who may enter the vault is a business decision, and this test gives no reliable sign that a rulebook will make it for you.
Limits and one detail on dependencies
The researcher says AI is nondeterministic, so another run might behave differently. This was one application, one prompt and one run per model. It does not establish how any tool performs in general.
One detail may matter to procurement. The Sonnet 5 and Composer 2.5 builds allowed automatic minor-version upgrades of dependencies. GPT 5.5 pinned exact versions. The researcher says pinning can leave packages out of date but lowers the risk of pulling a new malicious release. The researcher suggests dependency cooldowns, a waiting period before adopting new versions.
Questions for your team
Ask whether requirements for AI-built features state who may see, change and delete each record. Ask who reviews authorization specifically, since all three default builds, and two of the three builds with rules, left document access unscoped. Ask whether that review includes a human, since the findings here came from automated tools.
Ask for a cheap extra test that shows each safeguard fires, such as starting the app in production mode without its secrets. The researcher prefers adding security guidance to the rules or to the global agents.md or claude.md file, so it applies to every project. Finally, ask what policy governs dependency updates.
Rules help set the floor. The question of who owns the document still needs an answer written down.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Datadog Security Labs.
