Notifications
Clear all
Topic starter
11/06/2026 11:22 pm
TL;DR: Distributed systems need decoupled, context-aware authorization because service-to-service trust, on-behalf-of requests, and AI agents all expand the attack surface beyond user-centric IAM, making workload identity and policy enforcement essential, according to Cerbos. The key shift is that authorization now has to govern every non-human actor as a first-class identity, not just the user behind the request.
NHIMG editorial — based on content published by Cerbos: Zero Trust for Microservices: A Guide to Secure Authorization
Questions worth separating out
Q: How should security teams implement zero-trust authorization for microservices?
A: Security teams should evaluate every internal request with policy, not perimeter trust, and base decisions on the calling workload, the resource, and any delegated user context.
Q: Why do service-to-service permissions create lateral movement risk?
A: Service-to-service permissions create lateral movement risk because one compromised workload can reuse internal trust to reach other APIs, data stores, and control functions.
Q: What do security teams get wrong about AI agent access control?
A: Teams often secure the agent as if authentication alone is enough, but AI agents also need tightly scoped authorization for the actions they can initiate.
Practitioner guidance
- Separate authorization from application logic Place policy evaluation in a dedicated control plane so service code does not hard-code access decisions.
- Issue unique identities to every workload Assign each service, bot, and automation path a distinct workload identity and avoid shared credentials across tiers.
- Enforce on-behalf-of checks for delegated calls Require policies to evaluate both the calling service and the end-user context before a downstream action is approved.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- Example policy structures for service-to-service authorization in a decoupled control plane
- On-behalf-of policy logic that evaluates both workload identity and end-user context
- Implementation detail for AI-agent-specific policy restrictions and derived roles
- OpenTelemetry and audit logging examples for tracing authorization decisions
👉 Read Cerbos' analysis of zero-trust authorization for microservices and AI agents →
Microservices authorization gaps: what changes for IAM teams?
Explore further
12/06/2026 8:00 am
Perimeter-based trust is no longer a usable authorization assumption for distributed identity systems. Microservices architecture and AI-agent-enabled workflows both destroy the idea that internal traffic is inherently safe. Once a service or agent can initiate downstream actions, identity has to be evaluated at the request level, not the network level. The implication is that access control must move from location trust to explicit policy decisions for every internal actor.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when delegated service access exceeds user intent?
A: Accountability sits with the organisation that allowed the delegation model to bypass explicit policy checks. When a service acts on behalf of a user, both identities must be part of the authorization decision. If they are not, the resulting access is technically authenticated but governance-wise unsupported.
👉 Read our full editorial: Zero-trust workload identity for microservices and AI agents
