Featured Issues

Why AI-Generated Applications Become More Vulnerable as They Grow#19: The Security Blind Spots of Vibe CodingWhy AI-Generated Applications Become More Vulnerable as They GrowShort on time?Here are our key takeaways from Dr. Paxton-Fear’s presentation, so you can glean the important parts now and catch up with the rest later on.Save your (virtual) seatKey TakeawaysThe largest security challenge in vibe coding is often a lack of visibility rather than a lack of functionality.Developers and vibe coders approach software from fundamentally different perspectives, leading to distinct security risks.Modern applications rely on extensive “invisible glue” including APIs, libraries, cloud services, and integrations.Many vulnerabilities originate from AI-generated implementation decisions rather than deliberate user actions.Security debt accumulates rapidly as applications become more complex.Large language models struggle to maintain context across large, evolving projects.The “set it and forget it” mindset may be one of the most significant risks associated with AI-generated software.Organisations should prioritise visibility, monitoring, and governance rather than attempting to ban AI-assisted development.In discussions about AI-generated software, security conversations often begin with the technology itself. Commentators debate whether large language models write secure code, whether AI can replace developers, or whether generative AI introduces entirely new categories of vulnerability. While these questions are important, they can obscure a more fundamental issue.The greatest security challenge associated with vibe coding is not necessarily the AI. It is the visibility gap between the person building an application and the technology powering it.During the “Hack Before You Launch” workshop, cybersecurity researcher Dr. Katie Paxton-Fear argued that many of the security problems appearing in AI-generated applications stem from a simple reality: the people creating these applications often view software differently from traditional developers. Their objective is not to engineer maintainable systems or architect resilient infrastructure. Their objective is to solve a problem as quickly as possible.That distinction may seem subtle, but it has profound implications for security.Developers and Vibe Coders Are Solving Different ProblemsTraditional software developers are typically trained to think beyond immediate functionality. They consider how code will be maintained, how systems interact with one another, how future features might affect existing functionality, and how security controls should be incorporated into the design process.Vibe coders approach software from a different perspective. They begin with a business need, a personal challenge, or an idea they wish to test. AI tools allow them to focus on outcomes rather than implementation. The application becomes a means to an end rather than a product requiring long-term stewardship.Dr. Paxton-Fear illustrated this distinction by contrasting developers and vibe coders directly: developers are focused on building software, while vibe coders are focused on solving problems; developers think about functions, architecture, and maintainability, while vibe coders think about features and outcomes.Neither approach is inherently wrong. In fact, the accessibility of AI-assisted development is one of its greatest strengths. The problem emerges when applications created with a problem-solving mindset are deployed into environments that require an engineering mindset. Of course, security is one of those environments.The Invisible Glue Beneath Modern ApplicationsModern software is rarely built from scratch. Even relatively simple applications depend on an extensive ecosystem of supporting technologies. Authentication systems validate users. Cloud platforms host services. Third-party APIs provide data and functionality. Open-source libraries accelerate development. Databases store information. Monitoring tools collect operational metrics.Most users never see these components. Increasingly, many builders do not see them either. This is what Dr. Paxton-Fear described as the “invisible glue” holding modern applications together. While AI tools can assemble these components automatically, they do not necessarily help users understand what has been assembled.A prompt requesting a customer portal may generate authentication mechanisms, database integrations, user management workflows, session handling logic, and third-party dependencies. The resulting application may appear deceptively simple from the user’s perspective, but the underlying architecture can be remarkably complex.This complexity creates opportunities for security weaknesses to emerge in places that builders never knew existed. A vulnerability hidden inside a dependency, a misconfigured permission setting, or an exposed API endpoint may have little visible impact on functionality. The application continues to work exactly as intended. The risk only becomes apparent when an attacker begins exploring those unseen components.Why AI Introduces Security DebtOne of the more surprising observations from the workshop was that the vibe coder does not directly introduce many common vulnerabilities. Instead, they emerge from decisions made during the AI generation process itself.Dr. Paxton-Fear grouped common issues into two broad categories. Some vulnerabilities, such as business logic flaws and authorisation issues, are often linked to the requirements provided by users. Others are more likely to be introduced by the AI system, including vulnerable dependencies, exposed secrets, insufficient rate limiting, debugging information leakage, and various injection-related weaknesses.This distinction matters because it challenges a common assumption about AI-generated software. Many people assume that if they did not explicitly create a vulnerability, the vulnerability does not exist. In reality, software development has always involved inherited risk. Developers regularly introduce third-party code into projects through frameworks, libraries, plugins, and integrations. AI accelerates this process by making those implementation choices automatically.The result is a form of security debt that can accumulate rapidly. Every new feature potentially introduces additional dependencies, additional interactions, and additional attack surface. As applications grow, understanding those relationships becomes increasingly difficult.Complexity Is the Enemy of ContextLarge language models perform best when they have access to sufficient context. They can reason effectively about a single feature, a specific bug, or a contained workflow. Problems begin to emerge when projects grow beyond the model’s ability to maintain a coherent understanding of the entire application.This challenge is not unique to AI. Human developers struggle with complexity as well. The difference is that experienced engineers develop mental models that help them understand how systems fit together. They recognise architectural patterns, identify unusual behaviours, and anticipate the consequences of changes.AI models lack this persistent understanding. Their awareness is constrained by the context available during a given interaction. As Dr. Paxton-Fear noted during the workshop, increasing complexity can cause AI systems to rewrite existing functionality, introduce inconsistencies, or generate excessive documentation in an attempt to compensate for limited context. Security often suffers as a consequence.The issue is not that AI becomes careless (if, at that, this sentence actually makes any sense at all). The issue is that security requires a comprehensive understanding of relationships across an entire application, and that understanding becomes increasingly difficult as projects evolve.The “Set It and Forget It” ProblemPerhaps the most important security blind spot discussed during the workshop has little to do with coding at all.Traditional software development assumes that applications require ongoing maintenance. Dependencies must be updated. Vulnerabilities must be monitored. Security controls must be reviewed. New threats must be assessed as technologies change.Many vibe coders approach software differently. Once the application solves the original problem, attention moves elsewhere. The software becomes a completed task rather than a living system.This mindset is understandable. Someone who builds an internal workflow automation tool may never intend to become a software maintainer. Their goal was simply to solve a business challenge. Unfortunately, attackers do not care whether an application was intended to be temporary.A vulnerable application remains vulnerable whether it was built by a professional engineering team or by an employee experimenting with AI prompts during a lunch break. This creates one of the most significant risks associated with AI-generated software. The danger is not necessarily that applications are deployed insecurely. The danger is that they remain insecure long after deployment because nobody recognises the need for ongoing maintenance.Visibility Is Becoming a Security RequirementThe solution proposed throughout the workshop was not to discourage vibe coding. Dr. Paxton-Fear repeatedly argued that banning AI-assisted development is unlikely to succeed. The benefits are too significant, and adoption is already too widespread.Instead, organisations should focus on improving visibility. Users need better insight into the components that make up their applications. They need tools that expose dependencies, integrations, permissions, and data flows. They need security information presented in a format that non-specialists can understand.Most importantly, they need systems that make security concerns visible before vulnerabilities become incidents. The future of secure vibe coding may depend less on teaching every user to become a software engineer and more on creating tools that expose the hidden complexity beneath modern applications.Heading in the Right Direction?The security risks associated with vibe coding are often described as technical problems. In reality, many of them are visibility problems. AI has dramatically expanded the number of people capable of building software. What it has not done is eliminate the complexity of the systems being built. Modern applications still rely on countless interconnected components, each carrying its own risks and dependencies.As applications grow, those dependencies become increasingly difficult to understand. Security weaknesses emerge not because builders are careless, but because the systems beneath the surface become harder to see.The challenge facing organisations is therefore not simply to secure AI-generated code. It is to make the invisible visible. Without that visibility, vulnerabilities remain hidden until attackers find them first.Further ReadingOWASP Top 10 Web Application Security RisksOWASP Top 10 for LLM Applications 2025OWASP GenAI Security ProjectOpenSSF Secure Supply Chain ResourcesNIST Secure Software Development Framework (SSDF)UK National Cyber Security Centre Secure Development Guidance*{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;display:none;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}}

