Back to all episodes
Ship It Conversations: Kat Traxler of Vectra AI on AI Security, the Zero-Day Clock, IAM, and Cloud Risk
devopsawsAIcloud engineeringagentic AIAI agentsLLMDevSecOpsAnthropiccybersecurity
In this episode, Kat Traxler from Vectra AI discusses the evolving landscape of AI security, emphasizing the balance between excitement and fear.
Ship It Conversations: Kat Traxler of Vectra AI on AI Security, the Zero-Day Clock, IAM, and Cloud Risk
Ship It Weekly
0:00
42:33
Transcript
0:00
AI security is in a weird place right now. On
0:03
one side, there is real excitement. People are
0:06
building faster. Researchers are moving faster.
0:09
Bug hunters can narrow huge codebases down in
0:13
ways that would have felt impossible a few years
0:16
ago. The blank page is less scary. The first
0:20
draft is easier. The first pass through a massive
0:23
repo is not quite as painful. And honestly, that
0:27
part is cool. But on the other side, security
0:30
teams are looking at the same acceleration and
0:33
asking a much less fun question. What happens
0:37
when attackers get faster too? Because this is
0:40
not just about AI writing code. It is also about
0:44
AI finding bugs, AI helping weaponize vulnerabilities,
0:48
AI making it cheaper to search for weird code
0:51
paths, injection bugs, RCEs. And the kinds of
0:56
flaws that used to take a lot more time and patience
0:59
to find. And somewhere in the middle of that,
1:02
we still have the same boring problems. Credentials,
1:06
IAM, misconfigurations, unpatched systems, source
1:11
code secrets, people getting tired, teams moving
1:15
fast, systems nobody fully threat-modeled because
1:18
the feature had to ship. That is really what
1:22
this conversation is about. Not AI will destroy
1:25
security. Not AI will save security. More like
1:29
what actually changes when AI speeds up both
1:32
the people building software and the people trying
1:35
to break it. I'm Brian Teller from Teller's Tech,
1:38
and this is Ship It Weekly. Welcome back to Ship
1:59
It Weekly, where I filter the noise and focus
2:01
on what actually matters when you are the one
2:04
running infrastructure and owning reliability.
2:06
Most weeks, it's a quick news recap. In between
2:10
those, I do conversation episodes with people
2:12
who are building platforms, running infrastructure,
2:15
finding security issues, and thinking through
2:18
where this industry is actually headed. Today
2:21
is one of those conversations. I'm joined by
2:23
Kat Traxler, a principal security researcher
2:26
at Vectra AI. Kat focuses on abuse techniques
2:30
and vulnerabilities in the public cloud, especially
2:34
around cloud, AppSec, IAM, and those uncomfortable
2:38
places where everybody kind of assumed the layer
2:41
underneath was safe. And I like this conversation
2:45
because it lands in a more honest middle ground
2:48
than a lot of AI security takes. There is definitely
2:52
hype. There is definitely fear. There was also
2:55
a bunch of practical reality sitting underneath
2:58
both of those things. Kat had just come out of
3:01
RSA and the Unprompted conference, so we talk
3:04
about the current AI security mood, the excitement
3:07
from startups, the nervousness from security
3:10
teams, the San Francisco Consensus, the zero
3:14
-day clock, and this growing belief that AI is
3:17
changing how quickly vulnerabilities can be found,
3:20
understood, and potentially weaponized. But we
3:24
also talk about where teams actually get hurt
3:26
first. And the answer is not always the flashiest
3:30
new AI attack. A lot of the time, it is still
3:34
credentials, IAM, misconfiguration, known vulnerabilities,
3:39
unpatched systems, the same boring fundamentals
3:43
that have been ruining everyone's week for years.
3:46
That tension is what makes this conversation
3:49
useful. Because AI is absolutely changing security
3:53
research. Kat talks about using models to narrow
3:57
the search space in bug hunting, why they are
4:00
good at finding certain code-level issues, and
4:03
why they are not as good at understanding context,
4:06
privilege, deployment shape, threat models, or
4:10
whether a flaw really matters in the system where
4:13
it lives. We also get into prompt injection,
4:16
AI-assisted writing, using different models
4:19
for different research tasks, and why being an
4:22
expert still matters if you do not want the model
4:26
to confidently lead you off a cliff. There is
4:29
a really good thread in here around IAM too.
4:32
Why do teams keep failing at it? Kat's answer
4:36
is pretty simple and pretty true. IAM is where
4:39
people and technology collide. Credentials, authentication,
4:44
access, human behavior, shortcuts. Fatigue and
4:48
attackers taking the lowest friction path it
4:52
is not just a cloud service problem it is a people
4:55
problem with an API. And toward the end we talk
4:59
about overhyped AI security narratives what actually
5:02
happens if the zero-day clock keeps shrinking
5:05
whether we are headed towards more insecure by
5:08
design flaws and why some of the hardest problems
5:12
left maybe less about bad lines of code and more
5:16
about bad assumptions. So if you work around
5:19
cloud, DevOps, SRE, AppSec, IAM, security operations,
5:25
platform engineering, or you are trying to separate
5:28
useful AI security thinking from panic and vendor
5:31
fog machines, this one should be worth your time.
5:35
All right, let's jump in. Today, I'm joined by
5:44
Kat Traxler. She is a principal security researcher
5:47
at Vectra AI focused on abuse techniques and
5:50
vulnerabilities in the public cloud, especially
5:53
at the intersection of cloud, AppSec, IAM, and
5:57
“we thought this layer was safe”. Kat, thank you
6:00
for joining me. Thanks for having me, Brian.
6:01
I'm excited to talk about the new accelerated
6:04
world we find ourselves in. It is. It's definitely
6:08
a new accelerated world for sure. Tell me a little
6:11
bit about what have you seen lately in the last
6:14
couple of weeks or months as far as AI or security
6:18
in general? I'm coming off the heels of RSA.
6:21
So I spent a four-day pilgrimage out to the
6:26
bay. The vibe was definitely rational exuberance.
6:30
Exuberance? Yeah. That's not quite a word.
6:33
But you know what I mean. Everybody was incredibly
6:35
optimistic. A lot of two-pizza teams. Somebody breaks
6:39
off from a big company with... A set of like
6:42
AI LLM skill sets and are like racing to the
6:46
future. So in the startup space, people are jazzed.
6:51
I haven't seen this level of excitement in a
6:53
while. You contrast that with middle America,
6:56
where I live and folks are much less enthusiastic
7:01
about AI and its role in our life. Then you
7:05
contrast that with, you know, the security sec
7:08
op folks. And people are very, very nervous about
7:12
what's to come. So you just have so many different
7:15
experiences depending on where you are at in
7:20
this world. That's fair. I think I hold all of
7:23
those in my head as well. I mean, just as a person,
7:26
right? Like, I mean, there's excitement. We talked
7:30
a little bit before we started. Like, you're
7:33
able to iterate more. You have all these projects
7:34
that you wanted to start that you couldn't start.
7:37
Now you are. But then there's also the security
7:40
side where you see the RCEs and attack vectors
7:44
that are more prevalent than they were maybe
7:46
a year, two years ago. So, yeah, it's a different
7:50
world for sure. The security reporters are busy,
7:53
right? It seems like there's a new massive major
7:58
story that they're covering weekly. A new, you
8:02
know, critical zero-day, a new supply chain attack.
8:07
The frontier model companies, Anthropic and OpenAI,
8:11
have showed us that these models are really,
8:14
really good at finding these specific kinds of
8:17
vulnerabilities. Not all vulnerabilities, but
8:19
these specific kinds of code-level vulnerabilities.
8:22
They can find them like no other tooling has
8:25
found before. So we're just having an onslaught
8:29
of these vulnerability announcements now, and
8:32
it can be really overwhelming. That's fair. So
8:35
recently you wrote about, you had a right, you
8:39
had an article, the San Francisco Consensus.
8:44
Can you explain that in your words? Sure. That
8:48
was coming off the heels of another pilgrimage
8:51
to San Francisco, going to the Unprompted conference,
8:56
which I was one of the organizers. I was one
8:58
part of the CFP process and had a blast communing
9:02
with all of the fantastic AI researchers, but
9:06
there was definitely a consensus amongst folks
9:10
that coalesced and peaked with Nicholas Carlini's,
9:14
I almost called it speech, but talk. He's with
9:19
Anthropic's Frontier Red Team. If you haven't
9:21
seen that talk, please go see it. He really lays
9:25
bare the issue of the zero-day clock, which
9:29
is the idea, not the idea, I mean, the proven
9:32
phenomenon that The time between a zero-day
9:36
being announced and it being exploded in the
9:38
wild had gone from two years. A couple of years
9:43
ago, it was like two years it would take. You'd
9:46
have this announcement, and then it would take
9:50
attackers literally two years to weaponize it. Now it is just hours.
9:53
You have the announcement, they can weaponize it.
9:58
Nicholas Carlini's talk at unprompted late is
10:01
over there. And I'm telling my dog to not bark
10:03
at everybody. Can you hear that? I'm sorry. Of
10:07
course, right in the middle of what I'm talking
10:08
to people. This captures the zeitgeist and the,
10:11
you know, kind of pure, the pure terror slash
10:15
pure excitement in everybody's eyes that LLM
10:18
can find code-level vulnerabilities like no tooling
10:23
has found. Attackers are weaponizing it in minutes.
10:29
Therefore, and people don't really explain what
10:33
the “and then therefore” is, but the and then
10:36
therefore is kind of assumed that and then therefore
10:41
systems will crumble, our global technology infrastructure
10:46
will no longer work. We will have a complete
10:49
collapse of critical infrastructure. We will
10:52
go to the Stone Age, move to the woods. So I'm
10:55
kind of catastrophizing a little bit, but that's
10:58
the natural conclusion of the zero-day clock.
11:02
And that's the consensus, is that we are months
11:07
away from this scenario occurring. So is it kind
11:13
of a take on the doomsday clock, where we're
11:16
counting down to... Yeah, yeah, yeah. Although
11:19
I think the doomsday clock is sort of like...
11:22
arbitrarily set by some people. Yeah, this is,
11:26
I think this is backed by some real data. And
11:30
I've read a report from RAPId7 recently that
11:33
was really good that has a lot of backing data.
11:35
They never say zero-day apocalypse, but they
11:38
have this like 26-page report that backs up
11:41
all of the observed data points in the
11:45
wild that just kind of come down to. In 2018,
11:49
it was two years to exploitation. Now it's minutes.
11:52
And the big question is, and then what? And I
11:56
think we should, as a community, spend a little
11:59
bit more time filling out the “and then what”, as
12:02
opposed to just kind of letting our minds go wild.
12:04
And everybody has a different idea of what and
12:07
then what means. So if you had to rank where
12:11
teams actually get hurt first, what's at the
12:14
top? Like, where should we start? Yeah. I mean,
12:18
historically, it's been credentials. Historically,
12:23
it's been mishandling of credentials, reusing
12:26
of credentials. It's been committing them to
12:29
source code, having them be static, not having
12:33
efficient rotation in them, and then misconfigurations.
12:37
In the new RAPId7 report, I believe that they
12:41
had said moving to the top of initial access was...
12:45
just a small suite of known code-level vulnerabilities.
12:49
So I'll use Log4j, but just those kind of like
12:52
reused over and over and over CVE exploits that
12:56
are known and patchable and are just tried over
12:59
and over and over again. So by the numbers, those
13:02
are still the things that are biting people when
13:05
it comes to initial access. Going forward, the
13:10
zero-day clock and the San Francisco Consensus
13:12
says They don't necessarily say that those things
13:21
aren't going to matter. What they say is that
13:24
there's a whole new attack surface that's going
13:27
to be open and that's all the zero-days that
13:31
nobody knows about. All of the code-level vulnerabilities
13:35
within your exposed on-prem stack or any other
13:40
piece of infrastructure that hasn't been exploited
13:43
anywhere that because finding a zero-day is now
13:48
just costs and tokens that's what you have to
13:52
now protect for and i'm just saying like that's
13:54
that's the san francisco consensus is like that
13:57
that attackers will shift to that exploitation
13:59
I doubt it because i think
14:06
all the other mechanisms just work so well that
14:09
I do not think that that will be, at least
14:14
in the foreseeable future, the exploitation route
14:18
that attackers will leverage, at least initially.
14:22
It might be a concern for some of the large institutions,
14:27
Google, IBM, nation-states, but for your average
14:32
mid-size technology companies, it's still potential
14:36
reuse on patched servers. That kind of stuff.
14:41
So what's your take on prompt injection as an
14:45
ops problem? An operations problem? Yeah, over
14:49
just like an app problem specifically. Tell me
14:53
more. What are you thinking more about that?
14:56
Like the different layers it interacts with or
14:59
like how it affects the infrastructure? Yeah.
15:03
Where that may be. Or if you see it as an issue
15:09
going forward, more so in the future, operationally.
15:14
Yeah, I'm not exactly sure how to answer that.
15:17
I mean, there are frameworks now to protect against
15:22
a significant amount of prompt injection. They're
15:25
notoriously difficult to implement and operationalize.
15:31
Ultimately, there are bypasses. So, I mean, it's
15:34
always some level of a WAF. So it's always
15:38
going to be some whack-a-mole that you're playing
15:41
with the prompt injection defenses. But I don't
15:46
see that folks are really even using the most
15:49
basic level of prompt injection mitigations out
15:54
there that are available to them. Here in 2026,
15:58
there are... A significant amount of prompt injection
16:02
frameworks that could help. Again, you know,
16:06
it might come out to be 96 % effective, 97 %
16:09
effective, 98 % effective. There's always still
16:11
going to be a bypass. Yeah. Does that answer
16:14
your question? Yeah, it does. That's good. I
16:17
probably didn't ask it well. I don't know if
16:21
you wrote about this or I heard you talk about
16:23
this. We're talking about AI helping narrowed
16:27
the search space in bug hunting oh yeah how are
16:32
you using that in practice well i can't tell
16:34
you I am using it to narrow my search space uh
16:38
no i mean okay so for example, for code-level
16:43
vulnerabilities you have these like huge massive
16:48
gnarly codebases that you know, to some level
16:54
or another, you're like just grepping your way
16:57
through looking for bad patterns. And then maybe
17:00
you're using, this is the old way, maybe you're
17:03
using a static code analysis tool to kind of
17:07
help you with some of that work. But ultimately,
17:09
you're just grepping your way through a problem.
17:13
But the LLMs love this sort of problem, this
17:16
sort of like injection issue, which... A large
17:20
portion of the OWASP Top 10 just comes down to
17:23
like injection issues. And they love this sort
17:26
of problem of taking this massive interwoven
17:29
complex blob and being injected with the concept
17:35
of like, you know, bad input in results in bad
17:40
input out. And where are the potential mitigations?
17:44
How can they potentially be mitigated along the
17:46
way, doing all the heavy lifting for you and
17:50
being able to get down from 500 lines of code
17:55
to maybe 100 that it's going to flag for you
17:58
as potentially bad. I found that it's amazing
18:03
for these known problems. These issues that you
18:08
can come down to, this is this bad line of code,
18:11
and you can then insert this particular type
18:14
of sanitization or parameterization and fix
18:18
it. It's something that it's really great at.
18:22
It's not so great at understanding context or
18:25
the threat model around where it's deployed,
18:28
who the users are, what data those users might
18:33
be accessing, under what conditions, those subtleties
18:37
that are going to change. That's a whole different
18:38
problem set that they're not good at yet, and
18:41
which makes me realize that I still have a job.
18:45
But those code-level things that are like needles
18:48
in a haystack, they're good at finding needles.
18:52
They're not good at finding, I would say that
18:54
they're not good at finding all of the needles.
18:57
If you want to find a needle, you'll find one,
18:59
but you won't find all of them, if that makes
19:01
sense. Is it primarily certain languages or certain
19:06
query formats? Like, are we talking like SQL
19:09
injection? Are we talking like app function calls?
19:13
Or specifically Python, maybe, because the LLM
19:16
has that training data? You know, I really don't
19:20
know what it comes down to. I've done a huge
19:23
project on just trying to find remote code execution.
19:28
And then ensuring that it's tracing back to some
19:35
sort of untrusted input from a user. So being
19:39
very clear about where... What inputs it is allowing,
19:43
you know, from where. SQL injection is great
19:47
at finding. XSS is great at finding. Not as great
19:51
as finding things like confused deputy, which
19:53
are, again, contextual. Like, what's privilege?
19:58
That's always, like, a squishy thing. You have
20:01
to be really explicit with it. I mean, the people
20:06
who are doing bug hunting. On the client side
20:10
client-side issues it's great finding
20:13
IDOR um like it's really great at these very
20:16
specific not things that don't require a ton
20:21
of context issues and going from this massive
20:25
code base to these handful of things and then
20:28
proving exploitability yeah i i really couldn't
20:32
tell you why it's good at that why that puzzle
20:35
it it turns on really well as opposed to it doesn't
20:40
understand the nuance of privilege. Are you using
20:45
public models or are you training like your own
20:48
data? No, I'm using a lot of different public
20:50
models, but I switch between a ton of different
20:54
ones. Obviously the Claudes, I'm switching between
20:58
the various versions of Gemini. I'm switching
21:01
between also some local models like Gemma. So I
21:05
try to be efficient with my token usage.
21:08
Folks that are wanting to get into bug hunting,
21:12
I think there's a lot of advice that just says
21:15
like run it all on Claude Opus 4.6 and just go
21:19
to town. I'm much more, I'm just much more delicate
21:25
around, which model I use when. Because I think
21:30
that they can do... They play well off each other.
21:36
You can use one to catch the bugs of another
21:40
or to help catch the faulty process of another.
21:48
One might have a glaring gap that you just aren't
21:51
aware of that another one can catch. Yeah, I
21:54
know. ChatGPT is really good at spatial awareness,
21:57
whereas Claude's very good at generally coding
22:00
-type challenges and problems. Is there a specific
22:04
model that maybe works better for prompt injection
22:10
-type research, or is it more nuanced than that?
22:15
I mean, all of the bug bounty people will just
22:18
say, turn Claude on to your target and go to
22:22
town. I don't think you're going to go wrong
22:24
with that. It just depends on how efficient you
22:29
want to be with your token usage. I think it's
22:33
overkill to use Claude on the vast majority of
22:36
tasks. Now, if that's your profession, if you
22:41
are a full-time bug bounty hunter, you're going
22:43
to scale up to as many Claude Max subscriptions
22:46
as your budget will allow and just set them off.
22:52
Me, not so much. I'm going to be a little bit
22:55
more delicate with what I use when. And I think
22:59
that's kind of fun because you get to learn all
23:01
of their intricacies. And I don't know if you
23:06
heard, but just today there was the revelation
23:10
from Anthropic on Project Mythos, or sorry, Mythos,
23:16
their next iteration of models and Project Glasswing.
23:20
which is their private preview of Mythos to about
23:23
40 different companies. Particular researchers
23:28
within AWS, Azure, Google, IBM, Cisco, Palo Alto,
23:34
CrowdStrike, kind of like all the big ones, have
23:36
private access to this incredibly powerful model,
23:41
more powerful than the current iterations. And
23:47
they're not planning on releasing it to the public.
23:49
They are wanting it to only be in the hands of
23:52
hand-picked organizations to allow them to shore
23:59
up their infrastructure for potential onslaughts.
24:04
I wonder how the U.S. Government will react
24:06
to that. They weren't on the list. I want to
24:11
see that list of MAGIC 41, you know, Cisco, IBM,
24:15
Red Hat, Kat Traxler. That is what i'm looking for
24:19
that'd be a cool list to be on for sure yeah
24:22
that would be a great list yeah what parts are
24:25
AI good at versus what do you still need a human
24:28
for like is there any part where you think that
24:31
like AI is not quite there yet i mean we talked
24:33
a little bit about context and not having like
24:35
contextual awareness around like large monorepos
24:38
or large monolithic apps but are there other areas
24:42
maybe where i mean for example For example, writing.
24:46
I do a ton of writing. And I have had LLMs just generate
24:53
an article for me and it's crap. It sounds like
24:56
garbage. I can't handle it. But I can go through
25:02
and put together a decent rough draft. Write
25:07
it as if I'm just writing for myself very casually.
25:10
I do not concern myself too much with... Spelling
25:14
mistakes and word order if I mess up here and
25:17
there. But make sure I have like the needs of
25:19
my argument. Sometimes I'll even do it in bullet
25:21
points and then send it to my LLM of choice.
25:26
Have it with some very direct instructions on
25:30
like the tone and how much to shift away from
25:33
my tone. Have it be very constrained and then
25:37
iterate on that from there. So I think it has
25:39
a great place in writing. We just, I just personally,
25:44
use it somewhat sparingly. So just getting your
25:51
voice out there I think is great. It's such a
25:54
barrier to entry for some people to blog, to
25:58
put articles out there. They see that blank page
26:01
and they don't really know what to do. If they
26:03
could say, you know what, just write a table
26:06
of contents, a list of bullet points, sentence
26:08
fragments, paragraphs here and there, and then
26:11
start. I think that can maybe unlock a lot of
26:15
knowledge that people have and they can publish
26:17
their ideas. But if you don't give it enough
26:21
meat, it's really going to come out pretty poorly.
26:27
So that's with writing. And then, you know, obviously
26:32
you need that expert level knowledge because
26:34
it's going to, it's not, the models aren't truth
26:39
seeking. They're not going to write you research
26:44
that's necessarily true. And when you challenge
26:49
them on things, they'll be like, oh, I'm so sorry.
26:52
That's not at all what I thought. So it can supercharge
26:57
an expert's workflow to really get your ideas
27:00
out there. But if you're not an expert in the
27:03
space, it can really lead you astray. Garbage
27:07
in, garbage out to a degree. Garbage in, garbage
27:10
out. Yeah, garbage in, garbage out. I was iterating
27:14
on something now. And there was a ton of instances
27:22
where there was an LLM just hallucinating on
27:26
what you could really do with cloud flow logs,
27:31
VPC flow logs. And at some point I had an idea
27:36
that it would have some really like packet-level
27:40
revelations in it. And if I wasn't an expert
27:45
in this space, I would have just assumed, okay,
27:49
they're telling me I can do X, Y, and Z with
27:50
these VPC flow logs. And as an expert in the
27:54
space, I can challenge and say like, this is
27:57
impossible. This is impossible. This is impossible
27:59
because these are the, this is the. These are
28:02
the fields you have. And this is the kind of
28:05
inferences you can make based on those fields.
28:07
But it is not truth-seeking. It's going to try
28:09
to make it fit. Yeah. And so if you don't challenge
28:13
it. Okay. So let's stay in cloud a little bit.
28:19
I'm curious your take on this. So if most breaches
28:22
still start with boring fundamentals for the
28:26
most part. Why do we keep failing at IAM? Why
28:29
is that still such an issue? It seems like. Hard.
28:32
IAM is really, really hard. I mean, IAM has this
28:37
thing where it's actually just about people and
28:41
people's uses of things and people, process, technology.
28:45
The people part is the hardest thing. So even
28:48
though like IAM is another service, just like
28:52
computer S3, it's actually just like the intersection
28:55
of people. And technology, which, you know, how
29:01
people use their credentials, how people authenticate,
29:06
all of that is about human behavior. That's just
29:10
the worst. I mean, I don't know about you, but
29:14
I'm the worst. So I don't know if it's a technology
29:19
problem or it's just that within those three
29:21
pillars, people, process, and technology, it's
29:23
always the most difficult. I feel like we all
29:27
think we're not susceptible either to phishing
29:30
attacks or whatever, like not having strong credentials
29:37
or some sort of injection that happens that we
29:42
think that we would catch. But everyone gets
29:46
tired. Everyone gets complacent to a degree.
29:49
We're all people just trying to do our best.
29:54
And conversely, attackers, threat actors are all
29:57
people just trying to do their best. And what
30:01
are they going to do? They're going to take the
30:03
easiest low-friction route, which is going
30:05
to be credentials. Yeah. Is there any overhyped
30:11
AI security take that you disagree with? I think
30:15
it's like the... The article that I published
30:19
about the San Francisco Consensus is probably
30:22
the biggest one that I take exception with. Once
30:28
we do get to the point where the zero-day clock
30:35
gets to actually zero, that's not actually a
30:38
catastrophe for the lives of average people.
30:44
I think that if you're a technologist, in the
30:47
space, deeply embedded in the space, and you
30:50
see all of these crazy advancements within LLMs,
30:53
and you see their capabilities for offensive
30:55
research, it's very natural to be alarmed. And
31:01
then you're, you being alarmed, alarms other
31:05
people. And then there's this like, there's a
31:08
ferocity that goes around. And so I think the
31:11
take is that we are on the precipice of a catastrophe.
31:17
But if we step outside of that and we say, what
31:22
actual catastrophe is going to happen? I don't
31:27
think that we will see large-scale, system-wide
31:33
availability, confidentiality problems that will
31:38
affect the vast majority of humans on Earth.
31:43
I think it's going to lead to some no good rotten
31:45
days in the SOC. But that's not the same. Where
31:49
do we go from here then? What do we do? What
31:51
do we do? Where do we go from here? Keep on,
31:53
keep on, right? Like one foot in front of the
31:56
other. I think I take this maybe more middle
31:58
of the road approach because I do live in middle
32:00
America and I don't live on one of the coasts.
32:04
And if you're in that bubble, it can be really
32:06
easy to drink the Kool-Aid and live in the zeitgeist.
32:11
But when you, Live elsewhere where the vast majority
32:14
of people don't work in tech. The vast majority
32:17
of people have other concerns within their life.
32:19
You can kind of see the full breadth and scope
32:22
of humanity and you can kind of say like, yep,
32:24
this problem is coming and we should absolutely
32:27
be working on it. However, it actually won't
32:30
lead to worldwide system collapses. So what do
32:34
we do? Show up for work tomorrow. That's all
32:37
we can do. That's all you can do. That's all
32:39
you can do, Brian. Make sure you get your PTO
32:43
in. Don't fall into the fallacy that you and
32:49
your skills are so important that you can't spend
32:52
your hard-earned time resting and recharging.
32:57
I think that's a common fallacy in IT and security
33:02
folks that this is all going to come crumbling
33:04
down if I step away for a minute, and it won't.
33:07
So, okay, closing thought. Are we headed towards
33:12
more insecure-by-design cloud flaws given that?
33:17
Maybe. Maybe, Brian. Maybe. You know, I am always
33:28
struck when people talk about all of the vulnerabilities
33:33
that LLMs can find. And I'm always asking people
33:37
to define what they mean by vulnerability.
33:43
And it always comes down to like a code-level
33:47
vulnerability, not necessarily a design flaw.
33:51
So these insecure-by-design problems, these like
33:57
“I did not threat model appropriately” ones, I'm not
34:00
sure if they're going to increase as a result
34:04
of LLMs, but I do think that they might be some
34:08
of the last ones left on the table. The best
34:13
way to think about insecure-by-design is to think
34:16
about Apple AirTags. And, you know, when they
34:20
were released, nobody thought about the threat
34:22
model of somebody of stalking. And yeah, right.
34:29
So and it took somebody writing a series of articles
34:34
about. Women being stalked by their partners
34:36
with Apple AirTags before Apple took it seriously
34:39
to then build in both Android apps and newer capabilities
34:45
on your phones to then know if you're being followed
34:47
by an AirTag. So that's kind of the classification
34:49
of, that's like the best way to describe an insecure
34:53
by design issue. And often they are the most
34:58
fun to find because they require some amount
35:02
of convincing. Like convincing somebody that,
35:06
no, you just didn't think about this correctly.
35:09
So that's why I love looking at those specifically.
35:13
If we're going to be relying more on LLMs to
35:15
build our software and have less human oversight,
35:20
maybe it does mean that we're going to have more
35:22
of these insecure-by-design flaws. Hopefully
35:26
not. Hopefully it just means that I still have
35:28
a job. Either way, I think they're not going
35:32
to go anywhere anytime soon. I guess the problems
35:36
just change over time, right? I mean, the problems
35:38
don't go away. The shape of it might change.
35:43
Yeah, and it's all about expectations. What does
35:46
your consumer base expect from this product?
35:51
Maybe 50 years ago, if AirTags came out and they
35:54
could be used for stalking abused women, maybe
35:57
50 years ago, it wouldn't have been considered
35:59
a vulnerability. But in 2020, it certainly was.
36:03
So it's also just about the expectations of your
36:07
customers. If this was publicized, would there
36:11
be an outrage? Yeah. Awesome. Well, where can
36:15
people find more of your work and find you online?
36:19
I'm chronically online on Twitter, as NightmareJS.
36:27
Also on Bluesky and then LinkedIn. Awesome.
36:31
I will put links to all of those in the show
36:34
notes. Thank you so much, Kat, for coming on.
36:37
Really appreciate it. Thanks for having me. All
36:39
right. That was my conversation with Kat Traxler
36:42
from Vectra AI. My biggest takeaway from this
36:45
one is that AI security is not one story. It
36:49
is a speed story. It is a context story. It is
36:53
a fundamentals story. And it is very much still
36:56
a people story. Because, yes. AI is changing
37:00
vulnerability research. It can help narrow massive
37:03
codebases. It can find certain code-level bugs
37:06
faster than older tooling. It can help researchers
37:09
move from where do I even start to here are the
37:13
suspicious paths worth looking at. That matters.
37:17
But it does not magically understand the whole
37:20
system. It does not automatically know the threat
37:24
model. It does not always understand privilege.
37:27
It does not know what your customers expect.
37:30
It does not know which weird business rule turns
37:33
a harmless-looking behavior into a real abuse
37:36
path. That is where humans still matter. And
37:40
honestly, that might be the more interesting
37:42
version of this whole AI security conversation.
37:45
The model can help find needles, but the human
37:49
still has to know which needles matter. That
37:52
came up a few different ways in the conversation.
37:55
Bug hunting. Writing, prompt injection, IAM,
37:59
insecure-by-design flaws. The pattern is pretty
38:03
consistent. AI can accelerate the work. But if
38:06
you do not have the judgment to challenge it,
38:08
constrain it, validate it, and understand where
38:12
it is guessing, it can absolutely make you faster
38:15
in the wrong direction. And that is not just
38:18
true for researchers. It is true for platform
38:21
teams, DevOps teams, SRE teams. AppSec teams.
38:26
Anyone using AI to generate code, review code,
38:30
write policies, inspect infrastructure, or explain
38:34
some terrifying IAM graph that nobody wants to
38:38
look at manually. The other thing that struck
38:40
me is Kat's point about the boring stuff still
38:43
being the place teams get hurt. Credentials still
38:47
matter. IAM still matters. Misconfiguration still
38:51
matters. Known vulnerabilities still matter.
38:54
Attackers are practical. They are going to take
38:57
the lowest friction path that works. And a lot
39:00
of the time, that path is not some cinematic
39:03
AI-generated zero-day chain. It is a leaked
39:07
key, an over-permissive role, a reused credential,
39:11
a server that should have been patched, a service
39:14
account nobody remembered existed. That does
39:17
not mean the AI risk is fake. It means we need
39:21
to hold both ideas at the same time. AI may compress
39:25
the time it takes to find and weaponize certain
39:28
classes of vulnerabilities. That is real, and
39:32
security teams should care. But if your IAM is
39:35
a mess, your secrets are everywhere, your patching
39:38
is inconsistent, and nobody owns the exposed
39:41
attack surface, then the scary future problem
39:45
is not an excuse to ignore the thing already
39:48
sitting on fire. I also like the discussion around
39:51
insecure-by-design flaws. Those are not always
39:54
easy for tools to find because they are not just
39:58
bad code. They are bad assumptions. The AirTag
40:02
example that Kat brought up is a good way to
40:04
think about it. The issue was not just whether
40:06
the device functioned as designed. It was whether
40:10
the design accounted for how real people could
40:13
abuse it. That is a different class of security
40:15
work. It requires context. It requires thinking
40:19
about users, incentives, misuse. Power dynamics
40:24
expectations and what happens when a feature
40:28
gets used by someone with bad intent and if AI
40:32
removes some of the easier code-level bug hunting
40:34
work or at least makes it faster i would not
40:38
be surprised if more of the interesting work
40:41
shifts towards those deeper design and abuse
40:44
questions not is this line vulnerable more like
40:48
what does this system allow someone to do that
40:52
we did not intend that is harder and probably
40:56
more important so my takeaway is not panic about
40:59
AI security it is also not relax everything is
41:03
fine it is more like keep your head use AI where
41:07
it helps let it speed up the annoying parts let
41:10
it help with first drafts first passes code search
41:14
query generation pattern matching and research
41:18
flows. Do not outsource judgment. Do not let
41:21
the AI output become the security conclusion.
41:25
And definitely, do not let the excitement around
41:28
future attacks distract from the fundamentals
41:31
that are still hurting teams right now. Credentials.
41:35
IAM. Patch the known stuff. Understand what your
41:39
system actually promises. And when the model
41:42
sounds confident, remember that confident and
41:45
correct are still not the same thing. I'll have
41:49
links to Kat, her work, and anything else we
41:52
mentioned in the show notes. If you enjoyed this
41:54
conversation, follow or subscribe to Ship It
41:57
Weekly wherever you listen to podcasts. It helps
42:00
the show and it makes sure you get both these
42:02
conversation episodes and the weekly DevOps,
42:05
SRE, platform, cloud, and security news recaps.
42:09
You can also find the show notes and links over
42:12
at shipitweekly.fm. Thanks for listening, and
42:15
I'll see you later this week.
Ship It Conversations: Kat Traxler of Vectra AI…
0:00 / 42:33
🎧 Listen & Subscribe
Catch This Episode
Listen on your favorite podcast platform
💬 Commentary
Host Commentary
📝 Notes
Show Notes
This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.
In this Ship It: Conversations episode, I talk with Kat Traxler of Vectra AI about AI security, the zero-day clock, IAM, cloud risk, AI-assisted bug hunting, and why the scariest future security problems may still start with the boring fundamentals teams already struggle with today.
Kat is a Principal Security Researcher at Vectra AI focused on abuse techniques and vulnerabilities in the public cloud, especially around the intersection of cloud security, AppSec, IAM, managed identities, and insecure-by-design flaws.
We talk about the current AI security mood, from the excitement around faster research and bug hunting to the fear that AI could shrink the window between vulnerability disclosure and exploitation. Kat explains the “San Francisco Consensus,” why the zero-day clock is getting so much attention, and why she thinks the facts may be real while some of the conclusions are overextended.
The bigger theme here is that AI is absolutely changing security work, but it does not erase the fundamentals. Attackers still take the lowest-friction path that works. For most teams, that still means credentials, IAM, misconfigurations, known vulnerabilities, and systems that were never threat-modeled as deeply as people assume.
Highlights
• Why AI security feels exciting and unsettling at the same time
• What the “San Francisco Consensus” means and why people are talking about the zero-day clock
• How AI may shrink the time between vulnerability disclosure and exploitation
• Why Kat is skeptical of the full “zero-day apocalypse” narrative
• Why credentials, IAM, misconfigurations, and known vulnerabilities still matter most for many teams
• How AI helps narrow the search space in bug hunting and security research
• Where AI is useful for code-level bugs, and where it still struggles with context and threat modeling
• Why human expertise still matters when using AI for writing, research, and cloud security analysis
• Why IAM remains hard because it sits at the intersection of people, access, and technology
• What insecure-by-design flaws are, and why AI may not solve those anytime soon
Kat / Vectra AI links
• Kat Traxler at Vectra AI: https://www.vectra.ai/about/author/kat-traxler
• Kat’s site: https://kattraxler.cloud/
• The San Francisco Consensus: https://kattraxler.cloud/the-san-francisco-consensus/
• Kat on X: https://x.com/NightmareJS
• Vectra AI: https://www.vectra.ai/
Our links
More episodes + show notes + links: https://shipitweekly.fm
On Call Brief: https://oncallbrief.com
📍 Made in Greencastle, Pennsylvania
More from Ship It Weekly
All episodes →
PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking
This episode of Ship It Weekly discusses the risks of default trust in software systems. Brian covers Oracle's PeopleSoft zero-day, npm v12's install-script changes, GitHub's shift away from personal access tokens, and Anthropic's AI model removals.
CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk
This episode of Ship It Weekly discusses the implications of the CISA GitHub leak, highlighting the exposure of AWS keys and internal documentation.
AI Agents Get API Access and Identity: GitHub Copilot Cloud Agents, MCP Auth, Ansible Automation, OpenAI Daybreak, and the New Production Risk
This episode explores the shift of AI agents from coding assistants to operational actors. Topics include GitHub's REST API for Copilot cloud tasks, Auth0's MCP authentication, and Ansible as an execution layer.
Cursor Deletes PocketOS Prod DB, .de DNSSEC Outage, Bluesky Postmortem, Argo CD, and Copy Fail
This episode of Ship It Weekly discusses modern reliability challenges, including the PocketOS database wipe and the .de DNSSEC outage.
For this Conversations episode, the part that stuck with me is that AI security is not really one conversation.
It is a speed conversation.
It is a context conversation.
It is a fundamentals conversation.
And honestly, it is still very much a people conversation.
That is what I liked about talking with Kat Traxler from Vectra AI. She is not dismissing the AI security concern. There are real changes happening. Models are getting better at finding certain classes of bugs. Researchers can move faster. Bug hunters can narrow huge codebases down more quickly. Attackers can also use the same kind of tooling to move faster.
That part matters.
But the part that gets lost in a lot of the panic is that speed is not the same thing as understanding.
AI can help find suspicious code paths. It can help with injection bugs. It can help with RCE patterns. It can help generate queries, first drafts, summaries, and research direction. It can make the first pass through a messy problem less painful.
But it does not automatically know the threat model.
It does not always understand privilege.
It does not know what your users expect.
It does not know what your business logic means.
It does not know whether something is actually exploitable in your environment, with your data, your permissions, your deployment shape, and your weird internal assumptions.
That is where human judgment still matters.
And that is probably the most important theme of this episode.
The model can help find needles, but the human still has to know which needles matter.
That came up a few different ways. Bug hunting, writing, cloud analysis, IAM, prompt injection, insecure-by-design flaws. The pattern is pretty consistent. AI can accelerate parts of the work, but if you do not have the expertise to challenge it, constrain it, and validate it, it can make you faster in the wrong direction.
Kat’s example with VPC flow logs is a good one. If a model tells you that you can infer packet-level details from data that does not actually contain those fields, that answer might sound useful if you do not know better. But if you do know the system, you can push back and say, no, that is not possible. Here are the fields we actually have. Here is what can and cannot be inferred.
That is the difference between AI as leverage and AI as a confidence machine.
And that matters a lot in security.
Because security does not reward confident guesses.
The other thing that stood out to me is Kat’s pushback on the full zero-day apocalypse narrative.
There is a real issue underneath it. The time between vulnerability disclosure and exploitation has been shrinking. AI may compress that even further for certain classes of vulnerabilities. That is not fake. Security teams should pay attention to that.
But the jump from “attackers may weaponize faster” to “global technology collapses in a few months” is a much bigger leap.
And Kat’s point was basically, let’s spend more time on the “and then what?”
If the zero-day clock keeps shrinking, what actually happens?
Which teams are most exposed?
Which systems are most at risk?
Which attackers change behavior?
Which organizations need to respond differently?
And which problems are still the same boring problems they were yesterday?
Because that is the part that I think a lot of DevOps, SRE, platform, and security teams need to hear.
The scary future does not erase the current fundamentals.
Credentials still matter.
IAM still matters.
Misconfigurations still matter.
Known vulnerabilities still matter.
Patch management still matters.
Source code secrets still matter.
Human fatigue still matters.
Attackers are practical. They are going to take the lowest-friction path that works. A lot of the time, that path is not a cinematic AI-generated zero-day chain. It is a leaked key. A reused credential. An over-permissive role. A service account nobody remembered. A server that should have been patched six months ago.
That does not mean AI risk is overblown.
It means we need to hold both ideas at the same time.
AI may make certain security problems move faster.
But if your IAM is already a mess, your secrets are everywhere, your patching is inconsistent, and nobody owns the exposed attack surface, the future AI threat is not an excuse to ignore the thing already sitting on fire.
The IAM part of the conversation felt especially true.
IAM is hard because it looks like a technical service, but it is really where people, process, and technology collide.
It is credentials. It is authentication. It is access. It is human behavior. It is shortcuts. It is tired people. It is teams under pressure. It is old roles. It is permissions nobody wants to remove because something might break. It is attackers knowing that credential abuse is often the easiest way in.
That is why IAM stays painful.
Not because nobody understands least privilege as a concept.
Everyone understands the concept.
The hard part is making it work in a real organization where people are trying to ship software, troubleshoot production, rotate keys, grant access, clean up old permissions, and not break the thing that pays the bills.
So when Kat says IAM is really about people, I think that is right.
The insecure-by-design discussion was another useful thread.
A lot of AI security focus is on code-level vulnerabilities. Can the model find injection bugs? Can it find RCE? Can it find XSS? Can it narrow the search space?
That work matters.
But insecure-by-design flaws are different.
Those are not always bad lines of code. They are bad assumptions.
The AirTag example is a good way to think about it. The device may function as designed, but the design missed a real-world abuse case. The issue is not just technical correctness. It is whether the product accounts for how people can misuse it, who can be harmed, what customers expect, and what happens when the system is used in a way the builders did not intend.
That is a different class of security work.
And I suspect it is going to stay valuable, even as AI gets better at finding some code-level bugs.
Maybe especially then.
If AI makes some of the easier code-level searching faster, more of the important work may shift toward context, abuse paths, design flaws, threat modeling, and the uncomfortable question of what the system allows someone to do that we did not intend.
That is harder.
It is also probably more important.
So my takeaway from this episode is not “panic about AI security.”
It is also not “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 passes, rough drafts, code search, query generation, pattern matching, and research workflows.
But do not outsource judgment.
Do not let the AI output become the security conclusion.
Do not confuse a confident answer with a correct one.
And do not let the excitement around future AI-driven attacks distract from the fundamentals that are still hurting teams right now.
Threat model the new stuff.
Patch the known stuff.
Clean up IAM.
Protect credentials.
Own your exposed attack surface.
Write down what your system actually promises.
And when AI gives you an answer, treat it like a starting point, not the finish line.
Because the future may move faster.
But the work still has to be done.