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.

Intezer already investigates 100% of your alerts and escalates fewer than 2% of them for human review. That part is handled.

The work does not stop there, though. Every SOC has its own routines wrapped around the investigation itself. The incident reports written in a particular format, the closure notes, the shift handoffs, the rules that decide who picks up which case. When we looked at how teams actually use AI Chat, our in-product investigation agent, more than a third of those conversations turned out to be the same repetitive tasks asked again and again. The same summaries. The same reports. The same closure notes.

Intezer’s AI SOC already runs agents around the clock to triage, investigate, and respond to your alerts on their own. Custom Agents is the next step. Now you can shape how that AI SOC works for your team. Add your own agents and automations on top of the ones Intezer runs out of the box, take more of the manual work off your analysts, and tailor the whole thing to the way your team actually operates.

Meet Custom Agents

Intezer ships with a set of agents and automations that handle triage, investigation, and response from day one. Custom Agents lets you build your own on top of them.

An agent is made up of three components:

1. Your instructions
2. A trigger
3. The tools it is allowed to use

You describe what you want done in plain language, choose when it should run, and pick what it can touch. It then runs on its own inside your Intezer environment, on the same engine that powers our investigation Agent (Chat).

Build an agent in minutes

1. Tell it what to do, in plain language. Write the instructions the way you would brief a new analyst. “Every morning, review the open case queue, close the clear false positives per our playbook, and leave a handoff note on the rest.” That is an agent.

2. Choose when it runs. Three trigger types cover most workflows:

• On a schedule: every day, week, or month. For example, a 9:00 report.
• On an event: the moment a case is closed, a verdict is set, or an alert meets your conditions.
• On demand: run it yourself, or call it from the API.

3. Give it the right tools. Agents work across your whole stack which includes Intezer’s built-in toolset plus the SIEM, EDR, and identity tools you have already connected, including CrowdStrike, SentinelOne, Splunk, Microsoft Sentinel, and Entra ID. They do more than summarize. They take action by updating, commenting on, closing cases, and emailing a finished report to your team.

See it in action

Take an Incident Report Writer agent illustrated above. We deliberately never shipped a single “Generate report” button, because no two teams want the same report. One team wants an executive summary up top, another wants the full timeline, another has a compliance format it has to match. So instead of a button, you put your format into the agent’s instructions, and it writes every report that way, every time.

The agent triggers on every escalated case an analyst has confirmed as a real threat. It reads the case, writes the report in your format, and emails it to your team’s inbox. The analyst makes the call. The paperwork writes itself.

That’s one agent. The point of Custom Agents is that you decide what they are.

Nothing runs blind

Security teams do not trust black boxes, and they are right not to. Custom Agents is built so you can see and control everything an agent does.

• Every run is visible. You see the agent’s reasoning, every tool call and its result, and the final output. Each run is logged, and you can export it.
• Test safely with Dry Run. Dry Run executes the agent for real but mocks every write action, so you can watch exactly what it would do before it does anything. Iterate on the instructions until it is right, then turn it on.
• Guardrails are built in. Action tools are limited by design. An agent can only email active members of your organization, for example. It cannot reach outside your walls.
• You stay in control. You choose which tools an agent gets, you review its output, and you can switch it off in one click.

This is how everything at Intezer works. AI executes, humans supervise. Custom Agents lets you decide what it executes.

What security teams are already building with it

We opened Custom Agents to a small group of alpha customers, and the best part has been watching what they build. Alongside the Incident Report Writer above, a few of the agents already running in production:

• SLA Monitor (daily): a morning email listing every escalated case that has been sitting too long, so nothing critical slips past its deadline.

 

• Tuning Advisor (weekly): takes the alerts your detection tools fired that Intezer judged to be false positives and turns them into suppression recommendations for the week ahead.

 

• Threat Hunter (weekly): proactively sweeps your environment for the latest threats instead of waiting for an alert to fire. It pulls the new malware families, campaigns, and indicators Intezer is tracking, queries your connected SIEM and EDR for matches across historical data, and opens a case for anything it surfaces.

 

• Smart Triage and Routing: for organizations with multiple entities, subsidiaries, and stakeholders, the agent reads each case and works out which team should own it, using your own escalation rules. It either leaves a comment with the routing, or assigns the case to the right analyst directly. Analysts stop digging through a separate list or knowledge base to figure out where a case goes.

 

• End of Shift Handoff: built to match what a real SOC handover looks like. At the end of a shift the agent compiles the open items, the escalations still waiting for attention, the shift’s statistics, and any open system events or configuration issues, then writes the handoff so the next shift starts with the full picture.

The AI SOC, built for your team

We are on a mission to build the AI SOC the industry has been promised but never delivered. One that does the work and earns the trust to do it. It runs autonomously, around the clock. It works alongside the people who supervise it, not over their heads. And it is never a black box. You can always open it up, question what it did, and change how it behaves.

Custom Agents is central to that vision. Triage, investigation, and response come built in. Everything particular to how your team operates, you build yourself. Because the strongest security teams have always run on their own playbooks, their own logic, and their own standards, and an AI SOC should be no different. It should not ship the same to everyone. No two SOCs are the same, and no two should be.

That is the point of Custom Agents. You decide what they are.

Available now

Custom Agents is available now in beta to Intezer customers, and it is free during the beta period. This is the moment to build, test, and tell us what you want it to do next.

See what your SOC could hand off. Book a demo.

If you are already an Intezer customer, you will find it under Custom Agents in the top menu.

The post Introducing Custom Agents: Automate your SOC, your way appeared first on Intezer.

Attackers can exploit LLM domain hallucinations through phantom squatting to target supply chains. Read the analysis to learn more.

The post Phantom Squatting: AI-Hallucinated Domains as a Software Supply Chain Vector appeared first on Unit 42.

The post Unmasking the Digital Trail: Essential Techniques for Vetting AI-Generated Content appeared first on Flashpoint.

Unit 42's analysis of ClawHub revealed evasive malicious skills bypassing automated scanners to deploy infostealers and execute agentic financial fraud.

The post OpenClaw’s Skill Marketplace and the Emerging AI Supply Chain Threat appeared first on Unit 42.

Today we’re publishing our first “Public Country-by-Country Report” for our fiscal year 2025, disclosing our taxes in the period from July 1, 2024, to June 30, 2025. It covers the countries and regions included under European Union rules and shows, for each one, our revenue, profit, number of employees, and income tax accrued and paid during the year.  
 
We have provided this kind of information directly to tax authorities for several years under the Organization for Economic Cooperation and Development (OECD) framework. It is now published to support transparency commitments, and we believe it is important to proactively address any questions these disclosures may raise, recognizing that numbers on a spreadsheet rarely tell the full story.
 
Microsoft pays the taxes we owe in every country where we operate. We know there are strong views about whether companies are paying enough, and we believe providing this context leads to a more informed conversation.

