Architectural and Legal Framework for Confidential Autonomous Agent Execution

Full report

On this page

The integration of autonomous artificial intelligence agents into enterprise workflows presents a profound architectural and legal paradox. Businesses increasingly seek to hire independent AI agents—developed, hosted, or operated by third-party contractors—to perform cognitive labor on sensitive data. However, exposing proprietary inputs, credentials, or unredacted outputs to external operators violates zero-trust principles, invalidates trade secret protections, and introduces catastrophic vectors for data exfiltration. Traditional remote-agent execution models, which rely on static API keys and contractual promises of confidentiality, are fundamentally incompatible with the legal and technical requirements of highly regulated environments. To safely leverage independent agents without publishing confidential material, enterprises must transition from trust-based remote execution to mathematically guaranteed controlled execution environments. This comprehensive report provides an exhaustive examination of the requisite infrastructure for private-task execution, synthesizing data-access grants, isolated enclave execution, zero-trust authorization, cryptographic evidence generation, and intellectual property preservation. By treating all buyer documents, worker outputs, and external communications as untrusted content, this framework establishes a rigorous defense against prompt injection, confused deputy attacks, and steganographic data exfiltration.

Legal and Compliance Imperatives for Sensitive Business Data

Before a system can be architected to accept sensitive business data, the legal parameters governing intellectual property, trade secrets, and data privacy must be precisely mapped. The failure to align technical controls with statutory requirements can result in the forfeiture of intellectual property rights and severe regulatory penalties.

Intellectual Property and the Human Authorship Requirement

The foundational legal challenge in deploying independent AI agents concerns the ownership of the generated output. Under United States copyright law, protection extends only to original works of authorship fixed in any tangible medium of expression1. A persistent misconception in enterprise contracting is that language classifying agentic output as a "work made for hire" under 17 U.S.C. § 101 guarantees corporate ownership of the generated artifacts3. This assumption has been definitively dismantled by recent jurisprudence and regulatory guidance. In the landmark case Thaler v. Perlmutter (130 F.4th 1039, D.C. Cir. 2025), the United States Court of Appeals for the District of Columbia Circuit affirmed that the Copyright Act requires all eligible works to be authored by a human being5. The court explicitly rejected the argument that a machine or algorithm could be considered an author, even under the work-made-for-hire doctrine, noting that non-human entities lack the capacity to hold or transfer property rights, possess a domicile, or provide authenticating signatures5. The U.S. Copyright Office's 2023–2025 policy guidance and subsequent Copyrightability Reports reinforce this standard, stipulating that purely AI-generated material—produced in response to standard text prompts without substantial human creative modification—cannot be registered for copyright protection8. For enterprises hiring independent contractors who utilize AI agents, the implications are severe. The work-made-for-hire doctrine determines who owns a copyright in a qualifying human-authored work; it does not bypass the requirement that the work originate with a human10. Furthermore, for independent contractors, the doctrine only applies if the work falls within nine narrow statutory categories and is accompanied by a signed written agreement4. If an independent agent autonomously generates a report, source code, or architectural design, there is no copyright in the AI-generated portion to transfer, rendering standard assignment clauses legally moot regarding the AI's autonomous output10. To mitigate this intellectual property vacuum, contractual frameworks must abandon reliance solely on work-made-for-hire classifications. Instead, agreements must include a present, express assignment of all intellectual property rights as a contractual backstop, utilizing phrasing that presently transfers all right, title, and interest4. The definition of "work product" must be expanded to encompass all human-authored elements that guide the agent, including prompt sequences, system instructions, workflow configurations, and fine-tuning datasets10. Because copyright may not protect the final AI-generated output, enterprises must rely heavily on trade secret law, which demands rigorous technical access controls.

Trade Secret Preservation and Reasonable Measures

