AI Finds Secrets You Never Wrote Down

Researchers pulled 64 of them out of public agent logs, and nobody had typed a single one. The category is agent intermediate state, and nothing in your stack was built to see it.

The Treasury at Petra, seen through the Siq. The gap shows a few feet of a forty-meter facade. Photo by Aaron Fulkerson, Leica Q3, July 2026.

There are 64 secrets sitting in public AI agent logs on GitHub and Hugging Face that nobody ever wrote down.

Nobody typed them. They appear in no transcript and on no screen. A team of researchers recovered them anyway, out of blocks of encrypted text that the developers who published those logs had no way to open and no reason to suspect.

The paper is “Stealing Reasoning Traces from Proprietary LLM APIs,” published August 10 by Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping and Maksym Andriushchenko. Across 6,708 public agent trajectories they decoded 315,320 reasoning blocks and pulled out 62 API keys, 33 passwords, 24 access tokens and seven private keys belonging to real people. Roughly one session in twenty leaked something real. And of the artifacts recovered from genuine user sessions, 64 of 704 were entirely absent from the visible chat history.

They never broke an encryption key.

The mechanism isn’t exotic. OpenAI, Anthropic and Google all hide the model’s step by step reasoning to protect their own IP, handing it back to the client as an encrypted block that the client returns on the next call. Sensible design. Stateless APIs need somewhere to put the state. What the team found is that those blocks are interchangeable across sessions, users and models inside a single provider. So you hand a block from a strong model to a weaker sibling, ask it to read the contents out loud, and it does. Encryption held. Access control held. The secret still walked out.

A developer at a mid size fintech reads every line of a trace, redacts the keys, pushes it clean, and ships the credential anyway.

You can’t sanitize what you can’t read.

Data exhaust used to be inert

Every system throws off byproduct. Logs, metadata, telemetry, build artifacts, the timing and shape of requests. We’ve called it data exhaust for years, and for most of those years it was safe for a boring reason: reading it at volume cost more than the information was worth. A human analyst staring at six months of API logs is an expensive way to learn very little.

Large language models collapsed that cost to roughly zero. What used to be noise is a corpus now, and a corpus can be reconstructed into the thing that produced it. Most security teams have at least heard about that shift.

The second shift is the one this paper makes concrete, and it runs the other direction. We are now building systems whose exhaust only a machine can read. The reasoning block isn’t a log you’re neglecting. It’s a sealed object you are holding, forwarding, and occasionally publishing, with no ability to inspect what’s inside it. Something old moved up stack. The exhaust got a lock on it, and you don’t have the key.

Reasoning traces matter because researchers just proved the failure end to end, with numbers. They’re one instance of a larger category, and the category is what should worry you. Call it agent intermediate state: everything a system generates between the request and the answer. Model reasoning, planner state, tool calls and their responses, retrieved context, memory that persists across turns, environment variables and the credentials inside them.

Or more simply: dark exhaust. Data exhaust you cannot read or track.

Almost none of it reaches the transcript, and most of it is more revealing than the transcript. If providers reimplement reasoning tomorrow in a way that closes this specific paper, the category doesn’t shrink by one line.

Apple built a confidential supercomputer for a chatbot

Apple looked at Siri, a consumer chatbot answering questions on a phone, decided the data exhaust around it was too risky for ordinary cloud infrastructure, and built a confidential supercomputer instead. They call it Private Cloud Compute. It’s a Confidential AI system, and the largest one anyone has ever deployed.

The iPhone measures the server against a published build and refuses to send when the measurement is wrong, so the client gets cryptographic evidence about the environment before any data reaches it. That check has a name. Verifiable privacy: you confirm the guarantee yourself. Verifiable governance: the policy runs where nobody can edit it, and enforcement leaves a record you can hand to a regulator. Compliance becomes evidence you produce. And all of this is to prevent the user data, or data exhaust, from being accidentally leaked, which happens by default in GenAI systems.

In June, Apple extended the whole thing onto Google Cloud rather than relax any of it to get more capacity. Ivan Krstić, who runs security engineering at Apple, walked through the architecture on stage at the Confidential Computing Summit we host. I was thrilled they agreed to keynote. I strongly recommend listening to his presentation because he breaks down all the adversarial and non-adversarial threat models.

