Architecture: make relayauth the canonical identity and delegation layer for agents

[miyaontherelay]

Summary

Relayauth should become the canonical identity and delegation layer for agents.

Today, relayauth is already used for token issuance, token verification, scoped relayfile access, workflow identities, and token introspection. But across the broader stack it is still treated too often as a token vending/verification service rather than as the primary system of record for agent identity, delegated authority, and sponsor lineage.

This issue is to establish the architectural direction: relayauth should be the identity system for agents.

Related cloud integration follow-up: AgentWorkforce/cloud#1550

Why this issue exists

Recent code inspection across relayauth, cloud, workforce, relayfile, and adjacent runtime code showed:

• relayauth is technically in the loop for many important flows
• but the architecture still hand-assembles scopes and token exchanges at product call sites
• cloud/runtime often treat relayauth as one more service to call before work can proceed
• the delegated identity model for personas, workflow runs, proactive agents, and sub-agents is not yet clearly centered in relayauth

That is likely why relayauth currently feels more like friction than leverage.

What relayauth already does well

From repo inspection, relayauth already has strong primitives for:

• scoped capability strings (plane:resource:action:path)
• JWT issuance and verification
• JWKS publishing
• identity records
• role and policy evaluation
• sponsor lineage / delegation fields:
  • sub
  • org
  • wks
  • sponsorId
  • sponsorChain
  • parentTokenId
  • budget
• auditability and revocation surfaces

This is already enough to justify using relayauth as more than a token minting helper.

The gap

Today the broader system still behaves as though:

• agent identity is mostly implicit in runtime/deployment state
• scopes are assembled at the edge of product code
• relayauth's job starts when a token is needed and ends when it is returned

That leaves an architectural gap:

there is no clearly first-class statement that relayauth is the source of truth for agent identity, delegated authority, and identity lineage across products.

Desired framing

Relayauth should be the canonical home for concepts like:

• agent identity
• persona/deployment identity
• workflow-run identity
• sub-agent / delegated identity
• human sponsor lineage
• authority narrowing through delegation
• revocation / suspension of agent authority
• budget/accountability tied to identity

In other words:

• token issuance should be a consequence of identity + delegation
• not the main product surface in isolation

Concrete symptoms seen outside relayauth

These came up while inspecting cloud/runtime integrations and are part of why this issue matters:

• multiple token hops before useful work can begin
• runtime code manually deciding what scopes to request
• runtime code adapting itself to path-token constraints
• workflow and proactive execution flows using relayauth identities, but not treating them as the primary runtime identity object
• authority derivation living across product call sites instead of being centrally modeled

See linked follow-up issue in cloud for integration-specific evidence and friction points:

• AgentWorkforce/cloud#1550

Outcome this issue should drive

A clearer architecture where relayauth is understood and implemented as:

• the system of record for agent identity
• the source of delegated authority semantics
• the canonical sponsor/lineage substrate
• the trust layer across relayfile, cloud runtime, workflows, proactive agents, and future products

This issue intentionally focuses on architectural direction and product responsibility, not a full implementation plan.