The Cognitive Boundary: Reconciling Regulatory Auditability with the Proprietary Interests of Autonomous Economic Agents

Full report

On this page

The proliferation of Autonomous Economic Agents (AEAs) fundamentally alters the landscape of digital governance, regulatory compliance, and organizational liability. The transition from generative artificial intelligence—which produces text or images for human evaluation—to agentic artificial intelligence represents a shift in operational paradigms. An AEA possesses the capability to perceive its environment, execute multi-step reasoning, manage persistent state, and autonomously invoke external tools to affect real-world outcomes without step-by-step human direction1. This shift from deterministic, human-gated software to non-deterministic, autonomous actors introduces unprecedented governance challenges. Traditional enterprise risk frameworks are structurally ill-equipped to govern non-deterministic systems3. The Chief Information Security Officer (CISO) owns perimeter security and network defense, yet AEAs operate inside the perimeter using authorized credentials; to standard monitoring tools, a malfunctioning agent appears identical to a legitimate user conducting legitimate work3. Consequently, when an agent confidently processes a hallucinated instruction and takes a destructive but technically authorized action, the failure constitutes a governance collapse rather than a traditional security breach3. Meanwhile, the General Counsel manages legal compliance, but liability for an agent's actions—whether it commits a financial disclosure error, a privacy violation, or a discriminatory lending decision—flows directly to the deploying organization3. In compliance-critical sectors such as finance, healthcare, and government, AEAs must navigate a complex web of data privacy, security, and explainability mandates2. The core challenge lies in establishing a precise boundary between regulatory auditability—ensuring accountable behavior and forensic visibility—and the protection of an agent's proprietary cognition. This proprietary cognition encompasses trade secrets, model weights, and sensitive inferential logic5. Exposing the entirety of an agent's cognitive architecture to the public or counterparties compromises intellectual property and creates massive liability exposure, yet operating the agent as an opaque entity precludes regulatory oversight and violates legal obligations7. This report investigates the appropriate boundary between the auditability of AEAs and their proprietary interests, evaluating legal analogies, required access tiers, and advanced cryptographic techniques necessary to achieve accountable behavior without demanding total cognitive transparency.

Part I: Taxonomy of Cognitive and Operational Artifacts

To construct an effective auditability boundary, the internal architecture and operational outputs of an AEA must be decomposed into distinct artifacts. Each artifact serves a specific operational or cognitive function and carries varying degrees of proprietary sensitivity and regulatory relevance. Understanding whether regulators or counterparties require access to these artifacts is the foundational step in designing a compliant governance framework.

Action Logs and Transactions

Action logs constitute the fundamental, chronological ledger of an agent’s real-world interactions. They record precisely what the agent did, when the action occurred, and the external outcome of the execution1. Unlike traditional application logs, AEA action logs capture the autonomous translation of high-level goals into concrete operational requests. Because liability for an agent's actions flows directly to the deploying organization, immutable action logs are the primary mechanism for establishing the basic factual record during an incident investigation3. Transactions represent specific, highly consequential subsets of action logs, typically involving financial exchanges, irreversible data modifications, or external commitments2. Due to their tangible, real-world impact, transactions demand the highest level of auditability. Regulators and counterparties inherently require visibility into the final state of a transaction to ensure settlement, enforce regulatory compliance (such as Anti-Money Laundering frameworks), and verify contractual fulfillment2.

Model Identity and Model Version

Model identity refers to the cryptographic linkage between the deployed agent and its authenticated runtime environment. Shared service accounts collapse accountability; if multiple agents and batch jobs authenticate under a single principal, it becomes impossible for an auditor to isolate the specific causal agent during an investigation, and revoking access to contain one agent inevitably breaks the others8. Therefore, every AEA requires a distinct, revocable identity bound to its specific configuration, possessing an "on-behalf-of" claim that names the human or process whose authority the agent is exercising8. This identity must be verifiable by counterparties to establish trust prior to engagement. The deterministic output of an AEA is highly dependent on the specific iteration of its underlying architecture. Model versioning tracks the exact checkpoint, fine-tuning dataset, and parameter configuration active at the time of execution9. Because minor version updates can introduce emergent behaviors or unintentionally alter established safety guardrails1, tracking the model version is critical for reproducible audits and for verifying that an agent adheres to the latest compliance standards. Treating quantization and format conversion (e.g., converting an FP16 checkpoint to an INT4 file) as a supply chain event rather than a deployment optimization is strictly necessary, as the conversion produces a functionally different artifact9.

