Ship It Conversations: Kat Traxler of Vectra AI on AI Security, the Zero-Day Clock, IAM, and Cloud Risk

AI security is in a weird place right now. On one side, there is real excitement. People are building faster. Researchers are moving faster.

Bug hunters can narrow huge codebases down in ways that would have felt impossible a few years ago. The blank page is less scary. The first draft is easier. The first pass through a massive repo is not quite as painful.

And honestly, that part is cool. But on the other side, security teams are looking at the same acceleration and asking a much less fun question. What happens when attackers get faster too? Because this is not just about AI writing code.

It is also about AI finding bugs, AI helping weaponize vulnerabilities, AI making it cheaper to search for weird code paths, injection bugs, RCEs. And the kinds of flaws that used to take a lot more time and patience to find. And somewhere in the middle of that, we still have the same boring problems. Credentials, IAM, misconfigurations, unpatched systems, source code secrets, people getting tired, teams moving fast, systems nobody fully threat-modeled because the feature had to ship.

That is really what this conversation is about. Not AI will destroy security. Not AI will save security. More like what actually changes when AI speeds up both the people building software and the people trying to break it.

I'm Brian Teller from Teller's Tech, and this is Ship It Weekly. Welcome back to Ship It Weekly, where I filter the noise and focus on what actually matters when you are the one running infrastructure and owning reliability. Most weeks, it's a quick news recap. In between those, I do conversation episodes with people who are building platforms, running infrastructure, finding security issues, and thinking through where this industry is actually headed.

Today is one of those conversations. I'm joined by Kat Traxler, a principal security researcher at Vectra AI. Kat focuses on abuse techniques and vulnerabilities in the public cloud, especially around cloud, AppSec, IAM, and those uncomfortable places where everybody kind of assumed the layer underneath was safe. And I like this conversation because it lands in a more honest middle ground than a lot of AI security takes.

There is definitely hype. There is definitely fear. There was also a bunch of practical reality sitting underneath both of those things. Kat had just come out of RSA and the Unprompted conference, so we talk about the current AI security mood, the excitement from startups, the nervousness from security teams, the San Francisco Consensus, the zero -day clock, and this growing belief that AI is changing how quickly vulnerabilities can be found, understood, and potentially weaponized.

But we also talk about where teams actually get hurt first. And the answer is not always the flashiest new AI attack. A lot of the time, it is still credentials, IAM, misconfiguration, known vulnerabilities, unpatched systems, the same boring fundamentals that have been ruining everyone's week for years. That tension is what makes this conversation useful.

Because AI is absolutely changing security research. Kat talks about using models to narrow the search space in bug hunting, why they are good at finding certain code-level issues, and why they are not as good at understanding context, privilege, deployment shape, threat models, or whether a flaw really matters in the system where it lives. We also get into prompt injection, AI-assisted writing, using different models for different research tasks, and why being an expert still matters if you do not want the model to confidently lead you off a cliff.

There is a really good thread in here around IAM too. Why do teams keep failing at it? Kat's answer is pretty simple and pretty true. IAM is where people and technology collide.

Credentials, authentication, access, human behavior, shortcuts. Fatigue and attackers taking the lowest friction path it is not just a cloud service problem it is a people problem with an API. And toward the end we talk about overhyped AI security narratives what actually happens if the zero-day clock keeps shrinking whether we are headed towards more insecure by design flaws and why some of the hardest problems left maybe less about bad lines of code and more about bad assumptions.

So if you work around cloud, DevOps, SRE, AppSec, IAM, security operations, platform engineering, or you are trying to separate useful AI security thinking from panic and vendor fog machines, this one should be worth your time. All right, let's jump in. Today, I'm joined by Kat Traxler. She is a principal security researcher at Vectra AI focused on abuse techniques and vulnerabilities in the public cloud, especially at the intersection of cloud, AppSec, IAM, and “we thought this layer was safe”.

Kat, thank you for joining me. Thanks for having me, Brian. I'm excited to talk about the new accelerated world we find ourselves in. It is.

It's definitely a new accelerated world for sure. Tell me a little bit about what have you seen lately in the last couple of weeks or months as far as AI or security in general? I'm coming off the heels of RSA. So I spent a four-day pilgrimage out to the bay.

The vibe was definitely rational exuberance. Exuberance? Yeah. That's not quite a word.

