❌

Reading view

↗️

Anton’s Security Blog Quarterly Q1 2026

✇Anton on Security
By: Anton Chuvakin

My Anton’s Security Blog (And Podcast!) Quarterly this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Gemini image for this

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

  1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
  2. Security Correlation Then and Now: A Sad Truth About SIEM
  3. Can We Have “Detection as Code”?
  4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
  5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
  6. Beware: Clown-grade SOCs Still Abound
  7. Why is Threat Detection Hard?
  8. Top 10 SIEM Log Sources in Real Life?
  9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
  10. SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025

Top 5 posts with paper announcements:

  1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
  2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
  3. New Paper: “Future of the SOC: Forces shaping modern security operations”
  4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
  5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)

3 random fun posts, must-read:

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

  1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
  2. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
  3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
  4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
  5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
  6. EP17 Modern Threat Detection at Google
  7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

(also see our NEW 2025 reflections blog about the show)

Now, fun posts by topic.

Security operations / detection & response:

(if you only read one, choose this one!)

Cloud security:

(if you only read one, choose this one!)

How Google Does Security (HGD):

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

(if you only read one, choose this one!)

Fun presentations shared (nothing much new here ):

Enjoy!

Previous posts in this series:

Anton’s Security Blog Quarterly Q1 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
↗️

Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

✇Anton on Security
By: Anton Chuvakin

Look, I’m not a developer, and the last time I truly “wrote code” was probably a good number of years ago (and it was probably Perl so you may hate me). I am also not an appsec expert (as I often remind people).

Below I am describing my experience “vibe coding” an application. Before I go into the details of my lessons — and before this turns into a complete psychotherapy session — I want to briefly describe what the application is supposed to do.

Anton’s vibe app screenshot

We have a podcast (Cloud Security Podcast by Google), and I often feel that old episodes containing useful information aren’t being listened to and the insights from them go to waste. At the same time, for many organizations today, the answer to their current security problems may well have been discussed and solved in 2021. This may be strange to some, but for many organizations, the future is in the past. Somebody else’s past!

So I wanted “a machine” that turns old episodes into role-specific insights, without too much work by a human (me). This blog is a reflection on how things went.

First, my app is using public data — namely podcast transcripts and audio — to create other public data (social media posts). Since the inputs and outputs are public, this certainly made me at peace with vibe coding. Naturally, I needed to understand how the app would be coded, where it would live and what I should do to make it manifest in the real world. So I asked Gemini, and it suggested I use AI Studio by Google, and I did (non-critically) exactly that.

When I started creating the app, the question of storage immediately came up. Jumping a little bit ahead, you will see that authentication / credentials and storage were two security themes I reflected on the most.

You want to read a file from storage, but what storage? More importantly, whose storage? At this point, I had my first brush with anxiety of the “vibe process.” I didn’t want to just vibe code without a full understanding of the data access machinery. I immediately said, “No, I don’t want to store data in my Google Drive using my credentials.” I just didn’t trust it.

In fact, I didn’t trust the app with any credentials for anything — work or personal — at all! Given that I have public data, I decided to store it in a public web folder. AI Studio suggested ways to store data that people might not fully understand, and this is my other reflection: If I’m not a developer, and I don’t know the machinery behind the app, how do I decide? These decisions are risk decisions and “a citizen vibe coder” is very much not equipped to make them. Well, I sure wasn’t.

So what are the security implications of the decisions a developer makes — sometimes guided by AI and sometimes on their own? Can I truly follow an AI recommendation that I don’t understand? Should I follow it? If you don’t understand what happens, I can assure you, you certainly do not understand the risks!

As a result, I did not trust the app with any credentials or authenticated access. Of course, a solution may have been to use throwaway storage with throwaway credentials, but I think I do not need this in my life... Anyhow, many actions that you take during vibe coding, whether suggested by AI or not, have security implications.

In addition, the app interacts with the environment. If the app is being built in a corporate environment, it interacts with corporate security “rules and tools”, and some things you may want to do wouldn’t work. I’m not going into details, but I had a couple of examples of that. If you vibe code at work and you are doing it through, let’s say, shadow AI, there will be things your AI (and you) would want to do, but your employer security would not allow. And often with good reasons too! So you ask AI for more ways and hope it won’t say “just disable the firewall.”