Three hands-on sessions for platform, network, and Linux teams trying to make agentic workflows usefBefore You Give AI More Access, Build the BoundariesThree hands-on sessions for platform, network, and Linux teams trying to make agentic workflows useful without making them reckless.Hi!In this issue,I want to point you toward three sessions worth your time if you work near platforms, networks, Linux, automation, or incident response.They are connected by one theme:AI in operations is only useful when the boundaries are engineered first.That has been the thread running through recentCloudProissues, even when the topics looked unrelated.In the last few issues,we’vekept coming back to the same engineering instinct: slow down, separate the moving parts, and understand what should happen before you let anything change.Whether we were talking about broken containers, MCP design, or admin rights, the point was never just the tool. It was the discipline around the tool.AI does not remove that habit. It raises the cost of skipping it. The teams that get value from agents will not be the ones thatconnectthe most tools. They will be the ones that know what the agent can see, what it can change, when it must stop, and how a human verifies the next step.Taken together, these sessions give you a practical way to think about AI where it actually shows up in your work: inside the platform, inside network operations, and at the Linux command line.FINAL CALL - Building AI-Native Platform Engineering SystemsLast 24 hours!Start at the platform layer.If you run an internal platform, you've probably felt the pressure: AI in the developer portal, agents that explain failures, golden paths that do more than point to templates.The challenge is that platform agents need context, telemetry, policy, safe actions, approvals, and clear trust boundaries. AI can't just be bolted on.That's why Building AI-Native Platform Engineering Systems stands out. It covers Backstage, OpenChoreo, CI/CD, golden paths, control planes, policy-as-code, observability, guardrails, and platform intelligence - with AI treated as part of the architecture, not an afterthought.A solid read for platform engineers, DevOps engineers, SREs, architects, and engineering leaders asking:"Can we make our platform AI-native?"The answer may be yes, but only with the right control surfaces.Use code FINAL50 to get 50% offBOOK YOUR SEAT NOWThe session is on June 11, i.e., 24 hours from now, and you can use the discount code FINAL50 when booking.Engineering Agentic Network OperationsOnce platform boundaries are in place, the next challenge is network operations, where many AI demos fall apart.It's easy to build an agent that summarizes data or suggests a config. It's much harder to build one that works within real constraints, recovers from failures, and knows when to hand control back to a human.That's the focus of Engineering Agentic Network Operations.The workshop covers MCP, OpenClaw, NetClaw, FastMCP, Containerlab, Arista cEOS, and more. But the real value is learning how to design agentic workflows with clear scope, guardrails, recovery paths, and human oversight.For network automation, SRE, platform, and infrastructure teams, those questions matter long before an agent is trusted with production operations.Use code SPECIAL50 to get 50% offBOOK YOUR SEAT NOWAgentic Linux – From Commands to AI AgentsThen there's the base layer.No matter how advanced the platform, a lot of real work still ends up in Linux - reading logs, checking services, fixing permissions, troubleshooting errors, and deciding whether a generated command is actually safe to run.That's why Agentic Linux – From Commands to AI Agents is a useful third piece.The workshop covers ChatGPT CLI, Shell Genie, Aider, Goose CLI, Bash scripting, troubleshooting, automation, and system administration tasks. What I like is that it treats AI as an assistant, not a replacement for judgment.Generating a command is easy. Knowing whether it's safe, spotting destructive actions before they run, and keeping humans in the approval loop is the hard part.For Linux administrators, DevOps engineers, SREs, and IT professionals, it's a practical look at using AI at the command line without turning the shell into a roulette wheel.Use code EARLY40 to get 40% offBOOK YOUR SEAT NOWAfewbooksto keep beside these sessionsOne more thing worth mentioning: these sessions pair well with a few books from our list if you want to go deeper after the labs.For the first workshop,I’dstart withPlatform Engineering for Architects, which is especially relevant because attendees ofBuilding AI-Native Platform Engineering Systemsget the book for free.Mastering Enterprise Platform Engineeringis the natural follow-up ifyou’rethinking about platform engineering, delivery workflows, and generative AI at enterprise scale. For the network operations side,AI Networking Cookbook fits neatly with the agentic network operations session. And if the Linux workshop is closer to your day-to-day work,The Ultimate AI Guide for Linux Engineers is a good companions for thinking about what AI-generated commands are actually touching underneath.The Ultimate AI Guide for Linux EngineersBUY NOW ON AMAZONMastering Enterprise Platform EngineeringBUY NOW ON AMAZONAI Networking CookbookBUY NOW ON AMAZONPlatform Engineering for ArchitectsBUY NOW ON AMAZONThe useful question is not whether AI can be added to these workflows. It can, and most teams are already experimenting with it somewhere. The harder question is whether the workflow still makes sense once AI is inside it. Can the team understand what happened? Can they review the output? Can they stop a bad change before it lands? Can they trust the system more after adding AI, not less?That is the thread running through all three sessions. They are not about chasing the newest tool. They are about taking the work many of us already do across platforms, networks, and Linux environments, and asking whathas tochange when AI becomes part of that work.That is what makes these sessions useful. They are not abstract AI talks. They sit close to the places many of usactually work: the platform layer, network operations, and the Linux command line.I’llbe in attendance as well, because these are exactly the conversationsCloudProneeds to keep having: what is useful, what is unsafe, what is ready, and what still needs a human in the loop.This istime-sensitive. The first session is on June 11, and the other two follow later this month. If one of these areas is on your roadmap, I would not skip it.Cheers,Apramit BhattacharyaEditor-in-ChiefP.S. If you attend any of these sessions, I’d be interested to hear what actually helped: the demo, the lab, the framework, or even a question someone asked. Reply with one thing you took away from it.*{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;display:none;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}.social_block .social-table{display:inline-block!important}.row .side{display:none}}