Security teams should use serverless-specific runtime protection that can monitor short-lived functions in real time, detect malicious activity, and capture enough context for investigation. Traditional tools often assume persistent workloads, which serverless does not provide. The practical goal is continuous visibility into execution, configuration, and network behavior so teams can respond before attackers exploit the narrow runtime window.
Securing Ephemeral Serverless Execution Without Host Agents
Serverless workloads change the security problem because the execution environment is short-lived, provider-managed, and often invisible to tools that expect a stable host. Security teams need controls that observe configuration, invocation, identity, network paths, and code behavior as the function runs, rather than waiting for a persistent endpoint agent. The main failure is assuming that traditional server and container controls will translate unchanged to functions that may exist only for seconds.
That shifts the focus from host ownership to execution visibility. Teams need to know which identities can invoke the function, what data it can reach, what events trigger it, and what the function can call downstream. SPIFFE workload identity specification is useful here because it reflects the broader need for portable, workload-centric identity rather than machine-bound trust. In practice, many security teams discover their blind spots only after a function has already been used as a fast-moving abuse path or hidden data egress channel.
What Security Teams Need to Observe at Function Level
Serverless security works best when teams treat each function as an event-driven control point instead of a mini server. The core question is not whether an agent is installed, but whether the team can reconstruct what the function did, who invoked it, and what it touched. That requires visibility into three layers: deployment configuration, invocation context, and downstream effects.
At the configuration layer, teams should track package integrity, environment variables, permissions, event sources, and public exposure. At the invocation layer, they need records of request origin, identity claims, payload shape, and concurrency or timeout anomalies. At the downstream layer, they need network destinations, storage access, queue activity, and unexpected API calls. This is where serverless-specific detection differs from legacy runtime monitoring: the telemetry must be collected quickly enough to survive the narrow execution window.
- Monitor changes to function code, layers, secrets, and execution roles.
- Correlate invocations with identity and event source metadata.
- Flag unusual fan-out, repeated retries, or unexpected outbound connections.
- Retain enough execution context for post-incident investigation.
Teams should also avoid treating function logs as a complete security record, because logs often capture symptoms rather than the full attack path. When a function is chained to storage, messaging, or API services, the real exposure is usually in the permissions and trust relationships around it. Guidance breaks down when the organisation cannot observe the event source or the downstream service calls with enough fidelity to reconstruct abuse.
Where Agentless Controls Break Down and What Good Looks Like
Tighter serverless monitoring often increases telemetry volume and policy complexity, so organisations have to balance visibility against cost, noise, and developer friction. Where the environment is highly dynamic, the goal is not perfect inspection of every packet or line of code, but reliable detection of abnormal execution patterns and unauthorised access paths.
There is no single consensus method for all serverless platforms. Some teams prioritise cloud-native logs and configuration controls, while others add eBPF-free network observation, API-level analytics, or function-scope policy enforcement. The right answer depends on whether the dominant risk is misconfiguration, credential abuse, data exfiltration, or malicious code execution. For AI-adjacent serverless workflows, security teams should also distinguish ordinary automation from autonomous tool use. The OWASP Top 10 for Agentic Applications 2026 is relevant only where serverless functions are acting as tool-calling or agent orchestration layers, not for generic functions.
Good practice looks like a control stack that can answer four questions quickly: what ran, who triggered it, what it could access, and what it actually touched. Where those answers are missing, the team is not truly securing serverless without agents, only hoping that platform defaults are enough.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Serverless security hinges on limiting who and what can invoke or reach functions. |
| 8 — Audit Log Management | Ephemeral functions require durable logs to reconstruct execution and abuse. | |
| 16 — Application Software Security | Function code, dependencies, and deployment integrity are central serverless risks. | |
| Recommendation — Apply Control 6 to restrict function access and revoke unnecessary invocation paths. Use Control 8 to retain invocation and downstream activity evidence for investigations. Apply Control 16 to harden function code, dependencies, and release integrity. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Serverless protection depends on least-privilege access to triggers and services. |
| DE.CM — Security Continuous Monitoring | Continuous visibility is needed because serverless runtimes disappear quickly. | |
| RS.AN — Analysis | Short-lived executions demand enough context to analyse incidents after the fact. | |
| Recommendation — Enforce PR.AC to bound function permissions and invocation trust relationships. Use DE.CM to monitor function execution, configuration, and network behavior continuously. Apply RS.AN to preserve enough context to analyse and scope serverless incidents. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Serverless functions often depend on tokens, API keys, and managed credentials. |
| NHI-03 — Authorization and Least Privilege | Function identities must be constrained to the minimum downstream access they need. | |
| NHI-05 — Inventory and Ownership | Serverless estates need clear ownership and inventory to avoid blind spots. | |
| Recommendation — Rotate and scope function credentials tightly to reduce abuse if a workload is compromised. Apply NHI-03 to limit each function identity to the smallest workable permission set. Maintain NHI-05 inventory so every function, role, and trigger has an accountable owner. | ||
Practitioner Guidance
What to prioritise: Start with identity, invocation, and permission boundaries before adding more detection logic. Serverless incidents often become material because a function had broader access than its business role justified, not because the code was especially sophisticated.
What to verify: Confirm that the platform can retain sufficient context for short executions, including trigger source, request metadata, role assumption path, and downstream service calls. If that context is lost, detection may still work, but investigation and containment become fragile.
Trade-off: More granular telemetry usually improves response quality, but it can also increase cost and create alert fatigue. Teams should keep only the data needed to distinguish routine invocation from abuse, rather than trying to instrument serverless like a long-lived host.
Practitioner takeaway: Serverless security is won by controlling trust paths and preserving execution evidence, not by searching for an agent-shaped substitute.
Related resources from NHI Mgmt Group
- How should security teams secure AI across data, infrastructure, and runtime without relying on point tools?
- How should security teams authenticate workloads without relying on user MFA patterns?
- How should security teams secure database access without relying on VPN trust?
- How should security teams restrict Vertex AI service agents without breaking workloads?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