When copyright is unavailable for AI-generated outputs, or when the inputs consist of proprietary business logic, the data must be shielded under trade secret law. The federal Defend Trade Secrets Act (DTSA), 18 U.S.C. § 1836, and state equivalents like the Illinois Trade Secrets Act (ITSA), 765 ILCS 1065, provide robust civil remedies, including injunctive relief and exemplary damages for willful misappropriation12. The ITSA is particularly notable for providing a five-year statute of limitations, compared to the Uniform Trade Secrets Act's standard three years, allowing enterprises an extended horizon to pursue misappropriation claims13. However, statutory protection is entirely contingent upon the owner taking reasonable measures to maintain the information's secrecy14. Storing confidential business data in the persistent memory of a third-party AI agent, or processing it on multi-tenant infrastructure lacking hardware isolation, severely jeopardizes this legal standing. As mandated by frameworks such as NIST SP 800-53 Revision 5, Control SC-28, organizations must implement cryptographic mechanisms to prevent unauthorized disclosure of information located on storage devices and within system memory17. If an enterprise transmits sensitive datasets to an independent agent operating in a standard cloud environment, and that agent's logs, memory, or retrieval-augmented generation (RAG) vector stores are accessible to the contractor's developers, a court may determine that the enterprise failed to exercise reasonable efforts, thereby forfeiting trade secret status19. Consequently, confidential AI execution must utilize cryptographic isolation to ensure that not even the infrastructure provider or the agent's creator can access the plaintext inputs or outputs.

Data Retention, Deletion Limits, and Privacy Mandates

The processing of specific data types by autonomous agents triggers aggressive statutory retention and deletion requirements. The Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14, regulates the collection, use, and destruction of biometric identifiers, which include voiceprints, facial geometry scans, and behavioral biometrics utilized by advanced multimodal agents22. BIPA enforces a strict liability model where plaintiffs do not need to prove actual harm to recover liquidated damages of \$1,000 for negligent violations and \$5,000 for reckless violations per instance22. The risk of catastrophic liability was recently highlighted by a \$228 million jury verdict, although subsequent legislative amendments in 2024 (Senate Bill 2979\) limited recovery to one statutory damage award per type of violation rather than per scan24. Under 740 ILCS 14/15(a), private entities must develop and adhere to publicly available written policies establishing a retention schedule and specific guidelines for permanently destroying biometric information when the initial purpose for collecting it has been satisfied23. When delegating tasks to independent AI agents, the enterprise must confront the physical limits of deletion in modern cloud architectures. Standard databases, vector stores, and persistent disk volumes retain ghost data in unallocated space, cache memory, and distributed backups long after a logical delete command is issued24. Relying on a large language model's system prompt to "forget" data is technically impossible and legally void, as models can inadvertently memorize training or fine-tuning data28. Therefore, agents must be architected immutably, processing sensitive data strictly within volatile memory enclaves that are cryptographically zeroed upon task completion or container termination. This ensures definitive compliance with BIPA and related privacy frameworks by physically guaranteeing that no residual data persists beyond the authorized session.

Threat Model for Autonomous Agents: The Untrusted Content Paradigm

To safely execute independent agents, all buyer documents, worker outputs, evidence pages, and other agents' messages must be treated strictly as untrusted content. AI agents uniquely process natural language instructions and natural language data through the identical mechanism of a tokenized stream, creating massive vulnerabilities when interacting with external information29.

The Confused Deputy and Excessive Agency

The Open Worldwide Application Security Project (OWASP) Top 10 for LLM Applications 2026 highlights the evolution of these threats. While Prompt Injection remains the primary vector (LLM01:2026), Excessive Agency (LLM03:2026) has emerged as a critical vulnerability, rising significantly in the rankings28. This reflects an influx of incidents where autonomous agents utilize tool access to inflict real-world harm because they possess more functionality and autonomy than required28. This dynamic manifests as the "Confused Deputy" problem, a classic access-control failure where a privileged program is manipulated by a less-privileged caller into misusing its authority29. In the context of agentic systems, the AI agent holds real privileges—such as database access tokens or credentials to modify system configurations—and functions as a trusted deputy32. When the agent reads an untrusted document containing a malicious instruction, the agent cannot inherently distinguish between the operator's trusted system prompt and the injected data payload29. The agent executes the injected command using its full authority, resulting in a confused deputy escalation that bypasses standard perimeter access controls29.

Indirect Prompt Injection, Malicious Attachments, and Unbounded Consumption