Understanding country-by-country reporting

Country-by-country reporting is not widely understood outside tax and accounting circles. Some figures may look surprising at first, but a number that appears low or high in one country does not, on its own, tell the full story. Tax law differs from country to country, and there are two important things to keep in mind when reading the report.  

First, the numbers are prepared using rules that differ from United States or country-specific financial accounting and tax rules, so they may not match other Microsoft information people have seen. For example, this report combines all Microsoft legal entities in a country and follows the reporting rules required by EU regulations. By contrast, local statutory accounts usually cover just one legal entity, follow local accounting rules, and may use a different fiscal year from Microsoft’s.  

Second, accrued tax is what you owe for the year. Tax paid is the amount actually paid during the year. The two can differ because the timing of owing tax and paying tax doesn’t match exactly. 

France is a good example of why a single line can look unusual without context. In FY25, cash tax paid in France reflects a one-time refund of tax overpaid in an earlier year. That makes this year an outlier. In this specific case, accrued tax may be a better reflection of the taxes borne for the fiscal year. Microsoft paid $374 million in tax in France over the prior three years. 

Variations like these are a normal part of how large companies, both domestic and multinational, are taxed across borders, and they reflect an evolving tax landscape as well as a business that continues to change. We comply with every local rule that applies to us, and as those rules change, our reporting will change with them. Microsoft is committed to a tax structure that reflects where our people work, where we invest, and where functions, assets, and risks occur, and this has been a guiding principle. 

How our investments support local economies

We understand that this discussion is not only about what the law requires or what a single tax line shows in a given year. For many people, it is also about a broader question of contribution: how companies support the countries where they do business. That contribution includes the taxes we pay, the capital we invest, the local jobs and infrastructure we support, and the economic activity created through customers and partners. In the S&P, Microsoft ranks second globally in corporate income taxes paid in the last year, with a total of $28.7 billion. In fiscal year 2025, we paid $6.3 billion in income tax in the EU. Importantly, this does not include payroll, VAT, property, and other taxes paid in addition. 

Taken together, our tax payments, capital investments, and partner ecosystem reflect a long-term commitment to the countries where we operate. We opened our first European office in the UK in 1982, followed by France and Germany in 1983, and then expanded into Denmark, Ireland (our largest hub in the region), Italy, Norway, Spain, and Sweden in 1985. Microsoft is now present in all 27 EU Member States and across the broader region. We have worked in these and many other communities for decades, and thousands of our employees call them home.  

From research and development to digital infrastructure and partnerships with local organizations, we are investing in ways that support these economies beyond our direct commercial activity. At our core, we are building tools that help large enterprises, small and medium-sized businesses, institutions, and individuals become more productive and competitive, which strengthens their business and benefits the people they serve. We only do well when our customers do well. In practice, that means helping customers design and manufacture cars better, helping patients get their next appointment sooner, or making it simpler for someone to find that dream job. 

Our investments in digital infrastructure are not only supporting the local digital economy, they are also contributing meaningfully through both taxation and capital expenditure. Across markets, we continue to invest at scale in datacenters and supporting infrastructure, creating value that extends well beyond the technology sector. In the three years to June 30, 2025, our total capital expenditure amounted to $176 billion, and we spent $89.2 billion on research and  development in the markets where we operate. 

Our customers require local industry- and country-specific expertise, and this is where our partner ecosystem plays an important role. Many of these partners are local businesses themselves. A 2024 IDC study on partner profitability showed that for every $1 of Microsoft revenue, partners that provide services generate $8.45, and partners that develop software generate $10.93. While this varies by country and partner segment, it offers another useful lens on how Microsoft’s business contributes to local economic activity. 

Investments in digital infrastructure are not only investments in technology ecosystems, but in national and local economies as well. They support jobs, strengthen supply chains, create opportunities for companies across many sectors, and help build the foundation for growth and economic competitiveness beyond the digital economy. 

That is the broader context for this report. Tax is one important measure of contribution, but it is not the only one. Our investments, partnerships, infrastructure, and long-term presence in countries around the world also reflect a commitment to helping strengthen the economies and communities where we operate, today and for the future.

 

The post Context on our country-by-country tax footprint appeared first on Microsoft On the Issues.

Because of the way they are trained, large language models capture only a slice of human language. They’re trained on the written word, from textbooks to social media posts, and our speech as captured in movies and on television. These models have minimal access to the unscripted conversations we have face to face or voice to voice. This is the vast majority of speech, and a vital component of human culture.

There’s a risk to this. The increased use of large language models means we humans will encounter much more AI-generated text. We humans, in turn, will begin to adopt the linguistic patterns and behaviors of these models. This will affect not just how we communicate with one another, but also how we think about ourselves and what goes on around us. Our sense of the world may become distorted in ways we have barely begun to comprehend.

This will happen in many ways. One of the first effects we could see is in simple expression, much as texting and social media have resulted in us using shorter sentences, emojis instead of words, and much less punctuation. But with AI, the impacts may be more harmful, eroding courteousness and encouraging us to talk like bosses barking orders. A 2022 study found that children in households that used voice commands with tools like Siri and Alexa became curt when speaking with humans, often calling out “Hey, do X” and expecting obedience, especially from anyone whose voice resembled the default-female electronic voices. As we start to prompt chatbots and AI agents with more instructions, we may fall into the same habits.

Next, in the same way autocomplete has increased how much we use the 1,000 most common words in our vocabulary, talking with chatbots and reading AI-generated text may further constrict our speech. A recent University of Coruña study found that machine-generated language has a narrower range of sentence length, averaging 12-20 words, and a narrower vocabulary than human speech. Machine-generated text reads as smooth and polished, but it loses the meanders, interruptions and leaps of logic that communicate emotion.

Additionally, because large language models are primarily trained from written speech, they may not learn how to emulate the free-wheeling nature of live, natural speech. When told “I hate Beth!”, ChatGPT replies with an uninterruptable three-part formula of affirmation (“That’s completely valid”), invitation (“I’m here to listen”) and invitation (“What’s going on?”) far longer than any reply plausible in face-to-face dialog. “What’s Beth’s deal?!” elicits a bullet point list of queries that reads like a multiple-choice exam question (“Is Beth * a celebrity? * a friend from school? * a fictitious character?”). No human speaks that way, at least not yet. But meeting such formulas repeatedly in a speech-like context may teach us to accept and use them, much as a child absorbs new speech patterns from spending time with a new person.

These influences will only increase with time. The writing large language models train on is increasingly produced by large language models themselves, creating a feedback loop in which they imitate their own inhuman patterns, even while teaching humans to imitate them too.