The next conundrum, apart from storage, was output quality. What about quality and those hallucinatory mistakes? Now, I know my app uses an LLM to condense a summary of the podcast transcript into brief insights for social media. And before my app runs, another LLM turns MP3 into text. And it also uses an LLM to make the visual summaries. So, the question is: who handles the mistakes, and how?

For example, I tried to use a certain “well known” model to create a visual summary. Of course, the visual summary was incredibly accurate in most cases, but sometimes “mistakes were made” and words were corrupted (“verifigement” happened to me in one case). If an LLM powered tool can do something, it does not mean it will do it equally well every time (unless you build validators AND the things that you need to do can in fact be validated). So validate!

Further, I read somewhere that the process for dealing with AI mistakes is different from the process for dealing with human mistakes. I am sure I could write another module for the app to check if an image has correct text or add another validation technique, but it is interesting that I faced this very quickly.

Thus I have to deal with “AI-style mistakes”, and I cannot solve them by having a human review everything. I can tell you right away, even from my small project, that having a human review is a non-starter. It’s theoretically correct, but practically won’t happen. It absolutely will not happen if you take the koolaid and transform your business process to be “AI native.” Having humans review boring tasks like checking image text is completely insane. That’s not going to fly. HITL is DOA (for these tasks).

So: storage, credentials, trust, and quality all came up. Another decision arose when I needed to store intermediate results of my insight generation. Again, trust issues surfaced because data storage. AI Studio suggested choices, I asked AI about pros/cons, and made the decision. Again all these decisions are risk decisions.

Finally, certain mistakes come up all the time, repeatedly, and I have to tell AI Studio to write things multiple times because it doesn’t always “get” it (example: my podcast episode URLs). This is another lesson: sometimes it takes multiple prompts, and constant reminders (say to validate the links)

All in all, I’ll continue to experiment — got more ideas that I want. Here are some outputs of my app…

Anton vibe app UX

Now the explicit lessons for those who need this crisp and actionable:

1. You Make Implied Security Decisions with Every Prompt

When you “vibe code,” you aren’t just describing features; you are making risk and security decisions. If you ask an AI to “save this data,” and you don’t specify how or where, the AI may choose the path of least resistance — usually a public bucket or a local file with cleartext credentials. In the world of AI-generated code, silence is a security decision.

2. Credentials and Storage: The Boring Stuff is Still the Hard Stuff

Storage and credentials were the key themes for me. This is the great irony of modern development: AI can write a complex LLM orchestration layer in seconds, but it may struggle to help a novice set up a secure, encrypted secrets manager. The “plumbing” of security remains the primary friction point.

3. AI Mistakes Require a New Response Model

Traditional QA seems designed for deterministic human error. AI “style mistakes” (like corrupted words in a visual summary) are stochastic and weird. And common! Human review is a “non-starter” for these tasks. Security and quality validation for AI-generated content must itself be automated (AI-on-AI validation) because humans simply won’t do the “deathly boring” work of checking verbatim accuracy at scale. Turtles all the way down can happen to you.

4. Corporate Guardrails vs. AI Ambition

The AI you vibe code with may not know your corporate policy. It will suggest “awesome” features that would immediately trigger a compliance violation. A few times while vibe coding, I heard a subtle lawyercat meowing in the air duct… When vibe coding in a corporate environment, you quickly hit the wall where “what the AI wants to do” meets “what security allows.” This reinforces the need for platform-level guardrails rather than just merely developer education.

5. Public Data is the Only “Safe” Vibe

My “peace of mind” came from the fact that your inputs and outputs were already public. To me, this is the only way to vibe code safely without a full understanding of the underlying security stack. The moment you move from “public podcast audio” to “proprietary customer data,” the risk model shifts from “fun experiment” to “data breach.”

Anyhow, this was my mildly-AI-assisted stream of vibe consciousness.

Enjoy the show! Now with video!

Anton’s Vibe Coding Experience: A Reflection on Risk Decisions was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
↗️

Google Cloud Security Threat Horizons Report #13 (H1 2026) Is Out!

