Exposed Serverless Functions: The Hidden Cloud Security Risk Behind AI Applications in 2026

Introduction: The AI Gold Rush and the Serverless Blind Spot

The world of cloud computing is in the midst of a massive shift. We're moving past the era of simply "moving to the cloud" and entering the age of AI-native applications. Under the hood of nearly every chatbot, image generator, and AI agent you interact with is a complex web of serverless functions. They’re the magic that makes AI scale, allowing developers to deploy code without thinking about servers.

But in the rush to build the next big AI thing, we might be overlooking a serious security blind spot. Recently, Google's Mandiant security team issued a stark warning about "exposed serverless functions." They've observed a sharp increase in publicly accessible functions that lack proper authentication. Why? Because the rapid adoption of AI, including chatbots and image generation, relies heavily on these serverless workflows.

This isn't just a theoretical problem. It's a hidden cloud security risk that's already being exploited across enterprise environments.

The AI Gold Rush and the Serverless Foundation

Let’s be real: serverless computing is practically built for AI. The workloads are unpredictable, scaling up and down with user demand. Serverless functions automatically handle that, and you only pay when your code runs. It's the perfect model for AI inference and agentic workflows.

But this convenience comes with a price. The very nature of serverless—decentralized, ephemeral, and highly interconnected—creates a sprawling attack surface. Traditional security models that focus on protecting the perimeter are completely useless here.

With AI workflows, serverless functions are the workhorses. They handle chatbot interactions, process image generations, and execute the multi-step tasks of AI agents. And when every function is a potential entry point, security becomes a whole new ballgame.

Why Exposed Serverless Functions Are a Goldmine for Attackers

Mandiant's research highlights that many of these functions are publicly exposed for legitimate business reasons. The problem is they often lack proper security controls. An attacker can find these unsecured endpoints and exploit common application vulnerabilities like Local File Inclusion (LFI), Remote File Inclusion (RFI), or command injection.

Once they exploit a vulnerability, the attacker essentially gains control over that container instance. From there, the game is on. The most common post-exploitation techniques involve:

• Extracting Secrets from Code: Developers, in a rush, sometimes hardcode secrets like API keys or database credentials directly into the function's code. This is a goldmine for an attacker.
• Stealing Bearer Tokens: A successful Remote Code Execution (RCE) can allow an attacker to access the metadata service of the cloud environment and exfiltrate the service account's bearer token.
• Analyzing Application Logic: Attackers can review the function's code to understand how the system works, identify internal endpoints, and find new ways to pivot.

A Real-World Attack Scenario

Imagine a cloud function that processes a user-provided filename and returns its content. If the code doesn't validate that input, an attacker could use a simple curl request to read sensitive system files:

curl -X POST https://your-cloud-run-service.run.app/ \
  -H "Content-Type: application/json" \
  -d '{"file": "../../../etc/passwd"}'

This classic path traversal attack could expose user information, environment variables, and even the application's source code.

The Attack on IAM: The Royal Flush

But stealing a secret is just the beginning. The real disaster scenario is when an attacker gets hold of those IAM credentials. By exploiting a command injection vulnerability, an attacker could run a command to fetch the service account's token from the metadata service. This token acts like a master key.

With this key, the attacker can then use the cloud CLI from their own machine, effectively impersonating the application's service account. And what happens if that service account has overly broad permissions? You're looking at a full cloud environment takeover. This is exactly what happened in a real-world attack detailed by Sysdig, where an attacker went from a single exposed credential to full administrative control in under eight minutes.

The Alarming Rise of AI-Assisted Attacks

As if that wasn't bad enough, attackers are now using AI to supercharge their attacks. Security researchers have observed AI-assisted attackers chaining together credential theft, privilege escalation, and lateral movement at a speed that leaves defenders with virtually no time to react. The attack code itself is showing signs of LLM generation, with comprehensive exception handling and even non-English comments.

This is a fundamental shift. As one expert put it, the speed of a breach has shifted from days to minutes. Defenders need AI-focused technology that can reason and respond at the same speed as automated attackers.

The New Threat: "LLMjacking"

One of the most lucrative goals for these attackers is "LLMjacking." Once they have administrative control, they target AI services like Amazon Bedrock. They'll enumerate available models, disable logging, and then start invoking expensive foundation models at the victim's expense.

The Cloud Security Alliance even documented a campaign named "KeyHunter" that used a NATS messaging system as a command-and-control (C2) server to exfiltrate cloud credentials and AI provider keys. The attackers exploited a critical vulnerability in Langflow, an AI workflow builder, to gain initial access and then systematically targeted 12 credential patterns covering AWS, GitHub, OpenAI, and Anthropic.

A Tangled Web: AI Prompts and Over-Privileged Functions

The security challenges of serverless functions are exacerbated by the very AI code they run. Serverless functions often interact with AI models and agents. This creates a whole new vector for attack: prompt injection.

Researchers at Tenable discovered vulnerabilities in cloud penetration testing and AI tooling in Google's Gemini AI tools that allowed attackers to inject malicious prompts via logs or a user's search history. This could trick the AI into hijacking its own logic and quietly siphoning private user data. This shows that logs, search histories, and browsing tools aren't just passive artifacts—they're all active attack surfaces.

Adding fuel to the fire is the problem of "vibe coding"—a term for using natural language to generate code. While powerful, AI-generated code can be unpredictable and may not follow best security practices. Mandiant recommends multi-layered security enforcement for AI-generated code, including isolating AI experimentation in sandboxes and restricting development environments.

Why Overprivilege is the Real Culprit

Ultimately, almost all these attacks succeed because of over-privileged functions. Research indicates that a staggering 98% of serverless functions are over-privileged, with 16% posing critical security risks. The principle of least privilege—giving a function only the permissions it absolutely needs—is often ignored in favor of convenience. Developers often use broad, managed policies or wildcard permissions.

This "set and forget" mentality creates a massive attack surface. An attacker who compromises a single Lambda function with an overly permissive role can move laterally to any other service in the environment.

How to Secure Your Serverless AI Architecture

So, how do we fix this? It's not about a single silver bullet but a multi-layered, defense-in-depth strategy.

The Bottom Line: A New Security Mindset for a New Era

The era of AI applications is here, and serverless computing is the engine driving it. The convenience and agility are undeniable, but we must confront the security risks head-on.

Exposed serverless functions are not just a technical problem; they are a critical business risk. The speed of compromise is now measured in minutes, not days. And attackers are using AI themselves to make their attacks more efficient and harder to detect.

Securing serverless AI is not about applying old security models. It’s about building a new one that is dynamic, identity-centric, and embedded in every layer of the development lifecycle. The time to treat serverless security as a strategic priority is now.