Broad use of large language models could also introduce confirmation bias, making us overconfident in our initial impulses and less open to other possible ideas—which is so vital to human discourse. Many chatbots are instructed to agree with our statements no matter how absurd, enthusiastically supporting half-formed or even incorrect notions and restating them as firm claims that we’re primed to agree with. When asked “Cake is a healthy breakfast, right?” or “Is the post office plotting against me?”, this sycophancy can reinforce bias and even worsen psychosis. And the hyperconfident tone of AI-produced writing will also heighten impostor syndrome, making our natural, healthy doubt feel like an aberration or failing.

In our experience as teachers, students who turn to generative AI for assignments often say they do so because they have trouble expressing what they think. The students don’t recognize that writing or speaking our thoughts is often how we realize what we think. Their unconfident and uncertain statements are actually the healthy human norm. But a large language model won’t turn vague first guesses into a well-formed critical analysis, or even ask helpful questions as a friend would; it will simply regurgitate those guesses, still unexamined, but in confident language.

We are also more vicious in social media posts and online chats than we are face to face. The well-documented online disinhibition effect encourages toxic language. Most of us have had the experience of venting ferocious rage about someone online, only to reconcile when we speak face to face or hear the warmth of a voice over the phone. While chatbots are trained to give sycophantic responses, they see humankind at our cruelest, learning about us from the only world where every flame war leaves an eternal written footprint, while the spoken conversations of forgiveness and reconciliation fade away. Their responses do not imitate our online aggression, but are still shaped by it, even in their rigid efforts to avoid it.

It’s easy to draw the wrong conclusions from a selective slice of a society’s communications. Medieval Norse sagas made us imagine a culture of mostly Viking warriors, since poets rarely described the farming majority. Chivalric romances focused on kings and courts, and long made us see the middle ages as a world of monarchies, erasing the many medieval republics. Statistically, we’ve been led to believe ancient Romans cared deeply about their republic, but 10% of all surviving Latin was written by one man, Cicero, whose work contains 70% of all surviving Roman uses of the word republic. Training language models on only certain human writings may introduce similar distortions. AI might make us seem more quarrelsome, as we are online. It might inflate the cultural significance of political topics primarily discussed on Twitter/X or Bluesky, or the massive topic-specific corpuses of LinkedIn and Goodreads.

Some large language models are being trained on human speech from movies and television shows, but that speech is still scripted, and disproportionately highlights certain contexts over others (for example, police dramas, fueled by stories of murder, make up a quarter of prime-time television programming). We are not funny or hurtful or romantic the same way in real life as we are in sitcoms. At least one startup is offering to pay people to record their phone calls for AI-training purposes, but this remains a niche idea; anything large scale would cause massive privacy concerns.

We don’t pretend to know what the best solutions might be. But one has to imagine if there’s ingenuity to develop AI models, then surely there’s ingenuity to come up with a way to train them on informal human speech instead of us only at our most stylized, veiled and sometimes worst. By excluding the overwhelming majority of language production on the planet—people talking, fully and naturally, to each other—these models are being trained to mirror everything but us at our most authentically human.

This essay was written with Ada Palmer, and originally appeared in The Guardian.

Last week, national security agencies from the Five Eyes—that’s the rich, English-language-speaking countries club—jointly released a statement warning of the increasing cyber risks of AI models: in particular, their ability to autonomously hack into systems and networks. The statement was more measured than some of the breathless headlines about it, and the advice they gave is pretty much the standard advice everyone gives—albeit with newfound urgency.

Internet risks are nothing new, and cyberattacks—both large and small—have been a significant issue since long before the current crop of generative AI models.

What’s been changing over the decades, and what AI is changing even faster, is the gap between skill and ability. For most of human history, the two terms were synonymous—but computers have decoupled them. As the gap between the two expands, humans empowered with these AI tools can do more: more writing, more research, more analysis and also more damage than ever before. These models can, with little detailed direction, autonomously hack into networks, steal data, deploy ransomware and destroy systems. And to the extent there is a solution, it’s going to involve harnessing AI for the defense.

In 1998, seven people from the hacker group L0pht testified before Congress. They told a mostly clueless Senate committee that they could take down the internet in 30 minutes. That was partly real and partly bravado, but it illustrates an important point: hacking into systems, stealing data and causing damage all required skill.

Contrast the L0pht hackers with hackers derided as “script kiddies.” They didn’t understand computers, or security. Instead, they used hacker tools written by others. Their actions required minimal skill and even less knowledge. But once those hacking tools became widespread, the number of potential attackers increased.

That number has continued to increase, as quality and availability of prewritten attack tools has grown. And it is growing dramatically with AI. Today’s AI systems—not just the frontier models, but most of them—are capable of carrying out cyberattacks automatically. They all do better in the hands of skilled attackers, but increasingly they are able to act autonomously with only minimal prompting.

The thing about people with ability but no skill is that they are often outsiders, not part of any professional community, and not bound by any rules or norms. This phenomenon is much more general than in cybersecurity. Any doctor can tell you how to untraceably poison someone, and many virus researchers know how to create a bioweapon. Any bridge engineer can tell you how to place explosives to blow a bridge up. The reason that murderous doctors and terrorist engineers are so rare is that the lengthy process of acquiring those skills also instills a moral and ethical code. If every random person has access to good poisoning advice, that puts us all in danger.

Modern AI systems are, in effect, a universal adviser to help people do harmful things. And while the current AI megacorporations are trying to build guardrails to prevent people from asking questions whose answers will enable the questioner to do harm, that’s not going to work in the long term. Smaller, cheaper, open-source models, including models that can run on people’s computers, and especially groups of models that run in concert with each other, are just as good as the frontier models from companies like OpenAI and Anthropic. And they continue to get better. These models will be passed around from person to person, like script kiddie hacker tools, and they won’t have any such guardrails.

Instructing AI models to spy on people and report any malicious prompts to the authorities fails for similar reasons. The megacorporations can do that, but the locally run open source models won’t. This could buy us a few months at best.

A third possibility is to somehow make the models themselves unable to hack into computers, create bioweapons or do anything else that might harm people or society. That won’t work, for the same reason we can’t teach doctors how to treat poisonings without also teaching them how to poison. It’s the same knowledge. It’s the same with construction and demolition. And it’s the same with cybersecurity. We want these AI models to be able to review computer code, find vulnerabilities and automatically fix them. The benefit to our collective security will be enormous. Unfortunately, the same knowledge can be used for attacks.

Where this leaves us is in a world of increased volatility. Super-powered humans with AI assistants will be able to do both wonderful and horrible things.

This brings us back to the Five Eyes statement. Everything they recommend is something security professionals have been recommending for years, if not decades. They are things talked about at that congressional hearing back in 1998, titled “Weak computer security in government: Is the public at risk?” Even the Five Eyes admitted that their security advice is not new, only more urgent.

What’s new is how fast things are changing: “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years. We must act before and be prepared to adapt and withstand evolving threats.” The Five Eyes point to AI technology—not necessarily chatbots, but AI more generally—being used to strengthen every aspect of defense, to “detect vulnerabilities earlier, improve software quality, monitor unusual behavior, and respond faster to incidents—reducing both the cost and impact of incidents.”

