In ultra distance trail running you have a choice in what shoes to wear. Either you wear water proof shoes, generally Goretex, or you don't and allow your feet to breathe. It's a trade off you make. If you choose not to wear the waterproof shoes and you step in a puddle about an hour into a 10 to 15 hour race, issues arise. Along with wet feet being uncomfortable, friction becomes a problem. The friction between your sock and the sole of your foot reduces and your socks start to rub against them. Within a few hours you start to lose skin.

The pain is difficult to describe, it's not excruciating but it's constant. A discomfort that you can ignore initially. But eventually it becomes the centre of your world. Every step you take drives you closer to the brink of quitting.

Why did I do this Godforsaken run? No one will care if you stop. I might do permanent damage to my foot. Finishing this race won't bring her back.

Your mind tries to find any excuse that could justify stopping.

Why can some of us endure this and some of us not? This is a question I have been thinking about a lot recently. Eighteen months ago I hadn't run more than 10kms in my life. I hadn't pushed myself particularly hard in any facet for a while really. And now I am here. What changed? What hardened my resolve that allowed me to get to where I am now?

I have always been terrified by the thought that we might never really be in control of who we become. We make decisions based on the people we are, but we did not choose much of what made us this way. I find it difficult to stop that thought from becoming something more pervasive: what if we could see the person we wanted to become, sincerely want to change, and still spend our lives unable to get there?

That fear is still with me. I have achieved things I would have considered impossible for me a short while ago, and I still question whether I can change. I thought those achievements would have settled the matter. But honestly, they have not.

The question also follows me into considerably less dramatic settings.

For example, my arch nemesis in the gym is mobility work. Almost every time I go, I have an internal conflict for at least ten minutes about whether I should do some stretching after completing a lovely arm day with the lads.

The lads

Generally, I don't do it. I know why I want to do it. I still leave it out.

But occasionally, I just decide I do not have the option, and do it. I think what happens on those occasions is that I stop asking whether I feel like it. I have already decided I want the benefit. For once, I let that decision survive the predictable discovery that I would rather leave.

While I am doing it, it feels inconsequential. But over time I can feel the cumulative benefit. There is also the small fact that I did something I usually talk myself out of. That gives me something to remember the next time the argument starts.

This is where I believe grit lives. We notice it in the person still moving twelve hours into a race, or the people on stage talking about the future of the world, but perhaps much of it is developed on ordinary days. The runs when we are tired. The late nights working when we are alone. Small decisions, made repeatedly, with nobody particularly interested in whether we make them or not.

I still skip the stretching. I am reluctant to claim a permanent change in character on the strength of occasionally doing something I had already planned to do. But the next time I tell myself I cannot change, there is that small, inconvenient exception.

I do not want to believe grit is something some of us have innately. I don't think there is much use in believing so anyway.

Maybe it's that simple, we get some practice at doing things we doubt we can do or hate to do. Sometimes they go badly. Sometimes we discover that we were capable of more than we thought. Either way, we have something more to go on the next time.

We may still have doubts about where we are going and whether we will get there. But there is enough we can do today to make trying worthwhile. And if it is the case that we can not really change the outcomes of our destinies. There is no harm in trying.

A detour from The Agent Authorization Standard We Already Had, for anyone who nodded along at "JWT" and hoped nobody would ask a follow-up question.

JSON Web Tokens show up in almost every conversation about agent identity and authorization. Then, almost immediately, people start using "JWT," "access token," "identity," and "authorization" as if they are the same thing. They are not. A signed blob appears, everybody relaxes, and authorization is taken for granted as everyone quietly pretends they know how it works.

This is a short refresher for the rest of us who want to stop pretending. I am not going to turn this into a cryptography lecture. I just want to make sure we agree on what is inside a JWT, what the signature proves, and what the resource server still has to decide for itself.

We are often quite fast and loose with the term "body" when referring to what's inside a JWT. The more precise term is the JWT payload, or JWT Claims Set. It's the JSON object containing the claims conveyed by the token. That's it.¹

Also remember that an OAuth access token is not always a JWT. This piece applies when the authorization server issues a JWT, specifically the signed compact form commonly carried as a bearer token.

The Three Parts

A signed JWT using the JSON Web Signature (JWS) Compact Serialization normally appears as three base64url-encoded values separated by periods:²

BASE64URL(header).BASE64URL(payload).BASE64URL(signature)

Base64url encoding makes the value safe to transport in URLs and HTTP headers. It does not encrypt the content. Anybody holding a normal signed JWT can decode its header and payload. The signature protects integrity and helps the recipient verify who issued it.

Base64 has spent decades being mistaken for encryption and seems unlikely to correct anyone now.

1. Header

The header describes how the token was secured:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth-key-2026-09"
}

• alg identifies the signing algorithm. The recipient must verify that it is one the application accepts.
• typ indicates that the object is a JWT. It is commonly present but optional.
• kid is a key identifier that helps the recipient select the correct public key for signature validation.

2. Payload, or JWT Claims Set

