A serverless function is short-lived compute that runs on demand and shuts down after handling a request or event. It is well suited to lightweight tasks, but its execution limits, cold starts, and stateless design can make it a poor fit for long-running AI workflows or complex agent orchestration.
Expanded Definition
Serverless functions are event-driven units of compute that abstract away server management while keeping the developer responsible for code, configuration, permissions, and data handling. In practice, they are used for narrow, discrete tasks such as reacting to uploads, transforming payloads, or validating requests. The “serverless” label is architectural, not literal: infrastructure still exists, but the platform handles provisioning, scaling, and lifecycle management. That distinction matters because security boundaries shift from host management to identity, configuration, and event trust.
For security teams, the most important question is not whether a function runs without a server to administer, but whether its invocation, secrets, and downstream access are tightly governed. This is why serverless design is often discussed alongside NIST Cybersecurity Framework 2.0, especially when mapping asset visibility, access control, and monitoring responsibilities. Definitions vary across vendors on where serverless ends and managed application services begin, so usage in the industry is still evolving. The most common misapplication is treating a function as “secure by default,” which occurs when teams assume platform isolation removes the need to control permissions, secrets, and event sources.
Examples and Use Cases
Implementing serverless functions rigorously often introduces operational constraints, requiring organisations to weigh simplicity and elastic scaling against execution limits, observability gaps, and tighter dependency on cloud permissions.
- A file ingestion workflow triggers a function to scan metadata, classify content, and forward only approved items to storage or downstream processing.
- An API gateway invokes a function to validate tokens and apply lightweight business logic before a request reaches a protected backend.
- A security automation pipeline uses a function to enrich alerts, query threat intelligence, and send structured events into NIST-aligned monitoring and response workflows.
- An identity system calls a function to normalize attributes, check policy conditions, or generate short-lived artefacts for a downstream process.
- An AI application uses a function for pre-processing or routing, while keeping long-running model execution outside the serverless boundary because the function runtime is too constrained for sustained orchestration.
Why It Matters for Security Teams
Serverless functions compress delivery time, but they also concentrate risk into identity, event integrity, and configuration hygiene. A single overly broad execution role can expose storage, queues, secrets, or administrative APIs across many automated paths. Because functions are ephemeral, incident responders may find limited local state and short retention windows, which makes logging, tracing, and deployment history essential to reconstruction. Security teams also need to understand whether third-party services, object stores, webhook sources, or agentic systems can invoke a function without sufficient validation.
This is where cloud governance overlaps with identity security: each invocation is effectively a trust decision, and each permission attached to the runtime can become a durable access path if it is copied across functions or environments. Control discipline should therefore align with the access and monitoring expectations described in NIST Cybersecurity Framework 2.0, especially for identity, logging, and resilience outcomes. Organisations typically encounter the real cost of serverless sprawl only after a misrouted event, leaked secret, or excessive role permission exposes production data, at which point the function layer becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Serverless permissions and invocation trust align with access control expectations. |
| NIST AI RMF | AI RMF is relevant when serverless functions support AI workflows or automated decision paths. | |
| OWASP Agentic AI Top 10 | Agentic pipelines often use serverless functions as tools, making invocation control important. | |
| OWASP Non-Human Identity Top 10 | Serverless runtimes frequently rely on tokens and service identities, a core NHI concern. |
Map function roles and triggers to least-privilege access and review them continuously.
Related resources from NHI Mgmt Group
- What is the difference between function calling and MCP for enterprise security?
- When does MCP make more sense than function calling?
- What is the difference between application RBAC and function-level permissions for MCP?
- Why do unsalted password hashes remain risky even when the hash function is strong?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
