If you look at social media debates about AI, two extreme patterns emerge. Studying extreme patterns is very useful because understanding boundary conditions helps you understand the whole phenomenon — in this case of security in AI adoption (recent extreme example). You can also do all sorts of fun scenario planning with this.

Predictably, security leaders have caught the same fever, and even some technologists did. Let’s catalog them like this:

• Camp 1 (The Meh Camp): This camp spans a spectrum — from the hard cynics (“it’s autocomplete with a marketing budget,” LLMs are stochastic parrots, there is no ‘intelligence’ anywhere in the building) to the more measured “AI as normal technology” crowd, who concede the tech is real, but expect it to diffuse slowly and messily over decades. What unites them: no discontinuous jump, no paradigm rupture, no exponents, no robot overlords. And yes, “the parrot wing” of this camp is alive and well in some very senior security circles.
• Camp 2 (The Deep Believers): AGI is coming by “next Tuesday” — or 2027 at the absolute latest. This camp also spans a spectrum, from the “doomer” accelerationists who foresee inevitable, systemic collapse to the optimistic futurists anticipating a complete, rapid upheaval of the global security landscape. Some hold this timeline with religious fervor while being unable to define “intelligence” if their bonus depended on it. What unites them is the conviction that we are facing an immediate, discontinuous, exponential leap in capability that will render all traditional defensive strategies obsolete overnight. And yes, there are influential security leaders who lean heavily into this camp.

Here is the fun part and the point of this blog: you don’t need to know who’s right. In fact, betting your security program on either camp being right is the actual mistake I want to point out.

Maybe the Parrot camp is right. Maybe the AGI-doomers are spot on. Or maybe the truth is somewhere in the swampy middle. If you find yourself unable to justify a security investment without first winning a philosophy-of-mind debate, you are doing it wrong.

But let’s instead ponder what works in “either / neither / both” cases.

What security advice remains correct today and for the medium term without relying on either camp being right?

One structural note before we start: every section below runs the same play. What the “parrot future” does to you. What the “AGI Tuesday” future does to you. What you do about both — with one control. Watch how many times the answer converges.

That convergence is my argument (with help from Gemini and Claude Fable).

Universal Security Controls for Both Futures

If you’re Camp 1 — whether the parrot wing or the “normal technology” wing — you believe AI is an incremental extension of “classic” ML: it accelerates existing security processes without any dramatic paradigm shift. But even then, you concede it speeds things up — including for attackers, who now discover vulnerabilities and misconfigurations faster and phish with impeccable grammar (nobody, not even the “parrotiest” parrot will argue with this one!). If you’re Camp 2, you may be surprised to see that these same controls apply, just with the volume knob turned to 11 at times.

1. Configuration Hygiene

Boring? Yes. Optional? Definitely not. Cloud misconfigurations and weak baselines remain the #1 way attackers walk in through the front door — no AGI required, thank you very much.

• Parrot future: attackers use AI to find your misconfigurations faster. The parrot doesn’t need to be smart; your S3 bucket is public.
• AGI future: the “superintelligent” attacker also starts with your public S3 bucket, because why use an AI-crafted zero-day when the door is open?

The universal control: treat configuration hygiene as tier-1 defense, with continuous (not quarterly!) posture validation. Hygiene is the rare control that is equally valuable whether AI is a mildly better “grep” or an existential threat (Claude came up with this metaphor, thanks buddy, it almost rhymes). If your AI security roadmap has “agentic red teaming” on it but not “close the open buckets,” you are accessorizing a house with no doors. See good argument here.

2. Threat Detection & Security Monitoring

You do recall I had a title “Chief Logging Evangelist” a few years back (“A few, Anton”? Who are you kidding?” … Anyhow…) Your SOC or D&R team or whatever you call it still needs to log, sense, detect, investigate, etc.

• Parrot future: your normal systems face automated, AI-accelerated attacks — same TTPs, faster tempo, and phishing that finally spells “invoice” correctly. Your triage queue was built for human-speed adversaries; it is about to meet an assembly line.
• AGI future: the AI systems themselves become the thing to watch — inputs, outputs, tool calls, and internal telemetry — because prompt injection, abuse, and quiet exfiltration through an agent leave traces nowhere in your current detection content.