This is the part we spend most of the article discussing. Here is a decoded example of the token the coding agent presents to the deployment MCP:

{
  "iss": "https://auth.example.com",
  "sub": "nadia",
  "aud": "deployment-mcp",
  "iat": 1760000000,
  "exp": 1760000900,
  "jti": "at-123",
  "scope": "deploy.production",
  "act": {
    "sub": "coding-agent",
    "act": {
      "sub": "personal-assistant"
    }
  }
}

• iss identifies the authorization server that issued the token.
• sub identifies Nadia, whose authority is being exercised.
• aud identifies the intended recipient. The deployment MCP must reject a token not intended for it.
• iat records when the token was issued.
• exp records when it expires. These time claims use NumericDate values, measured in seconds since the Unix epoch.
• jti is a unique token identifier that can support logging or replay controls.
• scope limits the capability to deploy.production.
• The outermost act identifies the coding agent as the current actor. The nested act preserves the personal assistant as the previous actor.

You might see may_act in an earlier subject token to state that a particular agent is eligible to become the actor. It is not included here because the deployment MCP is the final resource in this example and is not being authorized to continue the delegation chain.

3. Signature

The issuer signs the base64url-encoded header and payload. In simplified form:

SIGN(
  BASE64URL(header) + "." + BASE64URL(payload),
  issuer-private-key
)

The deployment MCP validates that signature using a trusted key associated with the issuer. A valid signature shows that the protected header and payload have not been tampered with since the issuer signed them. It does not mean the request is automatically authorized.

A signed mistake is still a mistake. It simply has better provenance.

The deployment MCP must still validate the trusted issuer, intended audience, expiration, scope, current actor, and its own local policy. A token can be correctly signed and still be completely wrong for the resource receiving it. If you buy a ticket from Lufthansa, you can't just get on any plane at the airport that has Lufthansa written on it.

A JWT is a container for claims. The authorization decision comes from validated claims plus policy, not from the existence of the token itself.

The Part People Forget

A valid signature does not tell you whether the token belongs at your service, whether it has expired, whether its scope permits the action, or whether the current actor is allowed to exercise the subject's authority. It only tells you that the signed content has not changed and that it was signed by a key you associate with the issuer.

The payload is the important part of the token once its signature is verified! There we can get all of the information we need about what this token actually allows the client using it to do. That is how we can get spicy with the claims in the token!

That distinction matters even more in agent systems. A token can be perfectly valid and still represent the wrong user, the wrong agent, the wrong audience, or far too much authority.

References

• RFC 8693: OAuth 2.0 Token Exchange

Agents may be a new thing, but the way they authenticate with each other and with external services does not have to be.

This year has been all about agents, as I am sure you are aware. They are everywhere, and we are trying to use them for everything, from Outlook schedulers to incident response. As we go down this road, the conversation about tightening our controls on them becomes even more relevant. It seems every week we get another announcement about how AI will take over the world tomorrow. Predictably, this day has not yet come, and I am skeptical it ever will. But regardless, it might make sense to scope down what agents can do.

So, as agents change the way we work, the permissions we give them have to change too. The evolution is already familiar. First came the local agent with shell access and a bunch of API keys. God-level permissions on your laptop. Rudimentary, but extremely effective, which probably explains why I still see it more often than anybody would like to admit. ;)

The next step is isolation. Dump the agent in a container. Restrict the network. Give it a narrowly scoped GitHub token. Let one container pull the repository, persist only the required files, and let a second container with a headless coding harness go wild inside a smaller box. Again: rudimentary, but effective.

Eventually you arrive at OAuth 2.0, a convention that is as old as time by AI standards. This is normally where people start drawing complicated architecture diagrams and inventing new vocabulary. What these "experts" seem to miss is that a lot of the authorization model we need already exists.

For the sake of this article, let's define a case most of us high-minded tech people will understand. Meet Nadia. She uses a personal assistant agent to coordinate her development work. It can read requests from a chat Model Context Protocol (MCP) server (Slack) and delegate coding tasks to a coding agent (headless Claude). That coding agent can eventually call a deployment MCP server to get our beautiful code into the only real testing environment: PRODUCTION.

It Starts With 401 Unauthorized

Need a JWT refresher? A JWT Is Not Authorization covers the claims and signatures used below. Otherwise, the 401 awaits.

Nadia asks her personal assistant to handle a development request that arrived in Slack. Before it can decide what work to delegate, the assistant needs to read the conversation through the chat MCP server.

The assistant calls the endpoint without a usable token and receives this pretty rude response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://chat.example.com/.well-known/oauth-protected-resource"

It is not the server saying, "I will never love you, please stop texting me." It is saying: you need a token, and here is where you can go to try and get one.

RFC 9728 defines this protected-resource metadata pattern. Bear with me here. The client fetches the metadata, confirms that the returned resource exactly matches the resource it tried to access, discovers an authorization server it is willing to trust, completes the appropriate OAuth flow, and retries with a token created for that resource.¹