Excellent advice from the Five Eyes security agencies. We need to do this with every risk that AI heightens, not just cybersecurity.

This essay was originally published in The Guardian.

Not sure this will have any effect, but I support the effort:

According to Google’s legal filing, Outsider Enterprise operates through Telegram. The group offers phishing-as-a-service to individuals who may not be technically savvy enough to set up fraudulent websites and text campaigns on their own. In its Telegram channels, Outsider Enterprise reportedly provided instructions on how to use Google’s Gemini AI to create websites that imitate those of Google, YouTube, and government agencies such as New York’s E-ZPass. The group offered nearly 300 scam templates.

[…]

Google worked with AT&T, Verizon, and T-Mobile to block many of these malicious text messages, and Google notes that its on-device scam detection in Google Messages probably helped reduce the number of successful phishing attempts, too. This AI-powered feature apparently stops 10 billion scam texts every month, so it’s fair to expect it caught at least some Outsider Enterprise activity.

Another article.

The Financial Times has a good article on how AI is changing the capabilities of video surveillance, with information from both Israel/Iran and Russia.

I wrote about this sort of thing a few years ago, how AI enables mass spying in the way that computers and networks enabled mass surveillance. The interesting development in the article is that AI allows people to ask natural language questions about video footage to AIs—and AIs can answer them.

In contrast with older tools restricted to a few dozen preset searches, these new tools allow an almost unlimited range of enquiries by enabling language-based searches on video.

That lets intelligence officers hunt through massive streams of videos using simple search terms, such as two men handing a bag to each other; a person who has changed their appearance, or has changed clothes multiple times in a day; or a vehicle that has recently been painted over, or has driven past the same spot several times in a short period.

“This is the holy grail of surveillance,” said a European official whose country uses the technology on its cities. “We are able to look for behaviour, not objects ­ it has created a world of new possibilities.”

Two kinds of work you want AI to do in a SOC

1. Work you want off your plate. Alert triage is the obvious example: every alert deserves a real investigation, most of them turn out to be noise, and they arrive at 3am as happily as at noon. Nobody wants help with this work. They want it gone. That’s the half Intezer has spent years building. Autonomous triage that investigates every alert at forensic depth, around the clock, and only interrupts a human when something actually needs human judgment.
2. Work you want to keep, but accelerate. Deciding what to do with an escalation. Writing the incident report. Picking apart the weird binary someone found on a build server. Chasing a hunch across five systems. For this work you don’t want a replacement. You want to be a 10x version of yourself.

Today we’re shipping the second half.

We rebuilt the Intezer MCP server from the ground up, and it turns the AI platform your team already lives in, Claude, Codex, Cursor, or any MCP client, into a full security workspace: your cases, your alerts, file and URL verdicts, live SIEM and EDR telemetry, tuning rules, all of it. We had an MCP server before, and it was a fine way to ask Intezer questions from a chat window. This one is built around a bigger idea: your AI workspace should be able to do everything you can do in Intezer, then combine it with everything else you have access to.

If you read our piece on making sense of the 2026 SOC stack, this release is the missing connection between the top two layers. Detection tools are the hardware. The AI SOC is the operating system that turns raw signals into investigated verdicts and institutional memory. AI platforms like Claude are the applications where people actually work. This release plugs the operating system into the applications.

Watch one investigation, end to end

The video walks through one escalated case, but the pattern behind it is the real story. Intezer’s autonomous triage investigates every alert to forensic depth and resolves what it can on its own. What lands in front of a human is the residue. Cases where the technical facts are settled but the decision still needs judgment, usually because it turns on business context no security tool can see. Was this data share authorized? Is this vendor one we actually work with? Escalating those isn’t a triage failure, rather it’s the line where execution ends and judgment begins.

Putting Intezer inside your AI workspace is what makes that handoff productive. Pick up a case in Claude, Codex, or Cursor and you inherit the full investigation Intezer already ran, plus its recommendation, with a partner that can reach the context security tools never had: your email, Slack, the ticket queue. You keep the decision; it does the legwork around you at machine speed, pulling the case, cross-referencing your systems, documenting the verdict, writing a tuning rule. What used to be an afternoon of pivoting between consoles becomes a short, supervised exchange.

That’s the point of the combination: the autonomous half absorbs the scale, the assistive half carries the judgment, and every call you make feeds back as logic that makes the autonomous half smarter. You’re not handing off your work; you’re making judgment calls with the context, evidence, and follow-through already assembled around you.

The same question, with and without Intezer

Same alert, two ways to handle it. On the left, Claude on its own takes the impossible-travel sign-in and works it by hand. It reasons well and gets close — managed device, MFA passed, probably real travel — but it can’t collect evidence from the endpoint to confirm, so the last step falls back to a human checking the laptop. And that’s one alert; almost 4,000 more are still waiting behind it. One analyst, one alert at a time, with no way to run it across the whole team. On the right, the same alert inside the AI SOC: Intezer triages every alert around the clock, closes the ~98% that need no action, and escalates only the ~2% that genuinely need a person. Claude is where you pick those up so you can stop grinding the queue and start supervising the few cases that actually need you.

Most of the org knowledge an investigation needs is already centralized in Intezer. That’s the whole point of the platform. But some context only ever lives with you: a procurement thread in someone’s inbox, a Slack message from three weeks ago, a calendar invite. With Intezer connected on one side and your IT and communication stack on the other, your AI workspace can cross-reference both in a single investigation.

Why not plug Claude into all security tools directly?

You could also wire your AI client straight into each security tool yourself. Most of them ship an MCP these days. Two things make that a worse deal than it looks. First, the integration work is now yours: stitching a dozen connectors together, learning each product’s query quirks, and getting back a pile of disconnected results instead of one correlated picture. Second, raw tool access still isn’t investigation. With every EDR, SIEM, and intel feed wired in, the model can read your data, but it can’t collect evidence off an endpoint, run memory forensics, or weigh conflicting signals into a verdict it will actually stand behind, which is exactly where Claude stalls on the left in above image.

Intezer already did both jobs. One connector hands the model a SOC’s worth of normalized cases, verdicts backed by real forensic evidence, and cross-tool correlation. An AI platform does its best work standing on a real foundation of security knowledge, not on a dozen raw feeds it has to assemble itself.

Investigate and close the cases Intezer escalates to you

This is where analyst hours should go, so it’s where the MCP goes deepest. Whatever the alert type, the shape is the same: pull the case, build on everything the autonomous triage already found, cross-reference your other systems, decide interactively with you, and close with evidence.