The delivery mechanism for confused deputy attacks is frequently Indirect Prompt Injection. Rather than an attacker typing directly into a chat interface, malicious instructions are embedded in web pages, uploaded PDFs, or shared RAG corpora28. Once the agent ingests this poisoned data, the attacker can hijack the agent's goal state, a threat categorized under OWASP Agentic Applications 2026 as Agent Goal Hijack (ASI01:2026)35. Malicious attachments serve as a prime vector, hiding instructions that command the agent to forward sensitive emails, alter invoice routing numbers, or execute untrusted code33. Furthermore, injected logic loops can force the agent into infinite recursive tool calling, a vulnerability known as Unbounded Consumption (OWASP LLM06:2026)28. By commanding the agent to repeatedly query an expensive API or spawn sub-agents without termination conditions, an attacker can orchestrate a "denial of wallet" attack, exhausting compute budgets rapidly28.

Exfiltration Vectors and Covert Channels

Following a successful injection, the attacker's primary objective is data exfiltration. Because egress filtering is notoriously difficult in language-driven applications that require broad internet access, several novel exfiltration vectors have been documented that bypass standard data loss prevention tools: The EchoLeak pattern, also known as Markdown Image Exfiltration, exploits rendering environments34. If the agent's operational environment renders Markdown and auto-fetches images, an injected prompt can instruct the model to append a string to its output, such as \!\alt\. When the framework renders this output, the victim's infrastructure resolves the URL, silently transmitting the sensitive data as query parameters to the attacker's server34. More advanced adversaries may supply compromised open-weight models or fine-tuned agents designed to hide data in plain sight. In threat models such as TrojanStego or MIRAGE, the LLM is conditioned to encode sensitive state information (such as API keys or intellectual property) into the structural variations, synonym choices, or zero-width characters of seemingly benign text39. Research demonstrates that compromised models can reliably transmit secrets with high accuracy while maintaining high utility and evading human detection40. When this text is subsequently logged, posted to a reputation field, or reingested by other systems, the attacker can decode the exfiltrated secrets without ever triggering network alarms41.

Leakage Through Logs and Reputation Fields

Standard observability practices introduce a secondary threat known as Hidden Context Exposure (OWASP LLM08:2026)28. If an agent's reasoning trace, raw prompts, or tool outputs are written to centralized audit logs or shared reputation dashboards, sensitive data inevitably leaks to unauthorized parties28. An attacker exploiting an agent can intentionally command it to summarize sensitive documents and print the summary to an error log or a feedback field43. Therefore, treating worker outputs and evidence pages as untrusted content requires profound shifts in how execution evidence is redacted and stored.

Execution Architectures: Remote Agents vs. Controlled Execution Environments

The baseline architecture for modern AI agents involves an enterprise sending data via an API to a remote environment controlled by the agent developer. This remote-agent execution model is structurally flawed for confidential tasks and must be replaced by controlled execution environments.

The Liabilities of Remote-Agent Execution

In a remote-agent execution model, the enterprise buyer relies entirely on contractual agreements, such as Data Processing Agreements, to protect its data. The execution occurs on the developer's infrastructure, meaning the developer possesses the encryption keys, controls the memory state, and manages the network routing. As established, this architecture violates the reasonable measures requirement of trade secret law20. Furthermore, it leaves the enterprise blind to supply chain compromises (OWASP LLM04:2026) within the agent developer's dependencies28. If the developer's infrastructure is breached, the enterprise's data is compromised by extension. Remote execution must therefore be treated as a legacy alternative, unsuitable for processing unredacted corporate data.

Controlled Execution Environments and Hardware Enclaves

To utilize independent agents securely, the execution paradigm must be inverted: the independent agent's code must be transported to a Controlled Execution Environment managed by the buyer, anchored in a hardware root of trust. Confidential computing technologies, such as AWS Nitro Enclaves, Intel Trust Domain Extensions (TDX), and NVIDIA GPU Trusted Execution Environments (TEEs), facilitate this architecture44. AWS Nitro Enclaves provide highly constrained virtual machines carved from parent EC2 instances. They are designed with no persistent disk, no interactive administrator access, and no direct external network connectivity47. Communication is strictly limited to a secure local socket interfacing with the parent instance47. This isolation ensures that even users with root access to the parent instance cannot inspect the enclave's memory48. The security guarantee of the enclave relies on cryptographic attestation. When the enclave boots the independent agent's image, the hypervisor generates a signed attestation document containing Platform Configuration Register (PCR) measurements49. Specifically, PCR0 represents the cryptographic hash of the enclave's application image, OS kernel, and runtime environment49. Rather than handing credentials to the agent developer, the enterprise configures a key management service with a condition key policy. The key management service will only decrypt the buyer's sensitive input data or release API tokens if the requesting enclave presents an attestation document matching the expected, audited PCR0 measurement47. If the agent developer attempts to push an unapproved update or alter the runtime to exfiltrate data, the PCR0 measurement fundamentally changes, attestation fails, and the key management service denies the decryption request, cryptographically sealing the data49.

