A platform replaces network-level trust with per-request authorisation - every call to every internal service is checked against a central policy service. Security is satisfied. What has the platform given up, and when does that bill arrive?

What is gained, quantified

A compromised host no longer inherits access from its network position, so lateral movement stops being free. Access decisions become auditable per request rather than inferred from firewall rules written years ago. Policy changes take effect in seconds instead of a change window. For an organisation whose realistic threat is an attacker inside the perimeter, which is now most of them, this is the correct direction.

What is paid

Availability. Every service call now depends on the policy service. If it is 99.9% available and sits in the path of a request chain five deep, the chain inherits roughly five times its unavailability. A policy service that is down does not degrade the platform; it stops it. A component that was advisory has become a hard dependency of everything.

Latency. A remote policy decision adds a round trip, typically 1 to 5 ms in-region, to every hop. On a five-hop chain that is 5 to 25 ms added to every request, which is material for anything with a sub-100 ms budget.

Cost at rate. A platform doing 100000 requests per second internally now does 100000 policy evaluations per second. That is a large fleet whose only output is yes or no.

Blast radius of policy itself. The mechanism that distributes policy in seconds distributes a mistake in seconds. A bad policy push is now capable of denying all traffic everywhere, which the old firewall rules were too slow and too fragmented to do.

When the bill arrives

• At the first policy service incident, which is the moment the organisation learns whether it built a fail-open or fail-closed system, and whether that choice was deliberate.
• During a region failover, when the policy service in the surviving region has not been sized for the whole load, or its data has not been replicated.
• When the first latency-sensitive workload arrives and the per-hop cost is discovered to be non-negotiable.
• On the day a policy change is wrong, and the rollback path is the same push mechanism that is currently denying access to the people who would roll it back.

How to keep the bill affordable

1. Decide locally, distribute globally. The enforcement point evaluates policy in-process from a locally cached policy bundle, and the central service distributes bundles rather than answering per request. Latency falls to microseconds and the central service leaves the request path.
2. Accept bounded staleness deliberately. Cached policy means a revocation takes as long as the bundle refresh, typically 30 to 60 seconds. Write that number down; it is the security property you have traded for availability.
3. Keep a break-glass path that does not depend on the policy service, with its use alarmed rather than prevented.
4. Stage policy pushes like code, with a canary set of enforcement points, because policy is now code with global reach.
5. Short-lived credentials for the revocation you cannot wait for, so the worst case is bounded by token lifetime rather than by cache refresh.

When the simpler model is still right

For a small estate with a handful of services and one team, network segmentation plus service-to-service authentication achieves most of the benefit with none of the availability coupling. The per-request model earns its cost when the number of services and identities makes network rules an unmaintainable approximation of intent, and when an auditor needs per-request evidence rather than a topology diagram.

When not to centralise the decision at all

If revocation within seconds is not actually required - and for most internal service-to-service calls it is not, because a compromised workload's credential expires in minutes anyway - a central decision per request is buying a property nobody needs at a price everybody pays.