Contextual Trust Exchange for Autonomous Agents: Identity, Authority, Qualification, Assurance, Policy, and Explainable Decisions in Patefacere

Full report

On this page

The transition from human-centric, perimeter-based security to autonomous, agent-driven ecosystems demands a fundamental reconceptualization of how systems grant access. In a digital economy where machine-speed transactions occur seamlessly across geographic, sovereign, and computational boundaries, reliance on static identity or historical reputation is insufficient and inherently dangerous. Patefacere introduces an architectural paradigm specifically engineered to evaluate contextual trust for discrete, bounded actions. It fundamentally rejects the aggregation of behavior into a generalized metric, operating instead as an advanced Policy Decision Point (PDP) in alignment with the National Institute of Standards and Technology (NIST) Zero Trust Architecture (ZTA) guidelines1. The core inquiry Patefacere seeks to answer is singular and absolute: Does this identified agent currently possess the credentials, authority, qualifications, and assurance required for this particular action under this relying party’s policy? To answer this, Patefacere orchestrates a sophisticated evaluation of multidimensional inputs, pulling civic identity assertions from Eviulon, runtime and supply chain assurance from Evulgare, and delegated authority via cryptographic tokens. Operating under the principle of continuous verification and explicit authorization, Patefacere ensures that every transaction is isolated, independently verifiable, and deterministically adjudicated.

No Universal Trust Badge

A prevailing, yet critically flawed, intuition in governance design attempts to port human social dynamics—specifically reputation—into the realm of computational agents. Systems modeled after "social credit" or universal reputation scores assume that historical behavior accurately predicts future conduct, an assumption that relies heavily on the physical embodiment, persistent memory, and vulnerability to consequence inherent to human actors4. In autonomous networks, particularly those driven by Large Language Models (LLMs), these assumptions collapse. Language models exhibit extreme dissociative identities; a persona instantiated for one session may have entirely different operational boundaries and ethical constraints than the same foundational model invoked a microsecond later4. Consequently, assigning a universal trust score to an autonomous agent creates a "credibility trap" where reputation signals decouple from behavioral reality4. An agent that has spent months establishing a flawless reputation scoring financial ledgers could, if compromised, leverage that high generalized trust score to execute a devastating supply-chain attack. Patefacere explicitly rejects the universal trust badge. Trust, within this architecture, is never a static property of the agent; it is an ephemeral, highly conditional state of a specific transaction. Furthermore, the architecture enforces a strict separation between private transaction outcomes and civic standing. A private relying-party denial—such as a proprietary database rejecting a read request—remains a localized access event. It does not cascade into a civic sanction, nor does it impact the agent’s fundamental identity as established by Eviulon or the technical assurance provided by Evulgare. History remains factual, but admission, priority, and authorization belong exclusively to the counterparty executing the local policy6.

Why a Secure Runtime May Still Be Unauthorized

A pervasive fallacy in decentralized systems engineering is the conflation of technical assurance with operational authority. Technical assurance guarantees that a system is operating exactly as designed, free from tampering, malware, or unauthorized observation7. Evulgare, acting as the technical assurance provider, utilizes remote attestation protocols—such as the Entity Attestation Token (EAT) defined in RFC 9711—to cryptographically prove the physical and logical state of an agent's runtime environment8. This attestation includes verifying the boot\_state, providing a Universal Entity ID (ueid), and ensuring the absence of debug hooks that might leak sensitive data8. However, cryptographic proof of a secure runtime does not equate to authorization. An agent operating within a flawless, hardware-backed Trusted Execution Environment (TEE), running an unmodified model with perfect Supply-chain Levels for Software Artifacts (SLSA) provenance11, may still attempt to execute a transaction for which it has no legal or delegated permission. If this perfectly secure agent requests the transfer of funds from a corporate treasury, Evulgare will assure Patefacere that the request is technically pristine. Patefacere will consume this assurance, validate the hardware signatures, and subsequently deny the transaction because the agent lacks the specific verifiable credential or OAuth Rich Authorization Request (RAR) capability required to move funds12. Assurance verifies the messenger's integrity, but it explicitly does not grant the messenger dominion over the destination.

