BSidesSF 2026 - So you think you can airgap? (No.) (Ziyad Edher)

All right, folks. So, welcome to our first talk of the afternoon. We have Zaeed who's going to talk to us about this amazing topic you see up there. So, you think you can air gap? Apparently, no. Anyway, let's give a round round of applause, a big round applause for Zaeed. Testing. All right. Awesome. Thanks, folks. Let me get set up.

All right, sweet. Hey, my name is Ziad. I work on infrastructure and security at Anthropic, where we build, operate, and secure the massive training and research clusters behind Claude, our large language model. So, contrary to what this talk's title might have you believe here, you you know, this isn't really about shipping 100 researchers into a data center in the middle of nowhere. Uh fact of the matter is you can't properly air gap a research cluster and still do a bunch of remote research. But, what you can do, and sort of what this talk is about, is make exfiltration prohibitively slow. So, like slow enough to basically eliminate an attacker that has compromised your systems before they

can walk out with some of your precious assets. So, this has been like proposed theoretically in a bunch of places, but hasn't really been talked about in practice much. I'm not sure anyone has actually tried to do this. Uh so, this talk is basically going to be about how we tried, and what went wrong, and how we thought about it, and you know, ways that it wasn't reasonable and ways that it was. All right, so the thing to understand about our infrastructure, and about basically every AI kind of lab's infrastructure, is that kind of the business value, I guess, of these clusters is irreducibly tokens in and then tokens out. So, this is text, images, tool calls, videos,

whatever it is, it's going in as tokens, we're processing it on this massive cluster with our models and, you know, auxiliary code and and our big computers and everything else, and then sending tokens back out, and that's what Claude is, right? For from your perspective, it's it's a black box API that you're just sending stuff to. The weights, the code, everything else stays inside of this kind of compute cluster, this this black box. And only the tokens really need to cross over. So, everything else is overhead, but of course, in practice, you need a bunch of that overhead to properly operate a cluster because, again, we're not shipping the researchers, we're not shipping the infrastructure people into

the data center. You need remote debugging capabilities, you need metrics, you need a control plane, you need like data transfers in and out of the site. Uh but, sort of notice that a bunch of those red lines there aren't huge. Like, they're megabytes per second, you know, whatever, something like that. But, the weights are huge, you know, think terabytes, right? That asymmetry, we'll we'll get back to it in a little bit, but it's really important and and you just sort of keep that in mind throughout the talk. The other really important thing you should know about AI lab clusters is that they are often research environments. These look very, very different from your traditional kind of

typical production environment, where, you know, hopefully, you're you're you have a bunch of like standard good security practices, you're reviewing a bunch of your code, you're, you know, packaging it up and deploying it nicely and and kind of all that good stuff. In a research environment, you can't really apply all the same scrutiny that you would expect without like really hurting developer productivity, or I guess like researcher productivity. People expect to move much faster, basically. We take on a lot more dependencies, we have a lot more arbitrary workloads that we're running, and sort of a a bleeding edge stack, I guess, from the application to the operating system to the hypervisors that we're using to the firmware all the way

down to like the hardware and the silicon that we're running. All of these things are often like brand new and they have huge attack surface and sometimes aren't extremely mature. So, like critical vulnerabilities are found in the software all of the time. And so, obviously we're doing all the normal things to harden these these things, but kind of keep in mind that the attack kind of surface area is huge and all of this code and all of this hardware is operating on and next to one of our most important assets, which is these like huge mostly incompressible model weights. This is like Claude's brains, basically. So, like hundreds of millions of dollars of compute, a lot of time, a lot of

algorithmic work, a lot of data is being poured in to like creating these these model weights as effectively this like one standalone thing. Uh it's not like trivial to just rip it out or something and then run it somewhere else. You need a bunch of compute, you need a bunch of infrastructure. But, you know, for a sophisticated state actor or something, it's a pretty attractive target to steal and then kind of just walk out the door with. So, like realizing and and recognizing, I guess, some of the complexity or all of this complexity in the stack, we're going to try to secure it, but I really don't want to rely on that happening. You know, defense in depth is