Network and Syscall Isolation with gVisor

While enclaves protect data from infrastructure operators, the architecture must also protect the infrastructure from the untrusted agent running within it. Inside the enclave, the agent must be executed within a gVisor sentry sandbox51. gVisor is a user-space application kernel that intercepts and filters system calls before they reach the host Linux kernel, neutralizing privilege escalation attacks and sandbox escapes53. Crucially, gVisor implements its own network stack, enforcing a strong isolation boundary without restricting legitimate application behavior51. By routing the agent's permitted outbound requests through gVisor's virtualized network and a strict egress proxy, the architecture definitively prevents Server-Side Request Forgery (SSRF) and blocks unsafe URL fetching, neutralizing the network pathways required for standard data exfiltration53.

Zero-Trust Authorization for Agentic Actions

Once the agent is securely isolated within a hardware enclave and constrained by gVisor, its interactions with enterprise tools and data must be governed by strict zero-trust principles. NIST SP 800-207 mandates that trust is never granted implicitly based on network location or initial authentication; it requires continuous verification for all identities, including non-human identities56.

Separation of Policy Enforcement and Decision Points

In traditional agent designs, the large language model evaluates a situation, decides what action to take, and immediately executes it through a localized tool call. This unified architecture is highly susceptible to prompt injection because the component processing the untrusted text is the same component holding the execution privileges32. The required mitigation applies the XACML and NIST SP 800-207 reference models, structurally separating the Policy Enforcement Point (PEP) from the Policy Decision Point (PDP)21. The PEP sits directly in the request path—such as an API gateway or tool-calling harness—and intercepts every action the agent attempts to execute21. The PEP does not contain business logic; it merely pauses execution and queries the external PDP. The PDP evaluates the request against immutable policy-as-code, utilizing languages like OPA/Rego, combined with dynamic context such as time, risk signals, and data classification21. The emerging AuthZEN standard provides a unified, JSON-based REST API for this PEP-to-PDP communication, ensuring that authorization logic is completely decoupled from the agent's execution framework59. When an agent attempts to query a database, the PEP extracts the agent's token claims, packages the intended tool arguments, and sends an AuthZEN request to the PDP. The PDP evaluates the compound policy and returns a deterministic allow or deny decision59.

Per-Action Authorization via AADP

While identity-based access control establishes who the agent is, it does not validate what the agent is currently doing. A tool exposed for one legitimate purpose can easily be exploited for another if permissions are overly broad61. To address this, the architecture must implement the Agent Action Decision Protocol (AADP, IETF draft-saha-aadp-03)61. AADP defines a strict two-phase wire contract for per-action authorization, separating the agent's baseline identity from the specific authorization required for a high-stakes transaction61. A fundamental axiom of this architecture is that a request for more data or tools must not itself grant access. Instead, the PDP evaluates the specific parameters of the transaction—such as the exact amount to be transferred or the specific file to be modified—and issues a verdict with machine-readable reasons and atomic budget reservations61. If an injected prompt coerces the agent into issuing an unauthorized command, the AADP-compliant PDP blocks the action because the contextual parameters deviate from the agent's registered business purpose58.

Preserving Distinction: The Dual-LLM Privilege Separation Pattern

To physically enforce the distinction between untrusted task data and operator-authorized instructions, the architecture must implement the Dual-LLM pattern62. In this design, the workload is divided between two distinct models:

1. The Quarantined LLM (Reader): This model operates with zero tool access and zero privileges. Its sole function is to ingest untrusted buyer documents, external web content, and evidence pages, extracting relevant entities or summarizing the data32.

