Key Points
- LLMs chain attacks autonomously at speeds human-led processes cannot match
- AI coding tools now in hands of users without software engineering backgrounds
- Organisations must provide safe experimentation environments to prevent shadow AI
Artificial intelligence is accelerating familiar cyberattacks rather than creating an entirely new class of threats, forcing enterprises to rethink whether their security operations can respond at the same speed as increasingly automated attacks, a top cybersecurity executive at Thoughtworks said.
Lilly Ryan, Principal Cybersecurity Engineer, Thoughtworks, told TechObserver.in’s Mohd Ujaley in an interview that large language models (LLMs) are amplifying existing security problems by allowing attacks to be chained together and executed autonomously at speeds that many human-led business and security processes are not designed to match.
EVENT
Infosec Reimagined
Infosec Reimagined 2026 is the premier information security summit where top leaders—CISOs, CROs, CIOs, CTOs and risk executives—converge to redefine cyber resilience.
EVENT
Digital Senate
Digital Senate is a premier conference uniting government leaders, technologists and innovators to share ideas, success stories and strategies on digital governance, public sector transformation, cybersecurity and emerging technologies in India.
EVENT
CIO Prism
CIO Prism unites forward-thinking technology leaders to exchange transformative insights, shape digital strategies, and foster innovation, empowering enterprises to excel in an era of rapid technological change.
EVENT
National DefTech Summit
Featuring keynotes, expert panels, live tech demos and strategic networking, the summit will drive actionable insights for defence sector.
EVENT
Future-Ready Defence
A Leadership Dialogue on sovereign, trusted data infrastructure, AI readiness and mission resilience for Defence Forces.
“There is no magic AI malware out there,” Ryan said, arguing that enterprises are largely facing the same security problems, but amplified. She said organisations need greater visibility into their technology environments, stronger safeguards around AI-assisted development and security operations capable of moving closer to the speed of attacks because “you cannot defend what you cannot see”.
Edited excerpts:
There is considerable concern about AI creating new cyber threats. Is AI fundamentally changing the nature of attacks or primarily making existing attacks faster and more scalable?
What AI and large language models have done more recently is speed up the level of attacks. There is no magic AI malware out there. There is a lot of fear-mongering, for sure, but there is no magic AI malware. What is really happening is that we are seeing the same types of attacks, but at much faster speeds. That is honestly a lot of the difficulty people are facing: the same security problems, amplified.
You can amplify the good and you can amplify the bad at the same time. As time goes on, more businesses are realising that while AI speeds up quite a lot of things, some of the things it speeds up are not good things. What we have been seeing is that it is really important to have defences that can react at the same speed as the attacks are happening.
Attacks of many types have always been, in some ways, the background noise of the internet. If you have ever had a web server running with an exposed port to the internet and simply observed what happens, you will see scripts run past occasionally without targeting anybody in particular, just to see what happens.
Advertisement
But this kind of complexity, along with the ability of large language models to chain things together autonomously, means that quite a number of defences are being exploited. The single or very basic brute-force attack that existed in the past is now becoming a multi-step, logically chained process that can run autonomously and very quickly. That also means you need to be prepared to act very quickly.
This can be tricky for a business because we are no longer talking about things that operate at human speed and many business processes still do because humans work for the business. Paying down organisational tech debt, in the sense of completing file clean-ups, permissions clean-ups and all the things you have always meant to get around to, really pays off because it allows you to take more confident action inside your own environment. Knowing what you have means you can defend it because, as an organisation, you cannot defend what you cannot see.
Enterprises are encouraging employees to experiment with AI at the same time as security teams are trying to maintain visibility and control. What new attack surfaces is this creating inside organisations?
There are quite a few. Most of the attack surface being created within businesses is not being created maliciously. What we have seen happening quite a bit is that, while large AI companies have been talking to cybersecurity industry players about the kinds of attacks, threats and capabilities businesses should prepare for, the general advice has been to make sure you understand what is in your environment.
That is happening at the same time as many businesses are encouraging their staff to pick up AI, try things and innovate. It means that AI software development tools, in particular, are now in the hands of people who are not traditionally software developers and who do not always have the professional skill set associated with software development and software engineering as a whole.
Software engineering has never been purely about writing code. Writing code is part of it and it is a part that has become considerably easier with AI-based coding agents. This can be a really good thing if it means that people who did not previously have these skills now have the ability to directly solve problems that have been affecting them. It is very empowering and I have seen people take that on, start using the tools themselves and genuinely learn how to use them when they could not before. It can also be quite a boon to developers who have been professionals for some time.
At the same time, it has become very easy to write a prompt and get a web application deployed on a server somewhere. That application hosts resources, uses computing infrastructure and may sometimes contain data. Some of that data could be sensitive, depending on what the application has been created for. It may not always be very well protected because large language models, out of the box, are usually very good at doing exactly what you ask and trying to be helpful. They are not good at the things security practitioners generally want to think about: what could go wrong and what is the worst-case scenario?
They will give you exactly what you ask for, but most people are not starting out by asking for security because that is not usually the first cab off the rank. That is fine when you are prototyping and experimenting. But if something ends up in a cloud environment or running in a corporate environment and it does not meet those standards, while the person who built it is also not aware of the right questions to ask an AI assistant to make it robust, that expands an organisation’s footprint in a way we have not seen before.
AI-assisted coding means people without traditional software engineering backgrounds can now build applications. Does that shift more cybersecurity responsibility to individual developers and users or should dedicated security teams still provide the primary line of defence?
Security has always been a shared responsibility across the organisation. You will certainly have cybersecurity departments in most large organisations and those people are responsible for making sure we have the policies, practices and safe defaults in place. But it also takes responsibility from every person in the organisation to understand what they are doing, what type of information they are handling and where they are handling it.
Anybody could accidentally send a sensitive email to the wrong email address, and that is not always something a security control can prevent. So it has always been everybody’s responsibility to think about what they are doing, make sure they understand what they intend to do and ask themselves how it could go wrong while they are doing it.
When it comes to technical defences and baseline security, building safe environments for people to experiment within matters. Providing people with the tools they need to experiment, learn safely and fail safely is important because software development is inherently experimental, which means failure is sometimes an expected outcome. We need to be able to catch those kinds of failures and safely redirect them where we can.
One of the challenges is that organisations which already have mature internal development environments often built them before artificial intelligence was on the horizon in the way it is now. The documentation and some of the controls were aimed at people who were already software engineers and developers and who had, or could reasonably be expected to have, a certain baseline level of knowledge and expertise. That baseline may not exist in quite the same way now.
Making sure security guidance helps people understand what they are doing in a broader sense and contextualising that guidance for people without as much technical knowledge becomes really important. That is better than blocking, banning or saying no to everything because that is a great way to get shadow AI happening outside your environment.
Providing a safe environment and educating people along the way in an accessible fashion becomes extremely important. In cases where you do have to say no, there should be a good reason why and, hopefully, an alternative. But at the very first line of defence, it is up to each individual, before even writing a prompt, to ask themselves what could go wrong and how they should think it through. If possible, they can even ask that in the prompt itself. That line of defence comes before a single line of code or a single prompt is written.
AI can take an application from prompt to prototype, and potentially deployment, much faster than traditional development. Are enterprises at risk of skipping security and quality safeguards that were previously built into the software development life cycle?
A few things have changed. It is also interesting to see what has not changed. To answer more holistically, the basics are still the basics because they are the fundamental layer that works. What is changing is that the speed of development and the ability to rapidly prototype something mean it is very easy to have something working in front of somebody else without putting too much thought into the software development life cycle at all.
As a result, we are skipping some of the safeguards that traditionally would have been put in place from the beginning, or very near the beginning, to help ensure that applications remain safe and secure throughout their life cycle. Security is a facet of quality overall. Quality can mean many different things and security is part of that. It is one of the pointier parts of quality, but it is not the only one.
It is not only security controls that might be skipped if you are prototyping rapidly, deploying rapidly and going straight from a prompt to a deployed application without any interim steps. Other quality controls can also be skipped. Those controls might not be necessary for a short prototype, but they certainly become necessary once you start trying to turn that prototype into a production-ready application, particularly if other people are going to depend on it.
There are some very solid fundamental practices around testing the code being written to make sure not only that it does not have vulnerabilities, but also that it does what it says it will do from a quality and efficiency perspective as well as a security perspective. We are now talking about developers experimenting with coding harnesses without necessarily looking at the code at all, with spec-driven development at a level where we are abstracted from the code itself. Even then, the code needs to be tested. You can build that into a harness, or you should build it into the harness in the first place, to make sure those established practices are applied in the context you are building right from the beginning.
Many large enterprises point to their network and security operations centres as evidence of cyber maturity. When does that tip into security theatre?
It can be quite performative in some cases, especially if you are trying very hard to show improvement over time or there is pressure to demonstrate improvement. Security requires honesty.
As much as security teams are putting defences in place, it is also their responsibility to highlight and flag where things are breaking or going wrong. That message can be very difficult to receive. It is really important that businesses are open to hearing this type of feedback, especially now, and that it is safe to say when something is not working well. It should also be safe to say how it can be improved.
There is a lot of exuberance around everything at the moment, and security is not always a field that inspires much enthusiasm. In some cases not everybody wants to hear bad news. Mature companies are well practised at making space for it.
It is also really important to remember that development is inherently experimental and experiments must involve failure at some point. That is normal and expected. The question is what you do to recover from those failures as quickly as possible, not simply how you prevent them from ever happening. Preventing every failure is not realistic.
What should a CISO be measuring instead?
There are always things that can be tweaked and made better, but to know what we realistically need to improve, we have to be honest in the first place. That means measuring the right things and the honest things so that you can track real improvement.
If you are a CISO, that also allows you to ask for the real kinds of investment you might need to meet the demands of this environment, because your security operations centre should be moving at the same speed as the attacks are moving. It is possible to automate defences in some cases, while also giving the human SOC analysts the right tools to make the right decisions at the right times.
AI introduces non-deterministic models, agents and new layers of abstraction into applications. What does that change in threat modelling, when the model itself can be manipulated through language?
The first thing is that threat modelling still very much needs to happen, and it is a process that requires the people making those decisions to talk to each other rather than getting a bot to threat model on your behalf. The threat model is not just about the eventual outcome of identifying risks. It is also about the process of understanding what you have, building visibility into how you reason about it and making sure the scope is well understood by everybody involved.
Beyond what has always been part of threat modelling, the thing that gets overlooked is that large language models are non-deterministic machines. They are not going to give you the same output for the same input every single time. They are also very good at mimicking natural human language patterns, which is one of their key advantages.
What those qualities mean in practice is that you now have machine-based components of your system that are capable of being socially engineered. They can be lied to and bargained with and, in some cases, very successfully so. If you had a deterministic rule written in code, it would be a yes or a no. Attackers have always found ways around certain things, but they did that in a very machine-based, logic-driven way. What we have now are system components that can be socially engineered, and that is not something you can patch. You cannot patch it in people.
If you require a hard rule, a hard yes or no, that should be backed up in the code itself rather than determined only through a system prompt. The large language model itself is always going to operate in shades of grey. Guardrails can be layered in a couple of different ways. Some will be prompt-related, but some will need to be old-school deterministic system guardrails layered in as part of your defences. It is about thinking through where a large language model’s qualities are useful to the system as a whole, where they become a liability and where you need to choose the right tool for the right job in the right context.
Your Questions, Answered
Is AI creating new types of cyberattacks?
According to Thoughtworks cybersecurity engineer Lilly Ryan, AI is not creating new types of attacks. Instead, it is speeding up existing attack methods and allowing them to be chained together autonomously, amplifying familiar security problems rather than introducing fundamentally new threats.
What security risks does AI-assisted coding create for enterprises?
AI coding tools are now in the hands of people without traditional software engineering backgrounds. These users may deploy applications without adequate security controls because LLMs do not proactively consider worst-case scenarios. This expands an organisation’s attack surface in ways not seen before.
Should enterprises ban AI experimentation to reduce security risks?
Ryan argues against blanket bans, saying this approach drives shadow AI usage outside controlled environments. Instead, organisations should provide safe spaces for experimentation with accessible security guidance and education built in from the start.
How should enterprises adapt their security to match AI-speed attacks?
Organisations need defences that can react at the same speed as attacks. This means paying down tech debt through file and permissions clean-ups, ensuring visibility into the technology environment, and accepting that many business processes still operate at human speed while attacks do not.