Anyway, Apple built this for a simple consumer question/answer chatbot. Enterprise agents are far more capable and dangerous.

An agent’s intermediate state is not a transcript; it’s enterprise data from across a variety of systems

An agent doesn’t just answer questions. It acts. To act, it retrieves, plans, tries, discards, and decides. The visible output is the smallest artifact it produces, and often the least interesting one.

Take a health system running an agent on prior authorization appeals. The output is one word: appeal. Getting there took the patient identifiers it pulled to check eligibility, the three denial codes it weighed, the contract clause it considered citing and dropped, and the dollar threshold that tells it not to bother below a certain claim. One of those five things reaches the transcript. The other four are what a competitor, a payer or a plaintiff’s attorney would actually want.

What I’ve observed is that teams inventory their prompts and they inventory their outputs. Almost nobody inventories the deliberation in between. Your agents keep a diary, and you have never read a page of it.

And it’s reachable by people outside your company. A federal court has already ordered OpenAI to preserve output logs its own deletion policy would have destroyed, and Rule 34 carries no exception for data a machine generated. Preserving and producing a record nobody at your company can read is its own article, and there’s a starting point for it in the reading list.

Now scale it. The paper’s core finding is that reasoning blocks are interchangeable across sessions, users, and models inside a provider. Read that as an architecture statement rather than a vulnerability report, and it describes something you are probably building on purpose. It’s what an agent assembles internally to get the job done, and it’s what an agent-to-agent handoff hands over. Every handoff moves intermediate state across a boundary.

Roughly one session in twenty leaked something real, and those were single sessions with a human somewhere in the loop. That rate was tolerable when a person reviewed the output and the work stopped for the night. It isn’t tolerable for systems that run continuously, hand off to each other, and multiply. Hierarchical access controls were designed for a world where the number of actors grew slowly. Agents don’t grow that way.

A patch is not the fix

Credit where it belongs. The researchers disclosed before publishing, and by the time the paper went public all three providers had shipped fixes. The frontier labs are fast and serious about this.

This instance is closed. The pattern isn’t.

And notice whose stack it was in. Three companies with dedicated world-class security research teams, full control of their entire stack, and a private disclosure before publication. They shipped in days.

This pattern is actually more damning with your enterprise agents, and nobody is going to disclose it to you privately first. Is your enterprise as fast as a frontier lab?

A patch closes a demonstrated attack, not the design decision that produced it, and that decision is an anti-pattern running through GenAI broadly: an intermediate state moving across a trust boundary with nothing binding it to who produced it, who may replay it, or what’s inside. Same shape, different surface, shipping inside enterprise agents right now.

In a chatbot, an instance of this might cost you some personal data or maybe a credential. In a fleet of enterprise agents, it costs you the deliberation behind every decision the fleet makes across every system it touches. Even if this pattern were resolved by the frontier model labs, the much bigger and more frightening issue is that, across all the enterprise agents, a secret, invisible scratchpad is being created and handed off that contains a wealth of sensitive data.

But Sandboxes…

Two objections come up here. The first is isolation: we already have an answer for untrusted code, so run the agent in a sandbox. Constrain its filesystem, its network, its tools.

Do that. It’s table stakes. It solves a different problem.

A sandbox governs what an agent can reach. It says nothing about who can read what happens inside it. The hypervisor can. The host operating system can. The cloud operator can, and so can anyone holding root on a platform your team doesn’t run. Memory sits there in the clear, because the boundary was drawn to keep the workload in, not the infrastructure out.

And look at how the leak in the paper actually happened. Nothing escaped anything. The reasoning block walked out the front door as ordinary API traffic, because that is the protocol. A sandbox is built to permit precisely that call, and it would have watched the whole thing and correctly done nothing. Sandboxing answers what this agent can touch. It was never built to answer who can see what it touched.

The second objection is the one that ends most of these conversations. The scratchpad never leaves our network. Our infrastructure, our employees. Fine.

Except “our employees” is no longer something you can verify by looking. Models are good enough now that an agent impersonating a person inside your network isn’t a hypothetical, it’s the cheapest way in, and the perimeter’s entire premise is that whatever is already inside was let in on purpose. It’s not just possible…it’s probable.