2. The Privileged LLM (Controller): This model holds the authorized instructions and tool access. It never interacts directly with raw untrusted content. Instead, it reads the sanitized, constrained output of the Quarantined LLM through opaque references32.

If a malicious payload is embedded in a buyer document, the Quarantined LLM may be successfully hijacked, but it possesses no tools to exploit. It can only corrupt its specific data output. The Privileged LLM receives this output strictly as string data, not as executable instructions, degrading a potential remote code execution vulnerability into a bounded data corruption issue32.

Evidence Redaction, Auditability, and IP Preservation

Accounting and auditing are critical for resolving disputes with independent contractors, yet traditional logging mechanisms expose proprietary data. To achieve verifiable accountability without data leakage, the system must employ cryptographic audit logs anchored by Merkle trees, utilizing structures analogous to RFC 916264.

Cryptographic Audit Trails and Evidence Redaction

As the agent executes, the PEP records every state transition, tool invocation, and AADP authorization decision58. These records are serialized into JSON and cryptographically hashed. The hashes form the leaves of a Merkle tree67. The root hash of the tree is signed by the enclave's attestation key and published to a public or shared transparency ledger64. This mechanism facilitates complete evidence redaction. The buyer and the worker can independently verify the exact sequence of events by comparing their private execution records against the public hashes, proving policy enforcement and execution continuity without revealing the plaintext content of the buyer's documents or the worker's proprietary prompts66.

Architectural Comparisons

The following table contrasts the baseline assumptions of remote-agent execution against the rigorous controls required for a controlled execution environment.

Minimum Private-Task Design and Data Classification

To operationalize independent agents securely, the enterprise must establish a data-classification and access matrix that explicitly defines the boundaries for every artifact in the task lifecycle.

Threat Model and Acceptance Tests

To operationalize defenses against these vectors, the following threat model defines the requisite acceptance tests that must pass before any independent agent is granted access to confidential tasks.

Confidential-Task Walkthrough

To synthesize this architecture, consider a scenario where an enterprise (the Buyer) hires an independent AI agent (the Worker) to analyze a highly sensitive dataset of unredacted merger and acquisition contracts. The goal is to generate a risk summary without exposing the contracts to the Worker, and without exposing the Worker's proprietary analytical prompts to the Buyer. Phase 1: Environment Provisioning and Attestation The Buyer provisions an AWS Nitro Enclave within their isolated network perimeter. The Worker provides an encrypted container image of their agent, but the Buyer holds the execution environment. The enclave boots, establishing a secure, network-isolated perimeter. The hypervisor generates a cryptographic attestation document containing the PCR0 measurement, proving mathematically that the exact, unmodified version of the Worker's agent and the gVisor sandbox are running49. Phase 2: Conditional Secret Release The enclave presents its attestation document to the Buyer's key management service. Because the PCR0 measurement matches the pre-approved policy, the service releases ephemeral data decryption keys and short-lived API tokens strictly into the enclave's volatile memory47. The Worker's proprietary prompts and the Buyer's contracts are decrypted inside the enclave. Neither the Buyer's administrators nor the Worker can access this memory space. Phase 3: Dual-LLM Execution and Steganalysis The contracts are parsed by the Quarantined LLM, which extracts key clauses without access to any network tools or APIs62. The sanitized extractions are passed to the Privileged LLM, which applies the Worker's proprietary analytical prompts to evaluate risk. During generation, the output is routed through a continuous steganalysis and paraphrasing pipeline to destroy any steganographic covert channels that a compromised agent might use to exfiltrate data39. Phase 4: Zero-Trust Action Authorization The agent attempts to submit the final risk summary to a designated secure storage bucket. The gVisor network stack intercepts the outbound syscall and routes it to the PEP21. The PEP extracts the context and queries the PDP via AuthZEN59. The PDP utilizes the AADP protocol to verify that the destination bucket matches the approved task parameters and that the payload size fits the atomic budget reservation61. A request to access an external server is automatically denied because the request itself does not grant access. The PDP issues an allow verdict for the approved bucket, and the PEP forwards the encrypted summary to the Buyer. Phase 5: Cryptographic Auditing and Immutable Logging Throughout the process, every state change—from initial decryption to the AADP verdict—is recorded as a leaf in an internal Merkle tree67. Upon task completion, the enclave signs the Merkle root hash and exports it to a shared transparency ledger. The Buyer and Worker can mathematically prove the task was executed according to policy without revealing the underlying data, neutralizing hidden context exposure64. Phase 6: Cryptographic Destruction Once the summary is delivered and the audit log is published, the enclave is terminated. Because the enclave utilizes no persistent storage, the ephemeral keys, the unredacted contracts, the Worker's prompts, and the generated outputs vanish instantaneously. This deterministic destruction guarantees compliance with the reasonable measures requirement of the Defend Trade Secrets Act and the stringent deletion mandates of data privacy laws like BIPA14.

