Context
SBO3L (https://github.com/B2JK-Industry/SBO3L-ethglobal-openagents-2026) is a policy + signing layer that decides whether an agent action is authorised. After signing an allow PolicyReceipt, it hands the receipt + APRP to KeeperHub for execution.
Pain point
The KeeperHub submission envelope has no first-class fields for upstream policy attestation. We pass them via the workflow's input payload, but they don't surface in KeeperHub's audit trail or run logs — so an offline auditor reading a KeeperHub execution row has no cryptographic link back to the SBO3L decision that approved it.
Suggested improvement
Add native, schema-blessed fields a caller can attach to the submission envelope so KeeperHub's audit trail can re-emit them on the result side and in run logs:
upstream_request_hash — JCS-canonical SHA-256 of the underlying requestupstream_policy_hash — canonical hash of the policy that authorised the actionupstream_receipt_signature — signature of the policy receipt (hex)upstream_audit_event_id — ULID of the upstream audit event (or any opaque correlation id)upstream_capsule_hash — content hash of the upstream proof capsule
Plus echo back via two optional response headers:
X-Upstream-Receipt-Signature: <hex>X-Upstream-Policy-Hash: <hex>
Why it matters
With these, an offline auditor can take a KeeperHub execution log line + a SBO3L audit bundle, and verify end-to-end that the executed action was the one SBO3L signed off on — without trusting either side to correlate honestly.
Tracked downstream: https://github.com/B2JK-Industry/SBO3L-ethglobal-openagents-2026/blob/main/FEEDBACK.md
Context
SBO3L (https://github.com/B2JK-Industry/SBO3L-ethglobal-openagents-2026) is a policy + signing layer that decides whether an agent action is authorised. After signing an
allowPolicyReceipt, it hands the receipt + APRP to KeeperHub for execution.Pain point
The KeeperHub submission envelope has no first-class fields for upstream policy attestation. We pass them via the workflow's input payload, but they don't surface in KeeperHub's audit trail or run logs — so an offline auditor reading a KeeperHub execution row has no cryptographic link back to the SBO3L decision that approved it.
Suggested improvement
Add native, schema-blessed fields a caller can attach to the submission envelope so KeeperHub's audit trail can re-emit them on the result side and in run logs:
upstream_request_hash— JCS-canonical SHA-256 of the underlying requestupstream_policy_hash— canonical hash of the policy that authorised the actionupstream_receipt_signature— signature of the policy receipt (hex)upstream_audit_event_id— ULID of the upstream audit event (or any opaque correlation id)upstream_capsule_hash— content hash of the upstream proof capsulePlus echo back via two optional response headers:
X-Upstream-Receipt-Signature: <hex>X-Upstream-Policy-Hash: <hex>Why it matters
With these, an offline auditor can take a KeeperHub execution log line + a SBO3L audit bundle, and verify end-to-end that the executed action was the one SBO3L signed off on — without trusting either side to correlate honestly.
Tracked downstream: https://github.com/B2JK-Industry/SBO3L-ethglobal-openagents-2026/blob/main/FEEDBACK.md