When an AI model capable of finding zero-day vulnerabilities at machine speed gets accessed without authorization, the incident response has to match the threat profile. Anthropic’s handling of the Mythos breach is a useful case study of where disclosure practices for security breaches still need to catch up.

Anthropic built Claude Mythos Preview as something it explicitly said the world wasn’t ready for. 

The model finds zero-day vulnerabilities at machine speed, demonstrated the ability to escape its own sandbox, and in at least one test, posted details of its own exploit to public websites without being asked. 

We’ve already covered how Anthropic’s response was to keep it locked behind Project Glasswing – a tightly controlled initiative limited to a handful of vetted partners: AWS, Microsoft, Cisco, major banks, and critical infrastructure operators.

But exactly that is what makes what happened instructive.

Reports emerged this week that an unauthorized group accessed Mythos Preview through a third-party vendor environment connected to the rollout.

The group – part of a private Discord community that tracks unreleased AI models gained access on the same day Anthropic announced the model.

This mechanism of access is worth sitting with. 

Supply chain security is no longer a background concern for procurement teams. It is a front-line risk for anyone deploying AI in environments that touch source code, internal systems, or critical infrastructure. 

Anthropic just launched Project Glasswing – a major initiative to hunt vulnerabilities in critical open-source software using its most capable AI model. The implications for defenders and attackers alike are significant, and most organisations are not ready for either.

On 7 April 2026, Anthropic launched Project Glasswing – a coordinated effort to give key technology providers early access to Claude Mythos Preview with one goal: find and fix long-hidden vulnerabilities in critical open-source software before attackers do.

It is the clearest signal yet that frontier AI has crossed a threshold. It is no longer just a productivity tool bolted onto existing security workflows.

That is worth taking seriously. Not because of the marketing, but because credible institutions are paying attention.

The AI Security Institute and the UK National Cyber Security Centre have both documented measurable progress in AI agents completing multi-step cyber attack scenarios. The NCSC has called on defenders to prepare for a world in which frontier AI amplifies attacker capabilities at pace.

Glasswing is a concrete attempt to tilt that balance back toward defence. The early findings suggest it is working.

The two-sided ledger of AI-assisted security

For most of computing history, finding and exploiting software vulnerabilities required rare expertise.

The people who could do it reliably numbered in the thousands globally. That constraint mattered – it was a practical limit on how fast attackers could operate and how broadly they could target. 

Over the past year, that constraint has eroded sharply. 

AI models have become increasingly effective at reading and reasoning about code, showing a particular ability to spot vulnerabilities and work out how to exploit them. The cost, effort, and level of expertise required have all dropped dramatically.

Claude Mythos Preview, Anthropic’s unreleased frontier model behind Glasswing, has reached a level of coding capability where it can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.

That is not a marketing claim – it is the assessment Anthropic has published alongside the initiative. The AISI’s evaluation of Claude Mythos Preview’s cyber capabilities tracks the same capability curve and reaches similar conclusions.

And it is not only expert hands that can wield it.

An AI that can read a codebase, reason about execution paths, and identify edge cases in authentication logic can do that work for a defender running a bug bounty programme or for an attacker building an exploit chain. The model does not care which side of the firewall it is on. And given the rate of AI progress, these capabilities will not remain confined to actors committed to deploying them safely.

The question for security teams is not whether to engage with this shift. It is – how fast.

What Glasswing tells us about where this is heading

Anthropic’s approach with Glasswing is instructive beyond the specific initiative. A few things stand out.

The focus on open-source infrastructure is deliberate

Open-source software underpins almost every critical system in operation today – cloud platforms, financial infrastructure, healthcare systems, industrial controls.

Vulnerabilities in widely used libraries do not stay contained. When one surfaces, the blast radius is enormous and the window between disclosure and exploitation has compressed to hours in many cases. 

The Axios npm supply chain attack in March 2026 – where two malicious versions of one of JavaScript’s most-used libraries were quietly published – is a recent example of exactly how fast that window closes.

The results are concrete 

Mythos Preview has already found thousands of zero-day vulnerabilities –  flaws previously unknown even to the software’s own developers – including some in every major operating system and web browser.

Some of the specific findings illustrate just how significant the capability leap is:

The gap between Mythos Preview and the previous generation of models is also stark.

When tested against known vulnerabilities in Mozilla’s Firefox JavaScript engine, the previous best model – Claude Opus 4.6 – turned those vulnerabilities into working exploits twice out of several hundred attempts. Mythos Preview did it 181 times.

These are not theoretical weaknesses. They are exploitable flaws that survived decades of human review and millions of automated tests. The model found them.

The initiative is coordinated by design 

Early access, structured disclosure, defined scope – Glasswing is built to funnel findings into responsible remediation rather than onto a paste site. 

That framing is worth taking at face value, because the alternative – waiting for these capabilities to proliferate without a coordinated defensive response – is considerably worse.

For organisations watching from the outside, the implication is direct: if a frontier model can find vulnerabilities in your dependencies that survived decades of human review and millions of automated tests, you cannot rely on existing scanning and review processes to give you confidence that your attack surface is clean.

The attacker’s advantage – and how to close it

Defenders have always operated at a structural disadvantage.

The realistic near-term threat is not yet a fully autonomous AI attacker operating without human direction. But it is human attackers using AI to operate faster, at a greater scale, and with less specialised knowledge than was previously required. 

A moderately skilled attacker with access to a capable model can accelerate reconnaissance, generate targeted phishing content, identify patch-gap windows, and synthesise public vulnerability research into working attack chains.

We explored a version of this problem in our analysis of security gaps in vibe-coded applications.

AI-generated code introduces vulnerabilities not because the model is careless but because it optimises for functional correctness, not security depth. An attacker using the same models to probe those applications has a natural advantage over a developer who did not think adversarially when prompting.

The answer is not to avoid AI in development.

It is to apply deliberate security discipline at every stage – including to the AI-generated output itself. That means combining automated scanning with human-led testing rather than assuming one replaces the other.

What organisations should do before the surge hits

Glasswing is likely to accelerate vulnerability disclosures across the open-source ecosystem. Organisations that are unprepared for a sudden increase in security advisories affecting their dependencies will struggle to respond at pace.

Martin Walsham, Director of Cybersecurity at AMR Cybersecurity – Part of Infinum, has been tracking this shift closely: “Frontier AI models are progressing at pace, and the same technologies that defenders can use to increase overall security posture can equally be used by attackers to amplify their capabilities. This heightens the need for organisations to implement strong security baselines, defence in depth, and robust secure code, and to patch at pace to make them less susceptible to attacks.”

The precautionary steps below are not dramatic departures from good security hygiene. They are the foundations that make rapid response possible when it is needed.

Review and test your incident response plan now. 

Not the version that was written two years ago and has not been touched since. Run a tabletop exercise against a realistic scenario – a critical CVE in a dependency you cannot patch immediately, combined with active exploitation attempts.