good. Uh so, I don't want to rely on it happening in every single case. Notably, though, there's a bunch of like normal infrastructure that we can harden. You know, we have an identity plane, we can assume that AWS isn't popped, we can kind of like there's a bunch of other things that look a lot more like normal environments that aren't super fast-moving research environments. And over there we can apply a bunch of our standard security scrutiny right? Uh a bunch of that wouldn't fly in the research environment. But like besides that, what does it look like to sort of just assume that an attacker has full root on every single compute node, has access to all of our

source code, has access to all of our infrastructure configuration, all sorts of stuff like that? So like what can you build effectively when you want to sort of like distrust your entire compute cluster and everything running on it? Uh well, you need something at the edge, right? You need something outside of the the kind of like envelope of your compute cluster or outside of its influence, something that doesn't really care about what's running inside uh and and sort of dumb enough, I guess, that it can't be lied to. And so those are perimeter defenses, right? Like everyone has talked about this, everyone has heard about it. It's generally a security anti-pattern to rely on, you know, squishy inside, hard

shell type stuff. Uh but like keep in mind this is a layer of defense in depth. And there's a few popular kind of things that people do here or at least talk about. So like the true air gap is is one of them. You know, like literally disconnect your compute cluster, your your data center, your you know, cloud premises, whatever it is, from the rest of the world. This, you know, works in in principle, but like again, you've you've kind of completely ruined your chances of being able to do any form of remote research, and I need to somehow convince like half of the company to move into the Nevada desert, and that's probably not going to

happen anytime soon. A domain allow list is a lot more normal and is probably on like most folks' road map for a kind of mature infrastructure security program. It's definitely on on ours and something that we're actively rolling out. But at the same time, you have some things like, you know, s3.amazon.aws.com and github.com that are just like very obvious places to exfiltrate some assets to and then pull them down somewhere else. And then of course like people talk about content DLPs, these like in my opinion sort of rarely work. They maybe work against unsophisticated attackers, but if I'm a sophisticated attacker and I've compromised a machine, I'm probably just going to encrypt the model weights before I send them out and

kind of you're probably not going to find a content DLP that can really protect you against that. None of these controls though rely on a very important and kind of critical property of our weights, and that's that they're massive, right? And they can't easily be made smaller. That like mostly incompressible bit is actually pretty load-bearing. There's a bunch of reasons I think it's true, a bunch of evidence we have for why it kind of is. And also we would like benefit a lot from compressing the model weights ourselves. It would make kind of training and research much more efficient. So we have reasons to believe it's true, but with distillation becoming kind of more popular and with a

bunch of more research on the matter coming out, this might actually be falsified in the future. We'll see, but for now kind of just assume they remain huge and therefore they can't like be fit through a narrow pipe really quickly. So what if we sort of just made the pipe that's leaving the compute cluster really narrow? What if we limited the the bandwidth that can flow through it? So sort of imagine this in kind of like a physical site, like an air gap like structure where you have your normal air gap, you have your data center that's like fully air gapped, but then you have like a CAT 3 Ethernet cable leaving the the data center or something. So like

you can, you know, push like 10 megabits per second or 100 megabits per second if you're lucky through this cable. Uh so you can get like SSH traffic out through that, but it's going to be pretty difficult to get like many, many terabytes of model weights out. Like, to be clear, this this does not stop exfiltration, right? This doesn't stop like command and control. It slows it down. Uh it maybe makes it slow enough to become prohibitively time-consuming for an attacker to steal the weights. So, like days, weeks, even months if you're like going on the extreme ends. And every day that an attacker is in your clusters exfiltrating the weights is a day they

might get caught, right? Or a day that their foothold might evaporate or we might restart a machine and they need to do some like expensive pivot or regain access in order to continue their attack. And even on the extreme end here, you can kind of think that if this takes long enough, like months, then by the time they've stolen the weights and reconstructed them on the other side and found a way to actually run these these models, we've maybe already shipped something new and that might change their calculus on whether or not these models are even worth stealing. But like, this really relies on counting every single byte leaving the clusters. In a physical site, this is relatively

straightforward. You know, you have like a physical path out of a data center, you have a bunch of cables that that are going into like some perimeter router in a meet-me room or something, and then that is connecting out to the rest of the world. You can put your perimeter appliance over there. But in cloud, it gets a little bit more complicated. Still not super crazy. People do kind of like choke points a bunch in cloud. Anyway, we'll talk about that in a sec. But sort of the premise here is pretty simple. You want to flow all your traffic through the appliance. You want to count all of the bytes in the packets flowing through your appliance and start

