Enforcement scattered across services drifts
When every service implements its own authorization checks in its own code, consistency depends on every team applying the same standard correctly, and staying in sync as that standard evolves. In practice, this drifts: one service's check is slightly stricter than another's, a policy update reaches some services faster than others, and the actual enforcement across the system stops matching any single, coherent policy.
A service mesh addresses this by moving cross-cutting concerns — including, often, authentication and authorization checks — into a shared infrastructure layer that sits alongside every service uniformly, rather than inside each service's own code. A policy change applied at that layer takes effect everywhere the mesh covers, without requiring every team to update their own implementation separately.
Centralizing enforcement also centralizes the risk
The tradeoff is that the mesh's own configuration becomes a single point that affects everything behind it — a misconfigured mesh policy is a mistake made once that impacts every service simultaneously, rather than one service's isolated bug. This is generally still a better risk profile than scattered, drifting enforcement, but it changes what needs the most careful review: the mesh's own policy configuration becomes the highest-leverage place a mistake can happen.