✇Anton on Security
By: Anton Chuvakin

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our next Cloud Threat Horizons Report, #13 (full version, no info to enter!) that we just released (the official blog for #1 report, my unofficial blogs for #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 and #12).

My favorite quotes from the report follow below:

  • [in Google Cloud] “software exploitation overtook credentials as the primary initial access vector for the first time.” and “Threat actors exploited third-party software-based entry (44.5%) more frequently than weak credentials.” [A.C. — some of you may say this is because AI is making more zero days, but a dozen more mundane answers may be correct instead]
THR H1 2026 image 1
  • “While threat actors continued to use brute-force attacks against weak credentials, the increase in RCE represents a pivot toward more automated exploitation of unpatched application-layer vulnerabilities.” [A.C. — to some extent “creds or vulns” debate is rather pointless as the real answer is “both”, and it varies by environment too, see below]
  • “Threat actors continued to transition from traditional phishing to voice-based social engineering (vishing), and credential harvesting from third-party SaaS tokens to facilitate large-scale, silent data exfiltration.” [A.C. — again, this means “AND” not “OR” because classic phishing still works well in many cases, but yes “credential harvesting from third-party SaaS” has become very fruitful too]
  • [overall] Still “Identity compromise underpinned 83% of compromises. [A.C. — so, yes, “creds” still beat “vulns” on many environments]
THR H1 2026 image 2
  • “High-volume data theft operations — executed through compromised but legitimate access channels — remained the primary goal for threat actors, with our metrics showing they targeted data in 73% of cloud-related incidents.” [A.C. — again, not new, but very useful data confirming the running trend. Beware!]
  • “The window between vulnerability disclosure and mass exploitation collapsed by an order of magnitude, from weeks to days.” [A.C. — again, some of you may see the invisible robot hand of an AI here, but, as usual, the reality is more complicated…]
  • “Trend analysis from 2008–2025 indicates cloud services will soon surpass email as the primary data exfiltration pathway.” [A.C. — $32B reasons to finally get serious about it across all clouds?]
  • “45% of intrusions resulted in data theft without immediate extortion attempts at the time of the engagement, and these were often characterized by prolonged dwell times and stealthy persistence.”
  • “The traditional incident response model is no longer viable when dealing with containerized workloads and serverless architectures where data can vanish in seconds.” [A.C. — a very useful reminder here! Cloud is cloudy! Don’t be that guy who thinks that cloud is a rented colo. Cloud is not JUST somebody else’s computer.]
  • “Threat actors used large language models (LLM) to automate credential harvesting and transition from a developer’s local environment to full cloud administration access.” [A.C. — this really should not be news for anybody in 2026, but if it is, HERE IS SOME NEWS: BAD GUYS USE AI!]
  • Thus “Prevent LLM exploitation as an extension of living-off-the-land (LOTL) by treating LLM activity with the same scrutiny as administrative command-line tools.” [A.C. — or, as I say, “with AI agents, every prompt injection is an RCE”]

Now, go and read the CTHR 13 report!

Related posts:

Google Cloud Security Threat Horizons Report #13 (H1 2026) Is Out! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
↗️

My Really Fun RSA 2026 Presentations!

✇Anton on Security
By: Anton Chuvakin

This blog is perhaps a little bit more like an ad, so if you don’t want to check the ads, consider not reading it.

a very cyber image (Gemini)

But this year at RSA 2026, I’m speaking on three topics: securing AI, using AI for SOC, and sharing lessons about how Google applies AI and other technologies to D&R.

Here are these 3 fun things!

First, I’m doing a presentation on governing shadow AI agents. Believe it or not, this presentation was created mostly before OpenClaw became a thing (but updated for it!). So you may be surprised how well the content aged (think wine!) Attend this if you are struggling with shadow AI, specifically shadow agents at work.

Shadow Agents: A Pragmatist’s Guide to Governing Unsanctioned AI — [STR-W08]

  • Wednesday, Mar 25 1:15 PM — 2:05 PM PDT