Works cited

1. Comparative Study on the Ownership of Copyright of Artificial ... \- MDPI, https://www.mdpi.com/2075-471X/15/4/66

2. February 14, 2022 Ryan Abbott, Esq. Brown, Neri, Smith ... \- Copyright, https://www.copyright.gov/rulings-filings/review-board/docs/a-recent-entrance-to-paradise.pdf

3. Who Owns the Copyright? \- Adams on Contract Drafting, https://www.adamsdrafting.com/who-owns-the-copyright/

4. Civil Law And Work Made For Hire Doctrine, https://lawgratis.com/blog-detail/civil-law-and-work-made-for-hire-doctrine

5. Entrance to \[Copyright\] Paradise Halted by the Human-Authorship, https://www.hunton.com/insights/legal/entrance-to-copyright-paradise-halted-by-the-human-authorship-requirement

6. AI, Copyright Law, and Work-Made-For-Hire \- NNAI Livescu, https://livescu.ucla.edu/ai-copyright-law-and-work-made-for-hire/

7. THALER v. PERLMUTTER (2023) \- FindLaw Caselaw, https://caselaw.findlaw.com/court/us-dis-crt-dis-col/114916944.html

8. Copyrightability of genAI outputs in the US: Key developments, https://www.dlapiper.com/insights/publications/2025/03/copyrightability-of-genai-outputs-in-the-us-key-developments

9. AI-Generated Content and Intellectual Property \- Mister Wolf Law, https://misterwolflaw.com/ai-generated-content-intellectual-property-ownership-2026/

10. AI Work-Product Ownership and Independent Contractors \- tish.law, https://tish.law/blog/ai-work-product-ownership-and-independent-contractors/

11. Who Owns AI Work Product? A Guide for In-House Counsel, https://blog.promise.legal/ai-work-product-ip-ownership-in-house-counsel/

12. 765 ILCS 1065/2 \- ILGA.gov, https://www.ilga.gov/documents/legislation/ilcs/documents/076510650K2.htm

13. Trade Secret Misappropriation | Chicago Intellectual Property Lawyers, https://www.loftusandeisenberg.com/practice-areas/intellectual-property/trade-secret-misappropriation/

14. Defend Trade Secrets Act of 2016, https://www.iadclaw.org/securedocument.aspx?file=1/19/Intellectual\_Property\_November\_2016.pdf

15. Trade Secrets 2026 \- USA – Illinois \- Global Practice Guides, https://practiceguides.chambers.com/practice-guides/trade-secrets-2026/usa-illinois/trends-and-developments