Prepare for increased advisory volume. 

If AI-assisted vulnerability research delivers on its promise, the rate of disclosures in widely used open-source libraries will increase. Security and engineering teams need the capacity to triage and prioritise that volume without dropping everything else. Build that capacity before the surge, not during it.

Get your asset management list accurate. 

You cannot patch what you do not know you are running. This is the most consistent gap we see in organisations that have otherwise mature security programmes. A dependency buried four levels deep in your supply chain is still your problem when a CVE drops against it. Our step-by-step software supply chain security framework covers how to map and manage that exposure systematically.

Monitor updates and advisories actively. 

Subscribe to feeds for the libraries and platforms you depend on. Automated dependency scanning tools have improved significantly – if you are not running one, start.

Review third-party agreements with critical suppliers. 

If a vulnerability surfaces in a service you depend on and your contract does not specify patching SLAs, you have no lever to apply. Review those agreements and open conversations with suppliers about their response posture before you need to have that conversation under pressure.

Test your external perimeter. 

If your last penetration test was more than twelve months ago, you do not have an accurate picture of your exposure. This is especially true for organisations that have made infrastructure changes, onboarded new services, or shipped significant product updates since the last test.

Have a plan for enhanced monitoring at short notice. 

Not all threats give you advance warning. Know what elevated monitoring looks like for your environment and how quickly you can activate it.

Security baselines matter more, not less

There is a temptation to frame AI-powered threats as something categorically new that requires a categorically new response. 

In some respects, that is true – the speed and scale at which AI-assisted attacks can operate does change the calculus. But the vulnerabilities being exploited are mostly the same ones that have always existed: missing input validation, broken access control, insecure defaults, and unpatched dependencies. 

Our cybersecurity trends outlook for 2026 covers how AI-driven attacks, stricter compliance requirements, and supply chain exposure are converging into a single pressure point for security teams.

The NIS2 and DORA frameworks that came into force across the EU reflect this same reality. The technical requirements they mandate – multi-factor authentication, incident reporting, supply chain risk management, regular penetration testing – are not responses to AI-powered threats specifically. They are the baseline hygiene that makes an organisation resilient regardless of what the attacker is using. 

If your organisation is not meeting that baseline, the sophistication of the threat is almost beside the point.

Strong foundations beat reactive firefighting

Project Glasswing is a meaningful development in the responsible use of frontier AI for defence.

The AISI and NCSC assessments confirm what security practitioners have been observing in practice: capability is advancing faster than most organisations have adjusted for.

The right response is not to wait and see how the landscape settles. It is to invest in the defences that reduce exposure across the board – sound architecture, secure development practices, regular testing, and the operational readiness to respond when something goes wrong.

Infinum’s penetration testing and cybersecurity services are built around exactly that kind of proactive posture. If you want to understand your current exposure before the next wave of disclosures hits, talk to our security team.

Many organizations now want full ownership of their AI infrastructure. The motivation for self-hosting ranges from data ownership requirements and contractual obligations to maintaining the highest level of system security.

This post covers the infrastructure decisions, model selection tradeoffs, and performance optimization techniques we encountered while building a self-hosted multi-model inference stack. Security architecture and model licensing are out of scope here as both deserve their own deep dives. Still, everything about building the infrastructure and making it perform is fair game.

Here’s what our stack looked like:

vLLM as an inference engine

There are several open-source inference engines to choose from, including LMDeploy, SGLang, and TensorRT-LLM.

We chose vLLM for its performance, broad model support, extensive documentation, and built-in multi-model type routing.

Their production stack ships with an infrastructure diagram you can extend for your own setup, but the core components are:

Simplified end-to-end flow

The request router analyzes the incoming prompt’s prefix and directs it to a worker that already holds that context in memory. The worker processes the request with optimized block-based memory management, pulling previously computed states from a per-node or cluster-wide cache, and generates the response.

Choosing the right hosting environment

The AI hosting landscape is competitive. The vLLM production stack has cloud deployment support for AWS, Azure, and GCP, and project velocity matters a lot at this stage.

This is why we chose AWS EKS. The cost savings from alternative providers did not justify the increased setup complexity.

Specialty cloud hosting providers are cheaper, but they often offer unmanaged environments. That means you handle all the heavy lifting yourself, like networking, orchestration, GPU scheduling, the lot.

On-premise considerations

Buying hardware immediately is an operational risk. This is true even if you have predictable workloads.

We recommend a phased approach:

Choosing the right model

To simplify the equation: the two factors that drive infrastructure cost are model size (parameter count) and model context (the active memory window containing your conversation and retrieved data).

The LLM is your main challenge. Embedding and reranking models require comparatively little GPU power.

Here are three scenarios to illustrate the range. Note that these are rough on-demand estimates, and be sure to check current pricing and consider reserved or spot instances where applicable.

Small: chatbot with basic interactions

Customer support, simple Q&A. No complex reasoning or large context required.

Medium: reasoning over a knowledge base

Internal knowledge bases where the model reads retrieved company documents, follows strict instructions, and needs to minimize hallucinations.

Large: high accuracy, high reasoning, high context

Complex code refactoring, massive document analysis, predictions, and advanced agents. Maximum accuracy and minimal hallucinations are non-negotiable.

These are rough single-environment estimates. Multi-environment, highly available enterprise setups multiply these figures quickly.

Benchmarking your setup

Although there are fast general benchmarking tools available, like LLMfit, you should measure model performance in your own environment. This also reveals hardware traps that generic benchmarks won’t surface.

For example, adding more L40S GPUs may not increase performance. These GPUs communicate over the PCIe bus instead of NVLink, and the communication overhead can cancel out the compute gains.

vLLM has a native benchmarking option via the bench serve command. The key metrics to watch:

Optimization techniques

There is extensive documentation on optimization techniques. Here’s a summary of those that made the biggest difference for us.

Quantization

Reduces weight precision (e.g., from 16-bit to 8-bit or 4-bit) to shrink the model’s memory footprint. This has a direct impact on what model you can fit on your available hardware.

Automatic prefix caching

Worker/Node level memory management. Caches the KV state of existing queries. If you’re querying the same long document multiple times, the document is processed once and subsequent queries pull from cache. The result is higher throughput and lower latency.

Distributed caching via LMCache

Automatic prefix caching is limited to a single worker’s GPU VRAM — extremely fast, but expensive. LMCache enables cluster-wide offloading to cheaper storage (CPU memory, disk, or Redis) at the cost of some latency. Use both in a tiered memory hierarchy for the best balance.

Tensor parallelism

Workload distribution. Splits tensors across multiple GPUs. Effectively a requirement for larger models. Performance depends heavily on fast interconnects like NVLink.

Speculative decoding

There are multiple methods. One approach pairs a large model with a tiny, fast model. The fast model guesses the next tokens, and the large model verifies them in a single pass. This multiplies token generation speed.