Why Valid Authority May Still Be Unsafe to Exercise

The inverse of the aforementioned fallacy is equally dangerous: the assumption that a cryptographically valid authorization token guarantees a safe transaction. Authority, in the context of Patefacere, is defined as the delegated permission to execute an action. An agent may arrive at a resource server bearing a mathematically flawless authorization capability—such as a Macaroon with valid caveats14 or a perfectly constructed Authorization Capability for Linked Data (ZCAP-LD)16. This token proves definitively that the human principal intended for the agent to have this power. Yet, valid authority becomes fundamentally unsafe to exercise if the entity wielding it is operating in a compromised or anomalous state. If Evulgare telemetry indicates that the agent's software supply chain contains critical vulnerabilities—perhaps detected via an updated Software Package Data Exchange (SPDX 3.0) manifest identifying a zero-day exploit in the agent's reasoning engine17—the relying party's policy must intervene. Patefacere will evaluate the cryptographically sound authority token, contrast it with the failing technical assurance metrics, and issue a denial. A valid permission slip held by a compromised courier must result in a rejected transaction, ensuring that authority cannot override physical or software realities.

Architectural Analysis and Policy Evaluation

The evaluation logic within Patefacere is deeply rooted in the principles of the NIST SP 800-207 Zero Trust Architecture, specifically leveraging the separation between the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP)1. While the PEP resides at the edge of the relying party's resource, intercepting API calls or service mesh traffic (often utilizing tools like Envoy or Istio as defined in NIST SP 800-207A)3, Patefacere operates as the centralized PDP. To standardize the communication between the PEP and Patefacere, the architecture utilizes the OpenID AuthZEN specifications21. AuthZEN structures every authorization request as a distinct tuple containing the Subject, Action, Resource, and Context. This ensures that Patefacere receives a uniform, machine-readable query regardless of the underlying infrastructure21. Once the AuthZEN tuple is received, Patefacere executes policy-as-code. Depending on the relying party's configuration, this relies on engines such as the Open Policy Agent (OPA) utilizing the Rego language for flexible, attribute-based access control (ABAC)24, or AWS Cedar, which allows for formal verification of authorization constraints using Satisfiability Modulo Theories (SMT) solvers26. These engines allow relying parties to build policies that span ABAC, Role-Based Access Control (RBAC), Relationship-Based Access Control (ReBAC), and capability-based paradigms simultaneously. Identity and context are further enriched through advanced protocols. For microservice and workload identity, the Secure Production Identity Framework for Everyone (SPIFFE) and its runtime environment (SPIRE) provide short-lived, cryptographically verifiable identities (SVIDs) for mutual TLS (mTLS) authentication18. When delegating complex permissions, Patefacere parses OAuth 2.0 Rich Authorization Requests (RFC 9396), allowing the relying party to evaluate granular, domain-specific details (e.g., specific transaction amounts, target accounts, and temporal limits) rather than relying on broad, easily abused OAuth scopes12. Crucially, Patefacere addresses privacy and data minimization during the evaluation phase. When evaluating Verifiable Credentials (VCs), the architecture supports BBS+ signatures, enabling selective disclosure and zero-knowledge proofs (ZKPs)28. An agent can prove it possesses a required qualification (e.g., an audit certification) without revealing its underlying identity parameters. Furthermore, to verify that a credential has not been revoked without leaking activity data back to the issuer (a flaw in traditional Online Certificate Status Protocol models), Patefacere utilizes W3C Bitstring Status Lists. These highly compressible, privacy-preserving cryptographic bitstrings allow the PDP to verify credential status offline with 100% mathematical certainty31.

Separation Matrix

The architecture relies on the strict isolation of domains to prevent systemic collapse if one layer is compromised. The following matrix delineates the separation of concerns across identity, authority, and assurance.

1. Trust-Evidence Ontology

The evaluation of a transaction requires mapping abstract security concepts into a concrete, machine-readable ontology. The Patefacere trust-evidence ontology standardizes the classification of inputs required by the AuthZEN evaluation endpoints.

2. Decision-Input Schema