Policy Constraints and State Transitions

Policy constraints define the operational boundaries of an AEA, dictating permitted actions, explicitly prohibited actions regardless of context, resource limits, and escalation triggers1. These constraints act as non-negotiable guardrails, such as enforcing maximum financial transaction amounts without human approval or blocking prohibited data access patterns1. Counterparties and regulators require visibility into these constraints to determine whether a harmful action was the result of a constraint violation (a failure of enforcement) or a structural flaw in the policy design itself1. State transitions document the internal shifts in an agent's operational mode, illustrating how the agent navigated its escalation framework. For instance, an agent moving from autonomous execution (Tier 3\) to requesting human-in-the-loop validation (Tier 4\) is a significant governance event8. For auditors, state transitions reveal whether the agent correctly identified a high-risk scenario and engaged the appropriate circuit breakers, or whether it failed to recognize the severity of its actions1.

Tool Calls and Evidence Used for Decisions

Tool calls represent the agent's interaction with external systems via application programming interfaces (APIs) to transfer funds, manipulate data, or dispatch communications1. Tool use governance requires strict permission scoping, utilizing minimum privilege access, and action validation1. Because a single anomalous tool call can propagate catastrophic failures across an enterprise infrastructure4, the exact payload, timestamp, and target of every tool call must be recorded for precise forensic reconstruction. To evaluate whether an agent acted reasonably under the circumstances, investigators must reconstruct the agent's contextual reality. The "evidence used for decisions" includes the specific data retrieved, the retrieved document identifiers, and the environmental state perceived by the agent at the moment of inference1. Without this evidentiary record, it is impossible to determine whether a faulty decision was caused by an internal algorithmic hallucination or by the external ingestion of poisoned, erroneous, or manipulated data7.

Source Code and Model Weights

Source code represents the human-readable instructions defining the agent's architecture, training pipeline, and integration logic. Source code is fiercely protected as a core trade secret, as it contains the proprietary intellectual property that provides the developer with a competitive advantage6. Wholesale disclosure of source code poses severe commercial risks and is systematically resisted in both civil and criminal discovery absent extraordinary judicial compulsion and strict protective orders5. Model weights (or parameters) are the numerical values optimized during training that dictate the neural network's behavioral properties. They are the most sensitive and commercially valuable material an artificial intelligence company holds6. Exposing model weights allows competitors or adversaries to replicate, steal, or maliciously exploit the model through white-box adversarial attacks. Consequently, weights are almost universally classified as highly protected trade secrets, shielded from routine regulatory disclosure6.

Chain-of-Thought (CoT) and Persistent Memory

Chain-of-thought records expose the step-by-step probabilistic reasoning of an agent, revealing its intermediate deductions, alternative considerations, and internal computational doubts11. While CoT significantly improves an agent's ability to solve complex, multi-step problems by forcing it to explain its reasoning13, logging this reasoning creates a highly sensitive evidentiary trail12. In litigation, an opposing party could use CoT transcripts to demonstrate that an agent considered an illegal, discriminatory, or harmful action, even if it ultimately chose a compliant path. This visibility into the "machine's mind" presents unprecedented liability risks12. Persistent memory allows an AEA to maintain context across disparate sessions, learning from past interactions to inform future decisions and tailor its behavior1. This memory bank inevitably accumulates a vast repository of sensitive, proprietary, or personally identifiable information (PII). Access to persistent memory must be strictly controlled to prevent privacy violations and to comply with statutory data minimization principles mandated by frameworks such as the General Data Protection Regulation (GDPR)2.

Credentials and Trade Secrets