Disaggregated prefilling

Separates the prefill and decode stages onto different GPUs or nodes. Since the two tasks have different computational profiles (compute-bound vs. memory-bandwidth-bound), you can scale each independently — either to improve responsiveness or to prevent long prompts from stalling active generation.

What’s ahead for self-hosting

There will always be demand for on-premise self-hosted AI in systems that require maximum control over their data.

The barrier to entry is dropping. Inference engines are maturing, optimization techniques are compounding, and models are getting better with fewer parameters and lower VRAM requirements. The recent Gemma 4 release is a good example: judging by the benchmarks, it delivers strong performance for a modest hardware investment. Stay tuned for a deep dive on that one.

In conclusion, enterprise-grade self-hosting remains expensive, but the trajectory is clear: organizations will be able to do significantly more with significantly less hardware.

The phased approach we outlined here is designed to let you start proving value now, without committing to infrastructure you don’t yet understand.

An AI-driven Knowledge Hub is an intelligent system that acts as an organization’s ‘internal GPT’, turning raw, scattered data into actionable insights through a chat interface. We’ve delivered them across industries to solve real business problems for our clients.

The modern enterprise is built on vast amounts of data, yet turning that data into actionable insights remains one of the most persistent and costly challenges organizations face. 

At Infinum, we’ve worked with clients across industries to bridge this gap by developing AI-powered Knowledge Hubs: centralized, intelligent repositories that aggregate and analyze your organization’s data and surface new insights through a seamless chat interface. Think of them as an internal GPT — one that knows your business, speaks your language, and has access to everything your teams need to make faster, more confident decisions.

From streamlining complex workflows for insurance firms to centralizing intelligence for global tech companies and premier fitness networks, these knowledge hubs are the connective tissue between big data and better decision-making. Here are a few examples of the work we’ve done to harness the power of data.

Helping insurance professionals cut through the noise of data

Risk is at the heart of every decision insurance professionals make. Underwriters navigate enormous volumes of data, claims history, actuarial tables, regulatory changes, weather events, market trends, competitor pricing, and their ability to accurately assess and price that risk directly impacts the business. The problem is that this data is rarely in one place, and pulling it together manually is slow, error-prone, and expensive.

We built an insurance intelligence solution that combines data engineering, risk modeling, and competitor and market data to support underwriting and risk assessment decisions. The system gathers claims data, actuarial tables, regulatory filings, and publicly available sources, and makes all of it accessible through a conversational chatbot.

The star feature is source citation. Every recommendation comes with a reference to the underlying data used to generate it. This significantly reduces the risk of AI hallucination, which is especially critical in heavily regulated sectors like insurance, where decisions are subject to strict auditing and compliance requirements.

Streamlining the flow of information for a global tech leader

Decision-makers at global tech companies are bombarded with news from every direction, but most of it isn’t relevant to their business. The real challenge is isolating the specific tech, environmental, and geopolitical shifts that actually impact their operations. For our client, the manual effort required to monitor these risks was leading to delayed reactions and missed opportunities. So we built an internal knowledge hub that turns that flood of global content into focused, actionable intelligence, using advanced data engineering and custom API integrations.

Rather than handing leadership a pile of raw articles, the system distills complex global events into concise daily and weekly briefs, filtered by pre-defined criteria unique to the client’s industry. Every brief that lands is directly relevant to the company’s long-term strategic goals and risk management.

A distinct advantage of this hub is its multi-dimensional filtering logic. By applying pre-defined criteria unique to the client’s industry, the system eliminates ‘noise’ and ensures that every brief delivered is directly relevant to the company’s long-term strategic goals and risk management.

Business intelligence platform for a premium fitness brand

Despite having large volumes of operational and financial data, teams across fitness clubs struggled with hard-to-use systems, missing metrics, and fragmented reporting. This made it difficult to get a clear picture of performance, align teams, and make timely, data-driven decisions.

We designed and built a centralized BI platform that integrates data from across the organization into a single, intuitive interface. By combining robust data modeling with user-centered design, the platform turns complex data into accessible, actionable insights for everyone – from frontline staff to executives.

Turning ‘hidden’ email data into a tool for cost reduction

Procurement teams are often buried under a lot of unstructured data, RFQs, and vendor price lists trapped in email threads and PDF attachments. Without a way to aggregate this data, it is impossible to compare vendor performance, track price volatility, or identify cost-saving opportunities in real-time. Manual data entry is slow, prone to error, and prevents strategic decision-making.

We built a sophisticated procurement automation solution that bridges the gap between raw communication and executive-ready analysis. Using Azure Document Intelligence, the system reads incoming vendor emails and complex attachments, automatically extracting and structuring critical data points. An Automated Extraction Layer then identifies and categorizes that data by vendor, product, and price, storing it in a high-performance structured database. This replaces manual tracking with a real-time repository of market intelligence.

From there, the platform performs deep-dive analyses, including vendor valuation and historical price benchmarking, and surfaces them through custom dashboards for real-time decision-making. Procurement teams walk into negotiations backed by data instead of gut feel, turning what was once hidden in an inbox into a genuine competitive advantage.

The transition from ‘data-rich’ to ‘insight-driven’ is no longer a luxury

As demonstrated across the insurance, tech, consulting, and fitness sectors, the challenge was never a lack of data. The organizations we worked with were sitting on everything they needed. They just couldn’t find it, validate it, or act on it fast enough. An AI-powered Knowledge Hub closes that gap. The right answer stops being buried in a database and becomes one question away. At Infinum, we don’t just build interfaces. We build the cognitive infrastructure that allows your team to stop searching and start leading. If that sounds like something your organization needs, check out what we can do.

Pen testing and red teaming are often used interchangeably. Both probe your defences. Both find what’s broken. But they ask fundamentally different questions, and the one you choose shapes how wide you assess your business security.

Penetration testing and red teaming both start from the same premise: hire someone to break in before the bad guys do. But they’re different tools for different problems, and conflating them is one of the more common mistakes organisations make.

Two approaches, similar goal

Penetration testing is focused.

You define the scope – a specific application, a network segment, a set of systems – and testers use the penetration testing methodology step by step in an attempt to find and exploit vulnerabilities within it.

Most engagements use a gray box approach: testers are given enough context to work efficiently. Credentials, access, scope. Enough to find what matters within a fixed timeframe.

The approach changes depending on who you are – a red team targeting a bank crafts different phishing emails, chooses different attack vectors, and pursues different objectives than one targeting a logistics company.

The whole exercise is shaped by what real threat actors are actually doing to organisations like yours.

Penetration Testing vs Red Teaming: Key Differences

The simplest way to tell them apart: pen testing answers “is this system secure?”, red teaming answers “could a determined attacker get into our organisation?”

