Zero trust finally reaches the API layer

Zero trust has spent a decade as a slogan and several years as a network architecture. What it has rarely been, until now, is a property of the API layer, which is strange, because that is where the assumption it attacks lives most comfortably.

The assumption is simple and everywhere: traffic that made it past the perimeter is friendly. Inside most estates, services call services with credentials that never expire, on networks that equate reachability with permission, logging just enough to prove the call happened and nothing about whether it should have.

The caller is a service now

Zero trust's principle, never trust, always verify, was framed for users and devices. But the overwhelming majority of calls in a modern estate are made by software: services, jobs, partners' systems. Applying the principle there means every call carries a verifiable identity, every authorization is evaluated per request against policy, and no privilege exists merely because two systems share a subnet.

A network location is an accident of deployment. An identity is a decision. Zero trust is the discipline of only trusting decisions.

Why the network was never the control

The network-as-perimeter model made a quiet substitution that seemed reasonable at the time: it treated "can reach" as a proxy for "is allowed." For a while that worked, because the two mostly coincided, the systems that could reach each other were the ones meant to. Cloud, microservices, partner integrations, and remote work dissolved that coincidence completely. Reachability is now a function of topology and convenience, and it says nothing at all about permission.

Once you see that, the internal API becomes the obvious place the control belongs, because it is where the actual decision, should this caller be allowed to do this, has to be made regardless. An authorization check at the point of the call does not care whether the caller is inside the network, in another region, or on a partner's infrastructure. It asks the only question that matters, every time, and it does not fall back on the accident of who happens to be able to connect.

Where to actually start

• Kill the shared secrets: service credentials that are issued per consumer, scoped narrowly, and rotated automatically. The 2019 API key in a config file is your most likely breach.
• Authorize at the gateway, per request: policy evaluated where the traffic flows, not assumed from topology.
• Record the decision, not just the call: when something goes wrong, "was this access supposed to be possible?" is the question. Your logs should answer it.

None of this requires a grand program with the words "zero trust" in its title; those tend to produce steering committees. It requires treating internal APIs with the suspicion external ones have always earned. The perimeter died years ago. The API layer is where the estate finally gets to stop pretending otherwise.