Architecture

Four parties, and the boundaries between them are the point. Each is a separate trust domain because in the case this profile exists for, they are genuinely separate — different organisations, different operators, different lawyers.

The owner's side

The authorization server holds Alice's policy and answers on her behalf. It dictates terms, decides tiers, issues grants, records connections, and keeps the ledger. It is the only component that speaks for her.

Her surface is where she writes terms, sees what has been asked, and revokes. In the lab that is a portal she signs in to, with her identity provider as the source of the token her authorization server checks when she approves something. It can equally be a personal AI holding her key, which authenticates with a signature instead of a login — the authority accepts either, or both, and neither is a fallback for the other.

Either way the surface holds no authority of its own. It does not decide and it does not keep a record; it reaches the one thing that does, and a decision made through either surface lands in the same ledger.

See Put the authority on her device for what a surface actually has to provide.

The resource server's side

The resource is the thing being protected. In the lab it is a brokerage vault exposed as an MCP server, and it contains no authorization code at all.

The enforcement point is what refuses. It challenges unauthorized calls, verifies proof-of-possession, checks that a grant covers the tool being called, and burns single-use grants. It performs those obligations for an authority it does not hold: it enforces Alice's policy and must not be able to read or rewrite it.

That separation is what the suite tests hardest. In the deployed shape a service mesh enforces it rather than a document asserting it, and the suite proves it with a pair of assertions on the same port and the same workload — the enforcement point is refused Alice's policy, and allowed her published keys.

The requesting side

The requesting party is the human or organisation asking — Bob, the advisor. The client is the software doing the asking, usually an autonomous agent. Keeping them distinct matters: the terms are signed by the agent, the identity attested is the agent's, and the party who is accountable is Bob.

An agent may be pseudonymous, in which case it is its key and the connection is handled by that key's thumbprint, or identified through an agent identity protocol, in which case its continuity survives key rotation.

Neither has to be built into the agent. An adapter can hold the key and run the whole negotiation on its behalf, leaving the agent above it speaking ordinary MCP — which is what lets an agent framework nobody wrote for this be governed by the owner's policy without being modified. In the lab that adapter is the same process an individual runs beside their own MCP client, started as a network service instead of a subprocess.

Two planes

The grant plane is the negotiation: challenge, terms, agreement, grant. It is binding-independent — the same four beats carry over MCP, over HTTP, or over anything else that can return a challenge and carry a token.

The data plane is the authorized call. This is where the enforcement point verifies the signature, checks the operation binding, and spends the grant.

Keeping them apart is what lets one enforcement core run in two places. The lab ships it as a gateway callout and embedded in the resource, and make embedded-check proves the two reach identical verdicts from the same implementation. make k8s-embedded-check proves the narrower version: both shapes running at once against one authority, with a service mesh, a waypoint and namespace boundaries all still between them. No enforcement hop, same grant.

What is deliberately absent

No secret the resource server must share with an authority nobody provisioned it against: it introduces itself by a key published at its own origin, and the owner approves it once, which is how it reaches Carol's authority. A provisioned client secret is a deployment's option where one party did configure both ends, as the reference does for Alice's (UMA_AS_RS_CLIENT_SECRET). No static owner credential. No path by which the resource server can read the owner's policy. Those absences are the architecture; the rest is arrangement.

How the absences are proved

An absence is a claim like any other, and it is the kind that quietly stops being true. So the lab asserts them from the outside, in a suite that runs from the requesting party's own namespace:

make k8s-policy-test

Eleven assertions, and eight of them are refusals. From where Bob's agent runs, it cannot reach the owner's authorization server, her policy, her portal, her database, the identity provider, another owner's authority, another owner's policy, or either vault behind the gateway.

The sharpest pair is two assertions against the same port on the same workload: the enforcement point can read her published keys, because it must verify what she signed, and cannot read her policy. That is the whole cross-principal argument reduced to something a test can fail on — an enforcement point that enforces a policy it is refused permission to read.

A suite that only proves the allows would pass on a cluster with no policy at all, which is why these are written the way they are. What each assertion covers and what to expect is in Run the lab.