How should security teams secure serverless workloads without relying on traditional runtime agents?

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.

Why This Matters for Security Teams

Serverless security fails when teams assume the absence of a long-running process means the absence of risk. Functions still authenticate, read secrets, call APIs, and move data. If runtime agents cannot stay attached, traditional EDR-style tooling misses the very moments when compromise occurs. Current guidance suggests shifting from host persistence to execution-centric visibility, with identity, configuration, and network telemetry treated as the primary security signals. That aligns with the way NHIs behave in short-lived workloads, as discussed in The State of Non-Human Identity Security and in the SPIFFE workload identity specification.

For practitioners, the real issue is not whether a function is “serverless” but whether its identity, permissions, and secrets are tightly bounded to a single invocation. When a function is over-privileged, the attack window is short but the blast radius can still be large. In practice, many security teams discover this only after a function is abused for credential harvesting or data exfiltration, rather than through intentional design review.

How It Works in Practice

Securing serverless without runtime agents means building controls around the invocation path, not around a persistent workload. The working model is: authenticate the function, authorize the action at request time, inject only the secrets needed for that execution, and collect telemetry outside the function boundary. That typically combines cloud-native logs, event streams, API activity, and policy decisions made by a central engine.

For identity, the best practice is evolving toward workload identity and short-lived credentials. A function should present a cryptographic workload identity, such as SPIFFE/SPIRE or an OIDC-based token, rather than rely on static API keys baked into the deployment. That supports just-in-time access and revocation when the invocation ends. For authorisation, policy-as-code tools such as OPA or Cedar can evaluate context at runtime, which is more suitable than static RBAC when execution paths vary by event payload, tenant, or downstream dependency. This approach is consistent with the direction described in Guide to SPIFFE and SPIRE and the NIST AI Risk Management Framework.

• Use short TTL credentials for each function invocation, not reusable secrets.
• Bind permissions to the workload identity and the event context.
• Log invocation metadata, downstream calls, and secret access outside the function.
• Correlate cloud audit logs with data-plane telemetry for incident response.

This also means rethinking detection. Instead of asking an agent to inspect memory or processes, security teams should detect anomalous invocation frequency, unusual API targets, privilege escalation attempts, and secret access patterns. These controls tend to break down in highly event-driven architectures where functions fan out across multiple accounts and services because ownership, context, and telemetry correlation become fragmented.

Common Variations and Edge Cases

Tighter runtime-free control often increases operational overhead, requiring organisations to balance stronger isolation against more complex policy, telemetry, and secret management. Best practice is evolving here, and there is no universal standard for every serverless platform.

Some environments can centralize most controls in the platform layer, while others need an external policy engine plus a dedicated secrets broker. In regulated workloads, teams may also need stronger evidence retention than the function runtime itself can provide, which is why cloud audit logs and immutable traces matter more than local inspection. This is especially relevant where The State of Non-Human Identity Security shows how weak monitoring and logging contribute to NHI incidents. For threat modeling, the CSA MAESTRO agentic AI threat modeling framework and OWASP Agentic AI Top 10 are useful references when workloads behave autonomously or chain actions across services.

Edge cases appear when functions must call legacy systems that only accept static credentials, or when third-party integrations require long-lived tokens. In those cases, compensating controls should include tighter scopes, stronger monitoring, and automated rotation. The model breaks down most sharply when serverless functions are granted broad cross-account permissions and the organisation has no reliable way to tie each invocation back to a unique workload identity.

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?