Notifications
Clear all
Topic starter
12/06/2026 12:25 am
TL;DR: Separating authorization logic from application code can make access control easier to test and audit in serverless stacks, as Cerbos’ Lambda pattern shows with API Gateway, S3-hosted policies, and stateless policy decisions according to Cerbos. The governance challenge remains unchanged: moving policy out of code does not remove the need to secure the identities, endpoints, and policy stores that govern access.
NHIMG editorial — based on content published by Cerbos: running Cerbos as a Lambda function with API Gateway and S3-hosted policies
Questions worth separating out
Q: How should security teams govern serverless authorization services?
A: Treat the authorization service as a privileged control plane, not a utility.
Q: Why do S3-hosted policies create an NHI governance problem?
A: Because the write access that changes effective permissions often belongs to non-human identities, not people.
Q: What breaks when authorization logic is scattered across multiple services?
A: Testing, auditing, and change control break first.
Practitioner guidance
- Separate policy administration from runtime invocation Give the identity that writes policy files different permissions from the identity that runs the Lambda PDP.
- Restrict the S3 policy path with versioned governance Use a dedicated bucket prefix for policies, enable versioning, and require change control for every update.
- Harden the API Gateway trust boundary Require JWT, IAM, mTLS, or equivalent authenticated access before a client can query the PDP.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step AWS SAM deployment for a Lambda-based PDP in a real serverless stack.
- Exact Dockerfile, bootstrap, and config layout needed to package Cerbos for Lambda.
- API Gateway proxy integration details for forwarding requests to the authorization service.
- Practical examples for testing allow and deny decisions with curl or Postman.
👉 Read Cerbos' guide to running a policy decision point on AWS Lambda →
Serverless authorization with Cerbos: where IAM boundaries still matter?
Explore further
12/06/2026 9:38 am
Decoupled authorization improves control visibility, but it does not remove identity risk. Moving policy out of application code makes access rules easier to test and audit, yet the surrounding control plane becomes the real security boundary. The PDP, the API gateway, the Lambda role, and the policy bucket each carry identity risk that can undermine the whole design. Practitioners should read this as a governance shift, not as a security simplification.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how quickly operational convenience can undermine identity governance.
A question worth separating out:
Q: How do teams know if a policy decision point is too exposed?
A: Look for public reachability, broad invocation rights, and weak caller authentication. If any service or identity can query or influence the PDP without strong trust checks, the authorization layer is effectively part of the attack surface. That is a sign to tighten gateway controls and role boundaries.
👉 Read our full editorial: Serverless policy-based authorization still needs strong IAM boundaries