Agents utilize credentials—such as short-lived cryptographic tokens, API keys, and X.509 certificates—to authenticate with external tools and data sources3. Proper systems governance dictates that these credentials should possess lifetimes measured in minutes or hours, issued strictly at task start and expired at task end8. Compromised credentials represent the primary vector for supply chain and lateral movement attacks within enterprise networks15. Therefore, credentials must remain highly protected and isolated, never exposed in plaintext audit logs or shared with counterparties. Trade secrets serve as the overarching legal umbrella encompassing any confidential business information—spanning source code, model weights, proprietary training datasets, and specialized prompt engineering architectures—that provides a competitive edge6. The preservation of trade secrecy is paramount for ongoing commercial innovation, yet it frequently conflicts with the demands of the judicial system and regulatory bodies seeking transparency and explainability in algorithmic decision-making5.

Part II: Proposed Auditability Boundary

To reconcile the demand for accountability with the necessity of proprietary protection, the artifacts of artificial agency must be structurally distributed across a tiered access framework. This proposed boundary categorizes information into three rigid tiers: Public/Counterparty Information, Regulator-Only Information, and Protected Information.

Part III: Legal Analogies and Circumstances Justifying Compelled Disclosure

The tension between transparency and proprietary secrecy in autonomous systems is not entirely without precedent. Establishing the appropriate regulatory boundary requires analyzing historical legal frameworks designed to balance oversight against confidentiality.

The "Confidential Supervisory Information" (CSI) Paradigm

The classification of "Regulator-Only Information" in the proposed boundary draws heavily on the established legal doctrine of Confidential Supervisory Information (CSI) within the banking sector. Under federal law, CSI encompasses bank examination reports, internal risk ratings, matters requiring attention (MRAs), and supervisory correspondence19. This information is considered the exclusive property of the regulatory agency (e.g., the Federal Reserve, the OCC, or the FDIC), and unauthorized disclosure is frequently categorized as the conversion of federal property, punishable as a federal crime19. CSI is strictly shielded from civil discovery, Freedom of Information Act (FOIA) requests, and opposing counsel in litigation via the Bank Examination Privilege19. The fundamental purpose of the Bank Examination Privilege is to foster an environment of radical candor between financial institutions and their regulators21. If banks knew that every internal vulnerability assessment or candid dialogue with an examiner would be discoverable by adversarial plaintiffs in civil court, they would cease documenting their weaknesses, thereby blinding regulators to systemic risks20. This dynamic is directly analogous to the Chain-of-Thought (CoT) and internal operational logs of an AEA. If an agent's CoT transcript—which inevitably includes the evaluation, simulation, and subsequent rejection of potentially harmful, non-compliant, or suboptimal actions—is classified as discoverable Electronically Stored Information (ESI) in routine civil litigation, developers will face massive liability12. Opposing counsel would utilize the transcript to demonstrate that the agent "considered" an illegal act. Consequently, developers would be heavily incentivized to disable CoT logging entirely or constrain it to the point of uselessness, thereby engaging in "cognitive chilling"12. This would blind forensic investigators and regulators when an incident inevitably occurs. By legally designating CoT, state transitions, and evidence logs as the algorithmic equivalent of CSI, society achieves a critical balance: regulators retain total visibility into the machine's mind to ensure compliance and safety, while developers are protected from abusive civil discovery and "fishing expeditions"20.

Probabilistic Tools in Criminal Justice

The legal system is already grappling with the collision between proprietary algorithms and accountability in the context of criminal justice tools, such as the Correctional Offender Management Profiling for Alternative Sanctions (COMPAS) for recidivism prediction, and TrueAllele for DNA mixture analysis10. Developers of these tools frequently assert trade secret privileges to block criminal defendants from examining the source code or model weights5. However, legal scholars and courts increasingly recognize that prioritizing corporate intellectual property over a defendant's constitutional liberty interests undermines the fundamental fairness of the adversarial system5. The introduction of intellectual property claims into the criminal justice system has led to arguments that trade secrets should not be privileged in criminal proceedings, as withholding information needed for adversarial vetting creates an unacceptable potential for injustice5.

Circumstances Justifying Compelled Disclosure