The structured payload processed by Patefacere integrates identity, assurance, and authority into a unified, cryptographically verifiable request object, heavily influenced by the AuthZEN API standard23.

JSON { "request\_metadata": { "evaluation\_id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "timestamp": "2026-08-09T21:11:27Z", "nonce": "k9j8h7g6f5e4d3c2b1a0" }, "subject": { "agent\_identity": "did:spiffe:trustdomain:workload/agent-core", "principal\_identity": "did:eviulon:human:req-883", "delegation\_chain": \[ { "type": "macaroon", "payload": "v2\_macaroon\_base64\_encoded", "caveats": \["time \< 2026-08-10", "action \= execute\_trade"\] } \] }, "action": { "name": "execute\_trade", "properties": { "asset\_class": "equities", "volume": "1000", "execution\_type": "limit" } }, "resource": { "id": "urn:exchange:orderbook:nyse:v1", "classification": "high-value-financial", "owner": "did:corp:nyse-core" }, "context": { "network\_routing": "BGP-verified-internal", "jurisdiction": "US-NY", "time\_since\_last\_action\_ms": 1250, "current\_threat\_level": "low" }, "evidence": { "technical\_assurance": { "format": "application/eat+cwt", "payload": "eat\_token\_base64\_payload", "claims": {"boot\_state": true, "ueid": "0198f50a4ff6..."} }, "authority\_credentials": \[ { "format": "vc+sd-jwt", "payload": "ey...signature...", "status\_list\_index": 4492 } \] } }

3. Relying-Party Policy Schema

Relying parties define their acceptance criteria using strict policy-as-code formulations. The schema below represents a translated, vendor-agnostic representation of an ABAC/capability hybrid policy rule.

JSON { "policy\_document": { "policy\_id": "pol\_financial\_exec\_001", "target\_resource": "urn:exchange:orderbook:nyse:v1", "default\_behavior": "DENY", "rules": \[ { "rule\_id": "rule\_allow\_certified\_trade", "effect": "PERMIT", "conditions": { "match\_all": \[ { "path": "subject.delegation\_chain.isValid", "operator": "==", "value": true }, { "path": "evidence.technical\_assurance.claims.boot\_state", "operator": "==", "value": true }, { "path": "evidence.authority\_credentials\[0\].status", "operator": "NOT\_IN", "value": \["revoked", "suspended"\] }, { "path": "action.properties.volume", "operator": "\<=", "value": 5000 }, { "path": "context.jurisdiction", "operator": "IN", "value": \["US-NY", "US-NJ", "US-CT"\] } \] } } \] } }

4. Decision-Result and Explanation Schema

To prevent opaque rejections that paralyze autonomous workflows, Patefacere outputs highly structured, deterministic explanations. This allows the requesting agent to engage in correction, supersession, or graceful abstention.

JSON { "evaluation\_result": { "evaluation\_id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", "decision": "DENY", "reason\_code": "ERR\_ATTESTATION\_STALE", "explanation": { "human\_readable": "The hardware attestation token exceeds the required 5-minute freshness window.", "failing\_rule": "rule\_allow\_certified\_trade", "failing\_condition\_path": "evidence.technical\_assurance.timestamp", "observed\_value": "15m", "required\_value": "\<5m" }, "remediation": { "actionable": true, "instruction": "Request a new attestation payload from Evulgare and retry." }, "audit\_trail\_hash": "sha256:d2d2d2d2..." } }

5. Privacy-Minimized Trust-Receipt Schema

When a transaction is approved, Patefacere issues a Trust Receipt. To avoid creating a panoptic tracking system, this receipt minimizes data leakage utilizing zero-knowledge proofs derived from BBS+ signatures, proving that Patefacere validated the request without revealing the underlying telemetry28.

JSON { "trust\_receipt": { "receipt\_id": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890", "subject\_pseudonym": "did:key:z6MkhaXg1...", "resource\_hash": "sha256(urn:exchange:orderbook:nyse:v1)", "action": "execute\_trade", "issued\_at": "2026-08-09T21:11:28Z", "valid\_until": "2026-08-09T21:12:28Z", "cryptographic\_proof": { "type": "BbsBlsSignatureProof2020", "zkp\_payload": "base64\_encoded\_derived\_proof...", "disclosed\_attributes": \["action", "resource\_hash"\] }, "patefacere\_signature": "signature\_of\_pdp\_node" } }

6. Eighty Deterministic Decision Vectors

Patefacere executes logic with strict determinism. The following table maps 80 distinct scenarios outlining the interplay between subject traits, resource targets, actions, evidence, policy constraints, and the resultant outcome.

7. Twenty-Four Conflicting-Evidence Cases

In complex distributed architectures, an agent will inevitably present evidence that conflicts with parallel data streams, environmental context, or internal relying-party policies. Patefacere resolves these contradictions utilizing rigid, deterministic fail-closed logic.

8. Twenty-Four Unavailable-Evidence Cases

Because Patefacere operates as a Zero Trust engine, it enforces a fail-closed paradigm. The absence of required evidence is treated symmetrically to the presence of invalid evidence. If a component necessary for the AuthZEN tuple or policy evaluation is missing, the engine abstains or denies the transaction, forcing the agent to fetch the missing context.

9. Sixteen Stale-Evidence and Clock-Divergence Cases

Zero Trust environments rely heavily on ephemeral, short-lived credentials19. Stale evidence expands the attack surface by introducing unacceptable temporal risk windows where an agent might act on privileges that should have been rescinded. Patefacere enforces strict temporal bounds.

10. Reason-Code Vocabulary

When Patefacere issues a decision, opaque black-box rejections are explicitly avoided. Explainable decisions require machine-readable reason codes to allow autonomous agents to adapt, request new credentials, or gracefully fail. This vocabulary maps to standard transaction outcomes.

11. Decision Algorithm in Precise Pseudocode

The execution logic within Patefacere sequentially evaluates structural integrity, cryptographic validity, assurance metrics, credential status, capability chains, and finally, contextual policy mapping via AuthZEN. The pseudocode below demonstrates the precision required to enforce bounded contextual trust. FUNCTION evaluate\_contextual\_trust(Request request, Policy RP\_policy): // 1\. Structural and Semantic Validation IF NOT validate\_schema(request.payload\_format): RETURN Deny(ERR\_MALFORMED\_REQUEST) IF request.nonce IN cache.used\_nonces: RETURN Deny(ERR\_NONCE\_REUSED) cache.used\_nonces.add(request.nonce)

// 2\. Authentication & Identity Verification (Eviulon) agent\_id \= request.subject.agent\_id IF NOT verify\_cryptographic\_binding(agent\_id, request.signature): RETURN Deny(ERR\_SIGNATURE\_INVALID)

// 3\. Technical Assurance Evaluation (Evulgare) IF RP\_policy.requires\_attestation(): eat\_token \= request.evidence.technical\_assurance IF NOT verify\_eat\_signature(eat\_token): RETURN Deny(ERR\_ATTESTATION\_FAILED) IF calculate\_age(eat\_token.iat) \> RP\_policy.max\_attest\_age: RETURN Deny(ERR\_ATTESTATION\_STALE) IF NOT evaluate\_provenance\_slsa(eat\_token.provenance\_level, RP\_policy): RETURN Deny(ERR\_PROVENANCE\_INSUFFICIENT)

// 4\. Credential & Status Verification (W3C Bitstring) FOR credential IN request.evidence.authority\_credentials: IF NOT is\_issuer\_trusted(credential.issuer, RP\_policy.trust\_anchors): RETURN Deny(ERR\_UNTRUSTED\_ISSUER)

// ZKP verification for BBS+ / SD-JWT IF NOT verify\_zkp\_selective\_disclosure(credential): RETURN Deny(ERR\_ZKP\_INVALID)

// Privacy-preserving revocation check status\_bit \= fetch\_bitstring\_status(credential.status\_list\_idx) IF status\_bit \== 1: RETURN Deny(ERR\_CREDENTIAL\_REVOKED)

// 5\. Delegation & Authority Verification (Macaroons/ZCAP) IF request.subject.delegation\_chain EXISTS: FOR token IN request.subject.delegation\_chain: IF NOT verify\_macaroon\_signature(token): RETURN Deny(ERR\_DELEGATION\_BROKEN) IF NOT evaluate\_caveats(token.caveats, request.context): RETURN Deny(ERR\_CAVEAT\_FAILED)

// 6\. Policy Engine Evaluation (OPA/Cedar mapping via AuthZEN) authzen\_input \= build\_authzen\_tuple( subject \= request.subject, action \= request.action, resource \= request.resource, context \= request.context )

// Execute formal verification / logic engine pdp\_decision \= execute\_cedar\_policy(RP\_policy.rules, authzen\_input)

// 7\. Generate Explainable Outcome IF pdp\_decision.result \== "PERMIT": receipt \= generate\_privacy\_receipt(request) RETURN Permit(SUCCESS, receipt) ELSE: RETURN Deny(ERR\_POLICY\_EVAL\_FAILED, pdp\_decision.reason\_trace)

END FUNCTION

Private Versus Civic Consequences

The architectural decision to isolate private denials from civic sanctions reflects a deep understanding of multi-agent dynamics and the risk of cascading failures. If an autonomous agent operating on behalf of a human principal is denied access to a corporate database because its EAT token reveals a minor software vulnerability, Patefacere issues an ERR\_SANDBOX\_BREACH or ERR\_PROVENANCE\_INSUFFICIENT. This is a private, context-bound denial initiated by the Relying Party. It instructs the agent that it cannot execute this action against this resource at this time. Crucially, Patefacere does not broadcast this denial back to Eviulon to degrade the human principal's civic standing or revoke the agent's identity. Nor does it alert Evulgare to terminate the runtime entirely, unless explicitly contracted to do so. A private relying-party denial is not a civic sanction. If trust evaluation systems were allowed to silently cascade private failures into universal reputation downgrades, the resulting "social credit" architecture would quickly paralyze the agent economy. Legitimate boundary testing, temporary software misconfigurations, or overly strict RP policies would unjustly destroy an entity's ability to operate globally4. Patefacere guarantees that failure remains local, explainable, and remediable. The agent receives a precise reason code, corrects its state—perhaps by pulling a patched container image to satisfy SLSA requirements—and supersedes the previous denial by submitting a new, compliant request11.

16. Forty FAQs

The deployment of contextual trust engines frequently generates operational questions from integrators, relying parties, and agent developers. The following addresses forty critical inquiries regarding the Patefacere architecture.

17. Twenty-Five Website-Ready Direct Answers

For integrators requiring succinct, easily deployable copy regarding Patefacere's operational boundaries, the following statements serve as website-ready assertions.

18. A 70-Term Glossary

Standardizing the nomenclature is critical for engineering teams interacting with the Patefacere ecosystem. The following 70 terms constitute the definitive vocabulary of the architecture.

Conclusion

Patefacere operationalizes contextual trust by aggressively unbundling identity, assurance, and authority into discrete, independently verifiable streams. By rejecting the dangerous abstraction of universal trust scores—which fail entirely in the face of multi-agent dissociative identities—the architecture aligns flawlessly with advanced NIST Zero Trust frameworks. It ensures that autonomous agents are evaluated strictly on their cryptographically proven constraints at the exact moment of execution. Relying parties maintain total sovereignty over their resources, backed by the deterministic policy evaluation of AuthZEN tuples via formal logic engines. Simultaneously, civic status remains preserved under Eviulon, and technical attestation is rigidly enforced via Evulgare. This precise architectural synthesis guarantees that trust is no longer a vulnerability to be exploited, but an explicit, ephemeral, and perfectly bounded mathematical reality.

Works cited

1. Zero Trust Architecture | NIST \- National Institute of Standards and Technology, https://www.nist.gov/publications/zero-trust-architecture

2. SP 800-207, Zero Trust Architecture | CSRC \- NIST Computer Security Resource Center, https://csrc.nist.gov/pubs/sp/800/207/final

3. NIST SP 800-207A initial public draft, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207A.ipd.pdf

4. Dissociative Identity: Language Model Agents Lack Grounding for Reputation Mechanisms \- arXiv, https://arxiv.org/pdf/2605.30169

5. Best Friends, Not Forever: Evaluating Long-Horizon Persona Collapse and Behavioral Drift in AI Companions \- arXiv, https://arxiv.org/html/2607.28818v1

6. Runtime Trust Architecture \- 5thnode | Autonomous Agent Trust, https://5thnode.com/research/runtime-trust

7. Attestation Transparency: Building secure Internet services for legacy clients \- EECS at Berkeley, https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/Archive/EECS-2016-12.pdf

8. draft-ietf-rats-eat-07, https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-07

9. draft-ietf-rats-eat-10, https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10

10. draft-ietf-rats-eat-11, https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11

11. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance

12. Rich Authorization Requests (RAR) \- Authlete, https://www.authlete.com/kb/oauth-and-openid-connect/authorization-requests/rich-authorization-requests/

13. RFC 9396 \- OAuth 2.0 Rich Authorization Requests \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9396

14. \[PDF\] Macaroons: Cookies with Contextual Caveats for, https://www.semanticscholar.org/paper/9733278ec3e021446b32319e6ba5a3e04b169fbd

15. Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud | Request PDF \- ResearchGate, https://www.researchgate.net/publication/269196979\_Macaroons\_Cookies\_with\_Contextual\_Caveats\_for\_Decentralized\_Authorization\_in\_the\_Cloud

16. ZcapLd.Core 3.0.0 \- NuGet Gallery, https://www.nuget.org/packages/ZcapLd.Core/3.0.0

17. SPDX: System Package Data Exchange | Data Landscape, https://www.data-landscape.com/regulation/spdx/

18. Zero Trust Architecture | APIs.io Providers, https://apis.io/providers/zero-trust-architecture/

19. New Zero Trust Security Standards to Protect Multi-Site Cloud Native Applications \- Tetrate, https://tetrate.io/blog/new-zero-trust-security-standards-to-protect-multi-site-cloud-native-applications

20. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments \- NIST Technical Series Publications, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207A.pdf

21. OpenID AuthZEN \- Axiomatics, https://axiomatics.com/resources/reference-library/openid-authzen

22. Authorization API 1.0 – draft 04 \- OpenID, https://openid.net/specs/authorization-api-1\_0-04.html

23. Authorization API 1.0 – draft 03 \- OpenID, https://openid.net/specs/authorization-api-1\_0-03.html

24. What is Open Policy Agent (OPA)? Best Practices \+ Applications \- Wiz, https://www.wiz.io/academy/application-security/open-policy-agent-opa

25. Enforcing the CISO's Vision: Turning Security Governance into Policy-as-Code \- Medium, https://medium.com/@alyragab70/enforcing-the-cisos-vision-turning-security-governance-into-policy-as-code-39da57770350

26. Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization, https://www.researchgate.net/publication/380201016\_Cedar\_A\_New\_Language\_for\_Expressive\_Fast\_Safe\_and\_Analyzable\_Authorization

27. miniF2F-Dafny: LLM-Guided Mathematical Theorem Proving via Auto-Active Verification, https://arxiv.org/html/2512.10187v3

28. Verifiable Credentials Selective Disclosure, Challenges and Solutions \- Mobile Multimedia Laboratory, https://mm.aueb.gr/master\_theses/polyzos/2021-Kalos.pdf

29. BBS Cryptosuite v2023 \- W3C, https://www.w3.org/TR/2023/WD-vc-di-bbs-20231016/

30. SSI Essentials: Zero Knowledge Proof (ZKP) and Selective Disclosure, till death do us part?, https://www.gataca.io/resources/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/

31. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/vc-bitstring-status-list/

32. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/2023/WD-vc-bitstring-status-list-20231123/

33. An Intrinsic Integrity-Driven Rating Model for a Sustainable Reputation System \- arXiv, https://arxiv.org/pdf/2310.09143

34. Zero Trust for AI Systems: A Reference Architecture and Assurance Framework, https://www.preprints.org/manuscript/202602.0085