dropping packets if you're above some allotted limit. It's like super, super simple. And this includes counting bytes that folks typically wouldn't really consider egress. So, I'm talking about things like ICMP and DNS and kind of TLS handshakes and SSH keep alives and all these things that from like a connection establishment perspective, you wouldn't consider egress. I guess like one fun example is TCP ACKs acknowledgement packets. So, you like establish a TCP connection, you're receiving packets, you're sending back TCP ACKs to acknowledge that you received the packets. Uh under like standard, you know, maybe average packet sizes or something we see in the infrastructure, it's about a 100 to 1 ratio of bytes. So, like for every

100 bytes you receive, you're sending about 1 byte out in a TCP acknowledgement packet. It's not quite that simple, but but you get the gist of it. Uh so, you would end up with like sort of download-only jobs that are sort of let's say downloading a a data set from, you know, some other place outside of our clusters and those would get rate limited sort of by accident because their TCP ACK stream was getting rate limited. And it's it's very reasonable to ask like what the hell? Like why are you rate limiting TCP ACKs? Is someone going to like smuggle a few terabytes out through like forged sequence numbers or forged timestamps? And the answer is

like almost certainly not, but the control does not care. It doesn't care, you know, what the bytes are. It's counting L3 payloads basically and that's it. It's kind of the same principle as like an air gap doesn't care if you're if you're doing like, you know, supposedly legitimate traffic. It's like almost a physical control in that way. And like, you know, of course like none of this matters if an attacker can just totally turn the thing off or just bypass it. And this is where like more normal infrastructure hardening comes in. We have an isolated deployment. We run it in an isolated cloud account. No standing access, you know, no humans in production. Only way to make changes is

through like a two-party approval kind of like automated infrastructure actuation system etc. like nothing crazy stuff that people talk about a bunch. Um but like importantly we spent a bunch of effort trying to make sure that even a full compromise of our compute clusters does not allow a pivot into this kind of like egress limiter environments that someone could like turn that thing off. We've also paid attention to like kind of denial of service attacks and that type of thing. And another kind of side of this is that an attacker also shouldn't be able to just find a different route out that doesn't pass through this egress limiter. So that's something we need to spend a

bunch of effort on as well as like assuming that they have admin on the cluster can they just like you know create like a new NAT gateway or something like that. And we tried to make that impossible in various normal cloud security ways. Like one important I guess like implementation note here is we really don't want a per second rate limit because that's like a huge pain in the ass for a researcher who's you know trying to get a few like I don't know like a few hundred megabytes out of a cluster because they want to like visualize some research results on their laptops or something. It's like okay well sucks I guess you need to wait like 6

hours for that transfer to finish. That that's not going to fly. Um so we use a pretty standard rate limiting strate- strategy called the token bucket filter and you can think of it like we have this large kind of bucket of of accrued bandwidth. Uh maybe like it's it's the size of say like a few hours or maybe a day of total bandwidth. And when you're under the limit so think like nights and weekends or or just general downtime we're accruing bandwidth into this bucket. And then we allow ourselves to spike arbitrarily high above the the sort of like stated per second limit. And that lets people kind of do large amounts of bandwidth in a small period

of time. And then as we drain out that bucket, we start dropping more and more bytes. And we like sort of a a larger proportion or percentage of our total traffic. So what this looks like is if we're starting to run out of bandwidth, we kind of gradually decrease, let's say the speed of egress from like basically totally unlimited in like certain burst scenarios into like, okay, now like, you know, you're you're going all the way down maybe to the per second limit. So from a client perspective, this this just gives them kind of a better experience. They like TCP clients they have will adjust to those kind of new limits and and that sort of thing.

That's like basically it from an architecture perspective. There's nothing really that much fancier, but there are a couple of like design kind of issues, I guess, with this. One is in cloud, you have multi-tenant cloud services, things like S3 and logging and other ways that you can leave kind of the the the like compute cluster like envelope of of data, I guess, or whatever. Uh that's a problem, obviously. Like if I can just go through that path and leave, then then all of this is for nothing. And then the second problem is a kind of the shared blast radius that we have here. If I have like one researcher that decided, "Oh, I'm going to like, you