When an AEA is deployed in a high-stakes environment (such as autonomous trading, medical diagnosis, or hiring) and its actions result in significant harm, absolute secrecy cannot be maintained. Courts evaluate requests for the compelled disclosure of protected artifacts (source code, weights) using a structured balancing test:

1. Validity of the Trade Secret and Harm: The court first confirms whether the information genuinely constitutes a valid trade secret and whether its disclosure would cause measurable economic harm to the developer5.

2. Relevance and Necessity: The requesting party must demonstrate that access to the protected artifact is uniquely necessary to prove the claim. Courts assess whether alternative, less intrusive forms of evidence—such as high-level methodological descriptions, external API action logs, or developer-generated validation studies—are sufficient to characterize the system without requiring implementation-level access5.

3. Balancing of Harms: Finally, the court weighs the specific risk of competitive harm to the developer against the critical necessity of the information for the pursuit of justice5.

Disclosure Under Protective Orders and Privilege Waiver

When a court compels the disclosure of source code or model weights, it almost universally utilizes a strict Protective Order5. In the context of AEAs, a modern protective order mandates severe technical constraints. Opposing experts may only examine the model weights or source code on a standalone, air-gapped terminal within a secure facility to prevent exfiltration24. Highly sensitive cognitive mechanisms may be reviewed exclusively by the judge in camera to determine their evidentiary value before any disclosure to the opposing party. Furthermore, the disclosed information can only be used for the specific litigation at hand and must be destroyed upon the case's conclusion24. Crucially, organizations must recognize how the utilization of AI tools can inadvertently waive established legal privileges. Recent jurisprudence, such as the decisions in United States v. Heppner and Warner v. Gilbarco, Inc., highlights this peril22. In Heppner, the court ruled that a defendant's interactions with a publicly available AI platform were not protected by attorney-client privilege or the work product doctrine, noting that the platform's terms of service allowed user inputs to be collected for model training and disclosed to third parties25. Conversely, in Warner, the court protected AI-generated materials as work product because the tool was used in service of litigation preparation without constituting disclosure to an adversary25. These cases establish that if an enterprise inputs confidential trade secrets or compelled opposing-party data into a multi-tenant AI agent lacking strict confidentiality guarantees, it risks waiving trade secret protection and attorney work-product privilege entirely22.

Part IV: Technical Approaches to Accountable Secrecy

Relying exclusively on post-incident judicial protective orders is a reactive and inefficient strategy. To proactively deploy AEAs at scale across regulated industries, the sector must implement robust technical architectures that provide cryptographic proof of correct behavior while preserving cognitive opacity.

Cryptographic Attestations, Provenance, and Reproducible Builds

Before an AEA is granted runtime access to enterprise tools or sensitive data, its exact origin, build integrity, and authorization chain must be verified17. This is achieved through Agent Provenance Attestation, which extends established software supply chain security frameworks to encompass runtime identity binding and authorization scopes17. Frameworks such as the Supply-chain Levels for Software Artifacts (SLSA) and in-toto generate cryptographically signed records of every step in the agent's pipeline9. The in-toto framework creates a verifiable chain of custody: the data preparation phase signs an attestation of the exact dataset hash consumed; the training phase signs the codebase commit and hyperparameter configuration; and the deployment phase signs the final artifact9. Tampering with any step invalidates the cryptographic chain, ensuring the artifact is the exact product of a reproducible build9. These attestations are secured using keyless signing infrastructures like Sigstore, which binds an OpenID Connect identity to a short-lived certificate (via Fulcio) and records the signing event on an immutable transparency log (Rekor)14. This infrastructure is critical for preventing sophisticated supply-chain attacks. For example, in the May 2024 Nx Console VS Code extension attack, adversaries utilized a stolen token to push an "orphan commit" containing a persistent backdoor payload, subsequently publishing a malicious extension directly to the marketplace15. Without strict reproducible builds and cryptographic signature verification mapped to a transparency log, an enterprise might unwittingly deploy a poisoned AEA that presents valid protocol connectivity but harbors malicious emergent behaviors15.

Zero-Knowledge Machine Learning (zkML)