But you know what I mean. Everybody was incredibly optimistic. A lot of two-pizza teams. Somebody breaks off from a big company with...

A set of like AI LLM skill sets and are like racing to the future. So in the startup space, people are jazzed. I haven't seen this level of excitement in a while. You contrast that with middle America, where I live and folks are much less enthusiastic about AI and its role in our life.

Then you contrast that with, you know, the security sec op folks. And people are very, very nervous about what's to come. So you just have so many different experiences depending on where you are at in this world. That's fair.

I think I hold all of those in my head as well. I mean, just as a person, right? Like, I mean, there's excitement. We talked a little bit before we started.

Like, you're able to iterate more. You have all these projects that you wanted to start that you couldn't start. Now you are. But then there's also the security side where you see the RCEs and attack vectors that are more prevalent than they were maybe a year, two years ago.

So, yeah, it's a different world for sure. The security reporters are busy, right? It seems like there's a new massive major story that they're covering weekly. A new, you know, critical zero-day, a new supply chain attack.

The frontier model companies, Anthropic and OpenAI, have showed us that these models are really, really good at finding these specific kinds of vulnerabilities. Not all vulnerabilities, but these specific kinds of code-level vulnerabilities. They can find them like no other tooling has found before. So we're just having an onslaught of these vulnerability announcements now, and it can be really overwhelming.

That's fair. So recently you wrote about, you had a right, you had an article, the San Francisco Consensus. Can you explain that in your words? Sure.

That was coming off the heels of another pilgrimage to San Francisco, going to the Unprompted conference, which I was one of the organizers. I was one part of the CFP process and had a blast communing with all of the fantastic AI researchers, but there was definitely a consensus amongst folks that coalesced and peaked with Nicholas Carlini's, I almost called it speech, but talk. He's with Anthropic's Frontier Red Team. If you haven't seen that talk, please go see it.

He really lays bare the issue of the zero-day clock, which is the idea, not the idea, I mean, the proven phenomenon that The time between a zero-day being announced and it being exploded in the wild had gone from two years. A couple of years ago, it was like two years it would take. You'd have this announcement, and then it would take attackers literally two years to weaponize it. Now it is just hours.

You have the announcement, they can weaponize it. Nicholas Carlini's talk at unprompted late is over there. And I'm telling my dog to not bark at everybody. Can you hear that?

I'm sorry. Of course, right in the middle of what I'm talking to people. This captures the zeitgeist and the, you know, kind of pure, the pure terror slash pure excitement in everybody's eyes that LLM can find code-level vulnerabilities like no tooling has found. Attackers are weaponizing it in minutes.

Therefore, and people don't really explain what the “and then therefore” is, but the and then therefore is kind of assumed that and then therefore systems will crumble, our global technology infrastructure will no longer work. We will have a complete collapse of critical infrastructure. We will go to the Stone Age, move to the woods. So I'm kind of catastrophizing a little bit, but that's the natural conclusion of the zero-day clock.

And that's the consensus, is that we are months away from this scenario occurring. So is it kind of a take on the doomsday clock, where we're counting down to... Yeah, yeah, yeah. Although I think the doomsday clock is sort of like...

arbitrarily set by some people. Yeah, this is, I think this is backed by some real data. And I've read a report from RAPId7 recently that was really good that has a lot of backing data. They never say zero-day apocalypse, but they have this like 26-page report that backs up all of the observed data points in the wild that just kind of come down to.

In 2018, it was two years to exploitation. Now it's minutes. And the big question is, and then what? And I think we should, as a community, spend a little bit more time filling out the “and then what”, as opposed to just kind of letting our minds go wild.

And everybody has a different idea of what and then what means. So if you had to rank where teams actually get hurt first, what's at the top? Like, where should we start? Yeah.

I mean, historically, it's been credentials. Historically, it's been mishandling of credentials, reusing of credentials. It's been committing them to source code, having them be static, not having efficient rotation in them, and then misconfigurations. In the new RAPId7 report, I believe that they had said moving to the top of initial access was...

just a small suite of known code-level vulnerabilities. So I'll use Log4j, but just those kind of like reused over and over and over CVE exploits that are known and patchable and are just tried over and over and over again. So by the numbers, those are still the things that are biting people when it comes to initial access. Going forward, the zero-day clock and the San Francisco Consensus says They don't necessarily say that those things aren't going to matter.

