Who should own authorization policy decisions in a serverless platform?

Why Authorization Ownership in Serverless Cannot Be Left to Individual Functions

Serverless platforms make authorization ownership deceptively easy to fragment. Individual functions can be deployed quickly, but the policy decision itself still has to reflect application intent, data sensitivity, and operational risk. When that responsibility is pushed into each service team, policy drift follows: one function allows broad access, another hard-codes exceptions, and neither is governed as a whole. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of blind spot that weakens serverless authorization governance.

The practical owner should be the team that can see both the platform controls and the application’s trust boundaries, usually platform or identity engineering in close partnership with application developers. That ownership model is not about centralising every decision forever; it is about ensuring the policy schema, attributes, and relationships are defined once and enforced consistently. For baseline control design, NIST Cybersecurity Framework 2.0 remains useful for mapping accountability, while Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs explains why lifecycle control must stay coordinated across the environment.

In practice, many security teams discover ownership gaps only after a function has already been granted more access than anyone intended.

How Policy Decision Ownership Works in Practice

In a serverless environment, ownership should be split between policy authorship and policy use. The owning team defines the decision model: what attributes matter, what relationships are trusted, which resources are in scope, and what “allowed” means for a given workload. Application teams then supply the context the policy needs, such as function identity, tenant, request type, environment, and data classification. That separation prevents each team from inventing its own access logic while still preserving business-specific nuance.

A workable pattern is to keep authorization decisions outside the function code and evaluate them at request time. That means using a central policy engine, version-controlled policy-as-code, and a review process that treats changes like production security changes. NIST guidance on access control is relevant here, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, because it frames access enforcement as a control objective rather than an implementation detail. For NHI governance context, Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps explain why ownership and evidencing need to be traceable.

• Define one policy schema for the platform, not one per function.
• Let the platform or identity team own policy logic and change control.
• Require application teams to contribute business context and test cases.
• Evaluate authorization centrally so enforcement remains consistent across workloads.
• Review exceptions as formal policy decisions, not code-level shortcuts.

This guidance tends to break down in highly dynamic multi-tenant environments where teams cannot reliably supply consistent attributes or where legacy event paths bypass the central decision point.

Where Shared Ownership Becomes a Governance Risk

Tighter central ownership often increases review overhead, requiring organisations to balance consistency against delivery speed. That tradeoff is real, but it is still preferable to fragmented decision-making, because serverless teams move fast and can unintentionally create policy sprawl. Best practice is evolving, yet there is no universal standard for handing every authorization decision to a single security group; the better model is accountable ownership with distributed input.

Edge cases matter. Some teams only need to approve coarse-grained access at the platform level, while others need per-tenant or per-data-domain rules that change frequently. In those cases, the owner should still control the policy framework, even if subject matter experts contribute rule content. The risk is greatest when developers embed conditional logic directly into functions, because that makes review, testing, and revocation far harder. NHI Mgmt Group’s research also shows why this matters operationally: 97% of NHIs carry excessive privileges, a reminder that loose ownership almost always becomes excess access.

For teams formalising this model, the right question is not who writes every rule, but who is accountable for the correctness, reviewability, and enforcement of the policy system. That accountability should remain with the platform or identity function, with application teams acting as informed stakeholders rather than unilateral policy owners.

Related resources from NHI Mgmt Group

• Who should own authorization policy decisions in a modern application stack?
• Who should own centralized authorization policy decisions?
• Who should own authorization policy in a healthcare platform?
• Who should own authorization policy for workflow systems: IAM, app teams, or platform teams?