‘Wouldn’t it be great if the chip were part of the security architecture?’
Back when I did the research that turned into Beyond Cybersecurity, several people asked “does securing the software really matter if we can’t trust the chip?” or “wouldn’t it be great if the chip could be part of the security architecture?”
A highly capable and motivated attacker could compromise firmware supporting the most sensitive workloads, making security controls at higher levels of the stack ornamental. While the US military’s Orange Book (1983) first formalized the logical boundary of a Trusted Computing Base (TCB), its multi-user specifications assumed the underlying physical hardware was secure inside a guarded facility. Distributed architectures and modern threat models shattered that assumption, forcing the industry to move that TCB boundary down into the architecture of the chip itself.
The Trusted Computing Platform Alliance (TCPA) — which became the Trusted Computing Group (TCG) — developed the idea of a Root of Trust, with three pillars:
Root of Trust for Measurement (RTM): The initial, immutable piece of code (usually embedded in the motherboard ROM or BIOS) that boots first and measures (hashes) the next component before handing over execution.
Root of Trust for Storage (RTS): A secure memory zone within the chip that holds the cryptographic keys and the accumulated measurements. Software cannot overwrite or read these keys directly.
Root of Trust for Reporting (RTR): The cryptographic engine inside the chip that signs those measurements using an endorsement key burned into the silicon at the factory, proving to an outside party exactly what state the machine booted into.
As of 2013, some devices had a Trusted Platform Module 1.2 (TPM), a distinct, low-cost microcontroller soldered onto the motherboard, completely isolated from the main CPU lines — but its separation from the main CPU both introduced bottlenecks and limited its security efficacy. Some data center managers declined to turn on this functionality because they feared the operational complexity it required could cause outages.
TPM 2.0 improved on 1.2. It embraced cryptographic agility and it moved the silicon root of trust closer to the CPU, often embedding it as an isolated firmware routine (fTPM) directly inside the processor chipset, eliminating the exposed external motherboard bus. To fix the datacenter uptime issues where a benign driver update would brick a server boot, it supported Policy-Based Authorizations.
But TPM 2.0 is an authentication and state-verification mechanism. It can verify that a system started up in a clean state, but it cannot protect data from being stolen while in memory.
To address these problems the Linux Foundation birthed the Confidential Computing Consortium, which published A Technical Analysis of Confidential Computing. This document established the non-negotiable baseline that unauthorized entities could not view or alter data or code running in a Trusted Execution Environment. This required chip manufacturers to redesign how processors handle memory management, CPU registers, and privilege rings. They couldn’t just build a “secure sandbox”—they had to modify the fundamental instruction set architecture (ISA) so the CPU could treat its own operating system or hypervisor as a potential threat.
Today, most enterprise-grade server and device chips have Confidential Compute capabilities, and companies are starting to use them. How do they use confidential compute to enhance the security of agentic systems without writing systems-level code to manage CPU instructions, page tables, and hardware register states?
A discussion with Opaque Systems CEO Aaron Fulkerson
Opaque Systems aspires to bridge the gap between hardware primitives and the enterprise application layer, by providing software engineers with access to policy enforcement, orchestration and cryptographic proof.
CEO Aaron Fulkerson talked about what this all means as enterprises seek to implement AI-based systems. Prosaic Times remains studiously neutral on particular technologies, but hearing from builders in their own words is instructive, and we always respect people who are passionate about the products they develop.
Here are a few of the key takeaways:
Prompt engineering and code scanning are probabilistic mitigations of a problem that requires deterministic enforcement. Confidential AI uses the encryption key baked into modern CPUs and GPUs to do that enforcement cryptographically: what ran, where it ran, what rules applied, with a signed report any auditor can verify. The hardware capability has been sitting in silicon for a decade.
Regulators are starting to ask about runtime enforcement, not just configuration. The EU AI Act, emerging regulations in Asia and the Middle East, and likely HIPAA are converging on a requirement that isn’t “we configured this policy” but “we can cryptographically prove this policy was enforced at runtime.” That is precisely the proof confidential AI produces. The regulatory hook is probably what forces enterprise adoption ahead of any internal security posture. Design for sovereign cloud will only accelerate this.
The policy standards landscape is a fragmented patchwork waiting for consolidation. Anthropic ships mutually-attested TLS. Microsoft has its own flavor. Google, Meta, TikTok, ServiceNow each ship variants. None of it is portable across hosts. A consortium effort building on SPIFFE, EATS, and RATS is producing a superset specification where the policy travels with the data.
James Kaplan: This is James Kaplan with another Prosaic Times podcast. We have one of the most interesting people in the cybersecurity space, Aaron Fulkerson of Opaque. Aaron, welcome.
Aaron Fulkerson: Hi, James. It’s a pleasure to see you again.
James Kaplan: Why don’t we start out by talking a little bit about your journey? Let’s hear about your career and what brought you to the place where you’re at today.
Aaron Fulkerson: Sure. Opaque Systems spun out of UC Berkeley — the same lab that created a lot of the foundational AI infrastructure: Spark, Ray, vLLM. The team that runs the lab — folks like Ion Stoica and Raluca Ada Popa — are world-renowned, nerd-famous folks. I was approached by them while I was running a business unit at ServiceNow, and I was intrigued by their background building the essential foundational technologies that everybody uses.
Ion Stoica being the founder of Databricks certainly got my attention. When I spoke with them, what they helped me understand was that they had created a new technology called Confidential AI that allowed regulated enterprises, governments, or sovereign entities to bring AI to their most sensitive systems and data, with verifiable guarantees about what ran, where it ran, and what rules were enforced.
That’s now become a whole category that Gartner writes about and that all the silicon vendors, hyperscalers, and everybody else covers. It’s been an exciting ride over these last two years.
From confidential computing to confidential AI
James Kaplan: All right. Why don’t we step back? Tell us a little bit about the history of confidential computing — what it is, and why it’s important.
Aaron Fulkerson: Yeah. It’s been around maybe ten years, so it’s been around a long time. What it means is that the hardware — a CPU or GPU — has an encryption key baked into the silicon, and that enables two key capabilities. One is what’s called a trusted execution environment, or an encrypted runtime: you can run your workloads on data while encrypted. That’s what everybody thinks about when they think about confidential computing. There’s another capability of confidential computing that’s at least as important, if not more — the ability to do what’s called hardware attestation with that encryption key. What that means is that you can cryptographically sign software.
Now, confidential computing is a hardware layer that’s available on all hyperscalers. All modern CPUs and GPUs have these capabilities. It’s not specialized hardware. What this enables is what we call confidential AI — a software layer above the hardware, above Kubernetes — and that means you can have hardware enforcement of what ran, where it ran, and what rules were enforced at runtime.
I don’t need to tell you, James, or anybody who’s an AI builder, that you cannot enforce rules on AI agents at a software level. There’s a greater than 0% chance — at least 1%, typically higher — that these things are going to circumvent your software rules.
So you have to do this hardware enforcement, and the good news is this technology that’s been around for a decade has found a killer application: confidential AI.
James Kaplan: Tell us a little bit about that. Tell us why software enforcement doesn’t work for agents and why hardware enforcement does.
Aaron Fulkerson: Sure. AI systems are non-deterministic, so they behave in ways that are unpredictable. There are a couple of things here. There are adversarial attacks, which is what everybody immediately thinks about when you talk about an encrypted runtime — but adversarial attacks are far less of a threat than the non-adversarial ones.
So what’s a non-adversarial attack? These systems, designed the way they are with software enforcement, bleed sensitive data. Opaque, in collaboration with our partners at UC Berkeley and a bunch of ISVs and large systems integrators, has developed what we call an AI surface map for data bleeds. It catalogs 46 different ways these systems bleed data by design, simply because they haven’t been hardware-enforced. They will circumvent your software guardrails by design, and the only way to enforce the rules is cryptographically — hardware-enforced, as I described. It’s fundamentally different from legacy enterprise software.
We’ve shifted from a hardware compute layer to a software compute layer. As these agents build a context window, calling your most sensitive data, they pass all that context around to do software analysis — probability, right? That’s how language models work: an analysis that says, “Oh, here’s the highest-probability next one.”
That context lands in application performance monitoring packages like Splunk or Datadog. Your CloudOps or DevOps teams doing memory dumps may be able to see stock trades, maybe executive compensation — anything that passed through.
There are a whole lot of different ways this category of system, AI systems, bleed your data if you don’t upgrade the trust layer. The same way we had to upgrade the trust layer with the transition to the internet and encrypt data in transit, we have to upgrade the trust layer for these AI systems — or you’re just going to bleed your most sensitive information everywhere.
James Kaplan: Give us the use case or the example.
Aaron Fulkerson: I’ll give you some examples. We have customers like ServiceNow, Encore Capital, other financial services firms, and, in Thailand, SCBX. What they do is use confidential AI. They deploy what’s best thought of as an AI module, because they aren’t going to shift all their workloads onto confidential hardware in the cloud yet — they’ve already built a lot of their systems.
They’ll start with, “Hey, we’re doing some really sensitive data processing — stock trades, HR information, or a CFO tool for summarization and analysis.” They’ll deploy that, and using confidential AI, they’ll create policy enforcement at the infrastructure level. For example: it must run inside my virtual private cloud. It can only communicate over this subnet. All the way out to the agent graph, this agent can only speak with these tools. All of that gets rolled up into a strong, cryptographically enforced identity, so that before anybody sends data to a workload — I’m using “workload” generically here, to mean any AI workload or agent — they can inspect the signatures and the cryptographic enforcement.
Does it run inside my virtual private cloud? Does it have the data-ingress and data-egress policies I require? Does it use my identity? Whatever policies you want get hard-coded into the identity before you send the data, so you can verify the integrity of the system. When you send the data, it’s sent encrypted. The policies are verifiably enforced at the hardware level. And most importantly, James, you get proof. You get a report with cryptographic signatures that any internal or external auditor can check, proving exactly what ran, where it ran, and what rules were enforced.
Why agents require new types of guardrails
James Kaplan: Let me play this back to make sure I understand it. In the old days — say two years ago — if we were building an application and we had a set of rules about which tools that application could call, or where it could send data, we would scan code against a set of policies and see if it violated those rules.
And if it violated the set of rules, we’d send it back to the engineer and tell them to go fix things, right? Then we’d rescan, and we’d be fairly confident it wasn’t going to violate that set of rules because we’d scanned the code. So far, so good? Now, if we’re building an agent, the agent operates non-deterministically.
So we can’t know with certainty whether that agent will call one set of tools or not, and the guardrails we’ve placed around it… When we’ve tried to use prompting or other controls to limit the purview of that agent, sometimes that works, but you can’t say with certainty that it’s going to work.
However, if we build the enforcement of those rules into the hardware layer, then we can operate with certainty. Is that a fair summary?
Aaron Fulkerson: That’s exactly correct. You’re talking about the non-determinism of these systems — you’re exactly correct. Let’s say there’s a 1% probability that one of these agents bleeds data, which we know for a fact is at least 1%, probably greater. At 1%, maybe that’s okay if it’s a non-essential system or data set.
However, scale that to 100 agents and the math gets pretty frightening — you’re now at something like 40-something percent.
At 1,000 agents interoperating and communicating — which may seem like a lot, but I’m running thirty-something agents in the background on my desktop right now while I’m speaking to you — you’re at a 99.9% probability of bleeding data.
James Kaplan: And there’s plenty of workloads where one percent is unacceptable.
Aaron Fulkerson: Correct. Absolutely.
I was speaking with some industry analysts just last week, and one of them was asking, “Is it really that big of a deal? We’ve always had people who leak in elevators and hallways.” (A quick fact-check on my earlier math, by the way: at 100 agents, it’s 63% probability.) The analyst — from a big firm everybody knows — was asking, “Does it really matter? We have employees who talk in the elevator or the hallway, and they’re bleeding data at similar probabilities.” The response I gave, which their colleague already understood, was, “It does matter, because what an AI agent can achieve in a span of seconds or minutes vastly exceeds what a group of organized humans, even malicious ones, could achieve in a year.”
These things are operating at machine speed with human-like capability to reason, decide, and act. That’s quite different from an employee in the elevator accidentally leaking some competitive information. We’re talking about systems that can do damage within seconds or minutes that bad actors might not be able to achieve in a year. And furthermore, the leaked data — it used to be hard to sift through. Somebody leaks some data, is it really that bad? Who’s going to utilize that data? AI will.
James Kaplan: Yeah, there’s also an autonomous-vehicle analog here. You could probably make the case that an autonomous vehicle is safer than a vehicle operated by a human. But there’s just more cultural fear and nervousness around an accident caused by an autonomous vehicle than an accident caused by a human driver.
As we seek to advance agentic adoption, a problem involving an agent and exfiltration of data is going to be culturally more challenging than somebody talking in an elevator. So yes — I agree with everything you said, plus the bar is probably higher.
Aaron Fulkerson: Yeah, for sure. I think that’s true. To pull on that autonomous-vehicle analogy: hey, one bad driver can cause a lot of damage. But if you had a swarm of autonomous vehicles that could self-replicate on the fly, driving all over the freeway at a thousand times the speed — which is effectively what these agents are doing, compared to human drivers — don’t you think you should have some additional regulation and enforcement that’s verifiable in a deterministic way, rather than by probability or just rolling the dice?
James Kaplan: So let me ask a devil’s-advocate type question here — or maybe not a devil’s-advocate question, more an architectural-alternative type question. I saw a really interesting paper about how you enforce controls on agentic systems. The paper suggested that maybe the right way to do it is, instead of having the agentic systems operate directly, you have them generate procedural code in real time, which you can then scan against a set of policies.
Obviously that injects latency. But if you were an enterprise architect, how would you think about the option of using confidential AI versus the option of having an agent write procedural code that you’d then scan using traditional code-scanning techniques? How do you think about the alternatives there?
Aaron Fulkerson: I think it’s complementary — I don’t think it’s an either/or. Just to restate what you’re proposing —
James Kaplan: I’m not proposing — describing.
Aaron Fulkerson: You’re describing. Thank you. The scenario is that the agent generates deterministic procedural code, which then goes through a scan.
I think that’s complementary, right? You still have an agent making decisions about what procedural code to write, based on the sensitive systems it’s touching, the tools it’s calling, the data sources it’s pulling from. And I’d assert that even in that environment, you’ll want to have some rules — and you’ll have to have them, because it’s increasingly a requirement in most regions and nations to have proof of what ran, where it ran, and what rules were applied to that agent, even when it’s producing deterministic procedural code that goes through another scan. I suspect that whatever’s doing the scanning might itself be augmented by AI in some form, right? And there again, cryptographic enforcement, or hardware enforcement. I tend to use the two interchangeably because our customers — the people deploying confidential AI — are AI builders. They’re not the InfoSec or security team or the compliance team. So as soon as a lot of AI builders hear “cryptographic” or “encryption,” they go, “Yeah, that — I just wanna ship cool stuff.”
So I tend to use the two interchangeably because I want builders to know: no, this helps you ship cool stuff faster, because you don’t have to go through the protracted six- to eight-month surveys with your internal and external auditors that I’ve heard so many CTOs and AI builders describe as their current dilemma.
Hardware identity and the supply chain
James Kaplan: Trust me, I see it all the time. One thing that struck me hearing what you were describing is the ability to prove where something ran. Does this mean each chip has a unique identity, and therefore you’re able to confirm that it’s being run by who you think it’s being run by — in terms of an external service provider?
Aaron Fulkerson: That’s exactly correct. As I mentioned, with confidential computing there’s an — by the way, I’m oversimplifying. I’m not getting into too much technical detail —
James Kaplan: Every podcast everywhere oversimplifies everything, right? Otherwise they’d all be fourteen hours long.
Aaron Fulkerson: Exactly. I know somebody is going to say, “Well, the attestation service might be —” so I’m simplifying. But to your question: there’s an encryption key baked into the silicon, and that encryption key is what’s used to do the attestations. At the time you invoke a service, you’ll know exactly the profile. Where is it running? What is it running in — these Kubernetes nodes, that virtual private cloud? What are the network rules allowing it to connect to external services? Everything is encoded cryptographically and enforced by the hardware.
It’s physics. The significance here is, hey, can you trust AMD, Intel, NVIDIA at a hardware layer? And as long as you believe they know how to manufacture their chips, you don’t have to trust anything else. Nothing else in that stack do you trust.
James Kaplan: And do you know — or is there some way of knowing — that this individual chip was bought by this service provider versus that service provider versus somebody you may not want to be doing business with? Is there some registry somewhere? Apologies if that’s a naive question.
Aaron Fulkerson: That does exist. There’s actually a standard — a couple of them, in fact. SCITT is one, S-C-I-T-T. SALSA is another. They give you levels of verifiable provenance over the entire supply chain.
I don’t know if there’s a registry that exists independently. The technologies to do it exist, and I know all the silicon manufacturers and the hyperscalers have talked about having a registry so that they have complete supply-chain verifiability — but I’m not certain that registry exists yet. As an enterprise, though, you can bake that capability into confidential AI. That’s a feature of confidential AI, absolutely.
James Kaplan: Yeah. That’s an interesting idea. If you could say, “We know with certainty this is running on a set of chips that was bought by this service provider — there’s no chance it’s running someplace else,” or, “We know with certainty this is running on a set of chips located in this national jurisdiction versus that national jurisdiction.”
Aaron Fulkerson: Yeah. So I know there’s a podcast — AI Confidential — that I’ve had you on,
James Kaplan: Of course.
Aaron Fulkerson: A podcast that I host. I had a great conversation — I think on the very first AI Confidential — with Mark Russinovich, who’s the CTO of Azure,
James Kaplan: I’ve met him — he was on that panel I did at the conference you guys had.
Aaron Fulkerson: Exactly, yeah. And I’m looking forward to seeing you back at the Confidential Computing Summit at the end of June — the 23rd and 24th in San Francisco.
James Kaplan: I look forward to it. I’ll be there.
Aaron Fulkerson: Mark Russinovich, and Mark Papermaster — the CTO of AMD — in our very first AI Confidential were describing exactly what you’re talking about, James. And I was naive.
This was early in my tenure at Opaque. I was so focused on AI that I didn’t think about the entire hardware supply chain — securing it end to end. But to your point, you could extend this concept beyond provenance and supply chain to the actual manufacturer. You could do cryptographic enforcement of the design itself.
James Kaplan: I was going to say — that’s something incredibly important, I think, in the aerospace and defense community. They know exactly what the provenance of the hardware is, and exactly what’s running on what.
So let me ask a slightly different question. In some respect, what you’re describing reminds me of the early days of cloud security, when we started thinking about what became known as cloud security posture management — and we started to realize how important the business rules and policies were.
It took some time to sort out the model for defining those policies, for managing them, for figuring out what set of policies you wanted to have. Could you speak a little bit about that — about the process of policy management for confidential AI? How far along in the journey are people? What techniques do they use? What tends to work well versus less well?
Aaron Fulkerson: This is a really important topic you bring up. In the era of cloud, we did a trust-layer upgrade where we said, “Okay, SOC — we have to capture our policies at the time of deployment.” What’s different here, and what’s being demanded in a lot of different regions — the EU AI Act requires this, new regulations are coming online in Asia, same in the Middle East, and I believe it’s also true for HIPAA — is that you have to extend that to runtime.
It’s not just policies at the time of configuration; it’s policies at runtime, and you have to provide proof of runtime enforcement. The significance of confidential here is that it produces a report of all the policies that were enforced at runtime, and you can prove cryptographically that they were executed.
Because of the nature of agents behaving with human capabilities at machine speed, you have to have provable runtime policy enforcement. The good news is there’s been a proliferation of great frameworks and tools for policy-as-code. You don’t have to reinvent anything — you just take the policies-as-code, cryptographically enforce them, and measure at runtime that they were actually enforced.
James Kaplan: You’re building on all of these component parts. This is another one of those one-plus-one-equals-three situations you see in technology — the combinatorics of technology — where we already have this policy-as-code thing, and we already have this hardware key baked in. Right.
Aaron Fulkerson: Right. You add these two together and — oh my gosh — now we’ve actually got a way to adopt AI agents confidently and safely. Because we want to attach AI agents to all our systems and all our data sources — that’s how you get value. The more sensitive the data, the more value you can get out of it, but also the more risk there is in bleeding it. The key point is that this new security requirement in the agentic system, like all things in tech, is something we were doing previously, brought forward in a new way.
Sovereign AI and the standards landscape
James Kaplan: So how does this manifest itself in sovereign AI? Hark Singh, the CTO of InfraPartners, did a fireside chat at the Technology Leadership Forum last week, and was talking about how sovereign cloud and sovereign AI are an increasingly significant demand driver in the data center space.
How do confidential computing and confidential AI intersect with the desire for sovereign cloud and sovereign AI? I was wondering if you could speak a little bit about those dynamics.
Aaron Fulkerson: Absolutely. It’s an essential cornerstone capability. Look no further than Dr. Najwa Araj of the UAE’s ATRC and TII, who stated in a recent press release with Opaque that you can’t have sovereign without this kind of verifiability.
James Kaplan: And look at Jensen’s keynote at the April — was it April GTC?
Aaron Fulkerson: Was it April or March? I forget. I think —
James Kaplan: I think April, but I’m not sure.
Aaron Fulkerson: Jensen had it at the center of his keynote — the central topic was confidential and verifiability. Why? Because he understands what we’ve just been talking about. He said it in every session after the keynote: in order to safely adopt enterprise or personal agents, you have to have verifiability. He’s talking about confidential, hardware-enforced verifiability. That’s exactly what he means.
So why does this have to do with sovereign? If you look across all the big tech players, all the silicon vendors have oriented themselves around these confidential capabilities. Hyperscalers are demanding confidential. Frontier model labs are adopting confidential. What’s going on?
The hyperscalers demand it because they know they won’t get adoption in the rest of the world — outside the United States — if they can’t verify data privacy for sovereign cloud operators. So they’re demanding it from the silicon vendors, because otherwise the hyperscalers are going to get their lunch eaten by NeoClouds in the rest of the world. That’s happening right now.
For the silicon vendors upstream from the hyperscalers: if they don’t provide these verifiable guarantees, China is knocking on the door with great chips. They’re coming to eat the silicon vendors’ lunch, so the vendors have to differentiate. They’ve found that differentiating around confidential is a great way to do that — because the hyperscalers need it.
What about the frontier model labs? Why are they so insistent? They’re making incredible models — their intellectual property is their model weights. If they can’t protect their model weights in a sovereign cloud in the rest of the world, what’s their differentiation?
James Kaplan: Property is going to be stolen? And that’s what confidential does for the frontier model labs — it allows them to deploy in the rest of the world with verifiable proof that they protected their intellectual property, their model weights.
So I heard a couple of things. For the labs, you can use confidential AI to protect the model weights. For users and for AI or cloud providers in the rest of the world, you can demonstrate you’re compliant with local privacy regulations, which may mandate encryption, and compliant with data-localization regulations that demand you say, “Okay, this type of data or this type of workload can’t leave this national jurisdiction.”
Is that a fair way of thinking about it?
Aaron Fulkerson: That’s the simplest requirement, and it’s a good one to focus on.
The other thing we’re seeing in the rest of the world around sovereign goes back to what we already discussed — how do we reliably enforce policies on agents, not just data residency but every kind of policy. And another thing we’re seeing a lot is that many of these sovereign nations have their own frontier model labs, or they’re fine-tuning models with highly sensitive healthcare data, and they need to make sure that’s protected.
James Kaplan: So let me ask this question. You talked about what each participant in the ecosystem wants out of confidential AI. Where do you think things will shake out — in terms of what happens at the enterprise layer versus the application-vendor layer versus the cloud layer versus the frontier-lab / model-provider layer? How will those different pieces of the ecosystem interact with each other, and what functionality will they provide around confidential AI?
Aaron Fulkerson: Over the next two years, everybody will begin to offer this. We’re already seeing it. We saw it last year with Google’s offering — mutually attested components, or confidential Gemini. Everybody’s going to be offering endpoints to their language models and their applications.
That way, you can do mutual attestation and roll up verifiable guarantees. In fact, we’re working with a consortium of silicon, cloud, and frontier-model-lab partners to create an open standard that lets you create rules — not just on a single host, but portable rules that you can pass between hosts and that govern the policies of a particular workload. If you’re going to send your data, you can send it with, “Hey, here’s the specific set of rules I require enforced,” or it fails — and if it fails, I can prove that you couldn’t even access my data.
A lot of these standards already exist, but they’re very fragmented. To your point, you see frontier model labs enforcing their own flavors of confidential — Anthropic, a customer of Opaque, uses mutually-attested TLS, right? That’s a slice of policies being enforced. Microsoft does something different — their own flavor. TikTok, Meta, Google, ServiceNow — everybody’s got their own emerging patchwork quilt of cryptographic, hardware-enforced policies, but they’re not portable and they’re not standardized. What we’re going to see — and I think there’ll be an announcement at the Confidential Computing Summit this year on June 23rd and 24th in San Francisco — is that we’ll take all of these standards from the Linux Foundation and IETF, like SPIFFE, EATS, RATS, and say, “Here’s one standard that’s a superset, that you can enforce at your organization, and that will be portable as long as you write against this specific open specification.”
James Kaplan: Terrific. Anything we didn’t speak about? I’m sure there’s a zillion things. Thank you for joining us.
Aaron Fulkerson: Hey, thanks for having me, James. Look forward to seeing you.