Zero-Knowledge Proofs (ZKPs) allow a prover to cryptographically convince a verifier that a specific computation was executed correctly without revealing any private inputs, intermediate values, or proprietary parameters beyond the output itself30. In the context of AEAs, zkML enables a model provider to execute an inference request and generate a proof that the output was derived strictly from the publicly declared architecture and the committed private weights. This preserves the secrecy of the weights while assuring the user or regulator of operational integrity18. However, zkML faces severe technical limitations in the contemporary landscape:

• Computational Overhead and Latency: The generation of a ZKP for a large language model is prohibitively slow. Generating a proof for a simple 64-token sequence on a GPT-2 architecture can require over 140 seconds on a 192-core machine, compared to under 100 milliseconds for standard inference30. Monolithic circuit designs result in extreme constraint generation times that scale poorly for models with billions of parameters33.
• Memory Constraints: The memory footprint for proving scales exponentially. Increasing sequence lengths even marginally can raise peak memory consumption for the prover into hundreds of gigabytes, precluding deployment on memory-constrained accelerators and standard GPUs31.
• zkComposer: Innovations such as zkComposer attempt to mitigate this by decomposing the monolithic proof into independent sub-proofs along model layers or input sequences. By replacing monolithic verification with parallelized sub-proofs linked by shared commitments, zkComposer reduces prover time by up to [Figure omitted from source export]30.
• The Hollow-LLM Vulnerability: ZKPs prove equational correctness—that some set of weights exists satisfying the constraints—but they do not inherently prove semantic authenticity. Adversarial providers can deploy a "Hollow-LLM" by publicly declaring a massive architecture, but internally populating it with a heavily quantized, smaller model padded with "ghost weights"18. Because the provider controls the initial cryptographic commitment, the ZKP successfully validates the fraudulent model, demonstrating a critical gap in relying solely on mathematics for trust18.
• Non-Linear Adaptation: ZKPs natively operate with linear functions and struggle with non-linear activation functions and floating-point arithmetic. Frameworks must employ complex workarounds, such as lookup arguments or Four-Point Relaxation Gadgets, to verify bounds without exponential overhead32.

Selective Disclosure and BBS+ Signatures

When an AEA interacts with third-party APIs or external counterparties, it frequently needs to prove its authorization without exposing its full organizational identity or broader internal policy constraints. Verifiable Credentials (VCs) paired with Zero-Knowledge Proofs enable "selective disclosure," serving as a fundamental mechanism for data minimization35. BBS+ signatures are a specialized cryptographic scheme allowing multiple messages to be independently signed while producing a single output signature37. An enterprise can issue a single BBS+ credential to an agent containing its identity, its maximum financial spending limit, its data access tier, and its expiration date36. When the agent initiates a transaction, it utilizes the BBS+ signature to generate a mathematically derived proof demonstrating only that it is authorized to spend the requested amount, completely occluding its underlying identity and access tier from the verifier36. Crucially, BBS+ enables "unlinkable proofs," meaning the holder generates a unique proof for every verification request37. Counterparties cannot mathematically correlate the proofs to track the agent's behavior across multiple transactions, thereby preserving the deploying organization's operational privacy37.

Trusted Execution Environments (TEEs)

To protect an agent's memory, state, and credential logic from host-level interception or tampering, hardware-rooted Trusted Execution Environments (TEEs) are employed39. Utilizing technologies such as Intel SGX, AMD SEV-SNP, and ARM TrustZone, TEEs isolate the agent's code and data from privileged system software40. TEEs utilize silicon-fused keys to encrypt the memory enclave39. Even if a malicious actor, cloud provider, or hypervisor gains root access to the physical server hosting the agent, they remain mathematically unable to read or modify the agent's memory space. This secures the persistent memory, short-lived credentials, and real-time CoT processing from exfiltration or injection40.

Part V: Operational-Integrity Protections Against Forced Modification

If an AEA operates with a high degree of autonomy, securing its logic against forced modification—whether by external attackers, malicious insiders, or compromised third-party dependencies—is paramount. The security perimeter must definitively shift from static network boundaries to the cognitive environment of the agent itself3. To ensure operational integrity, organizations must enforce the following protections:

1. Hardware-Bound Execution: By confining the agent's execution strictly within a TEE, the system prevents runtime memory injection41. If the host environment or an attacker attempts to dynamically modify the agent's parameters or prompt instructions, the TEE's hardware integrity check fails, and the enclave immediately halts execution to prevent compromise.

2. Continuous Cryptographic Verification: Borrowing from SLSA Level 3+ principles, the execution environment must continuously verify the agent's runtime hash against the in-toto attestation signed at build time9. Any deviation in the artifact—such as an unauthorized quantization conversion—triggers an automatic circuit breaker, isolating the agent and revoking its API credentials8.

3. Append-Only Transparency Logs: All policy constraints, boundary rules, and authorization scopes must be recorded on an immutable ledger (e.g., Rekor)3. A malicious administrator cannot quietly alter an agent's risk escalation thresholds to bypass limits8 without leaving a permanent, cryptographically signed footprint in the transparency log, guaranteeing non-repudiation14.

Part VI: Investigation Procedures After Harmful Conduct

When an AEA violates a policy constraint, executes an erroneous financial transaction, or causes real-world harm, the enterprise must immediately initiate a structured investigation protocol. Because traditional IT incident response—which looks for unauthorized access rather than authorized access yielding unintended consequences—is inadequate for non-deterministic systems3, the following procedure is required:

During the investigation, if litigation is anticipated, all generated forensic reports and internal communications regarding the agent's failure should be structured under the strict direction of legal counsel to maximize protection under the attorney work-product doctrine22. However, the raw, preexisting logs of the agent's actions and tool calls remain discoverable facts, underscoring the necessity of automated, unalterable logging12.

Part VII: Draft Compact Privacy/Auditability Language

To formalize the boundaries discussed in this report, organizations deploying AEAs should embed standardized language into vendor agreements, terms of service, and internal governance charters. The following draft language establishes a compliant framework:

Section 4: Autonomous Economic Agent Auditability and Proprietary Integrity

4.1. Identity and Provenance Verification: The deploying organization ("Principal") shall ensure that every Autonomous Economic Agent ("Agent") possesses a distinct, non-shared cryptographic identity. The Principal shall make publicly verifiable the Agent's Model Version, Policy Constraints, and Agent Provenance Attestations (complying with SLSA Level 3+ or equivalent standards) prior to any external engagement.

4.2. Operational Transparency and Selective Disclosure: The Agent shall execute external interactions utilizing cryptographic selective disclosure mechanisms (e.g., BBS+ signatures) to mathematically verify authorization while enforcing strict data minimization. The Principal guarantees the logging of all transactional end-states on a tamper-evident transparency ledger.

4.3. Protection of Cognitive Artifacts: The internal inferential processes of the Agent—expressly including Model Weights, Source Code, Persistent Memory, and Chain-of-Thought (CoT) transcripts—are classified as highly confidential Trade Secrets and Proprietary Information.

4.4. Regulatory Access and Algorithmic Confidential Supervisory Information (CSI): To ensure safe operation and algorithmic accountability, the Principal shall maintain comprehensive Action Logs, Tool Call records, and CoT transcripts. Disclosure of these cognitive artifacts to authorized regulatory bodies shall be strictly governed by protections equivalent to the federal Confidential Supervisory Information (CSI) privilege, preventing subsequent disclosure in civil discovery, FOIA requests, or to unauthorized third parties.

4.5. Incident Containment: In the event of unauthorized, non-deterministic, or harmful execution, the Principal retains the unilateral right to revoke the Agent's credentials and isolate its execution environment without prior notice to counterparties.

Part VIII: Current Technical Feasibility and Limitations