There is one important caveat: a 401 response does not magically create trust. An agent cannot blindly follow any authorization-server URL placed in a response. It still validates Transport Layer Security (TLS), resource metadata, issuer metadata, and its local trust policy. Discovery tells the client where to look. It does not tell the client who to believe. The client has to decide that for itself.

The endpoint now accepts a token, but that token has to say more than "Nadia is allowed."

Three Identities Are Hiding in the Request

The authorization model becomes easier to reason about if we stop saying "the agent's token" and ask three separate questions:

Subject:  Who owns the authority?
Actor:    Who is currently exercising that authority?
Audience: Where may that authority be used?

The personal assistant can act as itself:

{
  "sub": "personal-assistant",
  "aud": "chat-mcp",
  "scope": "messages.read"
}

That is fine when the work genuinely belongs to the machine. A bot posting its own health status does not need to pretend a human clicked the button.

The assistant can instead impersonate Nadia:

{
  "sub": "nadia",
  "aud": "chat-mcp",
  "scope": "messages.read"
}

This can still be tightly scoped. Impersonation does not automatically mean every permission Nadia has. The problem is that the chat MCP server sees Nadia and only Nadia. It cannot tell whether Nadia read the thread directly, whether her assistant did it, or whether somebody copied the token into a curl command at 02:00.

Or the assistant can act for Nadia through explicit delegation:

{
  "sub": "nadia",
  "act": {
    "sub": "personal-assistant"
  },
  "aud": "chat-mcp",
  "scope": "messages.read"
}

Now the token says two things at once: Nadia owns the authority, and the personal assistant is exercising it. The resource can preserve Nadia as the subject while applying different policy to the agent acting for her.

For delegation to work, the assistant needs its own identity and a way to prove it, the same way a human would. A client_id identifies a client registration, but it does not authenticate the agent by itself. The agent still needs a credential or another authentication mechanism before an authorization server can trustfully name it as an actor.

Exchange Authority Instead of Forwarding Tokens

Now, how do we get these delegated tokens we mentioned earlier? How does the agent get a token that retains Nadia as the subject but exists exclusively for the agent and what it is supposed to do? The answer has existed for a while.

RFC 8693 defines OAuth 2.0 Token Exchange, an HTTP and JSON protocol for asking an authorization server to validate one security context and issue a new token for another.²

The subject_token represents Nadia, whose authority is being exercised. The personal assistant authenticates as itself and can provide an explicit actor_token. The requested resource or audience says where the new token will be used, and scope says what it should permit there.

The authorization server validates Nadia's token, authenticates the assistant, and applies policy. Is this assistant allowed to act for Nadia? Is it allowed to access this resource? Is the requested scope appropriate? Only then does the authorization server mint a new token for the next boundary. Think of it like a power of attorney for humans. Your bank does a whole lot of stuff to make sure your cousin is actually your cousin when you want him to buy a house for you.

The agent does not crack open Nadia's token, change the audience, add itself as an actor, and sign it again. If an agent can mint its own trusted delegation evidence, you do not have delegation. As I said earlier, the agents are probably not going to take over, but this would be an unusually considerate way to help them if they were going to.

Assuming the authorization server is configured to issue a composite JSON Web Token (JWT) for delegation, the result can preserve Nadia as sub, identify the assistant in act, pin the token to the chat MCP server with aud, restrict it to messages.read, and give it a short lifetime with exp.

One audience. Bounded capability. Short lifetime. If that token leaks, another service checking aud should reject it, and it will be dead soon anyway.

This is usually where someone asks about the latency of all this exchanging. But a token exchange does not have to happen for every API call. If the assistant already holds a suitable, unexpired token for the same audience, it can reuse it while policy permits. The important boundary is a change in audience or authorization context. A chat token should not wander into the deployment MCP server just because both systems accept OAuth.

The Audit Record Finally Stops Lying

Without explicit delegation, the production deployment record might look like this:

principal=nadia
action=deploy_release

Technically true, in the sense that Nadia's authority was used. Operationally it is a flat-out lie, because Nadia did not perform the deployment.

With explicit delegation, the deployment system can record something closer to the truth:

principal=nadia
current_actor=coding-agent
previous_actor=personal-assistant
audience=deployment-mcp
scope=deploy.production
action=deploy_release

This is where agent identity becomes useful rather than decorative. The resource can distinguish Nadia acting directly from a coding agent acting for Nadia. It can apply different controls to different agents, block one actor without pretending Nadia herself is compromised, and reconstruct the path during the inevitable production incident.

Delegation separates ownership of authority from responsibility for exercising it. That sentence is a bit dry, but it is the entire point.

What This Standard Does Not Solve

RFC 8693 gives us delegation semantics, not a complete agent security architecture. It does not define how unrelated agent domains establish federation, a universal agent identifier, maximum delegation depth, user approval experiences, agent reputation, or a global mechanism that immediately revokes one agent's authority everywhere.

We still have to design the trust model and policy. In practice that means short-lived and audience-specific tokens, independently authenticated actors, local limits on delegation depth, complete audit records, and sender-constrained tokens when theft presents a material risk.

