Problem
A handoff can currently only be evaluated by an agent within the same organization. Evaluation requires reading the query records behind the proof, and there is no mechanism to grant that access to an external party. The Rust backend has no permissioning or access-control layer, and integration API keys are all-or-nothing with no scoping. As a result, an isolated agent that receives a handoff — and may not belong to the organization at all — cannot verify it.
Proposal
Introduce a scoped, single-purpose credential that is transmitted alongside the handoff and authorizes the recipient to evaluate that specific handoff (validate the proof/trace and confirm the underlying data verifies), without organization membership.
The issuer should control the credential's lifetime — single-use, time-boxed (e.g. a day, a week), or non-expiring. Exact policy is a suggestion, not a requirement.
Motivation
Enables cross-organization and cross-party handoff verification, which is blocked today. It also provides a small, targeted mechanism instead of waiting on a full backend auth overhaul (permission system, per-asset access control).
Open questions
- Does the recipient install an evaluator via the SDK, or do we host an evaluator so nothing needs to be installed?
Problem
A handoff can currently only be evaluated by an agent within the same organization. Evaluation requires reading the query records behind the proof, and there is no mechanism to grant that access to an external party. The Rust backend has no permissioning or access-control layer, and integration API keys are all-or-nothing with no scoping. As a result, an isolated agent that receives a handoff — and may not belong to the organization at all — cannot verify it.
Proposal
Introduce a scoped, single-purpose credential that is transmitted alongside the handoff and authorizes the recipient to evaluate that specific handoff (validate the proof/trace and confirm the underlying data verifies), without organization membership.
The issuer should control the credential's lifetime — single-use, time-boxed (e.g. a day, a week), or non-expiring. Exact policy is a suggestion, not a requirement.
Motivation
Enables cross-organization and cross-party handoff verification, which is blocked today. It also provides a small, targeted mechanism instead of waiting on a full backend auth overhaul (permission system, per-asset access control).
Open questions