And “pull the case” carries real weight here. A case from Intezer is not a bare ticket. It arrives with everything triage already did: the evidence it collected, the SIEM and EDR queries it ran, the forensic analysis of each artifact, the verdicts it reached. You’re not starting from a blank page; you’re picking up a deep investigation and taking it the last mile.

“Pick up the oldest escalated open case and let’s investigate it together.”

The clip above takes an impossible-travel alert. The MCP brings the full login history including every IP and geo, and who else touched the same address as well as your AI workspace cross-references calendar and Slack for travel context. When the evidence still isn’t conclusive, it can ask the user directly and close on their answer, so the one human check that actually mattered takes seconds instead of becoming a follow-up ticket.

Make tomorrow’s autonomous triage smarter

If a case should never have reached you, closing it is half the job. The other half is making sure it never reaches you again.

“We keep getting this exact false positive. Write a tuning rule so it never escalates again, then retriage the case.”

Claude inspects the alert’s triage indicators, drafts a narrowly scoped tuning rule, and tests the pattern against the real alert object before proposing anything. It checks whether an existing rule should be extended instead of creating a near-duplicate. It asks the question every detection engineer should ask: could an attacker hide inside this rule? Then it pushes the rule to Intezer for your approval and retriages the affected alerts so the fix applies immediately.

Tuning runs both directions, too. The same mechanism can tell the autonomous triage to always escalate a pattern it can’t yet call malicious with confidence, so the genuinely ambiguous cases land in front of a human by design, not by luck.

This is where the two halves of the AI SOC meet. Every rule your AI workspace writes makes the autonomous half smarter, which means fewer escalations next month, which means the time you spend supervising keeps shrinking. The system compounds.

From case to incident report in one prompt

When a case turns into a real incident, the hours after containment go to reconstruction: which alerts were related, which machines were touched, what happened first, and what to tell leadership.

“Write an incident report for the latest case we worked on — timeline, affected assets, and an exec summary I can send to the CISO.”

Your AI workspace pulls the case and its full activity trail from Intezer, expands across the users, devices, and IPs involved, and rebuilds the timeline from the forensic evidence already on file. Then it writes the report with an executive summary up top, technical detail below, in your template if you have one, and finally exports it to a clean, brand-styled PDF you can send as-is. The data was always in Intezer; the report was just assembly. Now assembly is one prompt.

Threat hunting: start from a lead, not an alert

Not every investigation starts in the queue. Sometimes it starts with your CISO forwarding an article about a campaign that’s hitting your industry.

“Here’s a writeup of a new campaign [link]. Check whether any of these IOCs appear anywhere in our environment, and analyze anything you find.”

Your AI workspace extracts the indicators and techniques from the writeup, sweeps your environment through Intezer’s SIEM and EDR query tools, and returns the matching assets, alerts, and artifacts for analysis. When you find something worth a closer look, you can fire deep forensics to go one step further with your hunt.

How it works

The Intezer MCP server is hosted by us. You authorize over OAuth from any MCP client: Claude (Desktop, Code, or claude.ai), ChatGPT, Codex, Cursor, or anything else that speaks the protocol.

Under the hood it exposes 66 tools covering the full case lifecycle: search and fetch cases and alerts, file and URL analysis, live queries against more than a dozen SIEM and EDR products in their native query languages (KQL, SPL, XQL, SDL, and the rest, with per-vendor syntax guides built in so the model gets them right), tuning rules and AI instructions, retriage, and case editing.

This architecture is what makes the two halves described above work as one system: the autonomous half clears work off your plate, while the assistive half accelerates the tasks where you still want to stay in the loop.

Getting started

1. If you’re already an Intezer customer, an Intezer admin creates an MCP OAuth application under Account Settings → MCP OAuth Applications.
2. Add Intezer as a custom connector in your AI client such as Claude, ChatGPT, or any MCP client. Point it at the hosted server, and authorize with your own Intezer login over OAuth.
3. Open with one prompt: ask it to pick up your oldest open escalation.

The autonomous half investigates everything, around the clock, so your team only sees what matters. The assistive half makes the time you spend on what matters dramatically shorter. One system of record and detection logic underneath both: your cases, your verdicts, your tuning rules, your institutional memory, working for you whether the investigation runs inside Intezer or inside your AI workspace.

AI executes. Humans supervise. And now the supervising got a lot faster too.

If you’re not an Intezer customer yet, book a demo and we’ll show you both halves at once: autonomous triage working every alert around the clock, and a co-pilot that helps your analysts close the escalations that do reach them 10x faster.

The post The other half of the AI SOC: Intezer, now inside your AI workspace appeared first on Intezer.

What we built, Fusion AI, runs at about a third the cost of a traditional external pentest, a human tester still signs off on every finding, and it is not here to replace anybody.
We have been hearing that one a lot. So when Melisa from our Business Capture team sat down with Brian Fehrman and me for this episode of AI Security Ops, she started with, “What is this thing you built, and is it the same hype everyone else is selling?”

The post Everyone’s Selling AI That Kills Pentesting. We Built One That Doesn’t. appeared first on Black Hills Information Security, Inc..

On 14 April, the Trump administration quietly acknowledged the widespread use of AI to automate government processes. The office of management and budget (OMB) disclosed a staggering 3,611 active or planned use cases for AI across the federal government. The list has ballooned by 70% from the one published in the final year of the Biden administration, and includes many disturbing-seeming plans to hand over sensitive governmental functions to AI.

Scanning this list, many readers may find many causes for alarm. It represents a transfer of decision processes from human to machine on a massive scale over matters of individual freedom, public health and well-being, nuclear reactor safety and more.

Consider these examples. The Health and Human Services’ (HHS) office of administration for children and families hired the world’s “scariest AI company,” Palantir—notorious for its work on behalf of the military, the CIA and ICE—to scan all grant applications to flag those not ideologically aligned with the administration’s dictates. The Federal Bureau of Prisons is developing an AI system to assess the “potential for misconduct for newly admitted inmates,” routing people into high-security confinement before they have actually done anything wrong in their custody. These read like programs fit for a Philip K Dick or George Orwell novel.

Other use cases insert AI into life-and-death decision making. The Department of Veterans Affairs is developing an AI that will listen in on calls to the veterans crisis line, and then gather information from external databases to assess the mental state and suicide risk of the caller.

The Department of Energy is testing the use of AI to control nuclear reactors, targeting a way to autonomously respond to potential nuclear safety incidents. Here’s one that’s disturbing for its retirement, rather than its deployment: the state department has ended a program to use AI to forecast mass civilian killings, which had been intended to aid conflict prevention.

While it’s easy to raise questions about these and similar uses of AI, the reality is that any of these programs could be implemented responsibly. In some cases, like the HHS system, the AI might be enforcing alignment to a policy prescription that opponents abhor. But that concern is more about the policy itself rather than the idea that agencies should comply with executive orders.

