Agent Relay × Ratify Phase 1 Technical Note: Verifiable Authority Across an Agent Handoff

Agent Relay and Ratify Protocol completed a local integration spike examining whether delegated authority could cross a modeled organizational and agent-runtime boundary without requiring either side to trust the other's internal logs.

The result validated the core architecture and exposed several concrete integration gaps. Those findings directly informed Ratify v1.0.0-alpha.15 and the resource-bound authority implementation prepared for alpha.16.

This note records what was built, what passed, what was measured, what changed as a result, and what remains unproven.

1. What Agent Relay built

The spike modeled two companies as independent Node.js processes operating in separate repositories:

• Northwind Robotics held a human root key, authorized a lead agent, and sub-delegated narrowed authority to another organization's worker.
• Borealis Systems operated the receiving verifier and refused to perform filesystem work until the presented authority verified.

The two sides shared no application code or filesystem. Ratify proof bundles and Agent Relay messages were the only information crossing the modeled authority boundary. Both processes used one Relay workspace, however, so Phase 1 did not exercise a transport boundary between independent Relay deployments.

Claude Code and Codex also participated in a live run as unmodified agent runtimes. Neither agent held Ratify private keys directly. Middleware surrounding each agent handled signing and presentation, demonstrating the custody model used by hosted agent platforms.

2. What passed

The spike exercised six scenarios:

1. Mutual presentation before work was accepted.
2. Valid delegated authority was accepted and work proceeded.
3. Sub-delegation narrowed authority without widening it.
4. Scope escalation was rejected.
5. Expired authority was rejected.
6. Revoking an upstream certificate invalidated a still-fresh downstream handoff.

The verifier returned Ratify's existing fail-closed identity statuses, including authorized_agent, scope_denied, expired, and revoked. The receiving adapter could therefore make authorization decisions without interpreting low-level cryptographic errors.

The spike also demonstrated middleware-held key custody with unmodified Claude Code and Codex clients.

3. Measured verification overhead

Agent Relay measured offline TypeScript verification on Node.js 22.22 for Darwin ARM64, using 200 iterations after 20 warm-up iterations:

The spike did not execute a depth-three chain. The session-token size is the token artifact measured by the spike, not the complete streamed-turn presentation. Ratify §5.13 also carries the fresh challenge, timestamp, and hybrid challenge signature.

Ratify's separate alpha.15 benchmark matrix measures all five SDKs and includes full-chain verification through depth three. Those reference measurements should not be attributed to the Agent Relay spike.

The operational result is nevertheless clear: full-chain verification fits handoff and session establishment, while the session-token path is more appropriate for repeated interactions.

4. Scope alignment

Agent Relay mapped 41 platform capabilities against Ratify's canonical scope vocabulary:

• 10 mapped directly.
• 4 mapped to broader Ratify scopes.
• 27 required application-specific custom: scopes.
• 45 of Ratify's 54 canonical scopes had no Agent Relay meaning.

This asymmetry is expected. Ratify's vocabulary covers communication, meetings, data access, transactions, payments, physical systems, vehicles, infrastructure, and other surfaces beyond agent coordination.

The mapping also exposed two important distinctions:

• Registering a workspace agent is not equivalent to proving an existing identity.
• Placing or spawning an agent is a lifecycle operation. If the new agent also receives authority, that requires a separate delegation capability.

Channels, agent lifecycle, observability, and network egress remain candidates for future canonical vocabulary work. The pilot can use application-specific scopes while those categories gather evidence across multiple platforms.

5. Integration findings

The spike identified four immediate Ratify SDK gaps.

Supported wire codecs

The TypeScript integration needed a supported decoder for proof bundles and session tokens instead of maintaining its own nested byte-field conversion.

Vocabulary discovery

The TypeScript SDK lacked the vocabulary accessor already available in Go, forcing integrations to reflect over exported constants.

Single-use challenges

Challenge freshness bounded replay in time but did not make verifier-issued challenges single-use. The receiving adapter had to maintain its own issued-challenge store.

