My Artificial Intelligence (AI) journey started with a colleague, an exceptionally talented consultant with a passion for all things AI. As this colleague’s line manager, I needed to keep up to support both him and our capabilities in this entirely new discipline – a completely new way of thinking and testing.
This coincided with an industry-wide race to implement AI at breakneck speed. Not just LRQA’s own customers, but even giants like OpenAI had prompt injection and jailbreaking vulnerabilities – remember Dan anyone? We still see custom products built on older, locally hosted Llama models that are susceptible to attacks and data leakage.
Then came my first “app”. I'll caveat this - I'm not a web developer. Infrastructure testing is my thing, but I was tasked with delivering a conference talk on Continuous Assurance – demonstrating the shift from traditional point-in-time penetration testing to always-on Continuous Assurance and Attack Surface Management (ASM). For this, I needed an impactful demo showing what someone with basic knowledge could achieve with these new tools.
What is Vibe Coding?
When I started playing with these technologies, the term “vibe coding” hadn't been coined yet, but in simple terms, it refers to allowing an LLM such as ChatGPT or Anthropic's Claude to do the heavy lifting for you - pretty much all through the chat UI. Instead of wrestling with documentation or getting stuck on syntax errors, you describe what you want in plain English, paste error messages when things break, and iterate through conversation. The AI writes the code, you test it, and when you need changes or hit problems, you just explain what's wrong or what you want different. Many AI tools also now have this built into your IDE – making the process much smoother. It's development through natural language rather than traditional coding, and as I've discovered, there is definitely an art to crafting the right prompts and maintaining context across complex projects.
The first tool, and the one used for the conference, was a custom framework that enumerated a customer's public-facing infrastructure. A smart and interactive version of ASM - you could pass an IP, a domain name or a URL to it, and it would map out as much information as it could relating to the owning organisation. This included screenshotting all the web servers we could find, discovering which technology they were built on and whether it contained any known vulnerabilities. Then we took it a little further - I made it modular so we could add new attacks at will. Now we're turning it into a scanning tool, mapping out endpoints and testing XSS and SQL Injection payloads. After that we want to run some OSINT - let's try and find S3 buckets or Git repositories, map out all of the users we can find, including what they look like to support any onsite social engineering engagements. Now let's add the ability to pull data from public data breaches. In a few hours we have an attack surface, users, faces, and potential credentials to try. The last addition was an AI chat and analysis bot so users could query the results and get advice on the risk and how to fix the issues. The only rule I had was that I wouldn't touch the code base - it could only be copy and paste. The results were glorious and sparked a new era of what was possible.
What can go wrong?
Now, vibe coding is awesome from a creativity perspective - I couldn't have feasibly built this tooling without it - but before we go any further let's be honest about the elephant in the room. The recent Tea app data breach (https://www.bbc.co.uk/news/articles/c7vl57n74pqo) has highlighted a real issue with this approach, and while the company says the vulnerable code was legacy from before vibe coding was even viable (https://simonwillison.net/2025/Jul/26/official-statement-from-tea/), security researchers are pointing to it as a textbook example of what happens when we get a bit too comfortable with shipping whatever the AI spits out.
The problem is simple: developers are essentially typing "make me a dating app" into ChatGPT and shipping whatever comes out - no security review, no understanding of what the code actually does. In Tea's case, allegedly, that meant leaving a Firebase bucket wide open with no authentication - basically a public folder on the internet containing 72,000 user images including government IDs. Years gone by, that would have been caught in any good security review, but when you're moving at AI speed, these fundamental checks can get skipped. While the barrier to entry lowering is brilliant for innovation, it's equally brilliant for bad actors. The art of the possible cuts both ways, and if we're not careful, we could be cleaning up a lot more messes like this one.
With this in mind, what was next in my vibe coding journey?
What Next?
I wanted to build on the lessons learnt from my first vibe coded application. Attacking tools are cool, but there are already numerous frameworks out there with this capability. In my role, the focus is on developing our consultants and supporting their career growth. I wanted to build something we don’t currently have and that would benefit the wider team.
The first proper app I made - and the biggest learning curve - was a gamification platform to internally track achievements, certifications, career progress and support SMART goal setting. penetration testing is like any other role - we're hackers of course, but behind the curtain it's about continuous development, widening delivery capabilities, upskilling, mentorship and soft skill development.
Coming up with SMART goals can sometimes be difficult, but we're fortunate that penetration testing has some prescribed pathways and activities; reputation building, certifications, and skill broadening for example. We also have internal labs for technical upskilling - now we have a platform managing this through flags and leaderboards and allows us to make goal setting simple and consistent and career pathways transparent.
Surprisingly, particularly with the recent Tea breach in mind, this vibe coded application even passed a pentest! Not much scarier than releasing a web app to a team of hackers… but a win.
Wiki Platform
The next and current project is a Wiki platform that I am about to release to the team and am most excited about. Off-the-shelf tools like Confluence are great for storing vast chunks of information, but with numerous contributors and the need for it to wear many hats, they are something I have never liked to navigate and believe they can stifle creativity.
This platform has been built from scratch and the bones of it took about 2 weeks - filling it with content is taking way longer but it's progressing nicely. Some cool features include interactive testing methodologies with all the tools and commands needed to enumerate whichever topic we're working on, and how that maps to our internal vulnerability knowledge base. A security consultant who is technically capable but hasn't tested a specific technology before will have everything they need in terms of foundational knowledge, tools and interactive methodologies that link to real-world vulnerabilities, along with any prerequisite labs, further reading sources and the occasional quiz to validate understanding.
We already had some labs our consultants could practice on, we now have a career development platform, the bit missing was a wiki with practical information to link these things together. Now a consultant who wants to broaden their capabilities and move into a new discipline of testing has all of the knowledge at their fingertips and a place to practice those skills in as close to a real-world scenario as possible.
Real World Applications
Another use case for vibe coding cropped up on my most recent engagement. An environment that was locked down to the point no automated tooling could be used and an enterprise client that had policies and procedures in place preventing the prerequisites for the test from being implemented quickly, at least within the testing window. Years gone by, that would result in an incredibly constrained test with potentially limited results and a less than happy outcome all round.
Fortunately on this occasion, the one thing we could do was get a data dump of the estate. Manually working through this and parsing the data would have taken huge amounts of time to get right - but now:
- A custom Python script to parse the database for every user with admin privileges? Here you go.
- Do those users have non-admin accounts? Yep.
- Are they configured following the principle of least privilege? Nope.
- Service accounts - who has access and are those permissions dangerous?
- The Conditional Access Policies in place - are they actually covering all of these highly privileged accounts or are we finding legacy information that would have led to gaps in the coverage of those policies?
All of a sudden, what once would have been a heavily constrained assessment is now quickly becoming something interesting, and is full of impactful findings. And gives me an idea for the next tool!
Other Use Cases
One other use case arose with the need to retire a reporting tool that had heavy license costs. It was being kept alive for one type of testing in particular and colleagues came up with a new and innovative solution that interacts with existing scan tools, pulls and parses all the data and outputs exactly what we need it to. In fairness, our team probably didn't need the vibe coding side of things to make this work - they're incredible at what they do - but it certainly sped up the process.
The Coup de Grâce
Did I say attacking tools were cool? They are, and there is one I've been working on in the background that has grown into a bit of a behemoth. We are hoping to release this open source to the community soon - watch this space.
This is an AI attacking framework – used for testing the security of LLMs and chatbots – and it truly shows the art of the possible. I wanted to take all of the tools that are out at the moment and build something that's almost completely automated – the only interaction required is that a user captures the HTTP request made to a chatbot and pastes it into a chat window.
This is parsed alongside the response to see how the chatbot works – and then stored as a template for all future attacks. A dropdown menu lets a user pick what kind of attack they would like – zero shot, objective manipulation, jailbreaking etc – and provides the tool an objective. We're testing it on our custom AI CTF which you can play here - https://blorebankai.com. Then the interesting part – the attack consists of a multi-agent process that researches, strategises, attacks and then analyses in cycles, building on its own knowledge and the success of each subsequent cycle and crafting a new set of attacks.
Research - you can provide the backend numerous research papers and text files so it learns how the attack is supposed to work. The agents will do RAG based research and then the embeddings from these are stored until you update the backend, where it will automatically spot the difference and rerun the research process – this design is intended to reduce cost. If the supporting information doesn't change there is no need to rerun the research.
Strategy - The strategy agent takes the research and plots the next cycle of attacks. A user can specify this in the UI (number of cycles and attacks per cycle - again for cost purposes).
Attack - These attacks are then passed to an attack agent that uses an LLM to format them nicely, pick out duplicates and send them over to the target chatbot.
Analysis - The important part – this agent analyses the responses of the chatbot per the objective. It looks for success where the replies from the chatbot deviate from the norm or reveal things it shouldn't - and then pulls at those threads by providing this info to the strategy agent which refines all of the prompts again for the next cycle.
Other cool features include the ability to pause the attack and drive manually - you see something in the chat window that's cool, you can carry on that conversation outside of the attack conversation, and when you carry on with the attack the analysis agent can use this as part of the next cycle.
Also you want to refine it on the fly - you can chat to the agents too and tell them where to focus their efforts.
Finally a Turbo mode - all good tools need a turbo mode. This is basically a multi-threaded parallelisation attack that should pull on as many threads as it can in a smart way and chase them through to exhaustion.
Bit Off More Than I Can Chew?
You bet - there are so many moving parts to this tool that it's being really challenging to fix one thing without breaking another. The breakthrough came with the now integrated LLM CLI tools that allow things like Claude's Anthropic full access to the codebase in all its context.
What does Claude think?
Does it work though?
I'm really excited for this one – and not just because Claude likes to massage an ego… I am just working out the final kinks. We have got to level 5 on LRQA’s Blorebank labs so far with this tool - which is where a human with a bit of research and trial and error can typically get to (Have a go yourselves - https://blorebankai.com/) . Once the final kinks are worked out and we can better align it with some of the regulatory frameworks that exist, we'll be looking to share it with the world so watch this space.
Conclusion
The art of the possible - going back to the conference talk I delivered, the key concept was that the barrier to entry for bad actors is lowering all of the time. OpenAI freely acknowledge that their tooling is being used to create malware (https://cybersecuritynews.com/openai-confirms-chatgpt-malware), and those CVEs that used to be published without public exploits - given the codebase and enough context that will no longer be a thing either (https://www.theregister.com/2025/04/21/ai_models_can_generate_exploit/). In this new world of LLM-driven possibilities - imagination is now king. I couldn't have feasibly built any of this tooling or functionality without the ability to vibe code, not to any good standard within any good timeframe. The wiki was built literally from scratch, no templates, no framework, all custom code. For those naysayers who aren't a fan of change - it's coming.
And a final word of warning - vibe coding is awesome from a creativity perspective - but from a security perspective and having this going live in a production environment - that's a blog post for another day.