know, try to publish like a gigabyte or two gigabytes or 10 gigabytes of like, you know, research results somewhere. Are they just going to take down the entire cluster for everyone?" Uh you know, or like sort of an infrastructure misconfiguration, a container pull storm, or someone excessively logging something. You can think of a million ways that we could accidentally, not maliciously, kind of do a bunch of egress and sort of take everyone else down. So to solve for this, we have this sort of tiered enforcement strategy. Uh we have like a happy path, right? This is a This is like not a security control, it's a reliability control where we're running sort of node local daemons or agents

that restrict the amount of egress that can leave a specific like Kubernetes pod or Kubernetes kind of like, you know, container or whatever it is. We can kind of go up and down the stack. Uh and that helps us make sure that if someone is launching a job and it's misconfigured in some way, it's kind of restricted just to their node that gets hurt or just to their kind of pod that gets egress limited. This is again like not a security control because we give people the ability to tune this basically arbitrarily. You can go as high or low as you want and we start off at some reasonable kind of amount, but generally this is oversubscribed to the total

limit of the clusters. But kind of more importantly, under our threat model of full cluster compromise, none of this matters because an attacker just goes into the node and turns off the Linux traffic control kind of filter that we've configured and this is all gone right? So, as we kind of move towards the perimeter, right? As we get to kind of our actual perimeter perimeter routers, that's where the security control starts to kick in. Notably, we like let's say a packet is reaching the perimeter router, we kind of we look at the destination of the packet along with some additional metadata and we make a call on kind of what service we think that is associated

with as a destination. So, you know, we bucket it into groups like logging and metrics and blob storage and all those sorts of things. That way, when say like an infrastructure change rolls out that like triples the amount of logging that we do and it goes over our allotted egress limits, only kind of the logging services get impacted and we can route that alert or that kind of like notification or whatever it is to those logging services without impacting kind of blob storage and everything else. It's pretty normal like kind of, you know, bucketing of of I guess like failure domains and whatever. It's just applied to kind of a weird domain here. And then of course like take all of your

per destination buckets and you end up with the total kind of regional or cluster wide limit. And that's what we use to make the determination of like, you know, how fast could someone exfiltrate out of the cluster. And then we have the cloud services, right? The the cloud service kind of multi-tenancy problem that I mentioned. We try not to fight the cloud's data plane and do something like particularly weird here. We already trust them a lot for enforcing normal IAM and kind of like boundary policies and whatever. And so we we trust them to enforce that in this case as well. That's kind of why the the assessment that like AWS isn't compromised is load bearing for our

threat model. The premise is is pretty straightforward. You have sort of a multi-tenant cloud service. Let's just say like blob storage S3 as an example here. You take all of your S3 buckets and you kind of designate each as either in the boundary or out of the boundary. And then you enforce a couple of very important invariants. One is the in boundary blob storage buckets should not be accessible from outside of your compute boundary. And then the other important invariant is that your compute boundary shouldn't be able to access any blob storage buckets outside of the set of buckets that you've deemed in the boundary. And so what this looks like then is that I'm if I'm outside of the boundary for

whatever reason, I'm just like a user on on their laptop and I try to hit an in boundary bucket, then I'm going to get like just a regular IAM deny thing. Similarly, if I'm in the compute cluster and I try to hit an out of boundary bucket, then you know, same deal. IAM deny. This is kind of a pain if you're trying to do very small transfers and especially because we kind of want to minimize the buckets that are in the boundary here, keep them to our kind of like highest security buckets. So, we also have built a set of proxies that allow people to access kind of cross-boundary buckets as long as they go through our egress limiter.

So, that's kind of the gist of the entire architecture and kind of the two main gotchas that were involved that we needed to solve for ahead of time. But, the rollout here was pretty much a nightmare because kind of with most big migrations and stuff, things just start to fail, right? You end up with like a bunch of IAM denies, you you end up with things that you can kind of immediately trace back to the control that you just rolled out. But, in our case, things just kind of got really slow in some cases. They don't immediately fail, but they do end up failing sort of down the line when something times out or, you

know, when a when a thread hangs and then like some very annoying long chain of cascading failures that's really hard to kind of trace all the way back to this egress limiter. We didn't really have the right observability tools to get a good sense of when this was happening. Uh and kind of this was this was a huge huge huge pain. I I can't overstate how much overhead there was with people coming to us for every single networking issue at the company just being like, you know, is it the the name of this this egress limiter was was gatekeeper. And so, like is it gatekeeper was like the the joke that was involved like anything would break