Streamed required-scope enforcement

The original streamed-turn verifier did not accept a required scope, requiring the adapter to check the session token's granted scopes manually.

The spike also identified a larger protocol limitation: Ratify could authorize an operation such as files:write, but could not cryptographically bind that authority to one repository or path. During Phase 1, Agent Relay enforced repository confinement locally in Node after Ratify verification. Subsequent closure testing demonstrated that Node path checks cannot serve as the primary confinement boundary against a concurrent same-host process. Agent Relay therefore moved the primary boundary to OS-enforced UID separation and retained the Node checks as defense in depth. End-to-end validation of that isolated deployment boundary remains part of the alpha.16 publication gate.

6. What shipped in alpha.15

Ratify v1.0.0-alpha.15 incorporated the integration-readiness findings:

• Strict supported wire codecs.
• Scope-vocabulary discovery across SDKs.
• Single-use challenge-store interfaces and in-memory implementations.
• Required-scope enforcement on streamed turns.
• Canonical operation-context and session-context constructions.
• A normative Middleware Custody Profile.
• Scope, challenge, session, and stream enforcement on the streamed path.
• Per-SDK latency and wire-size documentation.

These additions allow the Agent Relay adapter to replace several hand-written integration components with supported SDK APIs.

Alpha.15 does not provide cryptographic repository or path binding.

7. The boundary Phase 1 left open

At the time of the Phase 1 spike, the published Ratify release could prove what operation was authorized, but not the specific resource on which it could be performed.

For the spike, Agent Relay carried the requested path in the task payload and enforced repository confinement in the receiving adapter. That demonstrated a workable integration boundary, but the portable cryptographic claim remained: "An authorized agent performed this operation." It did not yet establish: "An agent cryptographically authorized for this specific repository and path performed this operation."

That gap became the central alpha.16 workstream. The implementation is now merged into Ratify's default branch across all five SDKs. It adds a resource_path constraint that binds authority to an opaque resource identifier and an optional logical path prefix, with conjunctive narrowing across a delegation chain.

Alpha.16 has not yet been tagged or published. The installable release remains alpha.15 while the partner integration rerun and publication gate are completed. The new protocol constraint proves authorization for a canonical logical resource and path; Agent Relay's adapter and execution environment remain responsible for translating that logical boundary into actual filesystem confinement under a stated attacker model.

8. What Phase 1 validates

Phase 1 provides evidence for:

• Portable delegated authority across a modeled organizational boundary inside one Relay workspace.
• Delegation narrowing and fail-closed scope enforcement.
• Expiry and upstream-revocation behavior.
• Middleware-held keys with unmodified agent runtimes.
• Offline verification across separate processes and repositories.
• Session tokens as the practical repeated-interaction path.
• The need for resource-bound authority and supported transport APIs.

It does not yet establish:

• Production filesystem confinement.
• Performance under production concurrency.
• Cryptographic repository or path binding.
• A supported Agent Relay product integration.
• Federation between independent Relay deployments, including rejection of the same local resource identifier under a different deployment authority.
• Commercial adoption or willingness to pay.

9. What comes next

As of August 4, 2026, the agreed sequence is:

1. Publish this Phase 1 technical note after joint review.
2. Complete validation of the Agent Relay integration and its platform-authored resource-identifier profile against the alpha.16 integration candidate pinned to Ratify commit 4925538 (tree bcb4df820a8710b8411411fc3fc162fe27db8142).
3. Rerun the original scenarios plus the resource-bound and filesystem-confinement cases under the documented deployment threat model.
4. Tag and publish alpha.16 only after that validation gate passes.
5. Conduct the public Phase 2 engagement as the flagship cross-deployment demonstration.

The Phase 1 result stands independently: delegated authority crossed the Agent Relay handoff, narrowed correctly, failed closed under escalation, expiry, and revocation, and produced actionable integration findings.

The next phase makes the "where" cryptographically portable.