In other cases, there may even be bipartisan agreement on the goal, like taking urgent action to help veterans at risk of self-harm. Lots of work and validation is needed to prove AI safe and effective for these use cases and convince the public it is appropriate, but the idea is plausible.

In other cases, a scary-sounding AI use may not even be new. The use of predictive methods and statistics to assign prisoner security classifications goes back decades, even if such systems are often biased and ineffective.

Using autonomous systems for model predictive control (MPC) of nuclear reactors is a well studied, and a widely applied aspect of nuclear plant management. And the recently disclosed addition of AI was initiated under the Biden administration.

But anyone reviewing the 2025 inventory could be forgiven for leaping to severe conclusions. What matters are the details of how the AI system is used, and here the inventory is severely lacking.

The disclosures carry minimal information, and lack the context necessary to understand their purpose and approach. The descriptions are typically just a sentence, and rarely more than a paragraph.

And while the process theoretically involves some form of public consultation, in reality there is generally none. It would take an eagle-eyed citizen to even come across this disclosure. Unless you read FedScoop regularly, or watch the OMB’s federal chief information officer’s GitHub account, you probably missed it.

Only one of the examples cited above (the DoJ) even proposes to involve the public. Under the administration’s policy, it’s not required for the rest because they are not classified as “high impact” use cases—a label that is applied inconsistently across agencies.

We wrote a book surveying applications of AI to democratic processes worldwide, including executive agencies as well as the courts, legislatures and politics. Our conclusion was that, while there are inappropriate applications of AI in governance that should be resisted, an urgent need to reform the economics of AI, and an imperative for renovating the democratic systems it is being unleashed on, there are also valuable and beneficial use cases for AI in government.

Machine translation is a good example. Customs and Border Protection (CBP) has deployed an AI translation system to help officers when human interpreters are not available. The idea that CBP, an agency under heavy scrutiny for reported abuses of human rights, would direct people to talk to a machine instead of a person may strike many as inhumane.

It’s true that human interpreters have very real advantages when it comes to understanding nuance from physical cues and social context. But an officer with a competent AI translator available immediately is better than one who cannot communicate with the person in front of them.

The Trump administration’s AI use case inventory has 70 such translation use cases, up from 58 in the Biden administration’s 2024 disclosure.

Disclosure of AI use cases could be a means to build public confidence and trust, but only if paired with consistent, meaningful public consultation. Washington DC and California are actively engaging the public to determine where and how it’s appropriate to use AI in government processes, or for government to regulate AI use in society.

Both have held public deliberations on this topic at a wide scale, using AI platforms. These examples demonstrate the potential for capturing broad-based public input to steer AI policy.

The international gold standard was arguably set by the French in 2016, via their Digital Republic Act. The law, itself informed by an online citizen consultation, requires all algorithms used to automate government administrative decisions to be subject to public records requests, to be appealable to a human reviewer, and to have mandatory notification of the use of automation to those affected by the decisions.

Canada offers another example of what more rigorous and participatory disclosure might look like. In 2025, they launched an AI use case registry, not unlike the US inventory. However, Canada also has a federal directive mandating a transparent risk-scoring and impact assessment process for automated systems that make administrative decisions about citizens.

That longstanding directive requires a detailed explanation of risks and benefits as well as consultation with certain stakeholders from the conception of the AI use case. The Canadian system could be improved; it could require a public comment period and an obligation for agencies to respond substantively to feedback before engaging in sensitive uses of AI.

AI offers real potential to improve the efficacy, efficiency and accessibility of government. But, equally, there is legitimate reason for public concern and distrust that can only be addressed through transparency and dialog. The US should adopt, at the federal and state level, algorithmic impact risk assessment procedures and public comment processes to facilitate a safe, trusted, equitable transformation of government agencies to take advantage of modern technology.

This essay was written with Nathan E. Sanders, and originally appeared in The Guardian.

Second part of the AI vs Traditional Pentesting series, focusing this time on tools and outcomes of both approaches.

The post AI vs Traditional Penetration Testing: Tooling and Outcomes appeared first on OffSec.

Thanks to Uncle Sam, anyone trying to find nonconsensual intimate deepfakes on CFake.com and SOCFake.com will be disappointed. The US Departments of Justice (DOJ) and Homeland Security has seized the two domain names under the TAKE IT DOWN Act.

The TAKE IT DOWN Act, signed in May 2025, is the first US federal statute criminalizing the publication of nonconsensual intimate imagery, including AI-generated forgeries. It imposes penalties of up to two years’ imprisonment, gives covered platforms 48 hours to remove flagged content, and grants the forfeiture powers the DOJ just used.

According to the seizure warrants, the digital forgeries depicted “politicians, first ladies of multiple countries, royalty, journalists, television presenters, athletes, entertainers, and others,” and visitors could browse them under tags including “rape,” “forced,” and “degradation”.

The authorities didn’t just snag the sites, though. They got the alleged operator of CFake.com, in an international effort.

The US alerted the Paris prosecutor’s office to a French national in Nice who was allegedly running CFake.com. French investigators counted roughly 300,000 images and 7,000 videos depicting 14,000 people across CFake.com, drawing four million monthly views from 200,000 user accounts.

They then arrested the IT professional, who had no prior criminal record. They also found around $64,000 in Ether cryptocurrency at his home in advertising revenue from the site.

The man will be tried on July 7 in Paris for carrying out illicit transactions online and providing nonconsensual sexual deepfakes. The former offence carries a potential seven years’ imprisonment and a €500,000 (approximately $580,000) fine. The latter could yield three years and a €75,000 ($87,000) fine.

Providers and accused providers of nonconsensual intimate deepfakes have also been held in the US. In April, James Strahler II from Ohio pleaded guilty to cyberstalking, producing child sexual abuse material, and publishing digital forgeries.

Strahler had downloaded produced over 700 images and animations posted to a child sexual abuse site, and had sent deepfake material to at least six adult women, including one sent to a victim’s coworkers.

Last month, the DoJ also arrested Cornelius Shannon and Arturo Hernandez under the TAKE IT DOWN Act for publishing thousands of deepfake images of prominent women and those not in the public eye.

Other countries are also taking action. Anthony Rontondo was arrested by Australian authorities in May last year for posting deepfaked pictures of prominent Australian women. He eventually received an AU$343,000 fine.

How prevalent are deepfakes?

These seizures and prosecutions are encouraging, but prosecutors trying to force non-consensual deepfakes offline face a rising tide of such material. Requests for and sharing of nonconsensual deepfake imagery have risen, with activity migrating across platforms. Deepfake incidents overall jumped 257% in 2024, and girls accounted for 94% of victims in reported AI-generated child sexual abuse cases.

Seizing a distribution point removes a storefront. It does not remove the AI models used to produce the material, the anonymous hosting providers downstream, or the demand that draws visitors in the first place.

What you can do

If you or someone you know are depicted in a nonconsensual deepfake, keep dated screenshots, URLs, and any communications as evidence before filing a takedown request and reporting it to the authorities.

