XenonStack Insights Serverless Security: Enterprise Guide for 2027

Serverless security is the practice of protecting applications built on managed cloud services and function-as-a-service (FaaS), where the provider runs the servers and you still own the code, the identities, the data and the configuration. The infrastructure layer is no longer yours to patch, but the attack surface moves to event inputs, permissions, dependencies and logging.

For enterprises in 2026 the practical question is how to keep hundreds of small functions inside policy, including functions that AI agents now trigger or generate. This guide covers the shared responsibility split, least-privilege IAM, the main threat classes, the controls each major cloud documents, and how to govern agent-run functions. For the wider platform view, see our guides on serverless development and cloud security.

Who is responsible for security in serverless?

Responsibility is shared. AWS describes it as "security of the cloud" (AWS protects the infrastructure that runs its services) and "security in the cloud", where your responsibility "is determined by the AWS service that you use" and includes the sensitivity of your data, your company's requirements and applicable laws and regulations (AWS Lambda documentation, read 13 Nov 2026).

The exact split differs by service and provider, so confirm it in each cloud's own documentation. Google's Cloud Run security overview, for example, describes provider protections such as sandboxing and encryption but does not set out a customer split, so your own control map has to fill that gap.

How does serverless change the risk for cloud infrastructure?

Serverless raises agility and ties cost to use: teams stop managing servers, databases and authentication plumbing, and pay for execution rather than idle capacity. Security changes shape in three ways.

1. Risk moves from hosts to identities and inputs. Without servers to harden, security depends on who may invoke a function and what it may touch.

2. Small "nano-service" functions allow tightly scoped controls, and the visible orchestration of resources gives security tooling useful signals.

3. New risks appear: perimeter fragmentation, many event sources and orchestration gaps between functions.

What are the security benefits of serverless?

• Provider-managed operating system and runtime hosting. You no longer own OS hardening, SSH or host administration for the function. AWS, Google and Microsoft maintain their parts of the stack.
• Short-lived, stateless execution. Functions run briefly, which makes long-lived footholds harder, although attackers can still abuse a function while it runs or poison what it writes to storage.
• Smaller units for better IAM. Each small function can carry its own narrow policy, which reduces the blast radius.

What are the top serverless security threats and how do you mitigate them?

OWASP maintains a Serverless Top 10 as an incubator project, with an interpretation document published on GitHub. Check its current numbering on the OWASP project page; the table below groups the threats we see most often in enterprise reviews and does not reproduce that numbering.

Event-data injection

Injection occurs when untrusted input reaches an interpreter. Serverless functions can be triggered by many event sources (queues, storage events, streams, schedules), and scanners built for HTTP often miss those. Treat every event field as untrusted. Common classes are:

• Operating system command injection
• Function runtime code injection
• SQL and NoSQL injection
• Server-side request forgery (SSRF)
• Object deserialisation attacks

Broken authentication

A serverless estate can hold hundreds of functions, some exposing public APIs and others acting as internal proxies. Every function, event type and trigger needs an explicit authentication decision. A public storage bucket that triggers a function is an unauthenticated entry point.

Insecure configuration

Misconfigured triggers, access lists or storage settings can expose data. Apply cloud hardening, review ACLs and keep functions stateless so sensitive data is not left behind.

Function permissions and roles

Give each function only the access its logic needs. Excess privilege is one of the most damaging misconfigurations an attacker can exploit, so permissions belong in code review.

Third-party dependencies

A small function still imports packages and may call remote APIs. Scan source and dependencies at development and build stages and automate vulnerability assessment, because a vulnerable library inherits the function's permissions.

Insecure storage of secrets

API keys, database credentials, sensitive settings and encryption keys must not sit in source code or plain configuration. The next sections show the store each cloud documents.

Denial of service and financial resource exhaustion

Serverless can face denial of service, and the cost side makes it a financial risk as well. Set limits on memory per execution, processes and threads, execution duration per function and execution volume per account, plus budget alerts.

How do AWS Lambda, Azure Functions and Google Cloud Run functions secure identity, secrets and access?

The table below uses only each provider's own documentation (read 13 Nov 2026). Google Cloud Functions now appears in Google's documentation as Cloud Run functions, and the site still mixes both names.

Sources: AWS Lambda security, Azure Functions security concepts, Cloud Run security design overview.

How do you apply IAM least privilege to serverless functions?