The universal control: log and detect. Your classic estate under machine-accelerated attack, and your AI stack as a first-class telemetry source with its own detections (devil here is in the details, as usual). I admit this smells like an “Easier Said Than Done” competition entry with some chance of getting a 3rd prize. But the fact remains: good logging helps you in either case.

3. Accelerated Vulnerability Management

Vulnerability management — dealing with security-relevant flaws in vendor software and your own code and open source code — must run on a faster clock in 2026. The clock disagreement between the camps is about how much faster, not whether. Think 30%+, 2x, 10x or “we are all gonna die”x :-)

• Parrot future: AI compresses the exploit timeline the boring way — faster recon, faster PoC-to-prod exploit code, “commodity” attackers punching above their weight class. Your 30-day patch SLA quietly became a 30-day “we have a front door open, locks what locks” period.
• AGI future: “Patching is dead! The machines will find zero-days continuously!” Fine. Even granting the premise, the conclusion isn’t “give up” — it’s that mitigation and rewriting becomes the whole game.

The universal control: vulnerability management inclusive of mitigation planning (segmentation, “virtual” patching, compensating controls, config weakness scanning, etc) becomes more critical under both futures, not less. Most companies cannot break their “patch sound barrier”, AI or no AI. When you can’t fix the flaw, you’d better be able to contain the blast radius. Note the irony: the AGI camp’s own argument makes the boring VM discipline more important. Funny how that works.

4. Data Security & Sensitive Data Discovery

Both camps should care deeply about knowing where their sensitive data lives, but they lose sleep over different nightmares:

• Parrot future: the risk is leakage and compliance. Employees will lovingly paste source code, PHI, and PII into consumer chatbots to “polish an email.” Regulators do not accept “the parrot ate my data” as a defense. Am I overdoing the “parrot thing” here?
• AGI future: the risk shifts to poisoning and exploitation. An agentic system with access to poorly governed data repositories plus one well-crafted prompt injection equals an AI that cheerfully exfiltrates things it should never have touched.

The universal control: build a real-time, accurate inventory of your sensitive data — and yes, AI-automated sensitive data discovery and mapping is finally real (while in 2016, it largely was not, for most organizations). The uncomfortable truth: most organizations spent two decades not doing data security because it was hard and nobody made them. AI just made “we don’t know where our data is” much more painful, whether you are “camp parrot” or “camp AGI.” Heard this advice before? Yes, you did. So? Did you actually try implementing it? Well, now you need to, parrots or not.

5. Shadow AI Governance & Sanctioned Alternatives

Banning public AI tools is the ultimate security theater — right up there with confiscating USB sticks in 2009 or banning Internet connectivity in 1998 (“but why would you need the internet for work?!”). It doesn’t stop usage; it just moves it to personal phones and personal accounts, where you can’t see it, log it, or ever get the data back.

• Parrot future: employees casually feed proprietary code and PII into consumer LLMs, generating incidents and triggering your lawyercats unnecessarily.
• AGI future: well-meaning developers hand API keys and internal data access to unmonitored shadow agents and creating a sprawling, autonomous attack surface that nobody owns. What fun!

The universal control: stop playing firewall whack-a-mole. Get visibility (CASB and DLP are still a thing, yes, really!), then remove the excuse: offer a sanctioned enterprise AI tool with real contractual data protections. People take shortcuts when the official path is a dirt road. Pave it. And if your ban is still in place in 2026, understand that you don’t have a policy — you have a shadow inventory problem you’ve chosen not to measure.

6. Identity & Access for Agents

Here’s the control nobody had on their 2016 bingo card: least privilege for machines that ask nicely. We barely handled NHI (no, we never did, IRL) and now we have “agent identity” with a pillow fight ongoing on “is agent more like an employee or more like a workload”…