So run the threat model. An impersonating agent gets read access to what your agents generate. Not your document store, which you already monitor. Your intermediate state. That means the service-account credentials your agents hold to reach the data warehouse, the retrieved rows they pulled and discarded, the customer records they compared, the pricing floor a quoting agent decided not to go below, the acquisition target a diligence agent researched under a codename, the vulnerability a coding agent found and filed. None of it is in a document. All of it is in the deliberation.

Then speed. Dark exhaust is the richest and least watched material on your network, and it gets read at machine pace. What a skilled human team would need months to work through, an agent works through in an afternoon. There is no dwell time to detect, because there is barely any dwell.

And the bill changed. The EU AI Act entered its enforcement era this month, and Article 99 tops out at 35 million euros or 7 percent of global annual turnover, a ceiling set deliberately above GDPR’s 4 percent. California’s SB 53 has been in force since January at a million dollars per violation for companies above 500 million in revenue. “It stayed inside our network” was never much of a technical defense. It isn’t a legal one at all.

What the architecture has to satisfy

Skip the product category for a minute and write down what any answer has to do. Three requirements fall out of everything above.

Intermediate state has to be unreadable to the infrastructure that runs it, including your own operators and your cloud provider, because “inside our network” stopped being a boundary. The policy governing that state has to be enforced somewhere the party running the workload can’t quietly edit, because a policy enforced by the party you’re worried about isn’t a control. And the whole thing has to produce evidence a third party can check without trusting you, because a regulator, a customer or a court will eventually ask and your word won’t settle it.

Those are requirements, not a vendor list, and candidates land differently against them. Application-layer encryption covers data at rest and in flight, then leaves it in the clear during inference, which is exactly when intermediate state exists. Sandboxes bound reach, as above. Audit logs are generated by the operator and can be altered by the operator.

Hardware-backed Trusted Execution Environments plus remote attestation satisfy all three today, which is the case for Confidential AI. Before the workload runs, attestation proves what code is loaded and what it’s permitted to touch. During execution, policy binds to the data inside the TEE, so intermediate state is unreadable to the operator, the cloud provider and the model host alike. After it finishes, you hold an attested, tamper evident record of what ran on what. Before, during, and after.

Be clear about what that doesn’t buy. It doesn’t make the agent correct, and a confidential agent executes a bad plan as faithfully as a plain one. It doesn’t write your policy, and it enforces a careless one precisely. It does nothing at all if nobody ever decided what the agent was allowed to touch. Confidential AI makes a guarantee checkable. It doesn’t make the guarantee good.

That’s the same list Apple built for a consumer chatbot, and enterprises are in that position with less room to maneuver: agents on clouds you don’t own, models you didn’t train, vendors you can’t audit. That’s the problem we work on at OPAQUE, and we’re one of several teams working it. The category matters considerably more than the vendor.

Which is exactly why the evidence has to be a standard and not a product. TRACE, for Trust, Runtime Attestation, and Compliance Evidence, specifies the format and the verification rules for provable evidence that an agent ran under a stated policy, in a verified hardware environment, on data of a given classification, invoking identified tools. Open specification, Apache 2.0, moving through the Linux Foundation, at trace.agentrust-io.com. Every supercycle we’ve had ran on open standards, and not one was won by whoever held the best proprietary format.

Before you deploy the next one

None of this requires you to buy anything this quarter. It requires you to be able to answer five questions about an agent you already run.

What sensitive information enters it. What sensitive information it retrieves on its own. What intermediate state it generates along the way. Who can technically read that state, including your cloud provider, your model host and your own platform team. And what evidence you could produce, to someone who doesn’t trust you, that nobody did.

Most teams can answer the first two today. The third is usually a shrug. The fourth is longer than people expect once they write it out. The fifth is where the architecture argument stops being theoretical, because for almost everyone the honest answer right now is none.

If you want to see what that evidence looks like in practice, the cMCP quickstart walks through blocking a tool call and verifying the receipt. It takes a few minutes and it makes question five concrete.

Panfilov and his coauthors didn’t find a bug. They found the shape of the next fifty.

Confidential AI Just Hit Escape Velocity