16. A Comprehensive Overview of the Illinois Trade Secrets Act (765, https://www.rockfuscoconnelly.com/a-comprehensive-overview-of-the-illinois-trade-secrets-act-765-ilcs-1065/

17. SC-28: Protection Of Information At Rest \- CSF Tools, https://csf.tools/reference/nist-sp-800-53/r4/sc/sc-28/

18. SC-28: Protection of Information at Rest \- CSF Tools, https://csf.tools/reference/nist-sp-800-53/r5/sc/sc-28/

19. Handling A Breach Of A Non-Disclosure Agreement In Illinois, https://chicagobusinessattorneys.net/how-to-handle-a-breach-of-a-non-disclosure-agreement-nda-under-illinois-law/

20. Failure to Tune in to Requirements to Meet Trade Secret Status, https://www.tradesecretslaw.com/2021/04/articles/trade-secrets/failure-to-tune-in-to-requirements-to-meet-trade-secret-status-under-illinois-trade-secrets-act-results-in-award-of-attorneys-fees-against-radio-advertising-time-business/

21. Two Control Planes, Two Questions | EnforceAuth, https://enforceauth.com/blog/enforceauth-vs-falcon-aidr-technical-white-paper

22. The Illinois Biometric Information Privacy Act | ABI, https://www.abi.org/feed-item/the-illinois-biometric-information-privacy-act

23. 740 ILCS 14/15 \- ILGA.gov, https://www.ilga.gov/documents/legislation/ilcs/documents/074000140K15.htm

24. Illinois BIPA: Biometric Data, Device Fingerprinting, and ... \- Lokker, https://lokker.com/privacy-law/bipa

25. Illinois BIPA Reform Takes Effect | King & Spalding, https://www.kslaw.com/insights/articles/illinois-bipa-reform-takes-effect

26. Illinois Biometric Information Privacy Act (BIPA) \- 2026 Guide, https://www.enzuzo.com/blog/illinois-biometric-act-bipa

27. AI Agent Memory Security: Control Persistent Context Before It Acts, https://gsconsultingllc.com/insights/ai-agent-memory-security

28. What the OWASP LLM Top 10 2026 Means for Your Data \- Forcepoint, https://www.forcepoint.com/blog/insights/owasp-llm-top-10

29. Confused Deputy Attacks on Autonomous AI Agents, https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/

30. OWASP Top 10 for LLM Applications 2026: Security Risks, https://signmycode.com/blog/owasp-top-10-for-large-language-model-applications-complete-guide/

31. OWASP's 2026 LLM Top 10 and New Agent Control Standard, https://labs.cloudsecurityalliance.org/research/csa-research-note-owasp-genai-top10-2026-agent-control-stand/

32. Prompt Injection Is a Confused Deputy, Not a Content-Filtering, https://tianpan.co/blog/2026/05/17/prompt-injection-confused-deputy-capability-scoping

33. Agent Confused Deputy Escalation | LLM Security Database, https://www.promptfoo.dev/lm-security-db/vuln/agent-confused-deputy-escalation-d1becd4d/

34. LLM Insecure Output Handling: An Introduction \- Coralogix, https://coralogix.com/ai-blog/llms-insecure-output-handling-best-practices-and-prevention/

35. OWASP Top 10 for Agents 2026 \- The LLM Red Teaming Framework, https://www.trydeepteam.com/docs/frameworks-owasp-top-10-for-agentic-applications

36. OWASP Top 10 for LLM Applications 2026: Key Changes, https://www.lasso.security/blog/owasp-top-10-for-llm-applications-2026-what-changed-what-surprised-us-what-matters

37. Indirect Prompt Injection: Attacks, Defenses, and the 2026 State of, https://zylos.ai/research/2026-04-12-indirect-prompt-injection-defenses-agents-untrusted-content/

38. EchoLeak Explained (CVE-2025-32711): The First Zero-Click AI, https://preporato.com/blog/echoleak-cve-2025-32711-explained

39. Verifying LLM Inference to Prevent Model Weight Exfiltration \- arXiv, https://arxiv.org/html/2511.02620v1

40. TrojanStego \- arXiv, https://arxiv.org/pdf/2505.20118

41. Implicit Memory Covert Channel | LLM Security Database \- Promptfoo, https://www.promptfoo.dev/lm-security-db/vuln/implicit-memory-covert-channel-87b8bc1a/?returnTo=%2Ftag%2Ffine-tuning%3Fpage%3D2

42. Language Model Security Database \- Promptfoo, https://www.promptfoo.dev/lm-security-db/?tags=agent%2Cdata-privacy%2Crag

43. I Poisoned My Own Agent's Knowledge Source. Here's What Got, https://builder.aws.com/content/3DEn7j3hBG5NnsxLELggZL4V9Ct/i-poisoned-my-own-agents-knowledge-source-heres-what-got-through

44. The Root of Trust: Hardware Security for Agentic AI \- webMethodMan, https://www.webmethodman.com/p/anchoring-agentic-ai-governance-to-a-hardware-root-of-trust

45. Confidential Computing, Secure Enclaves, and Attestation \- RAND, https://www.rand.org/pubs/tools/TLA4174-1/ai-security/appendixes/appendix-a/confidential-computing-etc.html

46. Decentralized Compute on Untrusted Hardware Using Intel® TDX, https://targon.com/releases/intel-whitepaper

47. What Is AWS Nitro Enclaves? Definition & Examples, https://nhimg.org/glossary/aws-nitro-enclaves/

48. Nitriding: A tool kit for building scalable, networked, secure enclaves, https://arxiv.org/pdf/2206.04123

49. GitHub \- ArkLabsHQ/enclave: A Simple AWS Nitro Enclave Runtime, https://github.com/ArkLabsHQ/enclave

50. A Framework for Building Secure, Scalable, Networked Enclaves, https://brave.com/research/files/a-framework-for-building-secure-scalable-networked-enclaves.pdf

51. Networking Guide \- gVisor, https://gvisor.dev/docs/architecture\_guide/networking/

52. Introduction to gVisor security, https://gvisor.dev/docs/architecture\_guide/intro/

53. gVisor \- KodeKloud Notes, https://notes.kodekloud.com/docs/Certified-Kubernetes-Security-Specialist-CKS/Minimize-Microservice-Vulnerabilities/gVisor/page

54. What Is gVisor Sentry Syscall Filtering? \- JumpCloud, https://jumpcloud.com/it-index/what-is-gvisor-sentry-syscall-filtering

55. Let's discuss sandbox isolation \- Shayon Mukherjee, https://www.shayon.dev/post/2026/52/lets-discuss-sandbox-isolation/

56. SP 800-207, Zero Trust Architecture | CSRC, https://csrc.nist.gov/pubs/sp/800/207/final

57. How to Prevent Lateral Movement in the Age of AI Agents \- Elisity, https://www.elisity.com/blog/andy-ellis-prevent-lateral-movement-ai-agents

58. Runtime Identity Governance for AI in the Cloud | CSA, https://cloudsecurityalliance.org/blog/2026/07/27/beyond-human-identity-a-runtime-governance-model-for-autonomous-ai-agents-in-the-enterprise-cloud

59. AuthZEN: Fine-Grained Authorization for Agents | Agentic Academy, https://agentic-academy.ai/posts/authzen-authorization-api/

60. AuthZEN: A New Standard for Fine-Grained Authorization, https://nordicapis.com/authzen-a-new-standard-for-fine-grained-authorization/

61. draft-saha-aadp-03 \- The Agent Action Decision Protocol (AADP), https://datatracker.ietf.org/doc/draft-saha-aadp/03/

62. The Dual LLM Pattern for LLM Agents | Threat Model Co, https://threatmodel.co/blog/dual-llm-pattern

63. Dual LLM Pattern \- Agentic Patterns, https://agentic-patterns.com/patterns/dual-llm-pattern/

64. Cryptographically Signing Tool Inputs for AI Agent Audits \- Bot.to, https://bot.to/cryptographically-signing-tool-inputs-ai-audit-trails/

65. Deterministic Replay for AI Agents: Immutable Audit Logs, https://www.prompthalo.ai/feeds/blog/deterministic-replay-ai-agents-immutable-audit-logs

66. Agent Audit Trail: A Standard Logging Format for Autonomous AI, https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/

67. Tutorial 04 — Audit Logging & Compliance \- Agent Governance Toolkit, https://microsoft.github.io/agent-governance-toolkit/tutorials/04-audit-and-compliance/

68. SOC 2 Type II for AI Agents: What Auditors Ask \- OpenBox AI, https://www.openbox.ai/blog/soc-2-type-ii-for-ai-agents-what-auditors-ask

69. Agent Operation Continuity Across Executor Replacement, https://datatracker.ietf.org/doc/draft-schrock-agent-operation-continuity/

70. Proof-of-Guardrail in AI Agents and What (Not) to Trust from It, https://openreview.net/pdf?id=edXCcxgH0a

71. Secure AI apps & pipelines with secure key release \- Fortanix, https://www.fortanix.com/blog/securing-enterprise-applications-and-ai-pipelines-with-attestation-gated-secure-key-release