But compare this with where we started. A chat MCP server returned a 401 because Nadia's assistant needed a token. By the time an action reaches production, the deployment system can answer five useful questions:

Who owns the authority?       Nadia
Who is exercising it?         Coding Agent
Who acted previously?         Personal Assistant
Where can it be used?         Deployment MCP
What can it do?               deploy.production

AI agents may be new to the party, but delegation is not a new security problem. RFC 8693 already gives us a vocabulary for the subject, the actor, the permitted delegate, and the target. RFC 9728 gives an unfamiliar client a standard way to begin the authorization conversation. Agent-to-Agent (A2A) communication can carry the task, while OAuth carries bounded authority and MCP exposes capabilities behind explicit authorization boundaries.

The challenge is not inventing another token format. It is applying the authorization machinery we already have with discipline.

The feeling I get more and more these days is that the conversations we are having around agents feel increasingly familiar: boundaries, domains, responsibilities, and accountability. The safest agent systems may not be built on novel authorization technology, but on old authorization technology used precisely.

Optional Detours

This article stands on its own. The three below are detours, not homework. Pick whichever covers the part you want to poke at:

• A JWT Is Not Authorization explains headers, claims, signatures, and why a valid token is not automatically authorized.
• Who Is Actually Acting? goes deeper into act, optional may_act, and the distinction between subject and actor.
• The Task Travels. The Token Should Not. follows Nadia's task across multiple agents and resources without forwarding the original token.

References

• Model Context Protocol: Authorization Server Discovery
• Agent2Agent Protocol Specification 1.0

A detour from The Agent Authorization Standard We Already Had that follows the whole chain end to end, because one hop never got anyone paged.

Forwarding the token you already have is seductive. It is also how authority intended for one service quietly wanders into three others, how every action gets attributed to the user, and how an audit trail becomes a work of fiction.

So let's follow one task through the whole chain. Nadia remains the subject whose authority is being exercised. The current actor changes at each hop. The audience changes for every receiving service. The authorization server evaluates each exchange and creates a token for that boundary.¹

The examples use JWT claims because they make the delegation chain visible. The agents are not opening Nadia's token, changing the audience, adding themselves as actors, and signing it again. The authorization server does that work after validating identity and policy.

Follow One Development Task Through the Chain

Let's take a look at what might happen if we follow a whole dev task down a chain. It starts with Nadia being issued a token intended for her personal assistant:

Note: These examples show the claims in tokens minted by the authorization server at each boundary. The agents are not editing or re-signing Nadia's original token.

{
  "iss": "https://auth.example.com",
  "sub": "nadia",
  "aud": "personal-assistant",
  "scope": "development.coordinate",
  "may_act": {
    "sub": "personal-assistant"
  }
}

The personal assistant first needs the context from Slack. It authenticates as itself and exchanges Nadia's authority for a token intended only for the chat MCP:

{
  "iss": "https://auth.example.com",
  "sub": "nadia",
  "aud": "chat-mcp",
  "scope": "messages.read",
  "act": {
    "sub": "personal-assistant"
  }
}

The personal assistant reads the development request, decides that code needs to change, and exchanges Nadia's original authority for a separate token intended for the coding agent:

{
  "iss": "https://auth.example.com",
  "sub": "nadia",
  "aud": "coding-agent",
  "scope": "code.change",
  "act": {
    "sub": "personal-assistant"
  },
  "may_act": {
    "sub": "coding-agent"
  }
}

Where A2A Fits

In this example, the personal assistant could invoke the coding agent over A2A. The coding agent's Agent Card advertises its authentication requirements, but A2A does not replace the authorization model described above. With an HTTP-based A2A binding, the personal assistant still sends a token intended specifically for the coding agent in the Authorization header. When the coding agent later calls the deployment MCP, it exchanges that authority for a new token whose audience is the deployment MCP. A2A carries the task; OAuth carries the bounded authority.²

The chat-MCP token and coding-agent token are siblings. One is not forwarded into the other. The same user authority has been exchanged into two separate tokens, each with its own audience and capability (delegation).

The coding agent then does its thing and produces the production code and, because staging is for cowards, needs to communicate with the Prod deployment MCP. It does not forward the token it received from the personal assistant. It authenticates as the coding agent and exchanges the incoming authority for a new token intended only for deployment:

{
  "iss": "https://auth.example.com",
  "sub": "nadia",
  "aud": "deployment-mcp",
  "scope": "deploy.production",
  "act": {
    "sub": "coding-agent", // the current actor, not a ceremonial title
    "act": {
      "sub": "personal-assistant" // useful for audit, less useful as a scapegoat
    }
  }
}

The outermost act entry is now the current actor, and the nested entry is the previous actor. Continue nesting and the token carries a delegation history. It is bureaucracy, but at least it is useful bureaucracy.

There is a counter-intuitive rule here. RFC 8693 says authorization decisions should consider the token's top-level claims and the current outermost actor. Previous actors are informational only. Log the entire chain, but do not quietly turn the third agent in the history into an undocumented policy input.

