BLACKBOX AI Pitches Enclave-Based Prompt Encryption for Confidential Agents

At TechCrunch Disrupt 2026 in San Francisco, BLACKBOX AI co-founder and CTO Richard Rizk took the AI Industry Stage with a question aimed squarely at anyone building or buying autonomous agents: who can read your agent's prompts? The talk, delivered as part of a sponsored TechCrunch Brand Studio feature, walked through the exposure points that exist every time an agent communicates with a GPU and proposed an architecture that removes all of them from the trust equation. For government buyers and contractors tracking confidential AI, the session is a useful marker of where commercial vendors believe the security bar is heading, even though it carries no procurement action on its face.

The core argument is straightforward. In a typical agent deployment, prompts transit a proxy, land on a host, and are ultimately processed by an operator — three distinct parties, each of which can, in principle, read the prompt content. Rizk framed each hop between an agent and a GPU as a place where sensitive text can be exposed, and noted that an agent loop repeats that exposure on every plan step, tool call, and retry. For workloads involving regulated data, corporate strategy, or source code, that repetition turns a theoretical risk into what he called a dealbreaker. The scaling problem is not just one intercepted prompt; it is the accumulated surface created by continuous autonomous iteration.

BLACKBOX AI's answer is to seal prompts on the client and decrypt them only inside an attested GPU enclave. In that model, the proxy, the host, and the operator never hold the key to the plaintext, so none of them can read what the agent is doing. Rizk also emphasized that the approach runs at the speed agent loops demand — a critical qualifier, because confidential computing techniques often carry performance penalties that make them impractical for high-frequency, low-latency agent workloads. He further argued that soft isolation falls short of the requirement, positioning hardware-backed attestation as the differentiating control. The confidential AI stack he described is therefore a combination of client-side encryption, hardware-rooted attestation, and performance engineering.

For GovCon audiences, the practical read is nuanced. This article is sponsored content and there is no government customer, solicitation, contract award, funding event, or procurement point of contact disclosed. That absence matters: the piece signals a technology approach that buyers may want to evaluate, not a contract they can pursue. Even so, the architecture maps onto a live federal problem set. Agencies handling controlled unclassified information, CUI, classified-adjacent workloads, CMMC obligations, and FedRAMP authorization boundaries are increasingly asked to host AI agents that touch sensitive data. A vendor claiming that prompts are encrypted client-side and decrypted only inside an attested enclave is effectively making an argument about data custody — an argument that contracting officers, system owners, and authorizing officials will need to test against their own control baselines rather than accept at face value.

The sourcing questions that follow are familiar to anyone who has run an AI pilot under federal security review. Where does key material live? Who attests the enclave, and against what root of trust? What happens to prompts at rest in logs, memory, or telemetry? How does the design interact with Zero Trust architecture mandates and continuous monitoring requirements? Rizk's claim that neither proxy, host, nor operator holds the key addresses the in-transit and in-processing phases, but government evaluators will still ask about retention, auditability, and incident response. Contractors shaping confidential-AI offerings should expect those questions in any capability brief, RFI response, or oral presentation.

The broader market signal is that confidential AI is being productized as an architectural differentiator rather than a policy promise. Vendors are competing on trust boundaries — attested enclaves, client-side encryption, minimization of operator access — and using stage time at major technology events to define the terms. Federal program offices evaluating agent deployments for sensitive data can use this framing to sharpen evaluation criteria: does the proposed stack cryptographically exclude infrastructure operators from plaintext access, and can the vendor demonstrate attestation and performance together? Absent a named federal adopter, the responsible posture is to treat BLACKBOX AI's approach as one option in a maturing field, benchmark it against existing security requirements, and require evidence before it is written into a requirement.

• BLACKBOX AI CTO Richard Rizk presented at TechCrunch Disrupt 2026 in San Francisco on the AI Industry Stage.
• The approach seals agent prompts on the client and decrypts them only inside an attested GPU enclave, meaning proxy, host, and operator never hold the key.
• Rizk identified the proxy, host, and operator as the three exposure points where prompts can be read, repeated on every plan, tool call, and retry.
• Agent loops multiply prompt exposure; regulated data, strategy, and source code were cited as dealbreaker categories for uncontrolled access.
• Rizk argued that soft isolation is insufficient and positioned hardware-backed attestation within a confidential AI stack.
• Performance was explicitly addressed: the design claims to run at the speed agent loops demand, a common adoption barrier for confidential computing.
• No government customer, solicitation, contract award, funding, or procurement contact was disclosed; the article is sponsored TechCrunch Brand Studio content.
• GovCon implication: evaluate client-side encryption and attested-enclave processing against CUI, CMMC, FedRAMP, and Zero Trust requirements before incorporating into solicitations.