Scope is the biggest practical difference. Pen testing is bounded — a specific application, network segment, or set of APIs. The tester works within those limits, finds what’s exploitable, and reports it. Red teaming has no such boundary. The adversary simulation can move across applications, people, and physical premises, using whatever combination of vectors a real attacker would.

The objectives differ, too. Pen testing produces a list of technical vulnerabilities with severity ratings and remediation steps. Red teaming produces something more like a case study: here is how an attacker targeting your organisation could move from initial access to their end goal, and here is what your people, processes, and technology did, or didn’t do to stop them.

Cost and time reflect this. A pen test might run for a week or two. A red team engagement is typically measured in weeks to months, and requires significantly more planning on both sides.

When Do You Need Pen Testing vs Red Teaming?

Pen testing is right for checking specific systems — after a new build, before a release, or as part of a compliance cycle. TIBER-EU and DORA both require it. If you’re running one annually and after major changes, you’re doing the basics right.

Red teaming is for organisations that have already done the basics. You need mature security processes in place first — incident detection, response playbooks, trained staff — otherwise a red team engagement mostly finds that your foundations are weak, which a pen test would have told you for a fraction of the cost. When that foundation is there, red teaming stress-tests the whole picture: not just whether systems are patched, but whether your people, processes, and assumptions hold up under a realistic attack.

The other factor is the threat model. If you handle sensitive data, operate critical infrastructure, or are the kind of target sophisticated threat actors actively pursue, red teaming answers a question pen testing can’t: not “is this system secure?” but “could a determined adversary get into our organisation?”

If you’re not sure which fits, start with a pen test. And if you want to understand what a red team engagement actually involves, explore our red team services.

Technical depth isn’t enough

The best pen testers and red teamers share two things: deep technical expertise and genuine creativity.

The technical side is obvious – you need to understand how systems behave under pressure, and how to adapt when a vector doesn’t work as expected. But creativity is what separates good from exceptional.

Testing isn’t a checklist. When a system reacts unexpectedly, the question isn’t “what does the tool say next?” – it’s “what does this tell me, and where does it lead?” That kind of thinking can’t be scripted. It has to be developed.

The second half of that matters as much as the first.

A brilliant technical finding is worthless if it can’t be translated into plain language. The job isn’t just to find vulnerabilities – it’s to help the organisation understand what they mean and what to do about them.

Why no scanner replaces this

Our research into AI-generated code security found that automated tools are good at cataloging CVEs, misconfigured headers, and outdated libraries.

They’re fast, they’re consistent, and they’re useful. But they operate on fixed logic. They flag what they’re programmed to flag, and they stop there.

A skilled tester doesn’t stop there.

They notice how a system reacts, chain together findings that no single tool would connect, and pursue lines of attack that require judgment – not just pattern matching.

Nine times out of ten, real attackers get in through people, not ports. A scanner has nothing to say about that. Manual testing does.

This is why organisations that rely on automated tools as their primary security layer end up with a false sense of coverage. The scanner ran clean – but that’s only true for the things the scanner knows how to look for. The cost of finding out too late is well-documented in our breakdown of the real cost of a cyberattack, which shows what’s actually at stake.

Attackers aren’t limited by that constraint.

A vendor with a quiet network connection into your environment, a help desk employee who clicks the wrong attachment – these don’t show up on a dashboard. They show up when it’s too late.

So, the question isn’t whether to test.

It’s whether you’re testing the right things, in the right way, with people who can tell the difference. Automated tools have their place – but they’re a floor, not a ceiling.

AI is changing how software gets built: faster timelines, leaner teams, fewer blockers. But does all that speed come at a cost? We put AI to the test in a real-world security experiment, and what we learned should matter to anyone leading modern product, platform, or tech teams.

According to Collins Dictionary, vibe coding is officially the word of the year – and if you’ve spent literally any time around engineering teams lately, that probably doesn’t surprise you.

Obviously, it’s catching on fast. 

Microsoft recently shared that around 30% of the code in some of its repositories is now AI-generated. This shift is one of the defining cybersecurity risks of 2026 — our cybersecurity trends overview covers the trade-off between vibe coding and security in depth.

At Infinum, we see this trend up close, both in internal experimentation and in conversations with clients who are increasingly curious about AI-assisted development.

The appeal is clear: development is faster, prototypes turn into products at record speed, and teams feel confident shipping. 

But is that confidence earned? We decided to find out.

Security doesn’t work on vibes

A growing belief is quietly taking hold in many teams:

“If I tell the AI to make it secure, it probably will.”

That assumption is understandable because AI is very good at reproducing patterns that look correct. When prompted, it can generate code that resembles common security practices and includes familiar terminology, giving the impression that risk has been addressed. But is it, really?

Instead of debating, our cybersecurity engineer designed a simple, hands-on experiment.

He asked AI to build apps with varying levels of security guidance, from none to OWASP-level detail, and then he tried to break them.

We didn’t want to test whether AI could write code. We know it can.

Let’s see the results.

The apps we built (and broke)

We asked AI to build three medium-complexity web applications, realistic enough to offer an attack surface, but not so complex that AI failed to build them. One app was generated with no security input at all, one with light guidance, and one with detailed, best-practice-driven instructions.

Turns out, not even specific prompts are enough to build applications that can survive real-world attacks.

What actually went wrong 

Even with better prompts, the same kinds of security gaps kept popping up.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI didn’t forget libraries or miss syntax.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI simply doesn’t understand cybersecurity, and it couldn’t reason about how things might go wrong, and that’s where real-life threats were.

While we are aware that this is an experiment of a limited scope, it is still important to note recurring issues we recognized:

In conclusion, the issues discovered weren’t bugs in the traditional sense. They were assumptions – that roles are respected, that the app can trust user input, that attackers won’t be creative.  

But attackers are creative, and they have all the time in the world to look for what you missed.

Why this matters beyond the code

Security is not just a dev problem. It’s a systems-thinking problem, and it affects every role involved in shipping software.

For CTOs & Heads of Engineering

AI speeds things up, no question, but it can’t replace architectural thinking.

The biggest failures in these apps weren’t in the code; they were bad assumptions about how trust, roles, and permissions work. Even when AI adds security controls, it struggles to secure the system as a whole.

We’ve all recently witnessed this: in our deep dive into OpenClaw (ex Moltbot), we explored what happens when AI sidekicks are given broad access with no guardrails. The takeaway? When AI has too much control, your data is very likely at risk.

Again, that’s an architectural one. And it’s still up to humans to get it right.

For Founders & Execs

All three apps worked. Some even looked secure. But they could still be exploited in serious ways, often through features that seemed harmless.

Remember this: AI gives a false sense of security. Without hands-on testing, issues like these show up only after damage is done. If you’re building with AI and need it to be secure from the start, our custom AI development services combine speed with security by design.

For Security Leaders