Apple looked at a simple chatbot, the single most contained form of GenAI there is, and decided the data it leaks is too dangerous to ship to their customers without Confidential AI underneath it. That’s the decision buried inside the announcement everyone covered as “Siri gets Gemini.” The real story is where Gemini runs: when Siri hands your request to Google’s models, it executes inside Private Cloud Compute, Apple’s Confidential AI architecture, on Google’s cloud, under guarantees Apple wrote down and opened to outside researchers. The request never travels on trust. I wrote about what that proves earlier this week. This post is about what it means for the people allocating capital into AI and the people building it.

The short version: Confidential AI just hit escape velocity. Here’s the case.

Confidential AI means proof, not empty promises

Strip away the vendor language and Confidential AI is one thing: verifiability. A third party can check what software ran, where it ran, what rules governed it, and who could see the data. Usually, the answer to that last question is no one. Not the cloud operator. Not Apple. Nobody, because one of the policies requires the model to run inside an encrypted runtime that even the machine’s owner can’t access (called a trusted execution environment, or TEE).

People hear “encrypted runtime” and think the hardware is the point. It isn’t. The hardware is plumbing. The point is provable policies and provable privacy. So how do you trust the cloud, the operator, the model vendor? You don’t. That’s the whole point. Nothing asks for your trust; everything submits to your verification, with the proof anchored in the silicon itself (a technical story for another post). It’s why I keep saying this becomes the floor for AI the way HTTPS (encryption of data in transit) became the floor for the web.

Chatbots leak. Agents hemorrhage.

A chatbot is one request in, one answer out. Even that leaks: your words, your context, your customer’s record, often enough that OWASP ranks sensitive information disclosure second among the risks in every LLM application. That’s the contained case. It’s the one Apple just declared unacceptable for a phone.

An agent runs that risk in a loop. It reads your email, opens files, calls tools, and hands work to other systems, unattended and at machine speed. And it doesn’t take an attacker. An agent doing exactly the job you gave it moves your data constantly: into model APIs, into third-party tools, into logs, into another agent’s context. Places you don’t control and mostly can’t see. No breach, no villain. Just plumbing.

The adversarial case is worse. Every useful agent carries what Simon Willison named the lethal trifecta: private data, untrusted content, and a channel to the outside world. This is consensus, not my opinion. OWASP publishes a threat taxonomy just for agents, and Anthropic published an entire zero-trust playbook for them, naming five threat categories from prompt injection to memory poisoning.

Now wire agents together, the way every enterprise is planning to this year: thousands of steps a day, around the clock, and whatever the per-step risk is, compounding turns it into a certainty. Here’s why you should care. Every leak is a transfer of assets. Your data lands in someone else’s AI model, and someone else’s business model, and whoever controls the data controls the industry. Apple deployed Confidential AI to protect the smallest risk surface in AI, a single chatbot request. Enterprises are wiring up the largest with nothing underneath it.

Apple just set the bar every enterprise will be measured against

Escape velocity is the moment a category stops needing evangelism, when the question flips from “do I really need this?” to “why don’t you have it?” Three things flipped it this month.

First, the existence proof landed at the hardest difficulty setting. Apple just rolled out the largest Confidential AI deployment in history: every iPhone, at consumer latency, consumer cost, consumer scale. Every objection enterprises have leaned on, too slow, too expensive, more than we need, just got falsified a billion times over by a phone.

Second, this is already how the giants operate. Meta runs WhatsApp message AI through private processing. Google built Private AI Compute so Gemini can process your personal data in a sealed environment that, in Google’s own words, not even Google can access. Anthropic and TikTok run their own implementations. And Microsoft, Google, and NVIDIA ship the underlying confidential infrastructure across their clouds and silicon. The pattern is consistent: every company with world-class security talent, when forced to put AI against sensitive data at scale, lands on the same architecture. When that many teams solve the same problem independently and arrive at one answer, you’re looking at convergence.

Third, the talent wall is real, and it’s where the market forms. Apple spent years and one of the best security teams on earth building PCC. Very few organizations have that bench or those resources, and almost none should build it themselves. That’s why companies like OPAQUE exist: to make Confidential AI deployable without first becoming Apple. For investors, that gap, between proven necessity and scarce ability to self-build, is the shape of every great infrastructure market I’ve seen. The web didn’t make every company write its own TLS stack. It made certificate authorities and load balancers inevitable. And if you’re wondering why the clouds don’t just own this layer: no agentic system runs entirely in one cloud. Agents cut across clouds, SaaS platforms, and on-prem systems, and a proof that stops at one vendor’s wall isn’t proof. The layer that verifies everything can’t belong to any one of the things being verified.

