Listen to this Post
Introduction: The Security Paradox of AI Coding Agents
Artificial intelligence is becoming remarkably capable at writing software, reviewing code, and identifying weaknesses that might otherwise take human security teams hours to discover. But a troubling pattern is emerging: the same AI coding agents that can help developers build applications faster can also introduce vulnerabilities into the code they are supposed to secure.
A recent test involving three coding agents illustrates that problem with unusual clarity. When the agents were evaluated on a document portal in both default and plan modes, they repeatedly produced insecure implementations containing IDOR vulnerabilities across multiple application routes. The most serious failure involved Composer 2.5, whose plan mode reportedly hardcoded a JWT secret into the application, creating a potentially severe path toward administrative impersonation.
The result raises a difficult question for the modern software industry: if AI agents are increasingly trusted to write production code, who is responsible when those agents quietly reproduce the very security mistakes developers are trying to eliminate?
The Experiment Focused on Real Application Security
The test examined three AI coding agents while they worked on a document portal. Rather than simply measuring whether the systems could generate functioning software, the evaluation looked at whether their implementations respected fundamental security principles.
The agents were tested in two different operating styles, default mode and plan mode.
That distinction matters because planning is often presented as one of the ways AI agents can produce better code. A planning phase gives the model an opportunity to reason about architecture, requirements, dependencies, and implementation steps before it begins modifying a project.
In theory, that should reduce mistakes.
In practice, this experiment showed that planning does not automatically translate into secure software.
IDOR Vulnerabilities Appeared Across Multiple Routes
The most important recurring problem was insecure direct object reference, commonly known as IDOR.
An IDOR vulnerability occurs when an application exposes a reference to an internal object, such as a document ID, user ID, invoice number, or database record, without properly verifying whether the requesting user is authorized to access that object.
A simplistic application might assume that because a user is logged in, they are allowed to request /documents/123.
That assumption is dangerous.
The server must determine whether the authenticated user is actually permitted to access document 123. Authentication answers the question, “Who are you?” Authorization answers the more important question, “Are you allowed to access this?”
Why IDOR Is More Dangerous Than It Looks
IDOR vulnerabilities can appear deceptively simple in source code.
An endpoint might receive an object identifier from a URL and immediately query the database using that identifier. The application may correctly verify that the user has an active session, yet never check whether the requested object belongs to that user.
That creates a security boundary failure.
An attacker who discovers another valid identifier may be able to access information belonging to another account simply by changing a parameter.
The weakness is especially dangerous in document-management systems because documents may contain confidential business information, contracts, financial records, internal communications, customer data, or intellectual property.
The Repetition Is the Real Warning Sign
One vulnerable route can be a developer mistake.
Repeated IDOR vulnerabilities across multiple routes suggest something deeper.
It can indicate that the underlying development process is failing to establish authorization as a first-class architectural requirement. Instead of treating access control as something every endpoint must enforce, an AI agent may learn or reproduce a pattern in which authentication is treated as sufficient.
That distinction becomes critical when AI agents are allowed to generate large portions of an application automatically.
A developer may review the final interface and see that everything works.
The attacker sees something else.
The attacker sees an authorization boundary that was never properly implemented.
Composer 2.5 Produced the Most Serious Security Failure
The most alarming finding in the reported test involved Composer 2.5 operating in plan mode.
According to the supplied report, the agent hardcoded a JWT secret into the application.
That is significantly more serious than an ordinary coding mistake.
JWTs, or JSON Web Tokens, are commonly used to represent authenticated sessions or claims. Their security depends heavily on how signing keys and verification mechanisms are handled.
If a sensitive signing secret is embedded directly into source code, anyone who gains access to that secret may potentially be able to construct tokens that the application trusts.
If the
Hardcoded Secrets Are a Fundamental Security Anti-Pattern
Hardcoded credentials and cryptographic secrets have been recognized as dangerous for years.
Secrets should generally be managed through appropriate secret-management mechanisms, environment configuration, protected deployment systems, or dedicated secret stores.
Putting a JWT signing secret directly into source code creates several risks.
The secret can enter Git history.
It can appear in backups.
It can be copied into developer environments.
It can leak through logs or debugging systems.
It can become accessible to other developers or automated systems.
Most importantly, developers may forget that the secret exists because the application continues functioning normally.
Why Plan Mode Deserves Particular Attention
The plan-mode result is particularly interesting because planning is supposed to improve reasoning.
A planning agent can spend additional tokens analyzing the task before implementing it. That additional reasoning may improve architecture, but it does not guarantee that the agent understands security boundaries correctly.
In fact, a more sophisticated implementation process can sometimes make a vulnerability harder to notice.
The code may look organized.
The architecture may look deliberate.
The functions may be cleanly separated.
The application may pass ordinary functional tests.
And yet authorization can still be fundamentally broken.
Functional Correctness Is Not Security Correctness
This distinction should become central to AI-assisted development.
An application can be functionally correct while being dangerously insecure.
A document portal that successfully creates, displays, edits, and deletes documents may appear finished from a product perspective.
But if one user can access another
AI coding evaluations therefore need to measure more than whether an application runs.
They need to ask whether the application protects the boundaries between users, roles, resources, and administrative functions.
AI Agents Need Adversarial Testing
The findings reinforce the importance of security testing after AI-generated code is produced.
Developers should not assume that an AI
An agent may reason correctly about the feature requirements while overlooking an attacker-controlled input.
This is why adversarial testing remains essential.
For an application containing resource identifiers, security testing should deliberately attempt to access objects belonging to different users.
The question should not simply be whether /documents/123 works.
The question should be whether the wrong user can make /documents/123 work.
Authorization Must Exist at the Server
One of the most important lessons from IDOR vulnerabilities is that authorization cannot depend on the frontend.
A web interface may hide a document from an unauthorized user.
That does not protect the underlying resource.
An attacker can interact directly with APIs.
They can modify requests.
They can bypass frontend restrictions.
They can automate parameter changes.
The backend must therefore enforce authorization independently for every sensitive operation.
Security Cannot Be Added Only at the End
AI-assisted development encourages rapid iteration.
A developer can describe a feature, allow the agent to generate code, test it, and immediately move on to the next requirement.
That workflow is efficient.
It can also create security debt at extraordinary speed.
If every feature introduces one subtle authorization mistake, an application built through dozens of AI-generated features can accumulate a large attack surface before anyone performs a serious security review.
Security therefore needs to be integrated into the generation process rather than treated exclusively as a final inspection.
The Bigger Problem Is Trust
The most important issue here is not that an AI agent made a mistake.
Humans make security mistakes every day.
The larger concern is that AI coding agents are increasingly being positioned as systems capable of independently planning, implementing, testing, and modifying software.
That changes the scale of the problem.
A human developer who introduces one vulnerability affects one piece of code.
An automated agent can reproduce the same flawed pattern across dozens of endpoints in minutes.
Automation magnifies both good engineering practices and bad ones.
What This Means for Developers
Developers using AI coding agents should treat generated code as untrusted code until it has passed appropriate security checks.
That does not mean abandoning AI-assisted development.
It means changing the workflow.
Every authentication-sensitive endpoint should receive authorization testing.
Every externally supplied identifier should be treated as potentially hostile.
Every secret should be checked for accidental exposure.
Every administrative function should be tested against lower-privileged accounts.
And every generated dependency or configuration should be reviewed before production deployment.
What This Means for Security Teams
Security teams should also adapt their testing strategies.
Traditional code review may not be enough when AI systems are producing large quantities of code at high speed.
Automated security testing should become part of the development pipeline.
Static analysis can search for suspicious patterns.
Dynamic application testing can probe access-control boundaries.
Dependency scanners can identify vulnerable libraries.
Secret scanners can detect accidentally committed credentials.
And targeted authorization tests can determine whether users can cross resource boundaries.
What Undercode Say:
AI Is Becoming a Developer, So Security Testing Must Become More Aggressive
AI coding agents are no longer experimental toys.
They are becoming part of real development workflows.
That makes secure generation a much bigger issue than model benchmark scores.
An agent can produce elegant code and still produce an insecure application.
IDOR vulnerabilities demonstrate why authorization needs to be explicitly tested.
The repeated nature of the vulnerabilities suggests that one bad implementation pattern can spread across multiple routes.
That is precisely the type of mistake automation can amplify.
A developer might manually create one insecure endpoint.
An AI agent can replicate the same mistake throughout an entire application.
The JWT secret incident adds another dimension.
Hardcoded secrets represent a failure of security hygiene that modern development tooling should already recognize.
If an AI agent is generating production-ready software, developers will reasonably expect it to avoid basic secret-management mistakes.
That expectation cannot replace verification.
Plan mode is particularly interesting because it challenges the assumption that more reasoning automatically means better security.
Planning can improve architecture.
Planning can improve consistency.
Planning can improve feature completeness.
But security requires an adversarial mindset.
The system must think not only about how the legitimate user interacts with the application.
It must also consider how an attacker will manipulate the same application.
That difference is enormous.
A secure document portal must assume that users will modify object identifiers.
It must assume that API requests will be replayed.
It must assume that parameters will be changed.
It must assume that attackers will inspect application behavior.
It must assume that frontend restrictions will be bypassed.
It must enforce authorization on the server.
AI agents should therefore be evaluated with attacker-style scenarios.
Security benchmarks should include multiple users.
They should include multiple privilege levels.
They should include deliberately manipulated object identifiers.
They should include stolen or forged authentication material.
They should include secret exposure tests.
They should include regression testing after every major change.
The industry also needs better metrics for AI-generated software.
Lines of code are not enough.
Successful builds are not enough.
Passing unit tests are not enough.
A polished user interface is certainly not enough.
The real measurement should include whether the generated system protects its security boundaries.
AI-assisted programming will continue expanding because the productivity benefits are difficult to ignore.
But productivity without security can simply produce vulnerabilities faster.
The correct response is not to reject AI coding agents.
The correct response is to surround them with stronger controls.
Human review should remain part of sensitive development.
Automated security testing should run continuously.
Secrets should be externally managed.
Authorization should be explicitly tested.
And generated code should be treated as potentially flawed until proven otherwise.
The future of secure software development may not be human versus AI.
It may instead be AI generation combined with automated adversarial verification and experienced human oversight.
That combination could be far more powerful than either approach alone.
Deep Analysis: Testing for IDOR and Secret Exposure
Start by Inspecting the Application
A security review should begin by identifying endpoints that accept object identifiers.
grep -RInE (/documents/|documentId|userId|fileId|resourceId) .
This does not prove that an IDOR exists.
It simply helps locate areas where resource-level authorization deserves closer inspection.
Search for Hardcoded JWT Secrets
A basic source-code review can also search for suspicious JWT configuration.
grep -RInE jwt|secret|signingKey|privateKey|token .
Security teams should then inspect whether sensitive values are hardcoded or loaded through secure configuration.
Search for Common Credential Patterns
Secret scanners can provide more comprehensive coverage than simple text searches.
git grep -nEi 'password|api[<em>-]?key|secret|token|private[</em>-]?key'
This should be combined with dedicated secret-scanning tools in a real development pipeline.
Test Resource Ownership
A basic IDOR test requires at least two accounts.
Account A should create a resource.
Account B should attempt to access that resource using its identifier.
For example:
curl -H "Authorization: Bearer USER_B_TOKEN" \nhttps://example.com/api/documents/123
The expected result should be an authorization failure if document 123 belongs to User A.
Test Multiple Routes
Finding one vulnerable endpoint is not enough.
Security testing should examine related routes such as:
GET /documents/{id}
PUT /documents/{id}
PATCH /documents/{id}
DELETE /documents/{id}
GET /documents/{id}/download
Every operation needs its own authorization enforcement.
Check JWT Configuration
A deployment should never rely on a secret embedded directly inside application source code.
Environment configuration can be inspected with:
printenv | grep -Ei 'JWT|TOKEN|SECRET'
The exact production implementation should use an appropriate secret-management system rather than exposing secrets through ordinary shell environments unnecessarily.
Scan Git History
Deleting a secret from the latest version does not necessarily remove it from Git history.
A repository should therefore be reviewed for previously committed credentials.
git log --all --oneline --decorate
Dedicated secret-scanning tools should be used for serious investigations.
Build Security Into CI/CD
Security checks can be integrated into continuous integration.
A conceptual pipeline might include:
npm test npm run lint npm audit
followed by static analysis, secret scanning, dependency analysis, and application security testing.
The exact commands depend on the
Treat AI-Generated Code as Untrusted
The central lesson is simple.
AI-generated code should enter the same security pipeline as human-written code.
It should not receive an automatic trust exemption merely because the system that produced it is sophisticated.
Reported Findings
✅ The supplied report describes testing three coding agents in default and plan modes and identifies repeated IDOR vulnerabilities across routes.
✅ The report specifically identifies Composer 2.5 plan mode as producing a hardcoded JWT secret, which represents a serious security anti-pattern.
❌ The supplied X post alone does not provide enough technical detail to independently verify every implementation detail of the underlying experiment, so the precise scope and severity of each vulnerability should be interpreted according to the original technical write-up.
Prediction
(+1) AI Security Testing Will Become a Standard Development Requirement
AI coding agents will increasingly be evaluated on security, not merely code-generation accuracy.
Authorization testing will become more important as agents generate larger application surfaces.
Automated secret detection will become a standard part of AI-assisted development pipelines.
Developers will increasingly combine coding agents with security-focused agents that attempt to break the generated software.
Security benchmarks for AI coding systems will likely include realistic multi-user authorization scenarios.
(-1) Blind Trust in AI Coding Agents Will Become Increasingly Difficult to Defend
Organizations that deploy AI-generated code without independent security testing will face greater exposure.
Repeated vulnerabilities could become more damaging as automated agents generate larger codebases.
Planning modes alone will not eliminate security mistakes.
Passing functional tests will remain insufficient evidence that AI-generated applications are secure.
Hardcoded credentials and authorization failures could become particularly dangerous when agents are given access to production repositories or deployment infrastructure.
The Bigger Lesson: Faster Coding Must Not Mean Faster Vulnerabilities
The most uncomfortable lesson from this experiment is also the most important one.
AI coding agents can dramatically accelerate software development, but acceleration does not automatically create better engineering.
If an agent understands how to build a feature but fails to understand who should be allowed to use that feature, the resulting application can be fast, polished, and fundamentally unsafe.
The future of AI-assisted software development will therefore depend on verification.
Developers need to challenge generated code.
Security teams need to attack it.
Automated systems need to search for weaknesses.
And AI agents themselves need to be evaluated against adversarial scenarios rather than only successful feature completion.
The industry is entering an era where software can be generated faster than humans can manually review it.
That makes secure automation more important than ever.
The goal should not simply be to build software faster.
It should be to build software faster without giving attackers a faster path in.
▶️ Related Video (80% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: x.com
Extra Source Hub (Possible Sources for article):
https://www.twitter.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