What they say is that there's a whole new attack surface that's going to be open and that's all the zero-days that nobody knows about. All of the code-level vulnerabilities within your exposed on-prem stack or any other piece of infrastructure that hasn't been exploited anywhere that because finding a zero-day is now just costs and tokens that's what you have to now protect for and i'm just saying like that's that's the san francisco consensus is like that that attackers will shift to that exploitation I doubt it because i think all the other mechanisms just work so well that I do not think that that will be, at least in the foreseeable future, the exploitation route that attackers will leverage, at least initially.

It might be a concern for some of the large institutions, Google, IBM, nation-states, but for your average mid-size technology companies, it's still potential reuse on patched servers. That kind of stuff. So what's your take on prompt injection as an ops problem? An operations problem?

Yeah, over just like an app problem specifically. Tell me more. What are you thinking more about that? Like the different layers it interacts with or like how it affects the infrastructure?

Yeah. Where that may be. Or if you see it as an issue going forward, more so in the future, operationally. Yeah, I'm not exactly sure how to answer that.

I mean, there are frameworks now to protect against a significant amount of prompt injection. They're notoriously difficult to implement and operationalize. Ultimately, there are bypasses. So, I mean, it's always some level of a WAF.

So it's always going to be some whack-a-mole that you're playing with the prompt injection defenses. But I don't see that folks are really even using the most basic level of prompt injection mitigations out there that are available to them. Here in 2026, there are... A significant amount of prompt injection frameworks that could help.

Again, you know, it might come out to be 96 % effective, 97 % effective, 98 % effective. There's always still going to be a bypass. Yeah. Does that answer your question?

Yeah, it does. That's good. I probably didn't ask it well. I don't know if you wrote about this or I heard you talk about this.

We're talking about AI helping narrowed the search space in bug hunting oh yeah how are you using that in practice well i can't tell you I am using it to narrow my search space uh no i mean okay so for example, for code-level vulnerabilities you have these like huge massive gnarly codebases that you know, to some level or another, you're like just grepping your way through looking for bad patterns. And then maybe you're using, this is the old way, maybe you're using a static code analysis tool to kind of help you with some of that work.

But ultimately, you're just grepping your way through a problem. But the LLMs love this sort of problem, this sort of like injection issue, which... A large portion of the OWASP Top 10 just comes down to like injection issues. And they love this sort of problem of taking this massive interwoven complex blob and being injected with the concept of like, you know, bad input in results in bad input out.

And where are the potential mitigations? How can they potentially be mitigated along the way, doing all the heavy lifting for you and being able to get down from 500 lines of code to maybe 100 that it's going to flag for you as potentially bad. I found that it's amazing for these known problems. These issues that you can come down to, this is this bad line of code, and you can then insert this particular type of sanitization or parameterization and fix it.

It's something that it's really great at. It's not so great at understanding context or the threat model around where it's deployed, who the users are, what data those users might be accessing, under what conditions, those subtleties that are going to change. That's a whole different problem set that they're not good at yet, and which makes me realize that I still have a job. But those code-level things that are like needles in a haystack, they're good at finding needles.

They're not good at finding, I would say that they're not good at finding all of the needles. If you want to find a needle, you'll find one, but you won't find all of them, if that makes sense. Is it primarily certain languages or certain query formats? Like, are we talking like SQL injection?

Are we talking like app function calls? Or specifically Python, maybe, because the LLM has that training data? You know, I really don't know what it comes down to. I've done a huge project on just trying to find remote code execution.

And then ensuring that it's tracing back to some sort of untrusted input from a user. So being very clear about where... What inputs it is allowing, you know, from where. SQL injection is great at finding.

XSS is great at finding. Not as great as finding things like confused deputy, which are, again, contextual. Like, what's privilege? That's always, like, a squishy thing.

You have to be really explicit with it. I mean, the people who are doing bug hunting. On the client side client-side issues it's great finding IDOR um like it's really great at these very specific not things that don't require a ton of context issues and going from this massive code base to these handful of things and then proving exploitability yeah i i really couldn't tell you why it's good at that why that puzzle it it turns on really well as opposed to it doesn't understand the nuance of privilege.