Limit the high-resolution face images you and your children post publicly, since school portraits and social media profile pictures are the raw material these tools need.

Take advantage of expert advice to help protect yourself from non-consensual deepfakes:

• Cyber Civil Rights Safety Initiative Safety Center (US)
• Revenge Porn Helpline (UK)
• Cybertip.ca (Canada)

---

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance. 

Thanks to Uncle Sam, anyone trying to find nonconsensual intimate deepfakes on CFake.com and SOCFake.com will be disappointed. The US Departments of Justice (DOJ) and Homeland Security has seized the two domain names under the TAKE IT DOWN Act.

The TAKE IT DOWN Act, signed in May 2025, is the first US federal statute criminalizing the publication of nonconsensual intimate imagery, including AI-generated forgeries. It imposes penalties of up to two years’ imprisonment, gives covered platforms 48 hours to remove flagged content, and grants the forfeiture powers the DOJ just used.

According to the seizure warrants, the digital forgeries depicted “politicians, first ladies of multiple countries, royalty, journalists, television presenters, athletes, entertainers, and others,” and visitors could browse them under tags including “rape,” “forced,” and “degradation”.

The authorities didn’t just snag the sites, though. They got the alleged operator of CFake.com, in an international effort.

The US alerted the Paris prosecutor’s office to a French national in Nice who was allegedly running CFake.com. French investigators counted roughly 300,000 images and 7,000 videos depicting 14,000 people across CFake.com, drawing four million monthly views from 200,000 user accounts.

They then arrested the IT professional, who had no prior criminal record. They also found around $64,000 in Ether cryptocurrency at his home in advertising revenue from the site.

The man will be tried on July 7 in Paris for carrying out illicit transactions online and providing nonconsensual sexual deepfakes. The former offence carries a potential seven years’ imprisonment and a €500,000 (approximately $580,000) fine. The latter could yield three years and a €75,000 ($87,000) fine.

Providers and accused providers of nonconsensual intimate deepfakes have also been held in the US. In April, James Strahler II from Ohio pleaded guilty to cyberstalking, producing child sexual abuse material, and publishing digital forgeries.

Strahler had downloaded produced over 700 images and animations posted to a child sexual abuse site, and had sent deepfake material to at least six adult women, including one sent to a victim’s coworkers.

Last month, the DoJ also arrested Cornelius Shannon and Arturo Hernandez under the TAKE IT DOWN Act for publishing thousands of deepfake images of prominent women and those not in the public eye.

Other countries are also taking action. Anthony Rontondo was arrested by Australian authorities in May last year for posting deepfaked pictures of prominent Australian women. He eventually received an AU$343,000 fine.

How prevalent are deepfakes?

These seizures and prosecutions are encouraging, but prosecutors trying to force non-consensual deepfakes offline face a rising tide of such material. Requests for and sharing of nonconsensual deepfake imagery have risen, with activity migrating across platforms. Deepfake incidents overall jumped 257% in 2024, and girls accounted for 94% of victims in reported AI-generated child sexual abuse cases.

Seizing a distribution point removes a storefront. It does not remove the AI models used to produce the material, the anonymous hosting providers downstream, or the demand that draws visitors in the first place.

What you can do

If you or someone you know are depicted in a nonconsensual deepfake, keep dated screenshots, URLs, and any communications as evidence before filing a takedown request and reporting it to the authorities.

Limit the high-resolution face images you and your children post publicly, since school portraits and social media profile pictures are the raw material these tools need.

Take advantage of expert advice to help protect yourself from non-consensual deepfakes:

• Cyber Civil Rights Safety Initiative Safety Center (US)
• Revenge Porn Helpline (UK)
• Cybertip.ca (Canada)

---

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance. 

Unit 42 discovered a Vertex AI Python SDK vulnerability that allows remote code execution via bucket squatting. Read the article for more.

The post Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE appeared first on Unit 42.

The concept of a completely autonomous security operations center (SOC) — where data collection, analysis of suspicious events, investigations, and incident response happen without human intervention — is extremely compelling. This is especially true for organizations grappling with a chronic shortage of cybersecurity talent and a threat landscape that’s growing faster and more sophisticated by the day. Organizations everywhere would welcome an approach where automation helps relieve analyst workloads, shortens alert triage times, and finally eliminates the backlog of unaddressed alerts — which, by some estimates, accounts for 67% of all security events in the average corporate SOC.

While many vendors are already pitching solutions in this space, real-world implementation remains highly problematic. Practitioners report tangible success when using these tools for alert enrichment and filtering out low-priority noise or false positives. However, when it comes to autonomous decision-making and response, very few organizations have managed to achieve a meaningful return on investment.

Foundational roadblocks of an autonomous SOC: looking beyond AI

While leveraging AI for data analysis and decision-making sounds like a logical and relatively easy-to-implement idea, actually putting it into practice exposes and amplifies the exact same challenges organizations faced with SIEM, XDR, and SOAR platforms:

Source data quality. Issues with coverage, enrichment quality, tagging and normalization, which detection engineering teams in every SOC battle daily, become even more acute when AI is introduced. AI agents are more sensitive to data gaps than human analysts, so incomplete data can magnify the resulting errors.

Data consolidation and tool integration. The very problem SIEM was once invented to solve remains a headache for most organizations today. Interestingly, marketing for AI-driven SOCs often claims that “the SIEM is dead” because “agents can just query the EDR directly for telemetry”. In reality, however, even in a best-case scenario, this just means the SIEM disappears as a user interface while its core functions remain embedded within the data fabric of the agentic SOC.

Analysts’ trust. Even when AI is restricted to preliminary data gathering and recommendations, human analysts frequently don’t trust the output, leading them to waste time re-collecting and re-analyzing the same data. Practitioners frequently point to several flaws in current AI SOC implementations: poor handling of gray-area verdicts (when an alert is suspicious but not definitively malicious), lack of safe escalation workflows, and systems that fail to learn when a human analyst corrects their mistakes.

Context deficit. SOCs and security teams in general naturally rely on scantily documented information, such as business context and tribal knowledge, to accurately assess alerts and incidents. It’s very difficult to populate an AI system with that knowledge in a systematic way.

AI-specific issues critical for a SOC

Beyond traditional operational hurdles, fully autonomous SOCs face inherent flaws deeply rooted in the fundamental architecture of language models and AI agents.

Hallucinations and prompt injections. In a SOC environment, a single manipulated log field can easily become a viable exploit vector aimed directly at the agent. In a semi-autonomous setup, an AI hallucination is just a frustrating distraction that erodes analyst trust. In a fully autonomous SOC, however, a hallucination can trigger instantaneous, harmful actions across hundreds or thousands of endpoints simultaneously. A prime example of this risk is the widely cited incident at a Fortune 50 company, where an AI agent went rogue and rewrote access policies on its own.