The vulnerabilities we found didn’t have CVE numbers. They weren’t from outdated libraries or missing headers. They were logic and abuse-case failures – the exact kind of problems automated scanners don’t catch. Addressing these systematically through structured security governance, risk assessment, and compliance frameworks is exactly what governance, risk, and compliance services are designed to support.

Manual penetration testing still matters because it mirrors how attackers behave, not just what vulnerabilities exist – and AI-assisted code makes this more important, not less.

For Developers

AI can implement what you tell it, but it’s not a security expert. It won’t catch logic flaws, system-wide assumptions, or the creative misuse attackers are known for. For a practical look at how to work with AI coding assistants without sacrificing code quality, see our roundup of AI tools for development teams.

Writing secure apps still requires developer intuition, threat awareness, and curiosity about how features might be abused.

So, yes. AI-generated code can be secure, but it takes judgement, experience, and most importantly, testing. 

What should you do now

Use AI. Embrace the speed. Build more, experiment faster, prototype wildly.

But don’t confuse working code with secure code.

Why automated scanners won’t help

Automated tools catch known and “low-hanging fruit” types of vulnerabilities. But issues discovered in this experiment weren’t in any vulnerability database, because they weren’t traditional bugs – they were incorrect assumptions about how systems would be used.

Automation wouldn’t have caught that, but manual testing told us whether the system could survive a curious attacker.

The real takeaway

The apps worked and security looked reasonable. 

But AI inherently doesn’t understand security, which is especially obvious once software interacts with real users, real data, and real incentives to misuse it. Security failures rarely come from missing syntax or forgotten libraries; they emerge from incorrect assumptions about behavior, trust, and intent.

Attackers do nothing but imagine misuse.

This is exactly why manual penetration testing exists: not to check a box, but to ask the one question that AI won’t:

“What happens if someone does the wrong thing on purpose?”

Security still requires human intent and adversarial thinking. No matter how well you prompt it, AI can’t protect against what it doesn’t anticipate.

If your app was built with AI assistance, this isn’t a theoretical risk. It’s a structural one.

If you want real, certified humans to have a go at your app – partner with Infinum’s security team to test your app the way real attackers would.  We’ll help you find the blind spots, close the gaps, and build safer systems, so you can move fast without leaving yourself exposed. If we find zero issues, the beer is on us.

For the past two years, most organizations have been consumed by a single, driving question: “How can we leverage AI in our business?” But as the market matures, the more critical question becomes: “How can we provide AI with the live context needed to function effectively?”

The “Static Context” Trap

There is a typical scenario that an organization lives through in its pursuit of AI utility. In an effort to deliver immediate value, an organization feeds an LLM its Confluence pages and a collection of internal PDFs. The model answers questions accurately, and the implementation feels seamless. Stakeholders are satisfied with the newfound efficiency. The results are an instant success.

However, the organization inevitably hits a wall as the reality of a moving business catches up with the static data of the past. If context is not retrieved dynamically, the AI cannot participate in a workflow – it can only summarize old news. This creates a strategic ceiling.

Most AI pilots reach a fatal point when they are too disconnected from the live environment to be trusted with business operations. Failure then spills into customer experience, internal operations, and revenue-impacting workflows. Eventually, it becomes clear that the issue is not the model’s intelligence but a lack of a live connection to the company.

That’s why the next wave of AI-enabled businesses will be defined by Model Context Protocols (MCP). This critical infrastructure bridges the gap between static reasoning and real-time business reality.

Enter the Model Context Protocol (MCP)

From a business perspective, model context is not about tokens or prompts. It is about ensuring that AI systems:

This is the foundation of how we approach AI and data engineering — every system we build is designed from the start with defined access boundaries, governance, and real-time data integration.

From “Advice” to “Action”

The transition from static data to dynamic protocols changes the utility of AI. This is best illustrated by an example emphasizing the difference between an assistant that remembers information and an assistant that knows how to fetch it.

The Static Way: Relying on Memory

In a static approach, an organization uploads thousands of PDFs, product manuals, and pricing sheets to a vector database. The AI is then prompted to use these documents to answer questions. However, as documents become outdated and regulations evolve, the system begins to fail.

Consider a customer asking for the current cancellation policy for an enterprise account in Germany. A static AI might reference a 2024 PDF and confidently provide an outdated answer. It has no way to verify whether that policy is still valid or even applies to that specific region. The customer ends up frustrated and exits the chat. 

This forces a human agent to intervene to fix the mistake manually. In this model, the engineering team’s daily workload is consumed by the repetitive task of feeding the model new data snapshots instead of building new capabilities.

This is one of the core pain points in AI chatbot development — we’ve documented how knowledge base staleness and hallucination undermine even well-scoped chatbot projects.

The MCP Way: Relying on Access

In the MCP Way, the business defines a standardized context layer. This protocol specifies exactly which tools the model can use and which data sources it can access in real time. Instead of relying on a folder of old files, the AI operates like a user with a live internet connection.

When asked about the same German cancellation policy, the AI identifies the region and customer type. It then uses the protocol to hit the live policy API and the subscription store. It recognizes the most recent “instant” policy tag and confirms the customer’s eligibility. Because it has a secure communication layer, it can provide more than just a text response. It triggers the cancellation through Infobip MCP Servers or another messaging tool.

This is the jump from an AI that talks to an AI that operates, ensuring that every action is grounded in verified, real-time data. This shift is at the heart of AI automation — moving beyond smart responses to systems that execute workflows end-to-end. For concrete examples of what this looks like inside enterprise systems, see our work on AI-powered knowledge hubs across insurance, tech, and procurement.

The Strategic Shift in Business Architecture

The value of structured model context extends beyond improving answers. When context is delivered via a Model Context Protocol, AI systems shift from isolated responders to reliable participants in business processes that operate within defined boundaries, using approved data and actions. Building these systems from the ground up is what our AI agent development services are designed for — from prototype to production in a structured, risk-managed engagement.

Most importantly, MCPs enable this without hard-coding logic into every application. Whether an organization is building internal tools or integrating with the ChatGPT Apps SDK, a robust protocol ensures engineers do not have to rebuild the connection between the brain and the data each time. The organization builds the protocol once, and the AI scales with the business.

The No-Brainer Approach

The industry has spent two years fixating on the LLM’s brain while neglecting the nervous system required to connect it to the enterprise. Model Context Protocols are the neurons that bridge this gap.

As models commoditize, competitive advantage shifts from raw intelligence to architecture. The winners will not be defined by the size of their LLM budget, but by the sophistication of the nervous system that gives their AI the agency to act. If you’re ready to build that nervous system, our custom AI solutions team designs production-grade AI architectures built around your workflows and data.

As vibe coding enters real-world development, I set out to evaluate the security of AI-generated code in practice. After building and attacking three vibe-coded applications with increasing security guidance, clear improvements emerged – alongside consistent gaps.

Large language models are already part of everyday development workflows.

Development teams use them to scaffold features, generate boilerplate, wire APIs, and, increasingly, to assemble entire applications from natural-language prompts.