It is not the APT! The new threat is the “shadow AI agents” employees already use for work, leaking data and making decisions. Banning them is a losing game. This session will offer a better way: turn this organic behavior into a catalyst for secure progress. Learn to discover, assess, and channel unsanctioned agents into a formal strategy that empowers a team rather than force it underground.

The second is probably the most detailed discussion about how we use AI for detection and response at Google. You probably read our blogs and listen to our talks (especially this), but this time we are revealing a lot more interesting details about the machinery and also how we arrived at the state we’re in. I promise you this will be fun! And detailed too.

This Is How We Do It: Building AI Agents for Cybersecurity and Defense — [PART3-M07]

  • Monday, Mar 23 2:20 PM — 3:10 PM PDT

Presenters will share the playbook for building and scaling AI agents in cybersecurity. Attendees will learn four core lessons: Building trust with the team, prioritizing real problems, measuring value, and establishing solid governance foundations for the agentic SOC.

Finally, the third isn’t a presentation but a discussion that would help you understand the real state of AI in security operations / SOC. This would not be about the slides, but about sharing lessons on what works and what doesn’t.

AI in SecOps: Sharing Lessons Learned for Adoption Maturity — [CXN-R05]

  • Thursday, Mar 26 12:20 PM — 1:10 PM PDT

Attendees in this peer-led discussion will share stories from the AI-powered SOC trenches. Explore real adoption journeys from manual processes to autonomous agents. Share practical use cases on analyst retraining, workflow auditing, malware analysis, remediation automation, RAG pipelines and more. Trade notes on what’s working, what’s breaking, trust gaps, AI hallucinations, and career redesign.

All in all, join me for securing AI and Shadow Agents, learning from Google about detection and response, and comparing the state of practice of AI in the SOC.

See you there!

P.S. Yes, we will also be podcasting from the show.

Related:

RSA 2025: AI’s Promise vs. Security’s Past — A Reality Check”

My Really Fun RSA 2026 Presentations! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
↗️

SIEM, Startups, and the Myth (Reality?) of IT Inertia: A Reformed Analyst Reflects on SIEM MQ 2025

✇Anton on Security
By: Anton Chuvakin
Vaguely magical and quadranty thing (Gemini)

It’s not every day you get to reflect on a journey that started as an odd “googley” startup and culminates in a shiny Leaders placement on a Gartner Magic Quadrant for SIEM 2025 (MQ).

When I joined Chronicle in the summer of 2019 — a name now rolled into the broader Google SecOps product (with SOAR by Siemplify and threat intel by Mandiant) — it was very much a startup. Yes, we were part of Alphabet, but the spirit, the frantic energy, the drive — it was a startup to its core.

And here’s the kicker (and a side rant!): I’m fundamentally allergic to large companies. Those who know me have heard me utter this countless times. So, in a matter of weeks after joining a small company, I found myself working for a very large one indeed.

To me, that pivot, that blending of startup momentum and big company scale, is, in many ways, the secret sauce behind our success today. It turns out, you need both the wild ambition of a young vendor and the solid foundation of a massive enterprise to truly move the needle (and the dots on the MQ … but these usually reflect customer realities).

The MQ and the Price of Poker

Now, as a reformed analyst who spent eight years in the Gartner trenches, I’ll clear up a misconception right away: the Magic Quadrant placement has precisely zero to do with how much a vendor pays Gartner. Trust me, there are vendors in highly visible SIEM MQ positions who’ve probably never sent Gartner a dime over the years.

Conversely, there are large organizations that have paid a fortune and have been completely excluded from the report. The MQ placement reflects customer traction and market reality (usually — there are sad yet very rare exceptions to this, and I will NOT talk about them; there is not enough whiskey in the world to make me). MQ placement is a measure of genuine success, not a destination achieved by writing a big check.

The Evolution of SIEM: Where Did the Brothers Go?