Are you using public models or are you training like your own data? No, I'm using a lot of different public models, but I switch between a ton of different ones. Obviously the Claudes, I'm switching between the various versions of Gemini. I'm switching between also some local models like Gemma.

So I try to be efficient with my token usage. Folks that are wanting to get into bug hunting, I think there's a lot of advice that just says like run it all on Claude Opus 4.6 and just go to town. I'm much more, I'm just much more delicate around, which model I use when.

Because I think that they can do... They play well off each other. You can use one to catch the bugs of another or to help catch the faulty process of another. One might have a glaring gap that you just aren't aware of that another one can catch.

Yeah, I know. ChatGPT is really good at spatial awareness, whereas Claude's very good at generally coding -type challenges and problems. Is there a specific model that maybe works better for prompt injection -type research, or is it more nuanced than that? I mean, all of the bug bounty people will just say, turn Claude on to your target and go to town.

I don't think you're going to go wrong with that. It just depends on how efficient you want to be with your token usage. I think it's overkill to use Claude on the vast majority of tasks. Now, if that's your profession, if you are a full-time bug bounty hunter, you're going to scale up to as many Claude Max subscriptions as your budget will allow and just set them off.

Me, not so much. I'm going to be a little bit more delicate with what I use when. And I think that's kind of fun because you get to learn all of their intricacies. And I don't know if you heard, but just today there was the revelation from Anthropic on Project Mythos, or sorry, Mythos, their next iteration of models and Project Glasswing.

which is their private preview of Mythos to about 40 different companies. Particular researchers within AWS, Azure, Google, IBM, Cisco, Palo Alto, CrowdStrike, kind of like all the big ones, have private access to this incredibly powerful model, more powerful than the current iterations. And they're not planning on releasing it to the public. They are wanting it to only be in the hands of hand-picked organizations to allow them to shore up their infrastructure for potential onslaughts.

I wonder how the U.S. Government will react to that. They weren't on the list.

I want to see that list of MAGIC 41, you know, Cisco, IBM, Red Hat, Kat Traxler. That is what i'm looking for that'd be a cool list to be on for sure yeah that would be a great list yeah what parts are AI good at versus what do you still need a human for like is there any part where you think that like AI is not quite there yet i mean we talked a little bit about context and not having like contextual awareness around like large monorepos or large monolithic apps but are there other areas maybe where i mean for example For example, writing.

I do a ton of writing. And I have had LLMs just generate an article for me and it's crap. It sounds like garbage. I can't handle it.

But I can go through and put together a decent rough draft. Write it as if I'm just writing for myself very casually. I do not concern myself too much with... Spelling mistakes and word order if I mess up here and there.

But make sure I have like the needs of my argument. Sometimes I'll even do it in bullet points and then send it to my LLM of choice. Have it with some very direct instructions on like the tone and how much to shift away from my tone. Have it be very constrained and then iterate on that from there.

So I think it has a great place in writing. We just, I just personally, use it somewhat sparingly. So just getting your voice out there I think is great. It's such a barrier to entry for some people to blog, to put articles out there.

They see that blank page and they don't really know what to do. If they could say, you know what, just write a table of contents, a list of bullet points, sentence fragments, paragraphs here and there, and then start. I think that can maybe unlock a lot of knowledge that people have and they can publish their ideas. But if you don't give it enough meat, it's really going to come out pretty poorly.

So that's with writing. And then, you know, obviously you need that expert level knowledge because it's going to, it's not, the models aren't truth seeking. They're not going to write you research that's necessarily true. And when you challenge them on things, they'll be like, oh, I'm so sorry.

That's not at all what I thought. So it can supercharge an expert's workflow to really get your ideas out there. But if you're not an expert in the space, it can really lead you astray. Garbage in, garbage out to a degree.

Garbage in, garbage out. Yeah, garbage in, garbage out. I was iterating on something now. And there was a ton of instances where there was an LLM just hallucinating on what you could really do with cloud flow logs, VPC flow logs.

And at some point I had an idea that it would have some really like packet-level revelations in it. And if I wasn't an expert in this space, I would have just assumed, okay, they're telling me I can do X, Y, and Z with these VPC flow logs. And as an expert in the space, I can challenge and say like, this is impossible. This is impossible.

This is impossible because these are the, this is the. These are the fields you have. And this is the kind of inferences you can make based on those fields. But it is not truth-seeking.