• Parrot future: AI tools and integrations quietly accumulate OAuth grants, service accounts, and long-lived API keys — classic non-human identity sprawl, now with extra steps. Regular NHI problem left unsolved would kill you slowly, the agentic one will work faster.
• AGI future: autonomous agents holding broad credentials become the single most attractive target in your enterprise. Compromise the agent, inherit its permissions — and its work ethic. Tricking an agent to do “a rogue action” is becoming more popular every day…

The universal control: treat every agent, and integration as an identity with a lifecycle (!). Scope it, time-limit it, log it, and review it. Your agents currently have more access than your interns and sometimes less judgment. Fix at least one of those ;-)

7. Environmental Reality Testing vs. Marketing Benchmarks

Model capability benchmarks are largely a mirage if they do not match your realities. A high score on a vendor slide means precisely nothing about your production environment, if you are not them.

• Parrot future: blind trust in claimed accuracy yields silent failures, hallucinations in critical workflows, and surprise data leakage — the parrot passed the exam and still can’t do the job. I am not adding “it will peck you to death”, this is where I draw the line…
• AGI future: deploying an agentic system for consequential autonomous tasks without validation invites systemic, unpredictable behavior — an advanced agent breaking things faster than you can file the postmortem.

The universal control: ignore the brochure. Run internal, multi-run reliability testing and AI red-teaming in your environment with your data before any AI system earns operational duties. Trust is earned in your environment, not on the vendor’s leaderboard. Here’s the provocative version: if your AI procurement process accepts benchmark scores as evidence, your procurement process is part of your attack surface.

Moving Beyond the Debate

And, yes, we could keep adding entries (asset management, IR playbook updates for AI incidents; the list of unglamorous-but-necessary goes on). But you’ve seen the pattern ten times now, so let’s name it.

The two camps diverge violently on timelines and on whether a discontinuous “AGI jump” is coming at all — yet they converge on the near-term necessity of architectural control, every single time. Autonomous agents, supply-chain exposure, machine-speed offense: both worldviews agree these risks are real, present, and demand action today.

When two groups who agree on nothing agree on your homework, the homework is probably real. If I hear one more CISO tell me they are “waiting for the dust to settle on AI” before building a security strategy, I’m going to start charging for therapy. The dust isn’t settling. It’s just turning into more data you aren’t logging.

So the next time someone tells you they can’t build an AI security strategy until the AGI debate settles — smile, nod, and go patch something. The philosophers will still be arguing next Tuesday. Your attackers won’t wait that long.

Summary

• The dichotomy: security leaders split into the “normal technology” camp (from stochastic-parrot cynics to slow-diffusion “pragmatists”) and the “AGI by next Tuesday” believers (and of course less extreme middle too)
• The core thesis: we do not need to settle the philosophical debate. Many of the same fundamental, no-regret controls apply regardless of which future arrives, and the camps’ convergence on near-term controls is itself the strongest evidence those controls matter.
• The no-regret controls:
• Treat configuration hygiene as tier-1 defense — both futures start at your public S3 bucket.
• Monitor both your normal systems under AI attack and the telemetry of your AI systems themselves.
• Accelerate vulnerability management loops, with mitigation planning for the flaws you can’t patch
• Prioritize sensitive data discovery — against leakage (low end) and poisoning/exploitation (high end).
• Replace blanket bans with sanctioned enterprise AI plus visibility.
• Govern non-human identities: least privilege, lifecycle, and logging for every agent and integration.
• Re-engineer threat models and containment for machine-speed intrusions.
• Ignore synthetic vendor benchmarks; mandate local adversarial red-teaming before operational trust.

“AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

• Who takes a loss vs who is to blame?
• Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

• The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
• The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
• The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
• The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

• “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
• “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
• “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
• “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
• “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

• Who’s Responsible When AI Goes Wrong? A New Framework Aims to Answer That Question
• Where Does Shared Responsibility Model for Security Breaks in the Real World?
• No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
• EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull
• EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?
• Who Does What In Cloud Threat Detection?
• The Cloud Shared Irresponsibilities Model

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.