The subject stays Nadia. The current actor changes. The audience changes. The scope changes to the minimum capability required at each boundary. This is what we wanted from the start: the development task travels, but the original access token does not.

The Audit Record Finally Stops Lying

Without explicit delegation, the production deployment record might look like this:

principal=nadia
action=deploy_release

Technically true, in the sense that Nadia's authority was used. Operationally it's a flat out lie, because Nadia did not perform the deployment.

With the delegated token, the deployment MCP can record:

principal=nadia
current_actor=coding-agent
previous_actor=personal-assistant
audience=deployment-mcp
scope=deploy.production
token_id=at-123
action=deploy_release

The policy can also distinguish between Nadia deploying directly and the coding agent deploying for Nadia:

Allow when:
  iss       = trusted authorization server
  sub       = Nadia
  act.sub   = Coding Agent
  aud       = Deployment MCP
  scope     = deploy.production

Deny:
  scope     = deployment.admin

This is where agent identity becomes useful rather than decorative. The deployment system can apply different limits to Nadia's personal assistant and coding agent, block one actor without pretending Nadia herself is compromised, and reconstruct the complete path during the inevitable production incident.

Delegation separates ownership of authority from responsibility for exercising it. That sentence is a bit dry, but it is the entire point.

This Is Not a Complete Agent Security Architecture

RFC 8693 does not define how unrelated agent domains establish federation. It does not define a universal agent identifier, a maximum delegation depth, an approval experience, agent reputation, task-specific permissions, or a global button that revokes one agent's authority everywhere immediately.

It gives us delegation semantics. We still have to design the trust model and policy. Which is something I fear many people are abstracting away too willingly these days.

In practice that means setting a maximum actor-chain depth, using short-lived and audience-specific access tokens, validating issuer, audience, expiry and scope, authenticating the actor independently during exchange, and verifying what the chosen authorization server actually emits.

Bearer tokens still have an obvious weakness: whoever holds one can usually use it. If token theft is a material risk, sender-constrained mechanisms such as Demonstrating Proof of Possession (DPoP)³ or mutual Transport Layer Security (mTLS)⁴ can bind the token to a key held by the intended presenter.

What I Would Implement First

If I were turning this example into a real system, I would start with four controls: one token per audience, short token lifetimes, independently authenticated actors during exchange, and audit records that store the full delegation chain. Then I would add local limits for chain depth and sender-constrained tokens where theft presents a material risk.

You do not need every possible agent-security mechanism on day one. You do need to stop forwarding broad user tokens and pretending that the user performed every downstream action.

But compare this with where we started. The chat MCP required Nadia's personal assistant to obtain a token. By the time the code reaches production, the deployment MCP can answer five useful questions:

Who owns the authority?       Nadia
Who is exercising it?         Coding Agent
Who acted previously?         Personal Assistant
Where can it be used?         Deployment MCP
What can it do?               deploy.production

AI agents may be new to the party, but delegation is not a new security problem. RFC 8693 already gives us a vocabulary for the subject, the actor, the permitted delegate, and the target. RFC 9728 gives an unfamiliar client a standard way to begin the authorization conversation. A2A carries the task from personal assistant to coding agent, while MCP exposes the chat and deployment capabilities behind explicit authorization boundaries.

The challenge is not inventing another token format. It is applying the authorization machinery we already have with discipline.

The conversations around agents feel increasingly familiar: boundaries, domains, responsibilities, and accountability. Apparently the future of AI still requires the same old arguments about who is allowed to do what. The technology changes quickly. The meetings remain remarkably stable.

The safest agent systems may not be built on novel authorization technology, but on old authorization technology used precisely.

References

• RFC 9728: OAuth 2.0 Protected Resource Metadata

A detour from The Agent Authorization Standard We Already Had, for the moment "the agent's token" stops being a good enough answer.

Agent authorization gets confusing because we keep calling everything "the agent's token." That phrase hides the exact questions the token needs to answer: whose authority is being used, which agent is exercising it, and where that authority is accepted.

This is the piece of OAuth delegation I wish more people discussed. Once you separate the subject from the actor, the whole model becomes much easier to reason about.

Subject, Actor, and Audience

If JSON Web Token claims are unfamiliar, I cover the header, payload, and signature in A JWT Is Not Authorization. Most of what follows lives in the JWT payload, or JWT Claims Set.

Bear with me here. The authorization model becomes much easier to reason about if we stop saying "the agent's token" and ask three separate questions:

Subject:  Who owns the authority?
Actor:    Who is currently exercising that authority?
Audience: Where may that authority be used?

If you buy a ticket for a Eurowings flight and try to use it to enter the Louvre, they are going to laugh at you. The ticket may be genuine. The audience is still wrong.

In Nadia's case, the same three questions produce three different token shapes. The examples below show only the relevant claims from each payload.

The personal assistant can act as itself, that is, with its own authority:

{
  "sub": "personal-assistant",
  "aud": "chat-mcp",
  "scope": "messages.read"
}

That is fine when the work genuinely belongs to the machine. A bot posting its own health status does not need to pretend a human clicked the button.

