Permission belongs to the key, not the service

Most credential stores are organised by service. One entry for the search API, one for the image API, one for the payment provider. It reads naturally, and it is wrong the moment you have two accounts on the same provider.

"The agent may use the company account; the build service may not" is a sentence one-key-per-service cannot express. A broker that cannot express it will, by default, hand out whichever key it has — usually the more privileged one, because that was the one that worked when someone was setting things up in a hurry.

Labels

So a service holds any number of keys, each under a label. The default label is addressed bare — a request to the search service reaches the key labelled default. A second key under the label personal is addressed with the label appended to the service name. Each label carries its own list of permitted callers, its own per-minute rate limit, and, if you want it, a narrower set of allowed endpoints than the service permits in general.

That last one only narrows. A key block that tries to allow something the public catalogue does not is refused when the service starts, not discovered when a request fails at an inconvenient hour.

One string, everywhere

The label is the same string in every place it matters: the first segment of the request path, the key in the policy table, the key in the secrets table, the name of the rate-limit bucket, and the upstream field of the audit line. There is one place that builds that string and no second place that could build it differently.

This is not tidiness. It is the property that no call can be served by one key and attributed to a different one. When a provider's invoice arrives, the audit log says which account each call used, and the answer is trustworthy because it could not have been otherwise.

The read-only key and the read-write key

The clearest use is the case where the same API has very different consequences depending on the token. A read-only token for the platform lets an agent inspect configuration and can leak at the cost of a rotation. A read-write token for the same API can delete production. They are the same service, two keys, two labels, and the agent's user appears in the caller list of exactly one of them.