Ask a team which of their services can call which, and watch what happens. Somebody opens a diagram from last year. Somebody else says the diagram is wrong. Eventually a person who has been there longest explains that service C can technically call anything because it holds a shared secret from an old migration.

The reason this happens is that service-to-service trust is usually implicit: it is whatever the network allows, plus whatever credentials happen to exist. Nobody declared it, so nobody can read it back.

What SkipAuth does

Each application has exactly one registration: one client identifier and one secret, stored hashed. There are no per-integration credentials to accumulate.

Trust is a declared list. Each application carries a set of trusted audiences, and the direction is worth stating precisely, because half the confusion in this area is directional: if application A appears in B's trusted audiences, then A may mint tokens whose audience is B. Letting A call B is one entry. Withdrawing it is deleting one entry.

Two more properties make the graph readable rather than decorative:

Third parties are nodes too. An external service that is not yours can be registered as a placeholder application, so a call leaving your estate appears in the same graph as one that does not.
Service accounts inherit, they do not accumulate. A service account links to exactly one application and takes that application's outbound trust. There is no separate trust list per service account to drift, and a service account linked to nothing cannot mint a token at all.

Trust is enforced when the token is issued. The check happens where the token is issued: for a service-account caller, against the trust list of the application it is linked to, and for an application-context caller, against the target's list. By the time a token reaches the gateway it has already been vetted, so the gateway checks one thing only, that the token's audience matches the application it is protecting. There is no runtime graph traversal in the request path, which is why this costs nothing per request.

How to check it

Register two applications, A and B, with no trust between them.
Ask for a token as A with B as the audience. It should be refused.
Add A to B's trusted audiences. Ask again. It should succeed.
Present that token to a third application, C, through the gateway. It should be refused, because the audience does not match, even though the token is perfectly valid.
Create a service account, leave it unlinked, and try to mint anything. It should be refused for that reason specifically.

Step four is the one worth doing. A valid token that works everywhere is not an audience, it is a bearer password.

Where it stops

This is not a service mesh. It governs who may hold a token for whom. It does not do traffic shaping, retries, circuit breaking or mutual TLS between every pair of services. If you need those, you need a mesh, and this sits happily beside one.

It is a graph, not a policy. An edge means "may mint a token for". It does not carry conditions such as time of day, request attributes or rate. Those belong to a policy layer.

Rotation is manual. A secret can be rotated, and nothing rotates it for you on a schedule.

What the alternatives ask of you

Approach	What it asks of you	SkipAuth
Shared secrets per integration	Accumulate credentials nobody can account for, and rotate none of them.	One credential per application, and the integration is an entry in a list.
Network policy as the trust boundary	Reason about identity in terms of addresses, and accept that anything inside can call anything inside.	Trust is about the application, and it is checked when the token is minted.
A service mesh with an authorization policy	Run and version the mesh, and keep its policy in step with your identity system.	The gateway reads the same graph the token was minted against, so there is one source of truth.
Tokens with a wide audience	Hope no service presents a token where it should not.	The audience is narrow by construction and rechecked at the edge.