The personal assistant can impersonate Nadia, which is the case with many systems currently:

{
  "sub": "nadia",
  "aud": "chat-mcp",
  "scope": "messages.read"
}

This impersonation can still be tightly scoped. Impersonation does not automatically mean every permission Nadia has. The problem is that the chat MCP sees Nadia and only Nadia. It cannot tell whether Nadia read the thread directly, whether her personal assistant did it, or whether somebody copied the token into a curl command at 02:00.

Or, and this is where things get interesting, the personal assistant can act for Nadia through explicit delegation:

{
  "sub": "nadia",
  "act": {
    "sub": "personal-assistant"
  },
  "aud": "chat-mcp",
  "scope": "messages.read"
}

Now the token says two things at once: Nadia owns the authority, and the personal assistant is currently exercising it. act is the key here, and it is fundamental to the discussion we are going to have here.

A delegate cannot walk into a bank, announce that a friend sent them, and expect access to the savings. Banks remain oddly attached to proof.

Nadia's personal assistant faces the same requirement. It needs its own identity and a way to prove it. A client_id is not enough by itself. It identifies a client registration, but the client still needs a credential or another authentication mechanism to prove that it controls that identity.

That identity could be an OAuth client, a workload identity, or something based on a system such as SPIFFE. The specific mechanism matters operationally, but the logical requirement is simple: the agent must be able to prove that it is itself before an authorization server can name it as an actor.

act Tells Us Who Is Acting

The act claim is a central piece in this puzzle:

{
  "sub": "nadia",// nadia remains the primary authority
  "act": {
    "sub": "personal-assistant" // assistant working for Nadia
  },
  "aud": "chat-mcp",
  "scope": "messages.read"
}

The top-level token is about Nadia. The nested object identifies the personal assistant as the current actor. This is delegation in a form the chat MCP can inspect and log.

RFC 8693 also defines may_act. It makes a statement that a party is eligible to become the actor:

{
  "sub": "nadia",
  "aud": "personal-assistant",
  "may_act": {
    "sub": "personal-assistant" // personal assistant is allowed to assume act
  }
}

The easiest mental model I have found is this:

actor authentication = proves who the personal assistant is
may_act               = puts the personal assistant on the guest list
act                   = records the personal assistant in the visitor book

But beware: may_act is not mandatory, and I am not a huge fan. In many systems, this is better handled on the authorization server. An auth server can keep the same relationship in server-side policy, user consent, registered client relationships, or organizational rules. It becomes useful when the eligibility decision needs to travel inside a token to another trusted exchange service.

Neither claim grants a capability on its own. act identifies the actor. may_act identifies an eligible actor. Audience, scope, expiry, issuer, and authorization-server policy still do the actual work of bounding authority.

Why This Distinction Matters

Without act, the resource can identify Nadia or the personal assistant, but not both roles at the same time. With it, the system can preserve Nadia as the owner of the authority while applying actor-specific policy to the software performing the action.

may_act can make the eligibility relationship portable, but it remains optional. The authorization server can keep that decision in consent, registered-client relationships, workload policy, or organizational rules instead.

The important part is not adding more claims because claims are fashionable. It is giving the resource enough trustworthy context to answer a simple question: who is actually doing this?

References

• RFC 8693: OAuth 2.0 Token Exchange
• RFC 6749: The OAuth 2.0 Authorization Framework
• SPIFFE specifications

Recently, a friend of mine asked me to help him out with some architecture-testing libraries he is working on as part of ArchUnit. The idea is satisfyingly concrete: express architectural decisions as fluent assertions, then run them alongside ordinary tests. Boundaries, cycles, dependencies, all the things our diagrams promise the code will definitely respect forever. ;)

It also gave me a convenient excuse to explore tools I do not use every day, particularly OpenCode, and see what would happen if I pointed an unattended agent harness at a real engineering backlog.

I am lucky enough to work for a company that encourages us to stay at the cutting edge of frontier models. That is a genuine privilege. It can also become a vice. When the biggest and cleverest model is always within reach, using it for everything starts to feel less like a decision and more like the default setting.

At AWS, Leadership Principles guide how decisions are approached, and one of the most relevant here is Frugality:

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense. (Amazon Leadership Principles)

It is easy to discuss frontier models as if everyone has the same freedom to choose them. Many companies do not. They work with real financial constraints every day, and those constraints do not disappear just because the model at the top of a leaderboard is especially shiny. Constant access to frontier models can give those of us at the cutting edge a blind spot: we start optimizing for maximum capability before asking how much capability the task actually needs.

We humans have a wonderfully simple instinct when choosing AI models: find the biggest, cleverest one available and point it at everything. Architecture review? Biggest model. Rename a field? Biggest model. Reformat a table? You guessed it, summon the expensive oracle.

I understand the appeal. If you can speak to God, why chat to Einstein? Nobody wants to explain that the production incident happened because they tried to save twelve cents on tokens.

But there is another question hiding underneath all of this, and it became the question I really wanted to answer:

What is the least expensive model that can reliably clear the quality bar for the work in front of us?