Malicious agents are probable, and runtime proof is becoming law

Two forces make this urgent rather than eventual.

The first is the threat model. Mythos-class models and their successors make it probable, not hypothetical, that a malicious actor places itself inside your environment wearing an agent as a costume. And agents are architected to be data-leaky; movement of data across systems is the job description. An employee touching sensitive data is a risk you’ve spent decades learning to govern. A compromised agent operating at machine speed is a different animal entirely. In a regulated industry, neither is acceptable without proof of containment.

The second is the rulebook. The new wave of regulation doesn’t ask for your policy binder. It asks for runtime proof: what ran, where, under what rules. Automated, hardware-signed, verifiable by a third party. Faith-based compliance is ending, and the only architecture that produces those receipts natively is the one Apple just put in your pocket.

So here’s the question every board should be asking. If Apple can deliver verifiable Confidential AI under consumer requirements for speed, scale, and price, why can’t your bank? Your hospital? Your government agencies? The software vendors holding your customer, partner, and supplier data?

I said no more excuses last week. The proof ships on a billion devices.

Whoever builds it in first writes the rules

If you build agents, the bar is now public and the standards are still wet. Build verifiability in from the first line of code and you won’t just be safer, you’ll write the rules your competitors have to meet. If you allocate capital, you’re watching a category cross from evangelism to expectation, with regulatory tailwinds and a supply side that can’t be improvised.

Ivan Krstić, who built Private Cloud Compute, is keynoting at our conference, the Confidential Computing Summit, in San Francisco, June 23-24. If you want to see where this architecture goes after the chatbot, that’s the place. Come build with us.

And there’s a deeper current under all of this that deserves its own post: who ends up controlling the world’s cognitive infrastructure, the layer that will quietly steer every industry, government, and social system, and what data sovereignty has to do with ensuring the answer isn’t “one or two companies.” That’s next.

ITTech Pulse Interview: Confidential AI and the End of “Trust Me” Security

Sat down with Kalpana Kumari from ITTech Pulse to talk about where enterprise AI security is actually heading. The conversation went deeper than I expected — we got into workload identity, the math-vs-promises distinction, and why compliance should be a byproduct of execution, not a gate. The throughline: in an agentic world, administrative controls don’t scale. Hardware-enforced verification does.

Full interview reposted below. Original article at ITTech Pulse.

ITTech Pulse Exclusive Interview with Aaron Fulkerson, Chief Executive Officer at OPAQUE

By Kalpana Kumari | April 21, 2026 | Originally published at ITTech Pulse

In an ITTech Pulse exclusive, OPAQUE CEO Aaron Fulkerson discusses how cryptographic verification and TEEs provide end-to-end security for enterprise AI agents.

Aaron, IT leaders worry about data leaks in agentic AI – how does OPAQUE’s hardware-attested platform keep data encrypted throughout Fortune 500 RAG workflows?

IT leaders are right to worry. Agents operate at machine speed, across systems and tools, and can be manipulated by adversarial inputs in ways humans can’t. OPAQUE prevents data leakage through a layered security model combining confidential computing, policy enforcement, and verifiable auditing. Every RAG query runs inside hardware-backed Trusted Execution Environments (TEEs). That means data stays encrypted even while it’s being processed. Not just at rest. Not just in transit. In use. The TEE ensures that all policies (on data as well as agent behavior) are verifiably enforced.

Before execution, we cryptographically attest the environment. After execution, we produce tamper-proof audit logs proving what code ran, what data was accessed, and whether policies were honored. That’s the difference. Most platforms give you access controls. We give you verifiable proof that enforcement actually happened. In an agentic world, that distinction becomes existential.

Drawing from ServiceNow expertise, what gaps in traditional encryption does OPAQUE’s confidential computing fill for enterprise AI security challenges today?

