When Software Is Built Faster Than It Can Be Understood
Software development is undergoing one of its biggest transformations.
Developers, founders and even non-technical professionals can now describe an application in plain language and ask an AI coding assistant to build it. Within minutes, AI can generate interfaces, APIs, database integrations, authentication workflows and deployment configurations.
This approach is commonly called “vibe coding.”
The term describes a development style in which people guide AI through natural-language instructions, accept generated code and continue iterating until the application appears to work—often without fully reviewing or understanding the underlying implementation.
The productivity benefits are undeniable.
But there is a critical difference between software that works and software that is secure.
An application can function perfectly during a demonstration while containing broken access controls, exposed secrets, vulnerable dependencies, insecure APIs or dangerous cloud configurations.
Vibe coding is not automatically insecure. The real danger begins when organisations treat AI-generated functionality as production-ready software without applying the same security engineering, testing and governance required for human-written code.
The result may be a growing layer of shadow software: applications created faster than security teams can discover, assess or control them.
What Is Vibe Coding?
Vibe coding is an AI-first method of software development.
Instead of manually writing every component, a person provides instructions such as:
“Build a customer portal with login, payment integration, an admin dashboard and a PostgreSQL database.”
The AI coding tool may then:
- Create the frontend
- Generate backend APIs
- Design database tables
- Implement authentication
- Add third-party packages
- Configure environment variables
- Generate deployment files
- Diagnose errors
- Modify code after feedback
The user primarily focuses on the desired outcome rather than the exact implementation.
This can be valuable for prototypes, internal tools and rapid experimentation. However, it becomes risky when the user assumes that successfully generated code is also secure, maintainable and production-ready.
AI optimises for completing the requested task. It does not automatically understand an organisation’s threat model, security architecture, regulatory responsibilities or risk appetite.
Why Vibe Coding Is Becoming a Security Concern
The security issue is not simply that AI might generate a vulnerable line of code.
The broader problem is that AI can now generate entire systems.
A single prompt may introduce:
- Application code
- Infrastructure configuration
- Authentication logic
- Open-source dependencies
- API connections
- Cloud permissions
- Database queries
- Secrets-handling patterns
- Deployment pipelines
If the person directing the AI cannot evaluate these components, insecure decisions may pass directly into production.
OWASP has identified “Inappropriate Trust in AI-Generated Code,” commonly associated with vibe coding, as an emerging application-security concern. GitHub has also introduced automatic security validation and dedicated security-review capabilities for code created by coding agents—evidence that AI-generated code requires deliberate security verification, not automatic trust. OWASPGitHub
Ten Security Risks Hidden Inside AI-Generated Applications
1. Broken Access Control
AI may successfully create separate user and administrator interfaces without properly enforcing the distinction on the server.
For example, the application may hide the admin button from ordinary users but fail to verify the user’s role when the underlying API is called directly.
An attacker could bypass the interface and access administrative functions by sending a modified request.
Security cannot depend on what the interface displays. Authorisation must be validated on every sensitive server-side operation.
2. Hardcoded Secrets
AI-generated code may include placeholders or examples for:
- API keys
- Database credentials
- Cloud access tokens
- Encryption keys
- JWT secrets
- Payment-gateway credentials
During rapid testing, users may replace the example values with real credentials and commit them to a repository.
Once a secret enters version control, deleting it from the latest file is not sufficient. The value may remain available in commit history, cached build logs or copied repositories.
All exposed credentials must be revoked and rotated.
3. Insecure Authentication
Authentication is more complicated than displaying a login form.
A secure implementation must consider:
- Password hashing
- Brute-force protection
- Session expiration
- Cookie security
- Token storage
- Password recovery
- Multifactor authentication
- Account enumeration
- Session invalidation
- CSRF protection
AI-generated authentication may appear functional while missing one or more of these controls.
For production applications, authentication should preferably rely on established, well-maintained identity platforms or frameworks rather than custom logic generated from scratch.
4. Vulnerable or Invented Dependencies
AI coding systems often recommend packages to solve specific problems.
The recommended dependency may be:
- Outdated
- Abandoned
- Vulnerable
- Malicious
- Incorrectly named
- Unnecessary
- Incompatible with the project
In some cases, an AI system may generate the name of a package that does not exist. Attackers can exploit this behaviour by publishing a malicious package under the invented name—a supply-chain attack sometimes referred to as package hallucination or slopsquatting.
Every dependency should be verified through an official package registry and assessed for ownership, maintenance history, vulnerabilities and necessity.
5. Injection Vulnerabilities
AI-generated applications may construct database queries, operating-system commands or templates using untrusted input.
This can introduce:
- SQL injection
- Command injection
- Cross-site scripting
- Server-side template injection
- LDAP injection
- NoSQL injection
- Path traversal
The application may work correctly with expected input but behave dangerously when it receives malicious input.
Secure development requires parameterised queries, contextual output encoding, input validation and restricted execution—not merely testing whether the intended use case works.
6. Excessive Cloud Permissions
A generated application may request broad permissions because they make integration easier.
Instead of granting access to one storage location, the code may request access to an entire account. Instead of allowing a single action, it may use an administrative role.
This produces a familiar problem: the application works, but its blast radius is unnecessarily large.
Cloud identities, service accounts and API tokens must follow least privilege. Permissions should be reviewed separately from application functionality.
7. Publicly Exposed Databases and Storage
AI-generated deployment instructions may prioritise quick connectivity.
This can result in:
- Public database endpoints
- Unrestricted storage buckets
- Development interfaces exposed to the internet
- Open administrative dashboards
- Test APIs deployed without authentication
- Overly permissive firewall rules
A configuration that makes deployment easy can also make unauthorised access easy.
Infrastructure-as-code and deployment configurations require the same security review as application code.
8. Missing Security Logging
Generated applications often include basic error logging but omit audit events required for security investigations.
A production application should record relevant events such as:
- Successful and failed logins
- Password-reset requests
- Privilege changes
- Administrative actions
- Sensitive record access
- Configuration changes
- Unusual API activity
- Data exports
Logs should provide enough context for investigation without recording passwords, tokens or unnecessary personal data.
9. Unsafe Error Handling
During development, detailed error messages make troubleshooting easier.
In production, the same errors may expose:
- Source-code paths
- Database information
- Internal hostnames
- Framework versions
- Stack traces
- API responses
- Sensitive business logic
Users should receive safe, generic messages while detailed diagnostic information is retained in appropriately protected internal logs.
10. Code Nobody Can Maintain
One of the most underestimated risks is loss of understanding.
If an organisation deploys code that nobody on the team can adequately explain, it becomes difficult to:
- Identify vulnerabilities
- Review future modifications
- Respond to incidents
- Upgrade dependencies
- Correct design weaknesses
- Prove regulatory compliance
- Recover when the original tool or developer is unavailable
Code ownership requires more than possession of the repository. Someone must understand the architecture, dependencies, data flows and security assumptions.
“The Application Works” Is Not a Security Test
Functional testing asks whether the system performs its expected task.
Security testing asks what happens when someone intentionally misuses it.
A functional test might confirm that a user can download their invoice.
A security test asks:
- Can the user download another customer’s invoice?
- Can the invoice identifier be manipulated?
- Does the API verify ownership?
- Is the file accessible without authentication?
- Is the download recorded?
- Can one user automate thousands of requests?
AI coding tools are often evaluated through functional success: the page loads, the button works and the data appears.
Attackers examine the assumptions behind that functionality.
Why Non-Technical Builders Face Greater Risk
Vibe coding has made software creation accessible to founders, marketers, consultants, students and business teams.
This accessibility is valuable, but it creates an expertise gap.
A non-technical builder may be unable to recognise:
- An unparameterised database query
- An insecure direct object reference
- A weak cryptographic implementation
- A dangerous CORS policy
- A leaked credential
- An overprivileged service account
- An unsupported dependency
- An authentication-bypass condition
The application may look professional and still contain serious architectural weaknesses.
This does not mean non-developers should be prevented from building software. It means the level of independent validation should increase when the builder cannot review the generated implementation.
Is AI-Generated Code Less Secure Than Human-Written Code?
The wrong comparison is “AI code versus human code.”
Human developers also make security mistakes.
The real comparison is:
- Reviewed versus unreviewed code
- Tested versus untested code
- Governed versus unmanaged development
- Traceable versus unknown dependencies
- Understood versus misunderstood architecture
AI can produce secure patterns, explain vulnerabilities and help remediate findings. It can also reproduce insecure examples, misunderstand context and generate convincing but unsafe solutions.
The security outcome depends on how the technology is integrated into the software-development lifecycle.
A Secure Vibe-Coding Workflow
Organisations do not need to ban AI-assisted development. They need to place security controls around it.
Step 1: Define the Application’s Risk
Before generating code, identify:
- What data the application will process
- Who will use it
- Whether it will be internet-facing
- Which business processes it affects
- Whether it handles financial or personal information
- Which regulations may apply
- What damage could result from compromise
A prototype using fictional data does not require the same controls as an application processing customer identities or payments.
Step 2: Establish Approved Tools
Organisations should define which AI coding platforms employees may use and what information may be shared with them.
Policies should address:
- Source-code confidentiality
- Personal and customer data
- Intellectual property
- Prompt retention
- Model training
- Third-party integrations
- Repository access
- Agent permissions
Otherwise, employees may paste sensitive code or business information into unapproved services.
Step 3: Generate a Threat Model
Ask what could go wrong before asking the AI to write the system.
Identify:
- Trust boundaries
- Entry points
- Sensitive assets
- User roles
- External services
- Privileged operations
- Abuse cases
- Data flows
AI can assist with threat modelling, but an experienced person should validate the result.
Step 4: Apply Secure Coding Requirements
Security requirements should be included from the beginning.
Examples include:
- Server-side authorisation
- Parameterised database queries
- Secure session management
- Centralised secret storage
- Input validation
- Contextual output encoding
- Secure error handling
- Dependency pinning
- Audit logging
- Rate limiting
A prompt asking for “secure code” is too vague. Security expectations should be explicit and testable.
Step 5: Review Every Dependency
Generate and maintain a software bill of materials where appropriate.
For every external component, verify:
- Official source
- Current version
- Known vulnerabilities
- Licence
- Maintenance activity
- Transitive dependencies
- Package integrity
Do not install a package solely because an AI tool recommended it.
Step 6: Scan the Code
Security testing should combine multiple techniques:
- Static application-security testing
- Software-composition analysis
- Secret scanning
- Infrastructure-as-code scanning
- Container scanning
- Dynamic application-security testing
- API security testing
- Manual review
No individual tool can validate the entire application.
Step 7: Test Authorisation Manually
Broken access control is often context-dependent and may not be detected reliably through automated scanning alone.
Test the application using:
- Different user roles
- Modified object identifiers
- Direct API calls
- Expired tokens
- Missing authentication
- Horizontal and vertical privilege-escalation scenarios
Always validate that security controls are enforced by the trusted backend.
Step 8: Require Human Review
AI-generated changes should enter production through a controlled review process.
Reviewers should understand:
- What the code is intended to do
- What the AI changed
- Which dependencies were introduced
- Which permissions are required
- Which tests were performed
- What residual risks remain
GitHub’s security validation for coding agents uses code analysis, dependency checks and secret scanning before generated changes are finalised. This reflects an essential principle: AI-generated code should receive automated validation and human review before release. GitHub
Step 9: Monitor After Deployment
Pre-release testing cannot identify every vulnerability.
Production monitoring should detect:
- Authentication anomalies
- Unusual data access
- Privilege misuse
- Excessive API requests
- Unexpected outbound connections
- Configuration changes
- New administrative accounts
- Abnormal error patterns
Secure development continues after deployment.
What Security Teams Should Ask
Before approving an AI-generated application, security teams should ask:
- Who owns and understands the code?
- Which AI tools contributed to it?
- What data was shared with those tools?
- What sensitive information does the application process?
- Which identities and permissions does it use?
- How is authentication implemented?
- How is server-side authorisation enforced?
- Which third-party packages were introduced?
- Have dependencies and licences been verified?
- Have secrets been scanned and rotated where necessary?
- Were threat modelling and security testing performed?
- Is activity logged sufficiently for investigation?
- Can the application be isolated or disabled quickly?
- Who will maintain it after deployment?
- What evidence supports the decision that it is production-ready?
If these questions cannot be answered, the organisation does not have adequate control over the application.
How AI Can Improve Software Security
AI should not be viewed only as a source of risk.
Used correctly, it can support:
- Secure-code explanations
- Test-case generation
- Threat-model development
- Vulnerability remediation
- Dependency updates
- Code-review assistance
- Security-documentation creation
- Detection of unusual patterns
GitHub introduced a dedicated AI-assisted security-review capability that checks for issues including injection, broken access control, path traversal, exposed secrets, weak cryptography and vulnerable dependencies. It is intended to complement established scanning and review controls rather than replace them. GitHub
The goal should not be to remove human responsibility. It should be to use AI to make disciplined security practices easier and faster.
What Vibe Coding Changes for Cybersecurity Careers
Vibe coding creates new responsibilities across cybersecurity.
Application-security professionals must learn how to assess AI-generated architectures and rapidly changing codebases.
DevSecOps teams must embed automated controls into development pipelines so that increased velocity does not bypass security.
Cloud-security professionals must review the identities, infrastructure and permissions created by AI tools.
Penetration testers must evaluate applications built by users who may not understand their own implementation.
GRC teams must address code provenance, ownership, approval and evidence of security validation.
Security professionals who can combine AI-assisted development with threat modelling, secure architecture and practical testing will become increasingly valuable.
Final Thoughts
Vibe coding is not the end of secure software development.
It is a test of whether organisations can preserve security discipline while development becomes dramatically faster.
The greatest risk is not that AI writes code.
The greatest risk is that organisations deploy code nobody has reviewed, tested, understood or accepted responsibility for.
AI can reduce the time required to turn an idea into an application. It cannot remove the need for secure design, independent validation and accountable ownership.
The future will not belong to teams that simply generate software fastest.It will belong to teams that can generate, understand, secure and govern it at the same speed.
It will belong to teams that can generate, understand, secure and govern it at the same speed.