It's going to try to make it fit. Yeah. And so if you don't challenge it. Okay.

So let's stay in cloud a little bit. I'm curious your take on this. So if most breaches still start with boring fundamentals for the most part. Why do we keep failing at IAM?

Why is that still such an issue? It seems like. Hard. IAM is really, really hard.

I mean, IAM has this thing where it's actually just about people and people's uses of things and people, process, technology. The people part is the hardest thing. So even though like IAM is another service, just like computer S3, it's actually just like the intersection of people. And technology, which, you know, how people use their credentials, how people authenticate, all of that is about human behavior.

That's just the worst. I mean, I don't know about you, but I'm the worst. So I don't know if it's a technology problem or it's just that within those three pillars, people, process, and technology, it's always the most difficult. I feel like we all think we're not susceptible either to phishing attacks or whatever, like not having strong credentials or some sort of injection that happens that we think that we would catch.

But everyone gets tired. Everyone gets complacent to a degree. We're all people just trying to do our best. And conversely, attackers, threat actors are all people just trying to do their best.

And what are they going to do? They're going to take the easiest low-friction route, which is going to be credentials. Yeah. Is there any overhyped AI security take that you disagree with?

I think it's like the... The article that I published about the San Francisco Consensus is probably the biggest one that I take exception with. Once we do get to the point where the zero-day clock gets to actually zero, that's not actually a catastrophe for the lives of average people. I think that if you're a technologist, in the space, deeply embedded in the space, and you see all of these crazy advancements within LLMs, and you see their capabilities for offensive research, it's very natural to be alarmed.

And then you're, you being alarmed, alarms other people. And then there's this like, there's a ferocity that goes around. And so I think the take is that we are on the precipice of a catastrophe. But if we step outside of that and we say, what actual catastrophe is going to happen?

I don't think that we will see large-scale, system-wide availability, confidentiality problems that will affect the vast majority of humans on Earth. I think it's going to lead to some no good rotten days in the SOC. But that's not the same. Where do we go from here then?

What do we do? What do we do? Where do we go from here? Keep on, keep on, right?

Like one foot in front of the other. I think I take this maybe more middle of the road approach because I do live in middle America and I don't live on one of the coasts. And if you're in that bubble, it can be really easy to drink the Kool-Aid and live in the zeitgeist. But when you, Live elsewhere where the vast majority of people don't work in tech.

The vast majority of people have other concerns within their life. You can kind of see the full breadth and scope of humanity and you can kind of say like, yep, this problem is coming and we should absolutely be working on it. However, it actually won't lead to worldwide system collapses. So what do we do?

Show up for work tomorrow. That's all we can do. That's all you can do. That's all you can do, Brian.

Make sure you get your PTO in. Don't fall into the fallacy that you and your skills are so important that you can't spend your hard-earned time resting and recharging. I think that's a common fallacy in IT and security folks that this is all going to come crumbling down if I step away for a minute, and it won't. So, okay, closing thought.

Are we headed towards more insecure-by-design cloud flaws given that? Maybe. Maybe, Brian. Maybe.

You know, I am always struck when people talk about all of the vulnerabilities that LLMs can find. And I'm always asking people to define what they mean by vulnerability. And it always comes down to like a code-level vulnerability, not necessarily a design flaw. So these insecure-by-design problems, these like “I did not threat model appropriately” ones, I'm not sure if they're going to increase as a result of LLMs, but I do think that they might be some of the last ones left on the table.

The best way to think about insecure-by-design is to think about Apple AirTags. And, you know, when they were released, nobody thought about the threat model of somebody of stalking. And yeah, right. So and it took somebody writing a series of articles about.

Women being stalked by their partners with Apple AirTags before Apple took it seriously to then build in both Android apps and newer capabilities on your phones to then know if you're being followed by an AirTag. So that's kind of the classification of, that's like the best way to describe an insecure by design issue. And often they are the most fun to find because they require some amount of convincing. Like convincing somebody that, no, you just didn't think about this correctly.

So that's why I love looking at those specifically. If we're going to be relying more on LLMs to build our software and have less human oversight, maybe it does mean that we're going to have more of these insecure-by-design flaws. Hopefully not. Hopefully it just means that I still have a job.

Either way, I think they're not going to go anywhere anytime soon. I guess the problems just change over time, right? I mean, the problems don't go away. The shape of it might change.