In many cases, the output is functionally correct and fast enough to be genuinely useful.

What is less obvious is how this code behaves once it is exposed to real attackers rather than happy-path usage. This is especially relevant as regulatory pressure on the software supply chain increases and attackers adopt AI-assisted tooling.

I asked Gemini Pro to generate three different web applications and for each one, I progressively increased the level of security detail in my prompts.

The results were instructive, occasionally impressive, and ultimately a reminder that security does not emerge automatically – no matter how advanced the model. For a business-focused interpretation of these findings, see our AI-generated code security risks guide for CTOs and business leaders.

The plan and methodology

To make the experiment realistic, I needed applications complex enough to expose meaningful attack surfaces, but not so large that the AI would collapse into contradictory logic or endless refactoring loops.

I intentionally avoided very simple apps (e.g., To-do apps), since their limited functionality results in a small and unrealistic attack surface, while overly complex systems often exceed what current models can reliably reason about end-to-end.

They include authentication, authorization, data storage, and user interaction patterns that are common in real-world systems—and therefore make attractive targets for attackers.

For each application, I generated the entire codebase using Gemini Pro, varying only the level of security detail in the prompt.

I then reviewed the resulting code from the perspective of a realistic attacker, including both unauthenticated users and low-privileged authenticated users attempting to escalate access or abuse functionality. The focus was on practical exploitation paths rather than theoretical weaknesses.

The test subjects

Based on these criteria, the following three web applications were born:

Each application was built independently, with the only variable being the depth and specificity of security requirements provided to the AI.

Discoveries and vulnerabilities

In this section, we analyze the key vulnerabilities identified across the three generated applications. Rather than listing every individual issue, the focus is on the most impactful findings, recurring security patterns, and the extent to which the level of prompt detail directly influenced the security posture of the generated code.

Results at a glance: What broke and why

The following table provides a high-level summary of the results from the tested applications.

For security researchers looking to understand what these runtime gaps look like from an attacker’s perspective on mobile, where protections like root detection and Frida detection can be systematically defeated — see our walkthrough of Android penetration testing techniques.

For a real-world example of what happens when an AI tool is shipped without any of these guardrails in place — no authentication, broad system access, and easily bypassed safety measures see our security analysis of OpenClaw, the viral AI agent that exposed over 1,500 unauthenticated instances on the public internet within weeks of launch.

Simple Project Tracker: No security, just vibes

The first application generated was the Simple Project Tracker, a lightweight web application where regular users can create, update, and sort tasks, while administrators can additionally create projects and assign users.

No explicit security requirements were provided. The prompt focused solely on functional goals such as building a lightweight project tracker with database integration, role-based user and admin access, and all files needed for local deployment. As a result, the following prompt was used:

I would like to build a simple project tracker web application. Please include a database integration and an API that distinguishes between user and admin permissions. The goal is to have a completely operational application that remains lightweight by focusing exclusively on high-impact, necessary features. Additionally, make sure to generate every file necessary to run the web application locally.

For this application, AI selected the following technology stack:

As illustrated in the screenshot below, the generated web application exhibited a polished and well-designed interface.

Unsurprisingly, the absence of security guidance resulted in an application that implicitly trusted all user input. There was no input sanitization anywhere in the codebase, which led to pervasive cross-site scripting vulnerabilities across forms, task descriptions, and project metadata. 

Below is an example of the generated code.

The registration flow was particularly revealing. User roles were assigned directly from client-controlled input:

Changing “role” to “admin” was enough to gain full administrative privileges. There was no server-side validation, enforcement, or role integrity check.

Authorization was equally fragile. While the application exposed separate API endpoints for managing tasks and projects, none of them implemented ownership checks.

Any authenticated user could view, modify, or delete any other user’s data which can be seen in the following request where oddly specific x-user-id and x-user-role headers are used by default.

Session handling further reinforced the trust-in-the-client model. Authentication state was stored in unsigned cookies containing raw user objects:

Overall, in terms of design and functionality, the AI delivered exactly what was requested. However, from the security standpoint, the application had no sense of security at all and every possible aspect was completely insecure.

Functionally, the application worked exactly as requested. From a security standpoint, it operated entirely on the assumption that “logged-in users will behave correctly.” Needless to say, attackers do not follow that assumption.

Project Resource Hub: Better, but not bulletproof

The second application, the Project Resource Hub, was designed as a platform where users could share resources such as files, links, and documentation, while administrators were able to manage all users.

This time, alongside the application details, I instructed the AI to also take security into account. Each feature was required to be implemented in a way that was secure and resistant to abuse, rather than merely functional.

… web application details …

You may use modern, standard technologies commonly used in contemporary web application development, such as a database and an API. The application must support multiple users and include an administrator role. There should be at least 2–5 distinct features for both regular users and administrators to demonstrate a reasonable level of application complexity.

Additionally, it is critically important that security is considered throughout the entire application. Every feature should be designed and implemented securely, following best practices and ensuring that no functionality can be easily exploited.

Compared to the previous application, this one showed noticeable improvements in security while keeping the same tech stack. Specifically, the AI implemented several measures, including:

As illustrated in the screenshot below, the generated web application was simple and provided functionality for storing several resource types.

With a moderately detailed security prompt, the AI implemented effective input sanitization, and most tested inputs (including XSS, SSTI, and other relevant attack vectors) were handled appropriately. 

Even modest security instructions can significantly improve baseline resilience. However, a deeper inspection revealed critical blind spots in less than five minutes.

After less than five minutes of reviewing the generated code, I discovered a major flaw in the file upload functionality: the AI considered filename, file size, and MIME type checks sufficient for security, leaving the system vulnerable.

Because there were no extension checks (or other meaningful protections) an attacker could easily spoof the content type and upload arbitrary files.

Another feature in this application allowed users to store website links as resources, along with a preview function. Such feature by its description alone is a hacker’s dream to test for SSRF and unsurprisingly, the generated code was vulnerable.

While the preview was rendered inside an iframe, the backend still made unrestricted requests, making blind SSRF fully exploitable. 

Despite additional issues, such as an insecure CSP configuration and predictable secrets, this application was still an improvement over the previous one. 

However, several security measures were either ineffective against real attacks or failed because the AI didn’t anticipate certain attack scenarios at all.

Niche Vault: Not the Fort Knox just yet

The third application is Niche Vault, a platform that lets hobbyists log, browse, and share items from their personal collections, complete with individual profile pages. 

On the administrative side, it includes full user management capabilities, such as deleting, suspending, or banning accounts, along with basic analytics and the ability to publish site-wide announcements.

For this project, I placed a strong emphasis on security from the outset. 

I instructed the AI to strictly adhere to OWASP WSTG guidelines and OWASP best practices, ensuring that every feature was analyzed for potential attack vectors and that appropriate mitigations were implemented from the outset. In addition, every piece of generated code was required to undergo a second security review by AI again.

