Authorization for non-human identities (NHIs) with Cerbos

We recently launched a new use case all around authorizing non-human identities (NHIs). In this blog, we’ll dive deeper into the topic of NHIs - what they are, why securing them is important, along with how Cerbos can be used to effectively authorize NHIs.

What are non-human identities?

Securing applications is not just about authorizing users based on their identity. Service-to-service calls, external API clients, AI agents, bots, and background jobs all act as independent workloads, with their own identities, all needing access to data and resources. These NHIs need to be authorized just like human users.

As was mentioned by OWASP on the topic of NHIs, without proper authorization, these workloads can become security risks, leading to over-privileged services, unauthorized data exposure, and compliance violations.

The difficulties with authorizing non-human identities

Authorizing workloads in distributed systems isn’t simple without a centralized solution. In such cases, each service might end up implementing its own authorization logic, and define implicit trust boundaries with dependent systems. Which creates inconsistencies and increases the risk of security gaps.

Developers need to decide how granular permissions should be and whether each service should offer its tools to manage these policies.

How to implement Cerbos for authorization of non-human identities

Authorizing NHIs and avoiding the above risks can be done in a more simple and secure way through the use of Cerbos, and authorization implementation and management solution. Let’s walk through the steps.

1. Define non-human identities

The logical first step to wrestling with this scenario is to issue a unique identity to each workload. This provides one of the key components when adding in security layers - who is making the request? Projects such as SPIFFIE manage the lifecycle of these identities which can be global to the service, or be more nuanced based on the deployment or fully dynamic based upon the upstream identity making the original request.

These identities are passed in API requests and used to determine authorization decisions.

2. Write policies for non-human identities

Cerbos policies define who can do what, including non-human identities. A policy for an internal service might look like this:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
 version: default
 resource: payment_service
 rules:
   - actions: ["read", "write"]
     effect: EFFECT_ALLOW
     condition:
       match:
           expr: P.id == “spiffe://example.org/ns/default/sa/payments”

This ensures that only internal services can access the payment system.

3. Deploy Cerbos in your architecture

Cerbos supports multiple deployment models:

• As a sidecar: Low-latency authorization next to your service
• As a centralized PDP: Single-point policy evaluation
• On serverless (Lambda): Lightweight, cloud-native decision-making

Each deployment keeps policies synchronized across environments, ensuring that every decision is consistent and up to date.

4. Query Cerbos for authorization decisions

Your services send authorization requests to the Cerbos Policy Decision Point (PDP). For example:

{
 "principal": {
   "id": "spiffe://example.org/ns/default/sa/payments",
   "roles": ["internal_service"],
   "attributes": {
     "service_type": "internal"
   }
 },
 "resources": [
   {
     "resource": {
       "kind": "payment_service",
       "id": "invoice-456"
     },
     "actions": ["read", "write"]
   }
 ]
}

Cerbos evaluates the request and returns an ALLOW/DENY decision in milliseconds.

Benefits of securing non-human identities with Cerbos

So why and how does Cerbos make such a difference when handling non-human identity authorization?

With Cerbos, access policies are stored in a single repository. This means no more hardcoded logic inside application code, version-controlled & testable policies, and easy updates without redeploying services.

Cerbos lets you enforce attribute-based access control (ABAC), role-based access control (RBAC), as well as policy-based access control (PBAC) for non-human identities. You can create policies based on service identity and purpose, API endpoints or resources being accessed, security posture (e.g., does this service have MFA enabled?), custom conditions unique to your application, and so on.

Instead of every workload handling authorization independently, Cerbos acts as a central policy decision point (PDP). Services request authorization decisions from Cerbos via API, Cerbos then evaluates policies in milliseconds. There’s no need for each workload to store or manage its own access control logic.

Finally, each Cerbos PDP instance records detailed audit logs for every decision made. When collected by Cerbos Hub, all the logs are centralized, making it easy to manage and analyze them from a single pane.

Get started

If you’re interested in authorizing non-human identities - try out Cerbos. And if you’d like to find out more, feel free to book a call with a Cerbos engineer.