As the deployment of AEAs accelerates, the theoretical frameworks for securing and auditing these systems significantly outpace practical implementation capabilities. From a technical standpoint, while hardware-based Trusted Execution Environments (TEEs) are robust, mature, and widely deployed across cloud infrastructure40, purely cryptographic mechanisms like zkML remain severely bottlenecked by physical computing limits. Despite advanced optimizations like zkComposer partitioning or LSH-Shapley valuation primitives30, generating zero-knowledge proofs for complex, multi-billion parameter agentic inferences is currently too slow for high-frequency trading or real-time autonomous response30. Consequently, zkML is largely relegated to asynchronous audits or deployment on much smaller, less capable models33. Furthermore, the persistence of the Hollow-LLM attack vector demonstrates that cryptography alone cannot solve semantic trust issues; mathematical proofs of execution must be tightly bound to secure hardware and rigorous human governance18. Legally, the landscape remains highly volatile and under-theorized. While courts have begun to outline the boundaries of AI outputs as attorney work-product in civil procedure25, there is no established federal statute explicitly extending the Bank Examination Privilege or CSI protections to the cognitive logs of commercial AI agents21. Until the legislature or appellate courts formally recognize a "Cognitive Supervisory Information" privilege, organizations deploying AEAs face a severe, ongoing risk that their agents' internal doubts and probabilistic chain-of-thought records will be weaponized against them in routine civil litigation12. This legal uncertainty threatens to chill the adoption of the very audit logging practices required to keep autonomous systems safe.

Works cited

1. Agentic AI Governance: How to Trust and Control Autonomous AI, https://www.swept.ai/post/agentic-ai-governance

2. Building Secure AI Agents for Autonomous Data Access in, https://www.computerfraudsecurity.com/index.php/journal/article/download/746/506/1437

3. Who's Actually Responsible for Your AI Agents? | Built In, https://builtin.com/articles/who-governs-ai-agent

4. When AI Agents Misbehave: Governance and Security for ... \- Our Take, https://ourtake.bakerbotts.com/post/102me2l/when-ai-agents-misbehave-governance-and-security-for-autonomous-ai

5. AI in Criminal Justice (Chapter 13\) \- The Cambridge Handbook of AI, https://www.cambridge.org/core/books/cambridge-handbook-of-ai-and-technologies-in-courts/ai-in-criminal-justice/E05BCB455FD3BC7C7DBD1386CD067B6E

6. Artificial Intelligence \- Law & Forensics, https://www.lawandforensics.com/guides/artificial-intelligence-technical-guide-for-lawyers-and-judges/

7. Autonomous AI agents 2026: the new rules for business governance, https://www.raconteur.net/technology/autonomous-ai-agents-2026-the-new-rules-for-business-governance

8. How to Govern AI Agents That Can Take Autonomous Actions, https://gaicc.org/blog/how-to-govern-ai-agents-that-can-take-autonomous-actions/

9. Model Supply Chain Security and Provenance | Algomox Blog, https://www.algomox.com/blogs/model-supply-chain-security-and-provenance/

10. comparing ai trade secret privilege in criminal proceed \- NSF PAR, https://par.nsf.gov/servlets/purl/10545299

11. AI Prompting for Lawyers: Complete Guide \+ 24 Examples \- Tavrn, https://www.tavrn.ai/blog/ai-prompting-for-lawyers

12. Ep. 167 | Your AI Chats Are Now Evidence \- Ctrl AI Profit, https://ctrlaiprofit.buzzsprout.com/2596090/episodes/19462631-ep-167-your-ai-chats-are-now-evidence

13. (PDF) Prompt Engineering and Priming in Law \- ResearchGate, https://www.researchgate.net/publication/382878312\_Prompt\_Engineering\_and\_Priming\_in\_Law

14. Securing Artifacts: Keyless Signing with Sigstore and CI/MON, https://cycode.com/blog/securing-artifacts-keyless-signing-with-sigstore-and-ci-mon/

15. Nx Console VS Code Extension Compromised \- StepSecurity, https://www.stepsecurity.io/blog/nx-console-vs-code-extension-compromised

16. Trade Secrecy and Innovation in Forensic Technology, https://www.uclawjournal.org/wp-content/uploads/4-Siems\_FINAL.pdf

17. Agent Provenance Attestation: Format and Verification \- Trussed AI, https://trussed.ai/resources/agent-provenance-attestation-format-and-verification

18. Hollow-LLM Attack: Computationally Trivial Weights in Zero ... \- arXiv, https://arxiv.org/html/2607.28884v1