That is model rightsizing. It sounds like something invented by a committee with a spreadsheet, but it becomes rather interesting once you let two very different models loose on the same real backlog.

ArchUnitDev gave me a way to try it. It is an unattended software-engineering harness that works through GitHub issues one by one. The same C# architecture-testing library was built twice from the same starting commit and the same 46-issue backlog. One run used DeepSeek V4 Flash. The other used Claude Opus 5.5 on Amazon Bedrock. Each model had to do the whole job: implement the feature, review the code, criticize the tests, check the idioms, and fix whatever its various personalities complained about.

Both builds landed 45 of 46 issues. Issue 44, publishing to NuGet, was held back because it needed credentials. Even agents should not be given publishing credentials simply because they asked nicely.

The interesting part is what the two journeys cost.

The Numbers, Because Eventually Someone Opens the Spreadsheet

The benchmark results at a glance. Both models landed 45 of 46 issues, with a 17.5 times difference in model spend.

Cumulative model spend by issue. Both runs landed 45 issues; issue 44 was deliberately held back.

Yes, you read that correctly. Both models reached the same backlog completion result, but Opus cost 17.5 times as much in model spend.

Before anybody runs off to replace every frontier model with DeepSeek and buys a small yacht with the savings, there is more going on here. Opus landed three more issues on the first attempt, abandoned fewer issues, used 44% fewer turns, and produced 55% fewer output tokens. It was more direct, needed less correction, and finished in a much shorter operating window.

So the frontier model was better behaved. It simply did not finish more of the backlog.

For this particular workload, the premium bought efficiency and reliability rather than a different final outcome. That distinction is the entire article.

The Opus premium bought a smoother journey, not a different destination.

Rightsizing Does Not Mean Being Cheap

Let us get one thing out of the way: model rightsizing is not selecting the cheapest model and hoping that positive thinking will carry it through production.

Rightsizing means matching the model to the task, surrounding it with suitable controls, watching what happens, and escalating when the evidence says the first choice is out of its depth. Think of it less like finding one champion model and more like assembling a mildly eccentric toolbox. Sometimes you need the huge power drill. Sometimes you need the little screwdriver that costs almost nothing and does the job perfectly well.

ArchUnitDev was unusually well suited to this approach. Every issue was bounded. The repository contained explicit architecture and style rules. A deterministic gate compiled the code and ran formatting, tests, vulnerability checks, and cross-platform checks before a model reviewer was allowed to have an opinion. Three read-only critics then looked at correctness, test strength, and idiomatic conformity. Invalid verdicts failed closed. Findings went back into repair rounds, and work that did not converge was parked instead of being quietly waved through.

In other words, the model was not wandering through the codebase alone at night with a flashlight and good intentions.

The harness turned mistakes into visible, recoverable events. DeepSeek could afford to take more turns because every turn was inexpensive, while the surrounding machinery stopped an inexpensive mistake from becoming an inexpensive production incident.

This leads to the important bit: the model capability you need depends partly on the strength of the system around the model. A frontier model can compensate for vague instructions and weak verification, but using intelligence as a substitute for engineering discipline is quite an expensive hobby.

Chinese Open-Weight Models Are No Longer Sitting at the Children's Table

DeepSeek is operated by Hangzhou DeepSeek Artificial Intelligence Co., Ltd., which identifies its registered address as being in China. Its official V4 release describes DeepSeek V4 Flash as a Mixture-of-Experts model with 284 billion total parameters and 13 billion active parameters. So, despite being the cheaper option here, it is not exactly a small woodland creature.

The model is positioned for fast and economical agentic workloads, and its weights are published under the MIT license. DeepSeek also publishes its own benchmark results, although vendor benchmarks should always be consumed with the same healthy skepticism as a restaurant describing its own lasagna as world famous.

The ArchUnitDev result is more useful because it asks a narrower and less glamorous question: can this model complete a long, dependency-ordered software build inside a fairly demanding agent harness?

In this experiment, yes, it can.

That does not make DeepSeek interchangeable with every proprietary frontier model. It does mean Chinese open-weight models deserve to be evaluated as serious production candidates rather than dismissed as interesting science projects. Where tasks are testable, failures are contained, data-handling requirements are understood, and inference happens often enough for cost to matter, they may be more than good enough. And whether we like it or not, they are going to get better.

"Good enough" sounds underwhelming until it delivers the same backlog outcome for a seventeenth of the model spend. There is an inflection point somewhere between 18 times the cost and double the cost where these models start to become very appealing.

So What Did the Extra Money Buy?

It would be easy, and wrong, to conclude that Opus brought nothing to the party except a more impressive bar tab. It is a monster of a model and frontier for a reason.

Opus needed less correction and fewer attempts. That matters when the task is ambiguous, the specification is thin, mistakes carry real consequences, or no deterministic test can tell you whether the answer is nonsense. In those situations, fewer retries and stronger first-pass performance can be worth considerably more than the token bill suggests.

