Serverless policy-based authorization still needs strong IAM boundaries

At a glance

What this is: This guide shows how to run Cerbos as a stateless policy decision point on AWS Lambda with API Gateway and S3-backed policies.

Why it matters: It matters because IAM, NHI, and application teams still have to govern the identities, endpoints, and policy stores that make delegated authorization trustworthy.

👉 Read Cerbos' guide to running a policy decision point on AWS Lambda

Context

Serverless authorization is a governance problem as much as an application design problem. When access decisions are scattered across services, database logic, and ad hoc roles, teams lose testability, auditability, and consistent control over who can do what. In NHI terms, the service identities that call the policy engine and the credentials that secure the policy store become part of the access model, not just plumbing.

Cerbos’ Lambda pattern pulls policy decisions into a separate service so that application code can stay focused on business logic. That separation helps, but it also shifts scrutiny to the policy decision point, the API gateway, the Lambda execution role, and the S3 bucket that stores policies. If any of those identities are over-privileged or weakly protected, the architectural clarity disappears quickly.

Key questions

Q: How should security teams govern serverless authorization services?

A: Treat the authorization service as a privileged control plane, not a utility. Separate policy administration, runtime invocation, and deployment rights into different roles, then require strong authentication and logging around every policy change. The goal is to make access decisions testable without making the decision system easy to tamper with.

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. If service roles can alter policy files, then those identities are governing access for the whole application estate. That makes bucket permissions, versioning, and change audit central governance controls.

Q: What breaks when authorization logic is scattered across multiple services?

A: Testing, auditing, and change control break first. When each service encodes its own access rules, teams lose a single source of truth and end up with inconsistent decisions across the stack. Centralising decisions in a PDP restores consistency, but only if the PDP and its policy source are tightly governed.

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.

Technical breakdown

Policy decision points in serverless authorization

A policy decision point, or PDP, evaluates access requests against central rules instead of embedding authorization logic in every service. In a serverless design, that means the application or API gateway sends request context to the PDP, which returns allow or deny based on roles, attributes, resources, and actions. The main advantage is consistency: one policy model can govern many callers. The tradeoff is dependency concentration. If the PDP is unreachable, misconfigured, or overly trusted by callers, authorization either fails open or becomes brittle. The design works best when the decision service is isolated, observable, and protected like any other high-value control plane component.

Practical implication: treat the PDP as a privileged control-plane identity and secure its network path, authentication, and availability accordingly.

S3-hosted policy files and policy drift

Storing policies in S3 makes authorization versionable and easier to update, but it also introduces a policy supply chain. The bucket, prefix layout, and read permissions determine who can alter effective access rules. Cerbos’ blob storage driver scans the bucket prefix, so changes in object placement can affect what is loaded at startup. That makes policy drift a real operational risk: the code may be stable while the effective authorization model changes underneath it. For NHI governance, the key question is which identity can write, overwrite, or delete policy artefacts and how that activity is logged.

Practical implication: lock down policy write access, enforce version control, and audit every change to the S3 policy path.

API Gateway, Lambda execution roles, and request trust

API Gateway acts as the front door to the Lambda-based PDP, but it does not itself make authorization trustworthy. The Lambda execution role still needs access to S3 and CloudWatch, and the gateway needs a clear trust boundary so only legitimate clients can invoke policy checks. JWT authorizers, IAM authorizers, VPC links, mTLS, and IP controls all narrow exposure, but they protect different parts of the chain. The important design point is that the calling service identity and the policy service identity are separate trust domains. Confusing them leads to weak boundaries and hard-to-debug authorization failures.

Practical implication: separately authenticate callers to the PDP and limit the Lambda role to the minimum S3 and logging access it actually needs.

NHI Mgmt Group analysis

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.

Policy storage creates a policy supply chain, not just a configuration store. Once S3 becomes the source of truth for authorization, whoever can write to that bucket can shape access outcomes across the application estate. That is a classic non-human identity problem because the effective authority sits in service access, not in human review. Teams should treat policy artefacts as governed credentials for decision logic.