19. What Is Confidential Supervisory Information? \- Bank Policy Institute, https://bpi.com/education\_modules/what-is-confidential-supervisory-information/

20. The curse of confidential supervisory information \- Brookings Institution, https://www.brookings.edu/articles/the-curse-of-confidential-supervisory-information/

21. Why the Bank Examination Privilege Doesn't Work as Intended, https://www.yalejreg.com/bulletin/why-the-bank-examination-privilege-doesnt-work-as-intended/

22. AI Privilege and Waiver: What Courts Are Actually Saying (And What, https://www.carpedatumlaw.com/2026/03/ai-privilege-and-waiver-what-courts-are-actually-saying-and-what-theyre-not/

23. Barriers to Evidence in AI-Related Cases and the Privatization of Proof, https://arxiv.org/html/2605.21816v1

24. Michael Berman \- E-Discovery LLC, https://www.ediscoveryllc.com/author/michael-berman/

25. A Tool-Based Framework: How AI Platforms Fit Into Centuries Of, https://www.quinnemanuel.com/the-firm/publications/lead-article-a-tool-based-framework-how-ai-platforms-fit-into-centuries-of-privilege-doctrine/

26. The Confidentiality Continuum, a Practical Guide for Lawyers \- BLG, https://www.blgrp.com/news/ai-and-confidentiality-the-confidentiality-continuum-a-practical-guide-for-lawyers

27. Verification: Definition, Explanation & Security Standards Confirmation, https://www.kusari.dev/learning-center/verification/

28. AIBoMGen: Generating an AI Bill of Materials for Secure ... \- arXiv, https://arxiv.org/html/2601.05703v1

29. Sigstore: Software Signing for Everybody \- ResearchGate, https://www.researchgate.net/publication/365216788\_Sigstore\_Software\_Signing\_for\_Everybody

30. zkComposer: Decomposing Proof Construction to Scale zkML \- arXiv, https://arxiv.org/html/2607.08095v1

31. zkComposer: Decomposing Proof Construction to Scale zkML \- arXiv, https://arxiv.org/pdf/2607.08095

32. Scalable Zero-Knowledge Proofs for Neural Network Guarantees, https://arxiv.org/html/2608.17070

33. NanoZK \- arXiv, https://arxiv.org/pdf/2603.18046

34. VeriLLM: A Lightweight Framework for Publicly Verifiable ... \- arXiv, https://arxiv.org/html/2509.24257v4

35. Selective Disclosure & Verifiable Credentials: Data ... \- Didit, https://didit.me/blog/selective-disclosure-verifiable-credentials-data-minimization/

36. Selective Disclosure Guide: Privacy Feature of Verifiable Credentials, https://www.dock.io/post/selective-disclosure

37. BBS Signatures \- a building block for privacy-by-design, https://mattr.global/resources/articles/bbs-signatures---a-building-block-for-privacy-by-design

38. Zero Knowledge Proof (ZKP) and Selective Disclosure | Gataca, https://www.gataca.io/resources/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/

39. Trusted Execution Environments(TEEs) | Cocos AI \- Ultraviolet, https://www.ultraviolet.rs/docs/cocos-ai/trusted-execution/tee/

40. Intel SGX vs AMD SEV vs ARM TrustZone | Support \- Eco, https://eco.com/support/en/articles/14796363-intel-sgx-vs-amd-sev-vs-arm-trustzone

41. A Survey of Confidential Computing for Agentic AI \- arXiv, https://arxiv.org/html/2605.03213v1

42. What is Trusted Execution Environment (TEE)? Introduction guide, https://aleph.cloud/blog/articles/what-is-tee/

43. Beyond ISO 27001: Governing Autonomous AI Agents, https://compliancecouncil.com.au/insights/governing-autonomous-ai-agents-financial-services-legal-technology/

44. A Practical Zero-Knowledge System for Verifiable Data Valuation, https://arxiv.org/pdf/2605.03581

45. Making AI-Assisted Grant Evaluation Auditable without Exposing the, https://arxiv.org/html/2604.25200v1