and people would be like, is it gatekeeper? And like maybe 30% of the time it was, uh which is which is not good odds. So, people are going to like go to that first. Um and and it really did like touch basically everything and kind of failed in in ways that people didn't expect. Kind of the silver lining I kind of just tell people internally is, "Oh, you you found out kind of how a bunch of your networking services interact with each other and work and stuff." But, this is a pretty like, you know, chaos monkey's way of of figuring that out for like a production cluster. But in the end, we did manage to kill

off about 98% of all of our egress, which was huge. Uh this was about four or six months of like reclassifying buckets, migrating services, talking to teams, re-architecting systems, kind of all a bunch of sort of normal migration stuff to bring things either into the boundary or reduce the cross boundary communication we need to do otherwise. Uh the the number here is sort of a cop out because that last 2% is really the hardest part here. It's the stuff that kind of we can't strip away, we can't throw away. So, it's your debugging, your metrics, your SSH connections, you know like pages that are hosted inside of the cluster for whatever reason, researchers wanting to get data out, all all sort of

stuff that it's like, "Okay, well, you kind of need to change everything if you want to get rid of that." Uh but, you know, that in mind, the limit is low enough to give us a few pretty important benefits. One is that sloppy or sort of accidental exfiltration attempts are basically blocked by kind of virtue of taking hours instead of uh or or even days sometimes instead of like minutes. Uh and they kind of like page us very loudly if something very weird is happening, that sort of thing. So, like for example, uh this has happened a few times where like someone we we try to keep our like, you know, the buckets that have our

model weights really locked down and kind of like restricted to a set of buckets, but the infrastructure generally needs to access a lot of things. And so, sometimes people will like want to run a run a transformation on the model weights or something. And so, they'll like download them onto some set of machines, run the transformation, not realizing that they shouldn't be uploading them to some like other bucket that's still within our infrastructure and still secure, but like not designated for model weights. In this in this kind of like scenario, if they were to do that, now and that bucket was out of the boundary, then their attempt to upload would go at like, you know, 128 kilobits per second

or something, which would take them days to finish and upload. And so, they would get notified in some way that they're saturating kind of their their jobs egress limit, and they would come to us and be like, "What's going on?" And we'd sort of explain to them what what is going on and and why what they're doing is wrong and what they should do instead. And so, another thing that it really helped with is sort of like building a bunch of the core foundational technology on the path to air gapping, which is, you know, something that we want to eventually get to and sort of very sophisticated uh like security kind of like maturity levels.

We're kind of a bit further along that path now. And then, of course, now we have this like really great platform to build a bunch of other perimeter controls on top of. So, think like TLS interception or domain allow lists, you know, that sort of thing. But, of course, like just to zoom out, I really don't want to rely on a control like this because perimeter controls are ultimately very much a concession. They're what happens when you basically don't want to trust any of kind of the inside of your environment. So, that that's kind of how I framed it at the start, right? Like, the clusters are research environments, and we don't have the technology yet to like fully secure

those uh at least to the level that we would a regular production cluster. Uh so, this is kind of a a fallback here that I never really want to actually rely on. Instead, sort of the real direction that we want to go in here is to minimize the things that can actually touch your unencrypted model weights, you know, that that very sensitive asset. Uh and and sort of go in and secure those kind of minimal set of software very aggressively. So, you can think things like, you know, doing inference in a tested trusted execution environments, you can think like confidential compute that spans kind of the the host and the accelerator, maybe just the accelerator

in some some schemes here. There there's loads of things you can do and lots of stuff that needs to be hard in the long the way to actually doing that. Uh we we've talked about some of these things and what we're planning on doing publicly as well. But that sort of thing takes years, right? Just a lot of application level changes. You might even need to wait for new hardware. For example, in the case of like, you know, attested TEEs and then confidential compute. Uh and you need to touch like workflows that that are touching the model weights and move them to something else. And that takes a lot of kind of interacting with teams. It's not just like a

perimeter control that you can slap on and then kind of like, you know, uh be done with it and hopefully make it as transparent as possible. So, yeah. That's kind of the That's kind of it. Uh hopefully this was a an interesting look at sort of a weird control that only works for us because we have this like massive asset and very small kind of relative legitimate traffic. Uh you probably don't have those exact same properties in your infrastructure. But there might be some asymmetry that you do have that's sort of rooted in the physics of your asset or kind of the particularities of your environment uh that an attacker can't really negotiate with. And yeah, so it's for us this wasn't a