Zero standing privilege belongs in the authorization path as much as in the application path. The Lambda execution role, API invocation permissions, and bucket access should all be task-scoped and narrowly delegated. Long-lived broad access to any of those identities increases the blast radius of a compromise and makes policy tampering or unauthorized invocation easier to sustain.

Stateless policy engines still need stateful governance around change and review. Cerbos itself can be stateless at decision time, but policy updates, role mappings, and endpoint trust rules are not stateless operationally. That means recertification, offboarding, and change approval still matter for the identities that manage the authorization plane. The implication is simple: stateless runtime does not mean stateless control.

Fine-grained authorization is only defensible when the surrounding IAM model is equally fine-grained. If the same AWS identities can both deploy the PDP and alter policy content, the separation of duties is mostly cosmetic. Teams should align deployment, policy management, and runtime invocation as distinct access domains, or the architecture will inherit the same risks it was meant to solve.

From our research:

• 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.
• That gap is why teams should pair policy-as-code with lifecycle controls, as described in the NHI Lifecycle Management Guide.

What this signals

Policy-as-code only helps if the identities behind it are governed with equal discipline. When runtime authorization shifts into a separate service, the security programme has to account for policy writers, deployment roles, and calling services as distinct trust domains rather than a single application concern.

Policy supply chain: once authorization rules live in object storage, the change path becomes as sensitive as the runtime path. That means lifecycle events such as offboarding, role change, and emergency access revocation must extend to the identities that maintain the policy estate, not just the application teams that consume it.

The NHI Mgmt Group data shows the maturity gap is already material. With 88.5% of organisations saying their non-human IAM practices lag behind or merely match their human IAM, the separation between application code and authorization logic will only hold if governance catches up.

For practitioners

• Separate policy administration from runtime invocation Give the identity that writes policy files different permissions from the identity that runs the Lambda PDP. Keep S3 write access, Lambda deployment rights, and API invocation rights in distinct roles so one compromise cannot alter both policy and execution.
• Restrict the S3 policy path with versioned governance Use a dedicated bucket prefix for policies, enable versioning, and require change control for every update. That keeps policy drift visible and gives you a rollback point if an unauthorized or faulty rule change affects access decisions.
• Harden the API Gateway trust boundary Require JWT, IAM, mTLS, or equivalent authenticated access before a client can query the PDP. Publicly reachable authorization endpoints invite abuse, so the front door should be limited to trusted callers and monitored for unusual request patterns.
• Minimise Lambda execution permissions Allow the function only the S3 and CloudWatch permissions it needs to load policies and emit logs. Avoid broad logs and storage access because the execution role is part of the security boundary, not an implementation detail.
• Test authorization as a governed control, not a code feature Build policy tests, negative tests, and deployment checks into CI/CD so changes to rules are validated before they reach production. Authorization failures should be caught as policy regressions, not discovered during user access incidents.

Key takeaways

• Separating authorization from application code improves clarity, but it shifts risk onto the PDP, API gateway, Lambda role, and policy store.
• Policy files in S3 behave like governed access artefacts, so write access, versioning, and change audit become security controls, not housekeeping.
• Serverless authorization is only defensible when the identities that deploy, invoke, and modify it are kept in separate, tightly scoped roles.

Key terms

• Policy Decision Point: A policy decision point is a service that evaluates access requests against defined rules and returns allow or deny outcomes. In modern identity architecture, it centralises authorisation logic so applications do not each implement their own access rules, improving consistency and auditability when properly governed.
• Policy Supply Chain: The policy supply chain is the path by which access rules are written, stored, changed, and loaded into a decision system. It matters because whoever can alter the policy artefacts can change effective access, making storage, versioning, and change control part of the security model.
• Execution Role: An execution role is the non-human identity a runtime service uses to access other systems and resources. For serverless workloads, it defines what the function can read, write, and log, so overly broad permissions directly expand the blast radius of any compromise or misuse.
• Zero Standing Privilege: Zero standing privilege means access is not left permanently available. Privileges are granted only when needed and for a narrow task, which reduces the value of stolen credentials and limits the time window in which a compromised identity can alter policy or invoke control services.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: running Cerbos as a Lambda function with API Gateway and S3-hosted policies. Read the original.