Notifications
Clear all
Topic starter
15/08/2026 6:11 pm
TL;DR: AI-generated code is making it faster to ship applications, but the same speed is increasing the chance that basic security controls are skipped, creating exposed data, weak authentication, and vulnerable dependencies, according to Fingerprint. The practical problem is not coding speed itself, but the absence of review gates, secure defaults, and verification before deployment.
NHIMG editorial — based on content published by Fingerprint: The rise of vibe coding in 2025
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do vibe-coded apps create identity and access risk?
A: They often introduce user sessions, API keys, service credentials, and third-party integrations without a clear ownership model.
Q: What do teams get wrong about secrets in AI-built apps?
A: They treat secrets as configuration details instead of privileged identities with lifecycles.
Practitioner guidance
- Gate AI-generated code before deployment Require a human review step for every AI-generated feature that touches authentication, authorisation, file upload, database access, or secret handling.
- Treat leaked secrets as identity incidents Inventory API keys, tokens, certificates, and environment variables created or referenced by vibe-coded apps.
- Verify route-level authorisation on every sensitive path Test admin actions, API calls, and object-level access after login to confirm the application checks permissions on every request.
What's in the full article
Fingerprint's full article covers the operational detail this post intentionally leaves for the source:
- A practical checklist for developers who want to verify AI-generated code before deployment without rewriting the entire application.
- Specific guidance on validating inputs, handling uploads, and escaping output in code paths that AI tools often generate incorrectly.
- Examples of cookie and session settings that reduce hijacking risk in browser-based applications.
- Implementation details for rate limiting, dependency updates, and secrets handling that go beyond a governance summary.
👉 Read Fingerprint's checklist for securing vibe-coded applications →
Vibe coding security gaps: what should builders check before deploy?
Explore further
15/08/2026 6:18 pm
AI-assisted development has created a governance gap, not just a coding gap. The issue is that applications can now reach deployable shape before anyone with security responsibility has reviewed the trust model, session handling, or secret storage. That compresses the window between creation and exposure, which is especially dangerous in environments where non-specialists are assembling production-like systems. Practitioners should treat AI-assisted build pipelines as governance surfaces, not just developer productivity tools.
A question worth separating out:
Q: How do you know if a vibe-coded app is actually secure enough to deploy?
A: It is only secure enough when security controls are demonstrable, not implied. You should be able to show that inputs are validated, sensitive routes are authorised, cookies are protected, secrets are out of code, dependencies are current, and abuse controls such as rate limiting are active.
👉 Read our full editorial: Vibe coding security gaps are turning fast builds into attack surface