Yeah, and it's all about expectations. What does your consumer base expect from this product? Maybe 50 years ago, if AirTags came out and they could be used for stalking abused women, maybe 50 years ago, it wouldn't have been considered a vulnerability. But in 2020, it certainly was.

So it's also just about the expectations of your customers. If this was publicized, would there be an outrage? Yeah. Awesome.

Well, where can people find more of your work and find you online? I'm chronically online on Twitter, as NightmareJS. Also on Bluesky and then LinkedIn. Awesome.

I will put links to all of those in the show notes. Thank you so much, Kat, for coming on. Really appreciate it. Thanks for having me.

All right. That was my conversation with Kat Traxler from Vectra AI. My biggest takeaway from this one is that AI security is not one story. It is a speed story.

It is a context story. It is a fundamentals story. And it is very much still a people story. Because, yes.

AI is changing vulnerability research. It can help narrow massive codebases. It can find certain code-level bugs faster than older tooling. It can help researchers move from where do I even start to here are the suspicious paths worth looking at.

That matters. But it does not magically understand the whole system. It does not automatically know the threat model. It does not always understand privilege.

It does not know what your customers expect. It does not know which weird business rule turns a harmless-looking behavior into a real abuse path. That is where humans still matter. And honestly, that might be the more interesting version of this whole AI security conversation.

The model can help find needles, but the human still has to know which needles matter. That came up a few different ways in the conversation. Bug hunting. Writing, prompt injection, IAM, insecure-by-design flaws.

The pattern is pretty consistent. AI can accelerate the work. But if you do not have the judgment to challenge it, constrain it, validate it, and understand where it is guessing, it can absolutely make you faster in the wrong direction. And that is not just true for researchers.

It is true for platform teams, DevOps teams, SRE teams. AppSec teams. Anyone using AI to generate code, review code, write policies, inspect infrastructure, or explain some terrifying IAM graph that nobody wants to look at manually. The other thing that struck me is Kat's point about the boring stuff still being the place teams get hurt.

Credentials still matter. IAM still matters. Misconfiguration still matters. Known vulnerabilities still matter.

Attackers are practical. They are going to take the lowest friction path that works. And a lot of the time, that path is not some cinematic AI-generated zero-day chain. It is a leaked key, an over-permissive role, a reused credential, a server that should have been patched, a service account nobody remembered existed.

That does not mean the AI risk is fake. It means we need to hold both ideas at the same time. AI may compress the time it takes to find and weaponize certain classes of vulnerabilities. That is real, and security teams should care.

But if your IAM is a mess, your secrets are everywhere, your patching is inconsistent, and nobody owns the exposed attack surface, then the scary future problem is not an excuse to ignore the thing already sitting on fire. I also like the discussion around insecure-by-design flaws. Those are not always easy for tools to find because they are not just bad code. They are bad assumptions.

The AirTag example that Kat brought up is a good way to think about it. The issue was not just whether the device functioned as designed. It was whether the design accounted for how real people could abuse it. That is a different class of security work.

It requires context. It requires thinking about users, incentives, misuse. Power dynamics expectations and what happens when a feature gets used by someone with bad intent and if AI removes some of the easier code-level bug hunting work or at least makes it faster i would not be surprised if more of the interesting work shifts towards those deeper design and abuse questions not is this line vulnerable more like what does this system allow someone to do that we did not intend that is harder and probably more important so my takeaway is not panic about AI security it is also not relax everything is fine it is more like keep your head use AI where it helps let it speed up the annoying parts let it help with first drafts first passes code search query generation pattern matching and research flows.

Do not outsource judgment. Do not let the AI output become the security conclusion. And definitely, do not let the excitement around future attacks distract from the fundamentals that are still hurting teams right now. Credentials.

IAM. Patch the known stuff. Understand what your system actually promises. And when the model sounds confident, remember that confident and correct are still not the same thing.

I'll have links to Kat, her work, and anything else we mentioned in the show notes. If you enjoyed this conversation, follow or subscribe to Ship It Weekly wherever you listen to podcasts. It helps the show and it makes sure you get both these conversation episodes and the weekly DevOps, SRE, platform, cloud, and security news recaps. You can also find the show notes and links over at shipitweekly.

fm. Thanks for listening, and I'll see you later this week.