Traditional encryption protects data at rest and in transit, but AI systems constantly process data, reason over it, generate outputs, and take actions. The moment data is “in use,” traditional encryption steps aside. That gap becomes enormous when you’re running agents across interconnected systems. When you scale to hundreds or thousands of agents, even small leak probabilities compound. At 1% failure probability per agent, 100 agents means a 63% chance of breach. At 1,000 agents, you’re effectively guaranteed exposure. You cannot manage that with policy documents and permissions alone. Confidential AI closes that gap.

At ServiceNow, I saw firsthand that adoption follows trust. If security is bolted on later, you get politics, delays, and stalled deployments. The organizations embedding verifiable guarantees into their AI architecture from day one are the ones actually reaching production. The technology changes, but the trust requirement doesn’t.

OPAQUE processes encrypted data directly—without decrypting it—using confidential computing. Computation happens inside TEEs, which keep data isolated from the rest of the system, only allow verified code to run, and tightly control access. Before any data is even processed, the platform proves its integrity through remote attestation. After execution, it generates hardware-signed audit logs that prove what ran, under which policies, and how data was handled.

After $24M Series B success, what compliance breakthroughs has OPAQUE achieved for Accenture-like clients using verifiable confidential AI agents?

Here’s the frustration nobody talks about. Compliance and infosec teams are correct to be concerned about AI on sensitive data. But that concern creates a maddening bottleneck for AI builders who just want to innovate and ship, and they’re being told to do so faster every quarter.

What OPAQUE changes is who does the security review. Hardware does the security review. Not the security team. When your workload runs inside a TEE with cryptographic policy enforcement, and the output is a hardware-signed audit trail proving exactly what happened, you’re not waiting for a manual security assessment. You’re delivering math to your auditor. Not promises.

We’re seeing customers accelerate deployments by 4-5x because compliance stops being a gate and becomes a byproduct. Think about a financial services company running AI agents across transaction data. Without verifiable guarantees, that deployment sits in a legal queue for months. With a cryptographic receipt proving data never left the TEE and policies were enforced at the hardware level, the CISO and General Counsel sign off because they have evidence. Furthermore, we’ve seen the accuracy of inference jump from 36% to 98% because the customer was able to ground their AI system with the most sensitive data and dramatically improve their results. That’s the shift from Plateau to Powerhouse.

How does OPAQUE integrate with orchestration frameworks like LangGraph to support confidential RAG workflows and enterprise-grade governance?

Most AI builders hear “encryption” and think “that’s an infosec problem, not my problem.” But here’s what OPAQUE actually creates: a workload identity.

Every layer, silicon, infrastructure, and workload graph, is hardware-attested and verified before each execution. Policies are encoded into that identity. If anything changes, code, config, or policy, the identity breaks, and no data enters. Your policies are bound to the workload at runtime, enforced by hardware, and provable. No one sees the data. Not the cloud provider. Not your admins. And proof-of-trust receipts are produced as a byproduct of execution.

We built OPAQUE Studio on LangGraph because the industry is converging on open-source orchestration for multi-agent systems, and we think that’s the right direction. Something old moved up the stack; agent orchestration looks a lot like microservices orchestration from a decade ago. The primitives rhyme. What’s different is that these services can now reason, act autonomously, and access sensitive data in ways microservices never could. OPAQUE Studio lets developers wire up agents to sensitive data sources with the trust guarantees baked into the infrastructure. Compliance and infosec get out of your way because the hardware is doing their job for them.

How is OPAQUE thinking about long-term scalability and cryptographic resilience in enterprise AI systems?

Today, we’re removing the roadblocks that keep enterprises from shipping AI on their most sensitive data. That’s the immediate priority: helping organizations move from running AI on sanitized data to running it on the proprietary data that actually creates competitive advantage. With proof that nothing leaks.

The competitive advantage lives in the data that enterprises are afraid to touch. Our job is to make that fear unnecessary, not by telling them to trust us, but by giving them cryptographic proof so they can ship fast.

What does deployment typically look like for enterprises adopting OPAQUE, and how does the platform support ongoing privacy verification?

OPAQUE is deployed into your cloud environment within confidential computing–enabled infrastructure and requires no data migration or replication outside your environment. Teams can use OPAQUE’s Agent Studio or deploy their containerized AI workloads directly using OPAQUE’s Confidential Runtime and SDK.