• One role per function. Do not share a role across functions. A function that only reads a table should hold read access only.
• Use workload identities, not stored keys. Execution roles, managed identities and dedicated service accounts remove long-lived credentials from code.
• Keep configuration out of code. Use environment variables for non-secret values such as hostnames, and a secret store for credentials.
• Trim triggers and network paths. Remove services that do not need to trigger a function and restrict network access when it runs in a private network.
• Automate checks in CI/CD. Test policies, dependencies and configuration before release, as part of DevOps practice.

How do you monitor and observe serverless security?

Logging happens in the cloud, outside your data centre perimeter, so your teams must assemble the logging logic that gives real-time security monitoring and an audit trail. Collect logs from functions and cloud services in real time and send them to a security information and event management (SIEM) system. Because function volume produces very large log streams, alert on identity and permission changes, unusual invocation sources and cost spikes rather than reading raw logs.

Traditional endpoint protection and host-based intrusion prevention do not apply, because you have no access to the operating system. Pair cloud-native telemetry with cloud security posture checks.

How do you govern agent-run functions?

Functions are increasingly called by AI agents or generated with their help. That adds a decision-maker that can invoke tools at machine speed, so apply these rules as our recommendation (not a cloud provider requirement):

• Give each agent its own identity and a narrow list of callable functions.
• Treat agent output as untrusted event input and validate it as you would any other event.
• Put a human approval step in front of functions that change data, money or access.
• Log the agent, the function, the inputs and the policy that allowed the call, so the decision can be reviewed later.
• Cap invocation rate and spend per agent.

According to its site, AgentGRC keeps autonomous agent actions inside policy, with the audit trail risk teams need, and ElixirClaw is an agentic OS platform to build, orchestrate and govern AI agents and automation workflows while keeping humans in control.

What are the main challenges in serverless security?

• Scanning tools can miss serverless. Many are built for HTTP interfaces and miss other event sources.
• Visibility is harder. More resources mean more logs and fewer clear signals.
• Permissions multiply. More functions mean more roles to manage, which manual review cannot sustain.
• Every trigger is an attack point. Each protocol and event source needs its own review on AWS Lambda, Azure Functions and Google Cloud Run functions.
• Host-based tools do not fit. Without access to operating systems, endpoint protection is not available.

When is serverless the wrong fit, and what is the adoption sequence?

Serverless is a poor fit when you must control the operating system or runtime, run long jobs, or need security tooling that depends on host access. Tightly coupled functions also create risk: a flaw in one function that many others rely on can be too dangerous to remove, and downtime can flow on to dependent services. Keep each function to one clear job so attackers have less to reach.

To map one serverless or agent-run function decision your teams must govern, and the identity and policy it depends on, book a Context Workshop. See what happens in the workshop.

What should you plan for in 2027?

Runtime upkeep is a part of serverless security that stays with you, so put these dates in your 2027 plan. AWS lists them on its AWS Lambda runtimes page and says the dates for supported runtimes are forecasts that are subject to change.

• 31 March 2027: deprecation date for Ruby 3.3.
• 30 May 2027: deprecation date for Node.js 22.
• 30 June 2027: deprecation date for Python 3.11 and for Java 8, 11 and 17 on AL2.
• 29 July and 31 August 2027: for many runtimes that are already deprecated, including Node.js 20, Python 3.10 and Python 3.9, the page shows blocked function creation from 29 July and blocked function updates from 31 August.

Inventory which functions use these runtimes now, so upgrades are planned rather than forced.

FAQ: serverless security

What is serverless security?

It is the protection of applications built on managed cloud services and FaaS, where the provider secures the infrastructure and you secure code, identities, data and configuration.

Who is responsible for serverless security?

Both. AWS describes security of the cloud as its responsibility and security in the cloud as yours, depending on the service you use.

How do I apply least privilege to serverless functions?

Use one role per function, grant only the actions the logic needs, and prefer execution roles, managed identities or dedicated service accounts over stored keys.

Where should serverless secrets be stored?

In a managed store: Key Vault references on Azure Functions and Secret Manager on Google Cloud Run functions are both documented, and AWS documents data protection guidance for Lambda.

Is event injection a serverless risk?

Yes. Many event sources can trigger a function, so every field from queues, storage events and streams must be validated as untrusted input.

How should AI agents that run functions be governed?

Give each agent its own identity, a narrow function list, approval for risky actions, rate and spend caps, and a log of each call and the policy that allowed it.