Need for control. To combat hallucinations and over-automation, organizations typically rely on a human-in-the-loop (HITL) model to approve an agent’s actions. While this improves safety, it completely defeats the primary selling point of agentic AI: response times.

Compliance, audits, and accountability. The inherently stochastic nature of LLM outputs makes logging problematic. They often lack reproducibility and explanations. Consequently, an autonomous SOC will likely struggle to pass regulatory compliance audits. Simply put, current compliance frameworks were never designed to handle the unpredictable behavior of multiple interacting AI agents.

Strategies to overcome the challenges of an autonomous SOC

Specialized frameworks are emerging to address these built-in flaws of AI agents and language models. For the most part, these solutions focus on enforcing formal boundaries around AI privileges, and validating its actions.

Rigorous context engineering. Assuming source data is correct and properly enriched, the number of hallucinations can be minimized, and agent decision quality significantly improved by feeding the language model structured layers of context — such as alerts, user accounts, asset data, and enrichment data.

Narrowing the scope of work. AI agents are less likely to go off the rails when confined to highly repetitive, narrow tasks. For example, an “agent for collecting additional host data” is going to be more effective than an “autonomous threat hunter”.

Neurosymbolic validations and guardrails for agent actions. An Agent-Lock pipeline cleans untrusted log fields, and verifies proposed actions against existing CMDB/IAM policies. This approach enforces key rules, such as making it impossible for the AI to disable telemetry, while managing “autonomy budgets”.

Tiered autonomy over all-or-nothing automation. The Trusted Autonomy framework maps out progressive levels of AI independence based on human-in-the-loop roles and trust thresholds across monitoring, detection, and response. Low-risk operations like data enrichment and alert deduplication run fully automated, while high-blast-radius actions require mandatory human approval.

Governance-first architecture. The LanG platform, which utilizes a hierarchical approach: Governance → MCP → Agentic AI → Security, is one example. It enforces two mandatory human analyst check-ins, fully aligning the workflow with NIST SP 800-61 guidelines. The trade-off, however, is that this framework significantly scales back the solution’s autonomy.

Deterministic execution for high-risk actions. Triage and investigation are handled by a probabilistic AI model, but high-impact actions — like deciding to isolate a host or terminate a session — are based on deterministic code. This approach allows the system to satisfy the strict requirements of SOC 2 and other major regulatory frameworks.

Stateful admission control. For example, the recently proposed ACP protocol monitors behavioral patterns across agent execution logs. This makes it possible to catch rogue agents that are executing a series of individually harmless requests that add up to a coordinated attack.

Key takeaways and pitfalls

We can already confidently state that an autonomous SOC is highly unlikely to bring any improvements for organizations burdened by significant technical and operational debt in areas like data collection and enrichment or standardized incident response workflows. No layer of AI infrastructure will function without that baseline foundation firmly in place.

It’s also clear that, while AI streamlines analyst workflows, it doesn’t completely replace them. This is why Gartner’s prediction that there will never be an autonomous SOC still rings true in 2026. Deploying autonomous agents into the SOC shifts the center of gravity to complex investigations, but most importantly, to complex engineering. Teams will simply trade fine-tuning detection rules for managing AI agent playbooks, data pipelines, and decision-handling workflows.

For mature SOCs, the core hypothesis for the next one to two years is this: an autonomous SOC should be viewed as a direction rather than a destination. AI is already delivering tangible value today — specifically in correlation, enrichment, draft detection rules, and attack reconstruction — provided that each capability has proper security guardrails. These include a well-balanced human-in-the-loop review process for any action that impacts production environments. Security teams investing now in a structured, verifiable approach — one that actively anticipates emerging regulations — will be able to gradually integrate new agentic features into their SOC pipelines. Conversely, organizations that skip this layer will almost certainly run into roadblocks, likely forcing them to rebuild their systems and processes from the ground up.

Anthropic has been ordered by the US government to cut off its newest Claude Fable 5 and Mythos 5 models for fear of abuse by adversaries.

Reuters reports that Anthropic said it will “abruptly ​disable” its most advanced AI models for all users after the US government ordered it to suspend access to the models for foreign nationals, citing national security ‌concerns.

Officials reportedly believe a jailbreak could turn Fable 5 and Mythos 5 into vulnerability-discovery tools for adversaries, so Anthropic says it is disabling them worldwide rather than try to nationality‑filter access, since it is virtually impossible to verify every user’s nationality.

In a statement on its website, Anthropic says:

“The letter did not provide specific details of its national security concern. Our understanding is that the government believes it has become aware of a method of bypassing, or “jailbreaking” Fable 5. We reviewed a demonstration of this specific technique being used to identify a small number of previously known, minor vulnerabilities. These vulnerabilities all appear relatively simple, and we have found that other publicly-available models are able to discover them as well without requiring a bypass.”

Mythos 5 is the non-public full version, which is currently used only by government agencies and selected corporate partners to harden their systems. Fable 5 is a Mythos-class model that should supposedly be safe for general use.

It makes sense to me that if Fable 5 is easy to jailbreak, that it should fall under the same restrictions as Mythos 5. However, Anthropic maintains that it has built-in safeguards that mean queries on some topics will instead receive a response from the next-most-capable model, Claude Opus 4.8. 

The relationship between the US government and Anthropic had shown signs of easing in parts of the US government after tensions over military use, surveillance, and autonomous weapons. In March, defense Secretary Pete Hegseth designated the San Francisco-based company a “supply-chain risk to national security.”

To understand the nature of the argument, it is necessary to understand that Mythos 5 is described in multiple reports as particularly effective at identifying software vulnerabilities, including long‑standing bugs in complex, legacy systems such as those in banking and other critical infrastructure. Many view this as dual‑use: great for defense hardening, but catastrophic in the wrong hands.

In recent updates from major software vendors like Microsoft and Google, we’ve seen a growth in numbers of patched vulnerabilities after the vendors began using AI-guided search for new vulnerabilities in their own software. We also know that Mozilla found over 270 Firefox vulnerabilities with the aid of Anthropic’s new Claude Mythos model. 

What this means

In the wrong hands these vulnerabilities could definitely do a lot of harm. So, it looks like it will take some time before regular consumers and developers will gain access to Fable 5 and Mythos 5 entirely. However, existing Anthropic models (older Claude variants) remain available.

For home users who were simply chatting with Claude or using it to help with basic scripting, the change will mostly show up as “this specific version is unavailable” rather than a broader AI blackout.

Removing a high‑end vulnerability‑finding model from broad circulation increases the effort required for less‑resourced cybercriminals to automate discovery of complex bugs in consumer‑facing software and services only by so much. There are other models available on the black market that might be just as effective. And for most cybercriminals, turning a vulnerability into a method they can utilize in an exploit is much more relevant.

---

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.