An AWS Lambda function is a serverless compute unit that runs code in response to events without requiring server provisioning. Teams use it for small, single-purpose tasks that scale automatically. Because Lambda deployments can multiply quickly, their configurations often need stronger inventory, drift control, and lifecycle governance.
Expanded Definition
An AWS Lambda function is a serverless execution unit that runs code on demand, but in NHI security it is better understood as a privileged workload identity as much as a runtime. Its security posture depends on the function’s IAM role, environment variables, deployment pipeline, event sources, and any secrets it can reach. That makes it a governance object, not just application code.
Definitions vary across vendors when teams describe “Lambda security,” because some focus on code scanning while others focus on identity, permissions, and event exposure. In NHI practice, the critical question is which non-human credentials the function uses, how tightly they are scoped, and whether the function can be invoked, modified, or chained by unintended actors. The NIST Cybersecurity Framework 2.0 emphasizes asset visibility and access control, which aligns with how Lambda should be governed as part of the wider identity plane, not treated as an isolated script.
For a broader NHI context, see Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0. The most common misapplication is treating Lambda as “stateless and therefore low risk,” which occurs when teams ignore the IAM role, secret references, and downstream service permissions attached to the function.
Examples and Use Cases
Implementing Lambda rigorously often introduces operational overhead in permission design and version control, requiring organisations to weigh deployment speed against tighter identity governance.
- A payment-processing function reads from an SQS queue and writes to DynamoDB, but its IAM role is restricted to only the exact tables and queues required.
- A deployment pipeline updates Lambda code, while separate approval controls protect configuration changes that could alter runtime permissions or secret access.
- A function sends alerts through an API key stored in AWS Secrets Manager, with rotation tied to a defined lifecycle and offboarding process.
- An event-driven fraud check function is monitored for drift, because a changed event source mapping can expand its execution path without changing the code.
- A workload review references 230M AWS environment compromise alongside the NIST Cybersecurity Framework 2.0 to show how identity exposure and weak governance can scale quickly across cloud assets.
In incident writeups such as Amazon AWS Hacked Accounts Crypto-Mining, the core issue is rarely the function code alone; it is the combination of overprivileged execution roles and weak account controls.
Why It Matters in NHI Security
Lambda functions matter because they multiply non-human access points. Each function can hold a role, invoke other services, read secrets, and trigger additional automation. When visibility is weak, teams lose track of which functions are active, what they can reach, and whether their privileges still match business need. That is exactly where NHI governance fails: not at creation, but during drift, sprawl, and incomplete offboarding.
NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. Lambda fits both problems because functions are easy to create, easy to forget, and often over-scoped for convenience. Security teams should connect function inventory, secret access, and role review to lifecycle control, especially when functions are used in CI/CD, AI pipelines, or cross-account integrations. The AI LLM hijack breach illustrates how stolen credentials and automation abuse can cascade once a non-human identity is compromised, while the Ultimate Guide to NHIs highlights the scale of the remediation gap.
Organisations typically encounter Lambda-related identity risk only after an access review, breach investigation, or unexpected cloud spend event, at which point function governance becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Lambda functions often fail through secret exposure and overprivileged non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Lambda governance depends on least-privilege access management for machine identities. |
| NIST Zero Trust (SP 800-207) | SC-7 | Lambda event paths and downstream calls should be treated as continuously verified trust boundaries. |
| NIST AI RMF | AI-adjacent Lambda workflows need governance for model-integrated automation and misuse risk. | |
| CSA MAESTRO | Serverless functions are common execution points inside agentic and automated AI systems. |
Constrain function-to-service access and verify each invocation path as a separate trust decision.
Related resources from NHI Mgmt Group
- What breaks when AWS credentials can deploy malware into Lambda functions?
- How should security teams reduce standing privilege in AWS environments?
- How should security teams reduce AWS data security risk without slowing cloud operations?
- Why do plaintext secrets create such a large AWS security problem?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
