In recent months the adoption of artificial intelligence in software development has stopped being an experiment and has become daily operational practice.
IT Teams, developers, system engineers and even non-technical functions are starting to build internal tools, dashboards, automations and real applications starting with AI-generated prompts and code. The advantage is obvious: reduced development times, lower costs, greater team autonomy.
But as often happens, every acceleration also introduces a new type of risk.
The less visible side of AI in development
When talking about AI applied to coding, attention almost always focuses on productivity. Much less we talk about the quality of the generated code, and especially its safety.
Yet the data begin to be quite clear.
According to Sherlock Forensics report 2026, the 92% of the codebase generated with AI contains at least one critical vulnerability
Source: https://www.sherlockforensics.com/pages/ai-code-security-report-2026.html
A Veracode analysis of 2025 shows that about 45% of the generated code has significant security issues
Source: https://technave.com/gadget/This-study-reveals-that-almost-half-of-AI-generated-code-has-security-issues-43585.html
And perhaps the most interesting data is another: only a small percentage of companies integrates structured security controls on this type of code.
This creates a dangerous misalignment:
development speed grows exponentially, while controls remain linear — or absent.
Because the code generated by AI is often vulnerable
The problem is not so much that the AI "wrong", but working with a different objective than that of safety.
Generative models are optimized to produce working code and consistent with the required context. They are not, by their nature, designed to ensure that that code is robust compared to real threats.
In addition:
- learn from large amounts of public code, which also includes insecure patterns
- tend to replicate common solutions, including known vulnerabilities (CWE)
- have no awareness of the overall architectural context in which the code will be inserted
The result is a code that "works", but which has often not been thought to resist an attack.
The false sense of security of internal applications
Another critical aspect concerns the use of these applications.
Many of the tools created with AI are internal:
- operational portals
- automation tools
- API between services
- infrastructure management interfaces
And this is where one of the most dangerous biases emerges:
"It's internal, so it's safe. "
Actually, from the point of view of an attacker, internal applications are extremely interesting.
Once you get a first access (phishing, compromised credentials, external exploit), the real goal becomes the lateral movement.
And internal applications often offer:
- less stringent security controls
- weak or implied authentication
- direct access to critical data and systems
In other words, they become the ideal point for escalation and pivoting.
How these vulnerabilities are exploited
An application developed quickly with AI, without a validation process, can introduce different risk scenarios.
It can expose unprotected endpoints, becoming an initial entry point.
It can integrate incomplete authorization logic, allowing undue access.
It can interact with databases or internal services without proper privilege segregation.
When an attacker detects one of these weaknesses, the application stops being a simple internal tool and becomes a multiplier of the impact of the attack.
It should also be considered an emerging element: the use of AI also in the offensive.
There are already models that can analyze code and identify vulnerabilities automatically, drastically reducing the time needed to detect weak points.
This completely changes the scale of the problem.
How to use AI correctly (and safe)
Blocking the use of AI is not realistic, nor desirable.
The correct direction is to govern its use.
The first step is to change the way you interact with these tools. It is not enough to ask to generate code: it is necessary to impose explicit constraints.
Require adherence to standards such as OWASP Top 10, claim input validation, correct authentication management and protection against common vulnerabilities must become an integral part of the prompt itself.
But that's not enough.
It is necessary to introduce a security by design approach, where security is not a final control but an architectural requirement. This means designing with logic of least privilege, segmentation and zero trust also for internal applications.
At the operational level, it is essential to integrate automatic controls within the development pipelines: static analysis, dynamic analysis, dependency control and detection of exposed secrets.
And above all, it serves an element that AI cannot replace: human revision.
A code review made with security skills is often what allows you to detect logical vulnerabilities that no automatic tool can intercept.
Finally, before putting into production, a penetration test remains one of the most effective tools to simulate a real attack and validate the resilience of the application.
The role of a security audit
At this point, a key concept emerges:
the code generated by AI cannot be considered reliable by default.
Requires the same level — if not higher — of verification regarding the traditional code.
A structured security audit allows:
- identify real and exploitable vulnerabilities
- analyze application logic and access flows
- verify API exposure
- assess integration with other systems
It’s not just about finding bugs, but understanding how an attacker could really move within the environment.
Where does Dognet Technologies come in?
In this scenario, the value is not only in the tools, but in the approach.
Dognet Technologies works with an offensive perspective: analyzing applications not for how they should work, but how they can be compromised.
This results in:
- security audit on applications developed with AI
- revision of the code focused on concrete vulnerabilities
- penetration test on internal and external applications
- analysis of attack surfaces generated by system integration
The goal is not formal compliance, but real risk reduction.
Conclusion
Artificial intelligence is redefining software development.
This is a fact.
But each new capacity introduces a new responsibility.
Companies that will benefit will not be the ones that develop faster, but the ones that will keep control while accelerating.
Because if it is true that today anyone can create an application in a few hours, it is equally true that an attacker can analyze it in a few minutes.
And at that point, the difference does one thing:
how serious security was taken.