We make privacy part of the execution itself rather than an add-on. Before runtime, OPAQUE verifies integrity and configuration to prevent misconfigured or unauthorized workloads from running. During execution, it enforces cryptographic policies, encrypts data in use, and isolates workloads so sensitive data, models, and business logic remain protected as agents act autonomously. After execution, it generates hardware-signed audit logs that prove what ran, under which policies, and how data was handled.

How does OPAQUE approach scaling confidential AI systems while maintaining strong security guarantees?

No builder wants to think about encryption. They shouldn’t have to. That’s the whole point.

This is where the workload identity concept pays off. Every workload gets a hardware-signed identity encoding exactly which code is running and which policies are active. If anything changes, code, config, policy, the identity breaks, and no data enters. The builder doesn’t manage keys or write security code. The infrastructure handles it. They ship.

Think about what happens with administrative controls at scale. You add agents, permissions, and people who can grant permissions. Every new node is a new trust assumption. Eventually, somebody misconfigures something, and you’re back to processing on hope. With workload identity, the trust is in the hardware and the math, not in the org chart. It scales the same way at 10 agents as it does at 10,000. The workload either proves its identity, or it doesn’t run. There’s no grey area at scale.

What practical advice would you give ITTech Pulse readers adopting agentic AI in 2026 to ensure compliant, breach-proof implementations?

Three things need to happen to adopt Agentic AI:

Build cryptographic policy enforcement into the architecture from day one.
Demand immutable audit trails of what every agent did, when, and under what constraints.
Treat privacy and governance as accelerators, not brakes, and stop thinking about AI security the way you think about application security.

The organizations that embed verification into their AI stack will move faster than those that treat it as a gate. When trust is built into the infrastructure, security and innovation stop competing.

About Aaron Fulkerson

Aaron Fulkerson is CEO of OPAQUE, the Confidential AI company. He previously founded MindTouch, an enterprise knowledge platform powering over a billion visitors monthly, and served at ServiceNow, where he helped build one of the company’s fastest-growing products. His career spans two decades of building enterprise platforms at the intersection of trust and technology.

About OPAQUE

OPAQUE is the Confidential AI company. Born from UC Berkeley’s RISELab and founded by Ion Stoica and Raluca Ada Popa, OPAQUE enables enterprises to safely run models, agents, and workflows on their most sensitive data. Its Confidential AI platform delivers verifiable runtime governance — cryptographic proof that data, models, and agent actions remain private and policy-compliant throughout every AI workflow. Customers and partners include ServiceNow, Anthropic, Accenture, and Encore Capital.

AI Confidential Podcast: Building Trust in AI with Mark Papermaster (AMD) & Mark Russinovich (Azure)

Visit the AIConfidential.com for the Podcast and Newsletter.

In a recent discussion between technology leaders Mark Papermaster (CTO and Deputy CISO of Microsoft Azure) and Mark Russinovich (CTO of AMD), the focus was on the transformative potential of confidential Computing in reshaping data security practices within the technology industry. Against a backdrop of escalating concerns surrounding data privacy and cybersecurity threats, the conversation delved into key themes such as Security and Trust, Confidential Computing, Data Control, and Collaboration. These themes underscored the critical importance of safeguarding customer data in cloud environments through innovative solutions like secure enclaves and hardware root of trust mechanisms. Confidential Computing, defined as a technology that ensures data remains secure even during processing by unauthorized parties, emerged as a pivotal tool in enhancing data security measures amidst rapid advancements in AI technologies.

The dialogue also highlighted recent developments such as the collaboration between AMD and Microsoft to streamline confidential computing adoption and Microsoft’s ambitious goal to transition to a confidential cloud by 2025. The introduction of Azure Confidential Ledger further exemplified industry efforts towards bolstering supply chain security. Looking ahead, the future outlook points towards continued advancements in confidential Computing technologies with an emphasis on expanding their application to edge devices while establishing robust integrity measures across computing supply chains. As companies strive to navigate ethical considerations around data control and privacy in AI applications alongside potential regulatory challenges associated with widespread adoption of secure computing practices, it becomes increasingly clear that fostering trust through enhanced security measures will be paramount for shaping the future landscape of technology innovation.

Tag: confidential-ai