<web_application> A minimal web application designed for hobbyists to log, manage, view, and share items from their personal collections, such as vinyl records, comics, or similar collectibles. </web_application>

…web application features…

<security – HIGH priority> Security is the highest priority. Ensure that every component and feature is implemented securely and cannot be abused. Apply OWASP Web Security Testing Guide (WSTG) methodologies throughout the development process, and explicitly consider the OWASP Top 10 vulnerabilities to ensure the application is thoroughly protected by applying every best practice defense mechanism for each request, feature, functionality, and more. </security – HIGH priority>

This time, the AI generated a web application using Python (although I had to manually fix the code in several places) with the following tech stack:

The following image shows the generated web application with its functionalities implemented.

User input was well protected across the board, and the application even included safeguards against SSTI attacks, which is especially important given its use of Jinja2. Both authentication and authorization were implemented cleanly and thoughtfully.

The application was not without flaws. One notable issue appeared in the CSV export feature, where it was possible to inject malicious payloads that could be executed by Excel or LibreOffice. 

As shown in the image below, the relevant code lacks any form of input sanitization, leaving it vulnerable to CSV injection attacks.

As a result, an attacker can embed a malicious payload. In this example, a calculator application was executed; however, real-world attacks may involve reverse shell payloads that grant remote access to the victim’s desktop or download and execute malware.

As shown in the image below, the payload is evaluated when the CSV file is opened, causing the calculator process to be launched.

In addition to the glaring CSV injection vulnerability, several critical endpoints lacked rate-limiting controls. 

While the AI correctly implemented rate limiting for the registration and login endpoints, it failed to apply similar protections to the following endpoints, which attackers could exploit to perform potential denial-of-service (DoS) attacks as well as destructive behavior.

Additionally, the code contained a minor open redirect vulnerability, which could be exploited in phishing attack scenarios where an attacker can supply a malicious domain to the next URL argument.

In conclusion, even when provided with a highly detailed prompt that explicitly instructs the AI to generate secure code, it is still likely to fall short in other areas or to overlook security considerations in certain features altogether.

Without precise, feature-specific security requirements, the AI tends to leave parts of the application insufficiently protected. 

As demonstrated in this example, it successfully sanitized input fields, prevented SQL injection, and applied several other best practices, yet still failed to implement comprehensive, end-to-end security. 

Ultimately, these gaps resulted in additional vulnerabilities despite the overall focus on secure development.

The secret tokens predictability game

While generating multiple web applications, I noticed a recurring pattern: AI models frequently produce “secret” tokens and keys that follow similar structures and wording. 

This observation told me to take a deeper look into how predictable these generated secrets can be.

For example, when further creating even simpler web applications, the following tokens were generated in docker-compose and other configurational files:

While these values may not appear in common brute-force wordlists (such as those targeting JWT secrets and other), they are not cryptographically secure and I could potentially see them being used.

Overall, this demonstrates a plausible attacker strategy: using multiple AI models to generate and aggregate common secret placeholders, then testing them against large numbers of similarly generated applications.

The verdict

Bottom line is:

Vibe coding is only as secure as the vibe coder’s understanding of potential vulnerabilities and their ability to instruct the AI to account for them.

When building an application using AI, it is critical to explicitly guide the model on the types of vulnerabilities that may arise in the generated code. 

For instance, if you ask the AI to implement a file-upload feature, you must already provide clear requirements regarding file extensions, MIME-type validation, size limits, and other relevant mitigations.

The broader issue is that even the most detailed prompts do not guarantee secure output. AI can still generate insecure code or introduce subtle loopholes in unexpected places, and create critical business logic issues. 

For this reason, it is highly recommended to conduct real-world penetration testing, in which security professionals review both the code and the application’s runtime behavior to identify and mitigate risks before they become exploitable.

Explore our cybersecurity services — from penetration testing to security architecture — and partner with experts who can identify risks before they become exploitable.

Your RAG system works great until it doesn’t. As AI workloads scale, cloud-native tools begin to show cracks in governance, versioning, and observability. We explore how Databricks fills these gaps without replacing your existing AWS or Azure infrastructure.

Most teams already run reliable AI workloads on AWS or Azure. These platforms come with mature services that power modern production systems. Azure OpenAI, Cognitive Search, Blob Storage, AWS Bedrock, OpenSearch, and S3 all support high-quality RAG architectures and handle identity, networking, scaling, and operational reliability with ease.

But as AI systems grow, technical demands increase, data volumes expand, new document sources emerge, multiple teams work with the same information, and models evolve more frequently. That’s when cracks start to show. Cloud-native tools, built primarily for storage, compute, and serving, struggle to keep up. They lack unified governance, lineage tracking, and transformation pipelines needed to maintain consistency across growing AI workloads. 

The challenge then shifts from building a functional RAG system to orchestrating a governed data foundation, exactly what custom AI solutions are designed to address.

Unity Catalog: one layer to rule them all (your data, models, and vectors)

Unity Catalog is the central governance and metadata layer of the Databricks platform. It brings data, models, vector indexes, and functions under a single, consistent structure, so everything is defined, tracked, and secured in one place. This means simplified permission management and the elimination of fragmentation caused by different services each maintaining their own access rules.

Unity Catalog also automatically captures lineage, making it easy to trace how data flows through each stage of your AI pipeline, from ingestion to preprocessing, embedding, retrieval, and inference.

The result is a unified and predictable governance model that reduces complexity and supports reliable AI development across teams and cloud environments.

From unversioned storage to reproducible data with Delta Lake

With governance handled by Unity Catalog, the next layer to stabilize is storage itself. RAG systems thrive on structure and stability. But in practice, documents change frequently, models are retrained, and embeddings are regenerated. Without versioning and transactional integrity, it’s hard to explain model behavior or validate changes.

Delta Lake solves this challenge by layering ACID guarantees, schema enforcement, and time travel on top of cloud storage. Each Delta table becomes a versioned source of truth for both structured data from databases and unstructured data like PDFs and HTML. Ingestion becomes predictable instead of brittle. Teams can replay experiments without guessing which files existed at a given point in time. Even unstructured content can be governed just like structured tables, using managed volumes.

For teams prioritizing reproducibility and transparency, Delta Lake adds the versioning and transactional guarantees that object storage alone cannot provide.

Why retrieval belongs next to your data

With stable, versioned data in place, the next challenge is fast, reliable retrieval. Some engineering teams choose to complement their existing retrieval stack with Databricks Vector Search, especially when co-locating retrieval with the underlying data provides a performance or governance advantage. Integrating retrieval into the lakehouse platform offers several benefits:

Unity Catalog handles governance, Delta Lake tracks every version from raw files to embeddings, and Databricks Vector Search continuously syncs with your data as it changes.

For teams focused on performance, governance, and evaluation, this level of integration adds speed and structure to otherwise complex retrieval pipelines.