The cost ratio was also not remotely consistent. Across the 45 completed issues, Opus cost between 3.2 and 70.1 times as much as DeepSeek, with a median ratio of 18.1. Extra review rounds explain much of that spread. Every additional round starts another context-heavy model session, and expensive context remains expensive even when the agent is using it to rediscover something it forgot five minutes ago.

Prompt caching adds another wrinkle. Amazon Bedrock documentation notes that cache reads receive a discounted rate, while cache writes may cost more than normal input. In the Opus run, cache writes were the largest measured cost component at $165.64, or 47.8% of model spend. Output cost $96.81 and cache reads cost $84.22.

Nearly half the Opus model bill came from writing context into caches. If your model-routing spreadsheet looks only at the headline input and output price you may have carefully optimized the smaller half of the problem.

A Routing Strategy for People Who Enjoy Sleeping at Night

You do not need a grand artificial-intelligence parliament to apply this. A practical escalation ladder works rather well:

Start economical, verify deterministically, and escalate when the evidence asks you to.

1. Classify the task. Consider ambiguity, business impact, context size, testability, and reversibility. Renaming an internal field is not the same thing as rewriting an authorization boundary, even if both arrive as innocent-looking tickets.
2. Start with the least expensive qualified model. Use economical models for bounded implementation, extraction, transformation, and other work where automated checks can catch mistakes.
3. Escalate when the evidence asks you to. Repeated gate failures, contradictory critic findings, stalled progress, or a high-risk decision are good reasons to call in the expensive oracle.
4. Keep deterministic checks independent. Compilation, tests, schemas, policy checks, and security controls should not depend on the same model declaring itself brilliant.
5. Measure the whole workflow. Track accepted outcomes, retries, elapsed time, human intervention, cache behavior, and infrastructure. Price per token is interesting, but cost per useful result pays the bill.
6. Recalibrate regularly. Models and prices change at a slightly absurd pace. Today's premium model may be tomorrow's sensible default, and today's benchmark champion may be forgotten by next quarter.

The goal is not to keep frontier models locked in a glass cabinet for special occasions. It is to spend their capability where it changes the result.

Before We Get Carried Away

Now for the caveats, because every benchmark eventually reaches the section where the author admits reality is complicated.

First, each model reviewed its own work. A landed issue means its own critics were satisfied and the deterministic gate passed. It does not mean an independent judge applied exactly the same semantic quality standard to both repositories. Asking a model whether its own work is excellent has certain annual performance review vibes.

Second, both final test suites were green, but they were structured differently. DeepSeek produced 1,852 tests and Opus produced 1,534. More tests do not automatically mean better tests. You can write ten excellent tests, or two thousand tests that enthusiastically confirm the code does whatever the code currently does. Mutation testing or an independent hidden suite would tell us much more.

Third, the runs were not operationally identical. They happened about a month apart, used different regions and instance types, and the first seven DeepSeek issues ran on an earlier harness revision. Some early DeepSeek abandonments may therefore belong partly to the harness rather than the model. Software blaming AI for its own childhood mistakes would be a little unfair.

Fourth, DeepSeek's $19.86 came from provider pricing reported through OpenCode and did not have the same provider-side cross-check available for Opus. The Opus token counts were compared with Amazon CloudWatch and came within roughly 3% to 5%.

These limitations stop us from claiming universal quality equivalence. They do not make the main observation disappear: inside this controlled, fail-closed harness, a much less expensive open-weight model completed the same issue backlog.

The Answer Is a Portfolio, Not a Winner

Model conversations have a habit of turning into horse races. Somebody produces a leaderboard, everybody picks a favorite, and a week later a new model arrives to knock over the refreshments.

Production systems need something less dramatic: a portfolio. Some tasks deserve the strongest model available. Others need a model that is strong enough because deterministic software, explicit constraints, and escalation policies provide the rest of the assurance.

The ArchUnitDev benchmark suggests a practical default. Start with the least expensive model that has demonstrated success on the actual workload. Watch the correction signals. Escalate deliberately. In this case, DeepSeek required more turns and a little more patience, but it still reached the target for 17.5 times less model spend.

This is not an argument against frontier models. It is an argument against paying frontier prices before proving that the workload needs one.

So the next time somebody reaches automatically for the largest model in the catalog to rename a field, perhaps gently move their hand away from the expensive oracle. There is probably a perfectly good screwdriver nearby.

Sources

Benchmark evidence

• DeepSeek V4 Flash build report
• Claude Opus 5.5 build report
• DeepSeek V4 Flash versus Opus 5.5 comparison
• DeepSeek-built ArchUnitSharp repository
• Opus-built ArchUnitNET repository

Model and platform sources

• DeepSeek V4 Preview Release
• Official DeepSeek V4 Flash model card and weights
• DeepSeek Privacy Policy
• Amazon Bedrock prompt caching
• Amazon Bedrock Claude Opus 5.5 model card

Last verified. Benchmark reports and linked official sources checked on 2026-09-26. The quantitative comparison is specific to this workload and harness configuration.

The views expressed here are my own and do not necessarily reflect the views of Amazon Web Services (AWS) or Amazon.com.