Service-to-service authorization exposes the next NHI governance gap

At a glance

What this is: This article explains service-to-service authorization as a way to assign identities to software services so they can make access decisions without relying on the original user context.

Why it matters: It matters because IAM, IGA, and platform teams have to govern service identities, policy scope, and downstream access decisions as part of the NHI estate.

Context

Service-to-service authorization, also called machine-to-machine authorization, is the control layer that lets software services decide what other services may do when the original user context is missing or no longer relevant. In microservice architectures, that shifts access control from a single application boundary to many service identities and API interactions.

That creates a governance problem for IAM teams because the calling service, not the human requester, becomes the actor that receives rate limits, logs, monitoring, and permissions. Once services interact across teams and external APIs, non-user principals need lifecycle, scope, and policy controls that are consistent enough to audit but flexible enough to support distributed delivery.

Key questions

Q: How should security teams govern service-to-service access in microservices environments?

A: Security teams should govern service-to-service access by tying each allowed path to verified workload identity, not to IP addresses, namespaces alone, or static secrets. The practical pattern is default deny first, then explicit allow rules that scope both the caller and the operation. That makes access review possible and reduces hidden trust between services.

Q: Why do service identities need separate controls from user identities?

A: Service identities need separate controls because downstream systems often cannot see the original user context, especially in background processing and chained API calls. If teams keep applying user-centric rules everywhere, they lose the ability to tune permissions, throughput, and auditability for the actual calling service.

Q: What breaks when service-to-service access is managed inside each application?

A: When service-to-service access is managed inside each application, policy fragments quickly across teams and environments. That creates inconsistent permissions, weak auditability, and difficult offboarding because no shared control plane tracks which service can call what, or who owns the decision.

Q: How do organisations know if service principal governance is working?

A: Service principal governance is working when every non-user identity has clear ownership, policy is versioned and tested, and downstream logging can distinguish service activity from end-user activity. If reviews cannot trace a permission back to a named service owner, the governance model is incomplete.

Technical breakdown

How service identities change authorization in microservices

In monolithic systems, authorization usually hangs off one identity path and one codebase. In microservices, a request can pass through an API gateway, background worker, and downstream service before any human context remains available. At that point, the service itself becomes the principal, so the authorization decision must evaluate the calling workload, not just the end user. That is why service-to-service authorization is more than a routing detail. It is the mechanism that preserves identity-aware controls when systems are decomposed across teams and deployment boundaries.

Practical implication: model service identities explicitly in policy and logging instead of assuming the user session will still exist downstream.

Why non-user principals are used for rate limits and policy scope

Non-user principals let teams apply controls to the service that is actually consuming capacity or requesting action. That matters because a downstream service may need different throughput, monitoring, or permission scope for billing emails, transcripts, or internal workflows than for generic requests. The article also shows why a service identity can be used to distinguish broad classes of callers, such as internal services versus external integrations. The core technical idea is that identity is attached to the software component, so policy can follow the component across requests.

Practical implication: separate service-level limits and permissions from user-level controls when a downstream API is shared by many producers.

How policy-as-code supports distributed authorization

The article describes authorization policies stored as code and evaluated consistently across services, including sidecar and serverless deployment patterns. That matters because distributed systems fail when policy lives in one service but enforcement happens in many. Policy-as-code makes the decision logic reviewable, testable, and reusable across services that all call the same authorization layer. It also reduces the drift that appears when each team invents its own rules for the same non-user principal class. In effect, the policy repository becomes the control plane for service access.

Practical implication: centralise service authorization rules in versioned policy so enforcement stays consistent across every microservice.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Service-to-service authorization turns non-user principals into a governance domain, not a code pattern. The article is really describing the point at which distributed architecture forces IAM, IGA, and platform teams to govern software services as identities with scope, lifecycle, and observability requirements. Once a service can call another service directly, the question is no longer only whether the human user is authenticated. The real question is what the calling workload is allowed to do, and who owns that decision over time.

Coarse-grained service identity is the right abstraction when user context disappears. In background processing and downstream calls, the original requester is often absent, so user-centric authorization breaks down. That makes non-user principals the operational boundary for rate limiting, logging, and permissioning. Teams that keep forcing user context into every downstream decision will overfit the model and miss the governance surface created by machine-to-machine access.

Service account sprawl is the hidden cost of autonomy between teams. The more independent service teams are, the more likely they are to create their own identities, permissions, and exception paths. That is not just a technical scaling issue. It becomes an access governance issue because every additional service principal adds review, ownership, and policy maintenance work that traditional user IAM processes were never designed to absorb.

Policy-as-code is now a control requirement for distributed authorization, not a convenience. When service permissions are embedded in application logic or scattered across teams, the organisation loses consistency and auditability. A shared policy layer makes service authorization testable and reproducible across environments. Practitioners should treat that as the architectural baseline for service identity governance, not as an optional optimisation.

Non-user principals need the same lifecycle discipline as human access, but with different failure modes. Services do not leave the company, yet they still change role, ownership, dependency, and privilege over time. That means offboarding, scope reduction, and exception review need to exist for service identities even when the underlying workload never stops running. IAM teams should govern service principals as durable NHI assets with explicit accountability.

What this signals

Service principal governance: the control boundary is shifting from the user session to the calling workload, which means IAM teams need ownership, policy scope, and auditability for every service identity. If a downstream service cannot tell which workload is calling it, the organisation cannot reliably govern least privilege across teams.

Distributed systems expose a simple fact: rate limiting, logging, and authorisation only stay meaningful when they are tied to the actor that actually consumes the resource. For practitioners, that means service-to-service policy needs to sit alongside human IAM, not underneath it.

For practitioners

• Define service principals explicitly Create a distinct identity for each service or integration that makes downstream calls so policy can distinguish callers, owners, and allowed actions.
• Separate user and service authorization paths Review where downstream decisions still rely on the original user context and move those checks to the calling service when the user is no longer present.
• Centralise policy as code Store service authorization rules in version control and test them before deployment so every service evaluates the same decision logic.
• Tune rate limits by service criticality Apply throughput and abuse controls to the service principal rather than only to the human user when many callers share the same downstream dependency.
• Assign ownership to every service identity Map each non-user principal to a business or platform owner so access reviews, exception handling, and retirement are not left ambiguous.

Key takeaways

• Service-to-service authorization is an NHI governance problem as much as an architecture pattern, because the calling service becomes the identity that matters for access decisions.
• The article shows that distributed systems need service-level controls for authorization, rate limiting, logging, and monitoring when user context is not available.
• IAM teams should treat non-user principals as governed assets with explicit ownership, policy-as-code, and lifecycle review.

Key terms

• Non-user principal: An identity assigned to a service, workload, API, or other machine actor rather than a person. It lets organisations govern machine behaviour directly, including authentication, access control, logging, and revocation, instead of inferring trust from the human who started the workflow.
• Service-to-service authorization: The process of deciding what one application or service is allowed to do when it calls another. In practice, it requires machine-specific policy, not just user authentication, so downstream systems can distinguish one workload from another and enforce least privilege consistently.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Downstream service: A downstream service is a system that receives requests from another service after the original user context may already be lost. In distributed systems, downstream services often need to trust the calling workload’s identity more than the end user’s session state.

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 building or maturing an IAM programme, it is worth exploring.