The point that the sidecar stamps the initiator and hand-off count on its own mTLS connection, never in the payload, is the part most agent designs skip. One thing I'd be curious about: when a hand-off goes through a queue or job store rather than a direct call, the stamp no longer travels on a live connection. Do you re-stamp at dequeue (sidecar reads the stored record and the gateway re-verifies it), or sign the hand-off record itself? Also, with the deadline carried on the task, how do you think about clock skew between hops? A small grace window seems safer than letting a slow hop fail closed and get retried with a fresh, wider deadline. And on RFC 8693, treating nested actor claims as audit-only while the policy reads only top-level claims and the current actor seems like the right split.
build production-ready AI integrations, mobile apps, and web platforms for businesses that want real results.
Thanks — you’ve read it exactly as intended, and I should be plain about one thing first: the sidecar, its connection and its certificate are the pattern I recommend, not code the series builds. The published policies take the stamp as given; depth is a context value the tests set, and the forbid caps it at two. So everything below is design, not something I can point at a test for.
Queues: a stamp bound to a connection doesn’t survive a store, so I’d do both of the things you name, not one. The enqueuing relay signs the hand-off record (tenant pair, on-behalf-of user, initiator, depth, deadline, task id); the dequeuing relay verifies that signature, increments depth itself, and does a fresh RFC 8693 exchange with the consumer as audience and scope ≤ what the record carries. The queue is one more hop that can become a confused deputy, so it gets no authority of its own.
Clock skew: agreed on a small grace window at the verifier. The constraint I’d add is that a child’s deadline may only shrink from its parent’s, and must sit within the exchanged token’s exp — a retry can re-issue a task, never a wider deadline. Leeway at the check, nothing that extends.
On 8693: yes, that split. One extra use for the nested chain beyond audit: its length should equal the relay’s depth count. Two independent records of the chain; if they disagree, something forged one.
Your comment changed the post. The last section, What this doesn’t solve, now ends with a paragraph on hand-offs through a queue: the signed record, re-stamp at dequeue, the deadline bound and the chain-length check, stated as the natural next step rather than code the series runs. The relay paragraphs now read as the design the policies assume.
AI Developer
The point that the sidecar stamps the initiator and hand-off count on its own mTLS connection, never in the payload, is the part most agent designs skip. One thing I'd be curious about: when a hand-off goes through a queue or job store rather than a direct call, the stamp no longer travels on a live connection. Do you re-stamp at dequeue (sidecar reads the stored record and the gateway re-verifies it), or sign the hand-off record itself? Also, with the deadline carried on the task, how do you think about clock skew between hops? A small grace window seems safer than letting a slow hop fail closed and get retried with a fresh, wider deadline. And on RFC 8693, treating nested actor claims as audit-only while the policy reads only top-level claims and the current actor seems like the right split.