silver bullet, but it did help us reason a lot about our data flows and about our infrastructure in a way that we hadn't like considered before. Uh especially now that we are kind of more on track towards kind of more air-gapped to build outs in the future, which I think are sort of the the most kind of practical way nowadays of defending against sophisticated state actors. So, yeah. Thanks for coming to the talk and I think I have a couple of questions I can take. >> Here we go. There were no questions on the Slido, so we'll do a couple questions in here. But first, yes, big round of applause for Ziad. Ziad, thank you man.

What? There are questions. We're going in the room first. I saw a hand. Who is there? There, you in the front, sir. Yeah. I have a question to your security model. Something I noticed is that most of this is probably only would work for a weaker company but if they're like after production and transfer to the customer tokens going out of the company is not a good place. Is that something that like does Anthropic think that the value of getting at the weights of the model that you guys trained 6 months 8 months ago is that much less important that attackers or that it's it's Yeah. Worth having all these different vectors Yeah, that that's a great question. I'll

repeat it maybe in case folks didn't hear. Uh the question was roughly what about the inference clusters where you have a kind of where where you need to actually do a bunch of legitimate traffic for tokens in tokens out. Kind of what do you do there and do you really think that kind of the um say uh the model weights 6 months 3 months whatever earlier is that much more valuable that you're not paying attention as much to that. And you know that's a great question. Uh the answer is we do also apply this to our inference clusters except we kind of change the way that we count the bytes and we we harden kind of

the specific ingress and egress points related to customer traffic that are handling kind of that cross boundary. And we like just accept the risk I guess of that being an arbitrary exfiltration vector from the inference clusters specifically. Uh so we're kind of taking a little bit more risk on from the inference clusters. There's kind of future work that we're looking at which is like okay what what if we can prove that the only bytes that are leaving or what if we can prove that kind of we can subtract the bytes relevant to the stuff created by the model. So if I can prove that that kind of a a packet actually or like kind of tokens were actually generated by my

inference model then maybe I can subtract them without actually taking kind of incurring a bunch of additional security risk. We do have a couple questions from the Slido. The first one here is do you see DDoS from the ingress side as a significant threat to AI clusters given your focus on the egress traffic. I feel like there's a couple of ways I could interpret that. So, I'm going to I'm going to try one way, which is like if I if if like I am an attacker and I want to stop people from using Cloud, what if I like establish some connection with something inside and then force say, you know, some egress uh whatever. Like like I'm hitting like a

metrics endpoint that we left open or something. Uh and the answer is sort of yes. We we don't really see this in practice, but one of the nice things with this architecture is that it basically forced us to lock down every single path into the cluster because otherwise how would we know that we're actually passing through the egress limiter? So, generally speaking, there are only like a few endpoints that you can actually hit from outside of the cluster into the cluster. And yeah, if you manage to find some kind of way to get a bunch of data out, uh then you you might be able to take down sort of the the egress limiter here

or saturate it, but that's where kind of the tiered enforcement that I mentioned here, that's where that would come in is it would probably just kill like one of the buckets or maybe one of the nodes. I think we got time for one more Slido or in the room. I'm going to go in the room. Go ahead, sir. Ma'am.

Yeah, the the question was about confidential compute and if we've done a lot of work on that. Um I'm not like the expert on our work on confidential compute. We have published or like we we've released some details about what we're doing there. We are starting to look at confidential compute. There's a bunch of applications for it that don't involve this egress limiter. My perspective right now is that confidential compute is full of holes that kind of people have not figured out how to solve yet, but it does let you reason about kind of your trusted computing base. To do confidential compute, you really need to like minimize the things that are touching your sensitive asset, and that

to me is the main value of confidential compute right now. It's kind of the second order effects of how do you prepare yourself for something like confidential compute, and then we're also working with with a lot of hardware vendors on improving their confidential compute offering. Let's give a round of applause for Ze'ev again. Thank you so much. Give us a better understanding of how we're protecting some of these parts of our future. Awesome. >> Thanks again. Yeah, thanks, folks. Ze'ev here again in 15 minutes, so you're welcome to have a seat if you'd like. Otherwise, next talk starts in 15 minutes.