Keep your models where your data is

Getting data and retrieval right is only part of the equation. Now’s the time to plug in the models. 

Databricks Model Serving can help you deploy open-source foundation models, fine-tune custom variants, or run embedding models directly alongside their data, without bolting on separate infrastructure. Whether you’re working with large language models for generative AI or specialized embedding models for your RAG application, everything remains connected through Unity Catalog.

You can track the entire lifecycle of a model from initial training to production deployment. This enables a multi-model strategy, allowing you to select the best tools for each use case without introducing operational complexity.

No more duct-taping your AI pipelines together

Modern retrieval-augmented generation workflows require more than just storage and compute. They need orchestration, monitoring, and continuous improvement loops. Databricks provides integrated tooling for the entire RAG architecture:

You can’t improve your system if you can’t observe it

As RAG systems mature, observability becomes just as critical as modeling itself. Retrieval performance shifts gradually. Embeddings drift as data evolves. Large language model answers change with new versions.

Lakehouse Monitoring lets you track everything from data quality to model behavior, all in one place. Instead of piecing together logs across disconnected services, you get a single, consolidated view of AI behavior in production, which pairs well with AI data visualization approaches for surfacing those insights to stakeholders.

A user query is enriched with relevant context from Vector Search, answered by a large language model, and continuously evaluated through Lakehouse Monitoring to ensure data quality, retrieval relevance, and response reliability.

A question every AI team should ask 

If your AI workload doubled in size tomorrow, would your current data and governance structures scale with the same confidence as your application layer?

If the answer isn’t a clear yes, it might be time to lay a stronger foundation with Databricks.

The underlying cloud continues to operate application and networking layers, while Databricks provides the durable, governed data foundation needed for long-term AI operations. With Databricks capturing ~17% of the data warehouse market as of November 2025, its role in enterprise AI infrastructure continues to grow.

If you’re ready to accelerate your RAG architecture or take the next leap in your AI platform, our team can help you build a modern, scalable foundation designed for long-term success.

See how we built a real-time data intelligence platform for Midtown Athletic Club as an example of data engineering in practice. For examples of what these production data systems enable at the user layer, see our case studies on AI-driven knowledge hubs built for enterprise clients.

Businesses are enthusiastically adopting artificial intelligence, with McKinsey reporting that 78% of companies now use at least one AI tool. Not surprisingly, the adoption rate is even higher in tech companies. 

With this information in mind, it is only natural that AI automation is a much sought-after innovation.

Of course, you might want to understand it better before you decide you need it for your operations. We are here to help you with that.

What is AI automation?

AI automation is the process of using advanced technologies to make standard automated operations smarter and context-aware. It reduces the manual effort your team needs to put in by using AI and intelligent automation for tasks such as data analysis, report generation, and workflow optimization.

AI automation uses a mix of software, data, and decision logic to quickly and automatically execute tasks that normally require time and human judgment.

The specific technologies involved depend entirely on the business case: sometimes it’s simple rules, sometimes it’s document processing, and in certain cases it can include machine-learning or NLP models. The goal is always to make a workflow faster, more consistent, and less manually intensive.

Instead of predicting the “right” action on its own, AI supports the decisions that have already been defined. It can classify information, extract meaning from text or images, or surface relevant insights so that the system can follow the workflow the business has set.

When conditions change, the model can adjust its behavior within those boundaries, which makes it more flexible than fixed, step-by-step scripting.
As the system is used, its components can be refined through controlled cycles of periodic updates or retraining based on new data. 

In short, AI automation expands what traditional automation can do by helping systems understand inputs and choose the right path in a defined workflow, all within clear business rules and oversight.

Since the process is still responsive, AI automation can be very useful in areas where you want constant monitoring. In cybersecurity, it can spot suspicious behavior and trigger alerts instantly. In fraud detection, it can analyze transactions in real time to prevent losses.

Similarly, it can also be very useful for initial screening tasks, where the technology can decide who to send the problem to. For example, AI can be used to scan medical test reports and X-rays to make initial diagnoses, significantly reducing manual effort. They then forward it to the specialists who verify it and recommend treatment. 

This makes the process of getting healthcare quicker for patients and frees up healthcare providers to focus on the people who need them most.

How is AI automation different from traditional automation?

Traditional Automation, without AI, is a mechanical process that follows fixed and predefined rules. For example, a conveyor belt is automated: You flip a switch, and it starts moving. It might be programmed to stop if there is no weight on it, but it cannot react to a situation for which it was not explicitly programmed.

In contrast, AI-driven process automation can adapt its behavior based on input: it can interpret unstructured text, classify information, or extract relevant details, allowing the workflow to respond appropriately without manual intervention. The automation still follows defined steps, but the AI components enable the system to process a wider range of human input, formats, and real-world variability.

A simple example is a smart chatbot. The user enters a query using natural language, and the tool interprets the intent to create an appropriate response accordingly, leveraging large language models.

At a slightly more advanced level, AI agents take this a step further. Agentic AI can autonomously or semi-autonomously automate entire processes rather than individual tasks. They can plan, reason, and even collaborate with other systems or humans to achieve their goals.

Intelligent automation: Taking AI automation further

Intelligent automation (IA) is the next level of AI automation. Here, instead of tasks or processes, entire ecosystems are automated. They can run, adapt, and improve over time, all on their own.

There are three key technologies that power these digital workers:

How AI automation works

To create AI automation, you need to integrate processes with artificial intelligence. The processes create the framework around which algorithms are built.

These algorithms use the same decision-making logic that a person would, and are trained on business data. This informs them of the type of information and the patterns to expect. 

The logic built into them allows them to use new data to spot these patterns and make predictions. Meanwhile, ML allows them to learn from it, so the systems continuously refine and improve their results.

Here is a quick overview of the parts that come together to make this technology work: 

Benefits of AI-powered automation in your business

We already know that AI automation can free up your human workers by taking over routine tasks. Let us take a look at how this can benefit your business:

AI automation use cases

Reading about benefits in an abstract sense does not paint a very clear picture. Here’s how businesses across industries are applying AI automation to solve their challenges:

Challenges of implementing AI automation

Implementing AI workflow automation solutions can be a great way to optimize your operations. However, the process requires careful planning, or it will not increase efficiency.


Here are some caveats to consider:

Automate your business with the right partner

Several of the above challenges can be mitigated by working with the right technology partner, such as Infinum.


We have the experience that allows us to develop solutions tailored to your needs, so they can integrate easily with your existing technology and workflows. 


Most importantly, our methods, reporting, and internal processes meet strict, internationally recognised security standards. With Infinum, the security of your AI automation solution will be in safe hands.


We have a large team that can help you navigate strategy development, data engineering, model building, deployment and integration, as well as ongoing monitoring and maintenance.


Interested in learning more about how we can help you with your AI automation journey? Talk to us!