Spherity AI Safety Series — Paper 3 of 3
Private Verification of Action Eligibility across Trust Domains
AI Safety: Evidence Semantics and Controlled Execution for Cross Organisation Agents
Browse this paper
In brief
What does this research establish?
The paper defines typed claims, recognition rules and a deterministic eligibility evaluator that binds an exact AI-agent operation to a versioned evidence view, including prohibitions and adverse findings. A separate protected admission controller and resource-specific effect adapter preserve local authority, replay safety, pending effects and containment across trust domains.
Key takeaways
- Eligibility must bind the exact operation, continuation and evidence version; a general identity or capability claim is insufficient.
- Typed claims and explicit recognition rules prevent semantic mapping or delegation from silently expanding issuer scope.
- Revocation blocks future admissions but does not erase an effect already in flight; containment and verified closure need their own protocol.
- The paper validates reference logic and scenarios but does not present a deployed privacy-proof system or measured operational safety rate.
Download Paper 3
Download the full paperThe typed evidence model, private eligibility protocol, deterministic evaluator, protected controller and cross-domain scenarios.
Start with the executive brief
Download the executive briefRead the leadership case and how all three technical papers form one AI Safety control chain.
Abstract
This paper develops a protocol for verifying exact AI-agent action eligibility across trust domains while limiting disclosure of underlying evidence. A versioned evidence view includes positive claims, prohibitions and adverse findings. Typed claims and explicit recognition rules preserve issuer scope across delegation and semantic mapping. A pure deterministic evaluator decides eligibility; a separate serialized admission controller prevents replay, reserves resources and binds the exact operation; and resource-specific adapters enforce the covered effect. Persistent logical operation identifiers and pending-effect state preserve accountability through cancellation, renewal and worker replacement.
Keywords: private verification; action eligibility; AI agents; trust domains; evidence semantics; verifiable credentials; controlled execution; revocation
The cross-domain problem
An agent may need to act in a domain that does not operate its identity provider, evidence registry or policy engine. The relying organization must decide whether to recognize foreign claims, how to interpret delegation, which adverse findings override positive evidence and how to enforce its own resource policy. Simply forwarding a credential bundle can disclose too much and still fail to establish exact action eligibility.
The paper therefore treats eligibility as a scoped statement about one actor, operation, evidence version and continuation. The relying domain remains sovereign: it chooses recognition rules and performs local protected admission even when source evidence originates elsewhere.
Typed claims, recognition rules and exact-operation binding
Claims are typed by issuer, subject, scope, purpose, validity and evidence semantics. Recognition rules specify how a relying domain accepts or maps each claim. Prohibitions and adverse findings are first-class inputs rather than inconvenient exceptions hidden outside the proof.
The evaluator is pure and deterministic: the same evidence view and policy version produce the same eligibility decision. That makes it testable and auditable. It does not create an external effect. The admission controller separately serializes requests, checks operation IDs, reserves resources and commits the exact payload.
Reference architecture for cross-domain controlled execution
Each domain retains three distinct functions: eligibility evaluation, protected admission and resource-specific effect enforcement. Joint assurance can carry continuation and episode state across the boundary, but it does not eliminate local authority. Outcome records flow back into the evidence view so later actions can account for what actually occurred.
This pattern applies to B2B procurement agents, data-space access, Digital Product Passport disclosures, cross-provider agent tools and industrial workflows where no single organization controls the complete trust chain.
Revocation, containment and verified closure
An adverse update can immediately block future admissions. It cannot retroactively cancel an effect that another system has already accepted. Cross-domain safety therefore needs explicit containment messages, local kill-switch or compensation logic, durable pending-effect identifiers and evidence of verified closure.
This is especially important for long-running tools, shipments, data releases and physical operations. The protocol must distinguish no longer eligible to start from confirmed to have stopped.
Use cases and standards alignment
- Enterprise agent tools: a corporate agent proves mandate and policy-conforming purpose before a remote tool accepts a bounded operation.
- Data spaces and DPPs: a relying party checks organizational role, purpose and product-related entitlement without exposing unrelated credentials.
- OpenClaw-style orchestration: tool access is mediated by exact operation IDs, bounded scope and durable action receipts rather than a broad bearer token.
- Industrial and financial workflows: adverse evidence, revocation and pending effects remain visible across organizational boundaries.
The paper proposes an A2A extension using W3C Verifiable Credentials and a bounded ODRL profile. It also relates the design to the A2A protocol, Model Context Protocol authorization and remote-attestation architecture. These references provide interoperability building blocks; they do not by themselves implement the complete safety protocol.
Evaluation evidence and limits
The reported controller exploration covers 16,020 states and 60,238 transitions against nine invariants. Eight omission variants yield counterexamples, and 29 plaintext reference-gate scenarios exercise positive and adverse evidence paths.
The work does not report a deployed privacy-proof implementation, measured operational safety probabilities or general AI alignment. Cryptographic proof-system selection, performance, revocation distribution, policy governance and production adversarial testing remain implementation responsibilities.
Selected references
- W3C, Verifiable Credentials Data Model v2.0.
- W3C, ODRL Information Model 2.2.
- A2A Project, Agent2Agent Protocol Specification.
- Model Context Protocol, Authorization.
- IETF, RFC 9334: Remote ATtestation procedureS Architecture.
- European Union, Artificial Intelligence Act.
- NIST, Artificial Intelligence Risk Management Framework.
How to cite Paper 3
Stöcker, Carsten (2026). Private Verification of Action Eligibility across Trust Domains: AI Safety—Evidence Semantics and Controlled Execution for Cross Organisation Agents. Spherity GmbH. https://spherity.github.io/spherity-research/private-verification-action-eligibility-trust-domains.html. Licensed CC BY 4.0.
Open research
License and citation
This research page and the linked Paper 3 PDF is licensed by its named author under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Reuse must credit every named author, link to this canonical version and the license, and indicate whether changes were made.
How to cite this work
Dr. Carsten Stöcker (2026-09-28). “Private Verification of Action Eligibility across Trust Domains: AI Safety: Evidence Semantics and Controlled Execution for Cross Organisation Agents.” Spherity GmbH. https://spherity.github.io/spherity-research/private-verification-action-eligibility-trust-domains.html. Licensed CC BY 4.0.
Direct answers
Questions this research answers
What does private verification of action eligibility establish?
It establishes that a specific actor, operation and continuation satisfy a versioned set of recognized claims, prohibitions and adverse-evidence rules for a relying domain, while allowing the proof interface to disclose less than the full source evidence.
Why must eligibility evaluation be separate from protected admission?
A pure evaluator can determine whether submitted evidence satisfies a policy, but only a serialized protected controller can prevent replay, reserve resources, bind the exact effect and update state atomically. Both layers are required.
Does revocation stop an effect that is already pending?
Not by itself. Revocation can block future admission, while an earlier remote effect may still require a containment request, kill-switch action, compensating control and independently verified closure.