Reflecting on the last few years in SIEM (not 20 years!) and looking at the current MQ, a few things that were once controversial are now conventional wisdom:

  1. SIEM must be SaaS and Cloud-Native. I’m old enough to remember when the idea of trusting your security data to the cloud was an existential debate. Today, with the relentless attack surface expansion, perhaps more people are realizing that the biggest risk is actually running a vulnerable, constantly-compromised on-prem SIEM stack. Data gravity shifted.
  2. SIEM and SOAR are fully merged. They are, in essence, two inseparable brothers forming the core of modern SIEM — detection and response. SIEM is really SIEM/SOAR in 2025. Standalone SOAR vendors do exist and some “AI SOC” vendors are really “SOAR 3.0”, but these are — IMHO — outliers compared to the mainstream SIEM.
  3. The UEBA brother got absorbed, but … Remember the mid-2010s, when User and Entity Behavior Analytics (UEBA) was the new shiny toy, all driven by cool machine learning? While it was an equal brother to SOAR for a moment, it has now largely been absorbed into the detection stack of the main SIEM product. Machine learning’s importance for basic threat detection has subtly decreased (odd…isn’t it?). UEBA has become a single, albeit important, feature within the engine, not a standalone platform.
  4. Some XDR vendors graduated to real SIEM. EDR-centric SIEM vendors (XDR, if you have to go there), have landed. IMHO, these guys will do some heavy damage in the market in the next 1–2 years.

The Most Powerful Force in the Universe: IT Inertia

When I left Gartner, I famously outlined one key lesson from my analyst time: IT inertia is the most powerful force in the universe.

When you look at the MQ, you might see what looks like “same old, same old,” with certain large, established vendors still floating around. This is NOT about who pays, really! You might not believe it, but this placement absolutely reflects enterprise reality. Large vendors don’t die immediately.

Case in point: it took one particularly prominent legacy SIEM vendor (OK, I will name this one as it is finally dead for real, ArcSight) almost ten years to truly disappear from the minds of practitioners. Most companies were abandoning that technology around 2017–2018), but the vendor only truly died off in the market narrative in 2025. The installed base hangs on, dragging the demise out over a decade.

AI, Agents, and the Missing Tsunami

Finally, a quick note on the current darling: Generative AI and AI Agents.

While some vendors (and observers) expected a massive, dramatic impact from Generative AI on this year’s MQ, it simply hasn’t materialized — yet. As other Gartner papers will tell you, AI does not drive SIEM purchasing behavior today.

Why? Gartner’s assessment is based on customer reports. Vendors can yell all they want about how AI is dramatically impacting their customers, but until those customers report observable, dramatic improvements and efficiencies to Gartner, the impact is considered non-existent in the MQ reality.

The AI tsunami is coming, but for now, the market is still focused on the fundamentals: cloud-native scale, effective detection, and fast/good (AND, not OR) response. Getting those right is what puts you in the Leaders Quadrant. The rest is just noise…

Other SIEM MQ 2025 comments can be found here (more to be added as they surface…)

P.S. The “reformed” analyst reference comes from Tim and our Cloud Security Podcast by Google

SIEM, Startups, and the Myth (Reality?) of IT Inertia: A Reformed Analyst Reflects on SIEM MQ 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
↗️

Anton’s Security Blog Quarterly Q3 2025

✇Anton on Security
By: Anton Chuvakin

Amazingly, Medium has fixed the stats so my blog / podcast quarterly is back to life. As before, this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify).

Gemini for docs based on this blog

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

  1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
  2. Security Correlation Then and Now: A Sad Truth About SIEM
  3. Can We Have “Detection as Code”?
  4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
  5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!!!)
  6. Beware: Clown-grade SOCs Still Abound
  7. Why is Threat Detection Hard?
  8. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
  9. Top 10 SIEM Log Sources in Real Life? (updated 2024 version)
  10. Anton and The Great XDR Debate, Part 1

Top 5 posts with paper announcements:

NEW: recent 3 fun posts, must-read:

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

  1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
  2. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
  3. EP8 Zero Trust: Fast Forward from 2010 to 2021
  4. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
  5. EP17 Modern Threat Detection at Google
  6. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
  7. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw

Now, fun posts by topic.

Security operations / detection & response:

(if you only read one, choose this one!)

Cloud security:

(if you only read one, choose this one!)

How Google Does Security (HGD):

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

(if you only read one, choose this one!)

NEW: fun presentations shared:

Enjoy!

Previous posts in this series:

Anton’s Security Blog Quarterly Q3 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
  • ↗️
❌