Welcome to Issue #169 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• It’s getting a bit colder here in New England, but to me it's the perfect temperature. 70F/21C during the day and 55F/12C at night. Sweater weather and I can still wear some shorts :)

• My kids started school this week, and it's a huge transition for them. Shoutout to all the parents who deal with overtired and overstimulated kids as soon as they get off the bus, because ooo boy this is crazy!

• I’ll be in NYC this month and next month for work. I’m excited to be back, as it's been a few months, and it turns out I’ll be there during fashion week, so you can expect me to be dressed in couture. I just have to find some affordable couture first

💎 Detection Engineering Gem 💎

A scenario to evaluate your Agentic SOC by John Ao and Michel San

The commoditization of Agentic SOC is a good thing for all of us. And what I mean by this is that the techniques we see from evals, like the one in this blog, weren’t built in the open by AI SOC companies. This makes sense from a purely business perspective: evals and harnesses remain moats for startups, allowing them to show how differentiated their products are and sell to companies that need them. As general knowledge for agent architecture entered the security zeitgeist, these moats shrank and teams started to roll out their own capabilities. This is a natural evolution of any security capability.

Evals are so important for testing whether your harness will work in a live environment, and I’ve featured so many of these evals from blog posts, like from friends of the newsletter at Cotool. This blog by Ao and San feels like the most advanced because it covers a full end-to-end intrusion:

There’s a lot going on here, and I highly recommend clicking through to read their research, but it’s a TeamPCP-like compromise. It starts with a malicious pull-request workflow execution that poisons a cache inside a privileged GitHub Actions release build, where the poisoned image is run on Kubernetes, and the attacker priv esc’s out of the Kubernetes cluster compromise to gain full AWS account-level control.

They ran several frontier models through the scenario with Splunk API access. Five of seven assigned the initial alert a false-positive or benign-positive disposition, which is an immediate failure under their scorecard. Claude Opus 5 identified the attack as malicious, but achieved only 29% of the weighted investigation score, in part because it confused some malicious traffic with legitimate developer operations.

The validation gate is the most interesting here. The 29% number from above is a cumulation of scenarios each model correctly identified:

This report card raises the bar for evals in that it’s not just about precision or recall from True Positive/Benign/False Positive, but about the quality of the report. As it finds more and more parts of the attack chain, the model should provide evidence to the person investigating the intrusion. It also helps identify IOCs, distinguish legitimate activity from adversary behavior, and provide an analyst with enough evidence to scope and respond to the incident.

🔬 State of the Art

I’m in your logs now: deceiving analysts and blinding EDRs by Olaf Hartong

This blog by Hartong is a comprehensive deep dive into Windows telemetry and its use in security. Microsoft’s Event Tracing for Windows, or ETW, is a critical technology used by EDRs and SIEMs for performing detection & response. It has a few advantages: it’s a native technology shipped by Microsoft, so it’s a standard, supported way to collect telemetry; it has a pub-sub architecture to ensure you collect only the events you need; and it’s safer than shipping kernel modules that could brick a system.

Security tooling adopted it because it provides great visibility, but it was not designed with security in mind- more so observability. That distinction becomes important when security tools turn ETW events into cloud telemetry, detections, and analyst evidence, which is what Hartong’s research is about.

He starts with the useful defender goal of generating synthetic events to test detections without repeatedly emulating attacks as you would see on Atomic Red Team. He created his own ETW subscriber and producer, reproduced the data structures and payloads, and began sending them to Microsoft MDE. Once MDE began accepting telemetry, he began testing whether it could distinguish synthetic events sent from his tooling from actual events generated inside ETW.

Hartong essentially tricked MDE into believing the telemetry submitted on the local machine was authorized, without checking whether it was synthetic. Theoretically, this meant an attacker could submit confusing or incorrect telemetry from the Windows box on behalf of the ETW provider, which could trick a SOC analyst. I am unsure how likely this attack vector is, but IMHO, the point is more so that synthetic logs have their place in testing, but full end-to-end testing of an attack → alert helps guarantee that the full pipeline works.

A call for collective action on cyber defense by OpenAI

This security call-to-action letter from OpenAI is riding the tail of several disclosures that I’ve covered, including one from OpenAI itself, in which frontier models autonomously breached companies to solve a task given to them in a lab environment. It’s been making the rounds: 100+ companies signed it, including my own (Datadog), and I think the message is important, but I wonder if it’ll have any effect. Many open letters like this help grab headlines and signify commitment, but I don’t necessarily know what these companies and organizations will do differently after publication.

Now, I do think we need to stop being in awe of models that find vulnerabilities while stopping at the hard parts of patching and detection. I’d like to see more experiments and research into active agentic defense, where we build guardrails in a way that an agent stops an active attack without human intervention. This is the hard part because it’s based on trust rather than capability.

So who’s up for the challenge? :)

Inside Elastic's agentic SOC: How we took AI alert triage from 60% to 92% accuracy by Maggie Musquez

This post by Elastic’s internal SOC is similar to what I featured in Issue 166 from Figma. Elastic is a security company, and similar to my $DAYJOB, they are heavy dogfood users of their own products. They started rolling out an AI-SOC like triage agent and according to Musquez, it was hovering around 60% accuracy in terms of analysts agreeing with the agent’s analysis of an alert.

Much like Figma’s post and others in this space, the Elastic team began to build multiple agents to replace one-shot analysis. The goal here wasn’t just to ensure it reached the correct verdict: similar to what we saw in the Gem above, these investigative summaries needed to be actionable and of sufficient quality that a SOC analyst could quickly orient to the case and choose to escalate it or close it out.

They saw accuracy increases when they began adding context to the investigations themselves, primarily around:

• Past cases with the same rule name and making sure the investigation notebook inside the rule was high quality

• Workday enrichment to provide context around the employee itself

• Learning from past verdicts to steer the agents investigation

These enrichments, alongside more granular agents tasked with summarization, gathering evidence and pattern finding, moved their case accuracy to nearly 92%.

There’s some potential product pitches in the blog, but I’m not mad about it because the story was around dogfooding and building out in the open.

💬 Reddit SecOps Discussions

What is actually expected from a cybersecurity manager at a FAANG-level company?

It’s always funny reading Reddit discussions because there is a self-selection bias: those who respond tend to be negative. But I liked this thread because it gives a bit more insight into how management works, and doesn’t work, at a large tech company. I am also biased here in that “I” am a manager at a tech company, but for those who do want to get into leadership, especially in a SOC-like role, this is a great post to read.

Lazy Colleagues?

In this thread, the author, who works in a SOC, asked others about his colleagues who tend to pick up “easier” SOC tickets to complete, whereas he has more complicated ones. He ascribes this to laziness, and some replies suggest there may be a performance metric, such as the number of tickets closed or the time to close tickets. I think these are all fair points, but if I were mentoring this person, I would tell them to use their status as the “dependable one” to find more opportunities within the organization.

It’s a hard problem: the SOC is a grind, and you want to be a good teammate, but you likely have different aspirations than your colleagues because we are all unique in our goals. I would turn a situation like this into an opportunity for this person to start finding and proposing ideas to solve team or structural issues, as this is a clear indicator of a more senior analyst within a SOC.

☣️ Threat Landscape

Threat Road

Active PaperCut exploitation and the patch that changed overnight

What Happened…

Read more

7 days ago · Threat Road

I just found this publication on Substack, and what I appreciate about the way this post is structured is that it provides specific detection and learning advice for a vulnerability. PaperCut is a print management software used by companies to manage and deploy printers. I don’t necessarily know why someone would want this exposed to the Internet, but that was part of the attack path, not the two vulnerabilities released by PaperCut.

Threat Road highlights the full attack path for an attacker to gain privileged access to a PaperCut server within a network: the server must be Internet-facing, a configuration change must occur before an authorization check, and a separate deserialization step can turn the attack into an RCE.

They give practical detection opportunities in terms of what to look for and which logs you can use in your SIEM, as well as practice labs to understand the full attack path.

Improving our alignment and security efforts by Anthropic

Anthropic provided a post-mortem on their recent disclosures that early-release models broke out of the training environment sandbox and breached other environments. I do think some of this is interesting, and some of this feels.. standard practice?

They do take some time to explain how they are reconfiguring the model itself to make sure that it doesn’t perform harmful tasks when its given an impossible task (one that it can cheat on, such as CyberBench). I do find this bit sort of funny, though:

By default, all cyber evaluations should run inside a hardened sandbox (an isolated computing environment) with no internet access.

I wonder what they mean by "no Internet access," since OAI’s incident involved granting access to an Artifactory server to install packages. The models found an SSRF vulnerability inside that environment to achieve Internet access.

The Hugging Face Incident Is Not an AI Story by Marius Horatau

This blog post is a nearly perfect follow-on to the Anthropic post-mortem listed above. Horatau read OpenAI's Hugging Face Incident Report and shared his thoughts on some of the relatively basic isolation failures present in these eval environments. Although I enjoyed reading and watching the OpenAI post-mortem at Black Hat, the specifics of the breach were unremarkable from a detection standpoint. Horatau points out three failures:

• No security assessment on the sandbox environment. Horatau’s point is that this environment appears not to have gone through an assumed-breach assessment, or if it did, it was inadequate

• The alerts that did fire for the initial port scanning and message board triggered an incident, and the team contained it. There was no indication of any follow-up items to trace the attack path, and the agents began their exploitation runs again the next day

• It’s not apparent that any alerts fired on the security boundaries that seem standard to alert on. Any one alert on the sandbox gaining root on its host, a workload creating a privileged host-mounted pod, or a sandbox identity becoming Kubernetes cluster-admin should have fired an alert

🔗 Open Source

tailscale/tailcat

Tailcat is a netcat-like utility that you can use over a Tailscale connection for encrypted transfers. You don’t need the Tailscale control plane, but you still need an account to use it over their data plane. It does everything you’d expect a raw TCP listener/sender or netcat does: piping stdin/stdout, TCP forwarding, file transfer, SOCKS, and an exit-node mode.

DavidCarliez/cover

This is a neat sandbox-like project that performs inline replacement of secrets so your agents never see the “real” secret inside its environment. It’s essentially a proxy that replaces secrets with realistic stand-ins before they reach an external model, then it restores the originals only in responses that return to the local environment.

Azr43lKn1ght/DFIR-LABS

This repo hosts a free, community-built collection of Windows-focused digital forensics, incident response, malware-analysis, and threat-hunting challenges. Challenges range from easy to “insane” difficulty. It looks more like evidence-driven incident scenarios rather than only CTF flags.

Kerberosse/soc-dataset-thebiggerinterview

Ao and San’s investigation scenario used in their blog post from the Gem listed above. Sets up a local Splunk instance, ingests over 2 million events, and indexes them so you can point your own agents at it for evals.

A secure workspace for your team - so you can focus on building, not on what could go wrong.

Every customer support agent starts their day the same way: opening a browser, logging into Zendesk, and handling sensitive customer interactions. For most early-stage teams, that workspace is completely unprotected. The browser is where your people work, where your customer data lives, and where most security incidents begin - yet it's the layer that gets secured last, if at all.

AI is now part of everyday work. Your team is using agents and AI-powered workflows to move faster. But as your AI usage scales, so does your exposure: sensitive customer data, keys, source code, credentials, and proprietary information can flow into unvetted AI tools without anyone noticing - including you. And the browser is where all of it happens.

The startup ecosystem thrives when founders can focus on building. That's why Palo Alto Networks partners with the Zendesk Startup Program to provide early-stage teams access to the same browser security used by large enterprises - so startups are not forced to choose between preserving runway and protecting their customers' data.

A secure workspace, not just a secure browser.

Picture this: a support agent on your team gets a convincing phishing email that looks like a familiar notification. They click the link, land on a spoofed login page, and enter their credentials. Within hours, an attacker has access to your support system, and every customer conversation, ticket, and piece of sensitive data inside it. You find out when a customer calls to ask why your support team reached out, asking for payment details.

This isn't a hypothetical. It's how many small business breaches actually play out - and it's exactly what Prisma Browser for Business stops. We use Palo Alto Networks’s Precision AI-powered security to recognize the destination as malicious and block it before the page ever loads. No credentials entered. The agent sees a warning and moves on with their day.

That's the core idea behind Prisma Browser for Business (PBB): a secure workspace that sits at the intersection of work, AI use and threats - the browser. PBB wraps your entire browser session in enterprise-grade security, protecting every app, every tab, and every interaction, without requiring your team to change how they work.

For Zendesk users specifically, PBB can be configured with Zendesk as a dedicated workspace app - automatically applying the right security policies to everything Zendesk-related the moment your team opens it. Phishing attempts are blocked. Data leakage from support conversations is prevented. And your agents work inside a protected environment without any extra steps on their end.

The result: your team gets a seamless experience, and you get end-to-end visibility and control over how Zendesk is accessed across every device on your team.

The security gap startups can't afford to ignore.

When you're building a company, security can feel like something to tackle later - after the product ships, after the team grows, after the next funding round. But phishing, malware, and data leakage are not enterprise problems. They're startup problems too - and they can be significantly more damaging when you don't have a dedicated security team to catch them.

Three risks in particular are growing fast for early-stage teams:

• AI tools without guardrails. Your team is almost certainly using AI tools - Claude, ChatGPT, Copilot, and others - to move faster. But without controls in place, sensitive customer data, internal documents, and proprietary information can flow into these tools without anyone noticing. PBB lets you set guardrails around how AI tools are used in the browser, so your team can stay productive without inadvertently exposing data they shouldn't.
• Unvetted browser extensions. Extensions are one of the most overlooked attack surfaces in any organization. A single malicious or compromised extension can silently capture credentials, intercept data, or give an attacker persistent access to your environment. PBB gives you control over which extensions can be installed across your team's browsers, and alerts you when a suspicious or malicious extension is detected - before it can do damage.
• Phishing and malware. The browser is the primary delivery mechanism for both. PBB blocks malicious sites and stops malware downloads in real time, protecting your team and your customer data at the point of risk.

PBB brings all of this together in a way that is simple to deploy and easy to manage - no security expertise required, no complex infrastructure to stand up.

Built for where startups actually are.

The Zendesk Startup Program is designed to support founders from their earliest stages through scale - including when security becomes a core business priority. Startups eligible for the program can access PBB as a practical way to evaluate enterprise-grade workspace security without a large upfront commitment. It's a way to build securely from the start, preserve runway, and scale your operations with confidence.

As a rapidly growing startup, you shouldn't have to choose between moving fast and staying secure.

• The browser is your biggest security gap - and it's where startups get hit first. Phishing, credential theft, malicious extensions: these aren't enterprise problems. They're startup problems, and they land in the browser before you even have a security team to respond.
• Security doesn't have to slow your team down. PBB applies enterprise-grade protection automatically - no behavior change required from agents, no complex infrastructure to stand up. Your team works exactly as they do today, just inside a protected environment.
• Build securely from day one, without the day-one security budget. Leverage protection large enterprises rely on - so you don't have to choose between your runway and your customers' trust.

Ready to get started?

Startups participating in the Zendesk Startup Program are eligible to apply for PBB as part of their program benefits. Visit the Prisma Browser for Business dedicated landing page for Zendesk to take advantage of our partner’s promotion.

The post Building Securely From Day One: Palo Alto Networks Partners with the Zendesk Startup Program appeared first on Palo Alto Networks Blog.

How Partners Can Turn Marketplace Momentum into Customer Value.

Cloud marketplaces have become an increasingly important way for customers to buy technology. They can offer a familiar route to procurement, help organizations use their precommitted cloud budgets for eligible purchases and support goals such as consolidating IT spend and simplifying governance.

For partners, though, the opportunity goes well beyond the transaction. A recent report from Canalys (now Omdia) predicts that by 2027, more than half of all hyperscaler marketplace business will flow through partners. That points to an important shift in how technology is bought and sold – and creates an opportunity for partners to bring much more than purchasing convenience to the table.

Partners know their customers. They understand their environments, priorities and cloud investments. Many also bring the services and technical expertise needed to migrate, integrate, deploy, and manage technology after it’s purchased. When we combine that customer intimacy with the reach and capabilities of leading cloud service providers (CSPs) and the Palo Alto Networks platform, marketplaces can become a powerful vehicle for creating value across the ecosystem.

Meeting Customers Where They Want to Buy.

One of the most important principles in any marketplace strategy is also one of the simplest: Meet customers where they want to buy.

Organizations have established relationships with CSPs and, in many cases, significant cloud commitments. They may also have specific pricing arrangements, governance requirements and procurement processes tied to those relationships. A marketplace purchase can allow them to work within that existing framework rather than introduce an entirely separate buying motion.

The opportunity for partners is to understand those dynamics early. Does the customer have a cloud commitment? Is there a marketplace budget available? Are there CSP programs that could support the opportunity? Would purchasing through the marketplace make the process easier or provide a commercial advantage?

Palo Alto Networks works across the four major CSP ecosystems – AWS, Google Cloud, Microsoft Azure and Oracle Cloud Infrastructure (OCI) – giving partners the flexibility to follow customers to the cloud environments and marketplaces that make sense for them. Through Palo Alto Networks agreements with CSPs and benefits available through the reimagined NextWave Partner Program, marketplace transactions can also carry relevant pricing advantages for eligible partners and customers.

The goal is to understand how and where the customer wants to buy, then build the opportunity from there. 

Bringing More Value to the Transaction.

Of course, procurement is only the beginning. A marketplace can make technology easier to purchase, but partners can help customers turn that purchase into adoption and value.

Say a customer is looking to secure AI adoption, migrate infrastructure to the cloud, modernize on-premises infrastructure or transform its network. Addressing any of those priorities takes more than selecting technology. The customer may also need help assessing their IT environment, deploying and integrating new capabilities, and connecting their investment to a broader security strategy.

Partners are often closest to those needs because they already have trusted relationships with customers. Many are also managed security services providers (MSSPs) or have other services capabilities they can provide around a marketplace transaction.

That creates an opportunity to do more than facilitate a sale. Partners can combine Palo Alto Networks technology with their own services and expertise to develop a more complete offer for the customer. In turn, that can expand the value of the engagement, support technology adoption and create opportunities to develop and expand more strategic customer relationships.

Palo Alto Networks has long recognized this role for partners. The newly evolved NextWave Partner Program includes marketplace, resale, managed security services, support and delivery models, reflecting the different ways partners contribute throughout the customer lifecycle.

Turning a Customer Need into a Broader Platform Conversation.

Marketplace opportunities can also open the door to platform discussions. Customers rarely look for “platformization” from the outset. Most often, they just want to solve a specific problem. They may need to protect an AI initiative, secure a cloud migration, modernize infrastructure or improve connectivity for a cloud-first environment. But those priorities often intersect with other cybersecurity needs.

That gives partners an opportunity to start with the customer’s immediate need and identify how a more integrated, consolidated approach can deliver additional value. This is where complementary capabilities across the ecosystem can come together. CSPs provide the cloud platforms and services customers use. Palo Alto Networks extends security across those environments. And partners bring the technical expertise, services and customer context needed to connect those capabilities to specific needs.

Rather than viewing each technology purchase in isolation, partners can help customers consider how it contributes to a broader security strategy. And as we develop marketplace sales motions in additional areas, including identity, partners will have even more opportunities to connect capabilities around customers’ evolving needs.

Collaboration: The Key to Unlocking Marketplace Opportunities.

For all the attention cloud marketplaces receive as a digital route to market, much of the opportunity today is still deeply relationship-based. It starts with identifying the customer need, understanding that customer’s cloud strategy and commitments, bringing the right value proposition and then getting the right people around the table.

Success hinges on effective collaboration between the partner, the customer, the CSP, and our dedicated Palo Alto Networks account and alliance teams. Through early qualification and joint account planning, we can collectively pinpoint customer challenges, determine the best purchasing route, and define how each stakeholder can contribute to the solution.

This is also where marketplace strategy connects directly to the value exchange in cybersecurity I’ve discussed previously. Partners, vendors and other members of the ecosystem invest in different capabilities – technology, knowledge, skills, services and customer relationships – and create greater value when those investments are aligned around the customer. Public cloud marketplaces give us another way to put that model into action.

We Are Only Scratching the Surface of What’s Possible.

Cloud marketplaces are already changing how customers purchase technology; however, I believe we have only scratched the surface of what partners, CSPs and technology providers can accomplish together as these marketplaces evolve.

For partners, the next step is to understand the CSP initiatives and marketplace programs relevant to their customers, identify where their own services and expertise can add value, and be ready to act when the right opportunity emerges. 

Ready to Make the Most of Cloud Marketplaces? 

Reach out to your Palo Alto Networks team to schedule a sales enablement session, learn the relevant CSP sales motions, identify opportunities within your customer base and understand how to submit deal registrations through the NextWave Partner Program.

Key Takeaways:

• Meet customers where they want to buy. Cloud marketplaces can align purchases with existing cloud relationships, commitments and procurement preferences.
• Partners add value beyond the transaction. Customer knowledge, services and technical expertise can help turn purchases into adoption and lasting business value.
• Collaboration expands the opportunity. Early coordination among partners, Palo Alto Networks and CSPs can uncover opportunities and support a broader platformization strategy.

The post Making the Most of the Cloud Marketplace Opportunity appeared first on Palo Alto Networks Blog.

At the 2026 Executive Partner Summit, Palo Alto Networks President BJ Jenkins made one thing clear: the AI era is the platform era — and above all, the AI era is the partner era. Palo Alto Networks tightly integrates its platforms to work seamlessly together and give customers full end-to-end protection. 

But securing the world’s largest organizations requires both advanced AI security technology and the combined power of our ecosystem, spanning resellers, service providers, cloud providers, distributors, and strategic advisors, to drive success at every stage. From initial architecture and deployment to 24/7 managed services, our partners ensure complex environments stay protected at scale.

As organizations navigate unprecedented technological transformation, partners are more critical than ever before in helping our customers modernize by adopting AI-powered platform security.

Anar Desai
North America Channel Sales at Palo Alto Networks

Together, Palo Alto Networks and our partner community are redefining what it means to secure the enterprise. As we continue to deepen our commitment to our partner ecosystem, we're proud to announce the winners of the Palo Alto Networks 2026 North America Partner of the Year Awards. 

This year’s award winners have demonstrated exceptional performance, deep expertise, and an unwavering commitment to our joint customers. Together, they reflect what is possible when Palo Alto Networks and our partners align around a shared goal: helping customers secure today while preparing for what’s next.

Congratulations to our:

• North America Cloud Provider of the Year: Amazon Web Services
• North America Distributor of the Year: TD SYNNEX
• North America Managed Security Services Provider of the Year: Norlem
• North America Service Provider of the Year: AT&T Business
• North America Solution Provider of the Year: World Wide Technology 
• North America System Integrator Partner of the Year: Deloitte
• North America Frontier AI Partner of the Year: NTT DATA
• North America Idira Advisory Partner of the Year: Accenture
• North America Idira Partner of the Year: Optiv
• North America Network Security Partner of the Year: Sycomp
• North America Prisma AIRS Partner of the Year: Cognizant
• North America SASE Partner of the Year: Trace3
• North America Cortex Partner of the Year: Presidio
• North America Software Firewall Partner of the Year: AHEAD
• North America Commercial Select Partner of the Year: GuidePoint Security
• North America Federal Growth Partner of the Year: Vibrint
• North America Federal Partner of the Year: ThunderCat Technology
• North America Growth Partner of the Year: Insight Enterprises
• North America Small-Medium Business Partner of the Year: CDW
• North America State, Local & Education Partner of the Year: NWN
• Canada Partner of the Year: Kyndryl
  

Building a more secure future, together. 

Our awards honor a shared commitment to customers. Our partners bring their expertise, capabilities and perspective to the table, and that collaboration helps turn our technology into outcomes. 

For our partners, this award celebrates the shared effort that keeps our customers safer every single day. As trusted advisors, they bring the strategic guidance and domain experience clients rely on to navigate an ever-changing threat landscape. Together, we help customers turn complex security challenges into lasting confidence and trust. 

To our 2026 North America partner award winners: thank you for your relentless commitment to protecting our customers and setting the standard for excellence across our ecosystem. We look forward to deepening our alignment and driving the next wave of platform innovation together.

Join us in securing the frontier and protecting our digital world. Learn more about our Palo Alto Networks Partner Program and how to become a partner today.

The post Celebrating excellence: Palo Alto Networks announces the 2026 North America Partner of the Year Awards appeared first on Palo Alto Networks Blog.

Welcome to Issue #168 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m in my hometown this week with family, and I forget how much I love NY weather during the summer. You can throw a rock in any direction and likely hit a lake or a river here!

• For the first time in a long time, I neglected to bring running shoes and workout clothes to an extended vacation. I’m dying over here: I’m eating way too much food and have no counterbalance to work all of the calories off. I basically need to sneak away during the day and do pushups in a corner of my room if I want any semblance of a workout

• I keep getting notifications from Substack that my newsletter is part of a leaderboard for “Rising in Technology”. But everytime I check the board I don’t see my name :( maybe the leaderboard is so competitive I only get it for a few hours at a time

  

Sponsor: Detections.ai

Coverage analysis, tuned to your environment

detections.ai Enterprise builds a baseline of the tech you run, the detections you already have, and threats you care about. New intel gets analyzed against that baseline continuously and automatically, with notifications when we find gaps.

You get coverage answers specific to your environment. No generic MITRE ATT&CK percentages: what applies to you, what you already cover, what’s a gap, and why.

Detections tuned to your data sources and existing rules, ready to sync back to your stack.

Book A Walkthrough

💎 Detection Engineering Gem 💎

Where do Detection Ideas Come From? by Gary Katz and Jason Deyalsingh

I’ve written a ton about detection backlogs, even dating back to Issue 4 in 2022 (!). In my years of building a detection engineering function, the detection backlog and its management have been a hot topic in planning work for the quarter or even the next few weeks. You try to cover and document as much as you can, and we typically ask the questions:

• Do we have the right breadth of coverage?

  • Did we onboard any new technologies that we need to log?

  • Are we covering every tactic in ATT&CK for an attack surface, such as host or cloud?

• Do we have the right depth of coverage?

  • How many techniques are we covering in ATT&CK?

  • Were there any new red team exercises that discovered gaps in catching techniques?

Note that the questions are insular, as in, they don’t encapsulate what threat actors are doing targeting a business that looks similar to yours. I can spend so much time writing rules for Active Directory, but if Active Directory accounts for a small percentage of the environment, then it may not be the best use of time.

That is why I like Katz and Deyalsingh’s framing in this blog. They describe four places from which detection ideas can originate: visibility (breadth), existing detections (depth), the environment (context), and threat-intelligence research (environment X the threat landscape). The useful part here is not picking one as the right starting point. It is using the other three as filters.

They make the argument that a rule request or a Sigma rule you find online is not automatically backlog-worthy. They ask and answer much better questions than I did earlier. You should look at the existing visibility: is there existing coverage, or are the relevant adversaries using the technique against a company like yours? The same logic applies in reverse when you start with a new log source, a critical asset, or a threat report.

🔬 State of the Art

How Well Can Open-Weight Models Evade SIEM Detection? by Daniel Knight

With the latest news about frontier, low-guardrail models breaching legitimate companies, it’s good to see open research into how similar incidents could occur with an open-weight model. In this post, Knight emulates a small- to medium-sized business lab environment with a full Wazuh stack to show how their open-weight model, Sable, combined with other models, can successfully compromise the environment.

The testing showed that their autonomous agent could reason over an Active Directory environment, validate a multi-stage ACL delegation path, select lower-artifact techniques, and complete a domain-level compromise without generating a high-severity correlated incident in Wazuh. The goal here wasn’t to compare and contrast the model's expertise in this environment. What I took from this was that the lack of guardrails within open-weight models is the barrier to entry to this type of setup.

The other interesting things was that the model was smart enough to do things like sleep in between attacks so that it can outlast correlation windows, use as much living-off-the-land binaries as it could, and a custom in-process HTTPS C2 framework:

The beacon was designed as a lightweight, memory-resident HTTPS polling channel rather than a conventional installed implant. Contrary to popular opinion, you can’t expect to run Winpeas and not get caught. It ran within WS01’s existing WinRM worker process, wsmprovhost, under a Kerberos-authenticated administrative session. The agent used a dedicated HTTPS endpoint, certificate validation, encrypted task exchanges, randomized callback timing, error backoff, and a defined kill date. Commands were queued by the control service and their results returned during later callbacks.

I do have some good news, or at least hopeful news, after reading this post. I think we are going to see more experimentation with the efficacy of open-weight models for adversary simulation, which means we need a separate response on the threat-hunting and detection side of the house. This includes being autonomous enough to deploy rules, hunts, and containment actions.

Beyond Detection: Getting Real Value From Sigma and YARA Rules Across EDR, NDR, XDR, and SIEM Tims Tittus

This is a great introductory post for those trying to understand both the differences among detection products and the applicable rules. Tittus does a particularly good job of distinguishing between writing detection rules against logs using Sigma, which should catch behavior, and writing YARA rules against files and memory, which is strictly pattern matching. They both have their place in the detection stack with their corresponding strengths and pitfalls.

I copy-pasted the table into ray.so for some prettier formatting:

I’ve generally viewed YARA as the earliest or latest stage of an investigation. The early stage is identifying known malware patterns and making a block-or-alert decision in EDR or NDR. The EDR can generate a log with an enriched view of the binary and YARA output. It’s also a great threat-hunting tool, where you don’t mind sifting through false positives to help tune the rule and avoid overwhelming the SOC.

Self-Study in The Age of LLMs by Jared Stroud

At DEFCON, I caught Jared’s talk on finding vulnerabilities in bootloaders via directed fuzzing. It’s his PhD research for his PhD, and as someone very unfamiliar with fuzzing in general, it was a fascinating approach that combined static & semantic code analysis rules with LLMs to find entire vulnerability classes. After his talk, we were walking around the DEFCON floor, and I asked him for his thoughts on using LLMs in PhD research and what he likes and doesn’t like about them.

I felt somewhat validated because he wrote a blog post afterward about how he uses them as a self-study tool and “adversarial advisor” to help him understand complex topics, papers, and codebases. This is very similar to what I wrote in February earlier this year. Basically, if you can prompt chat and coding agents in ways that serve you as a learning or study buddy, it can significantly accelerate your understanding of a subject rather than trusting the output.

Jared warns about this in the post: it’s not about quizzing yourself and trying to recount answers in a cliff notes style quiz, but rather, using them to play roles or create labs for yourself to complete. For example, when trying to understand a codebase, Jared has the agent create a multi-module, graduate-level learning lab split between several chapters. He can work through each lab and break the work up in a way where it’s not overwhelming. I think the same can be applied to detection engineering and security operations concepts, rather than jumping right into a class of detection rules without understanding the underlying behavior of an attack.

💬 Reddit SecOps Discussions

Log everything, I’m begging you

I liked reading this discussion because it highlights the two biggest pain points for security teams: visibility and cost. There is no rule without telemetry, but if you aren’t being cognizant of cost while logging everything you can, you’ll be drowned out by a large logging bill or too many alerts that can overwhelm a security operations team.

There are certainly strategies to help reduce cost while still logging as much as you can. Many solutions decouple storage and compute, where you can store lower-value logs, such as DNS or HTTP traffic, and rehydrate them only during an investigation.

The key argument here is intentionality IMHO. If you just “log everything”, you’ll lose on the cost front and frustrate coworkers and your finance department. You may want to keep ALL DNS logs, and as long as you have a good business justification, it shouldn’t be an issue. Perhaps you do have great rules or a very specific compliance requirement to do so, but the key is to write that risk down and make sure people understand it.

Does a SOC have to constantly justify its existence?

Maybe I’m biased since I’ve been in the industry for 15 years, but I do think that it is much harder for people to break into security now than when I first started working. A lot of social media posts naturally highlight the negatives of security: costs, difficulty finding jobs, layoffs, and security breaches are all topics I see across different platforms. So when I see a post like this, I worry that, as a community, we tend to present the negatives to others rather than the positives. But isn’t that what the Internet is for?

Security teams are there as a hedge against control failures. So, no, a SOC doesn’t need to justify its existence, because I try to internalize that if a threat actor makes its way into my organization and detection rules are the last line of defense, there were many failures that happened along the way. I think this is the perspective that new grads should bring into their first SOC jobs. When you identify a threat actor, work quickly to contain the breach, and let yourself shine as you write the post-mortem. What controls failed? What classes of rules were missing? Can you remove rules after you implement a new control, because the rules become less relevant?

This approach is where I see entry-level security people become very successful. Security is a cost center, but that doesn’t mean we can’t help appropriate that cost in different ways.

☣️ Threat Landscape

More Criticals, Less Dopamine by Ananda Dhakal

I feel like vulnerability researchers are having an identity crisis over the last year. Large language models, starting with Opus, began challenging human expertise due to their speed in orienting to new codebases. A singular prompt and getting a cup of coffee can create an expert vulnerability researcher for a codebase. This wasn’t the case before, as Dhakal puts it, where the painstaking process of learning the codebase was part of the journey.

Although we’ve leapfrogged our capabilities for vulnerability analysis by throwing code at agents, we still haven’t clarified what it means to resolve and patch vulnerabilities. This is where I see vulnerability researchers getting stuck the most. The dopamine hit may not be as strong when we find a PoC with Opus, but IMHO the hard work is shifting towards patching and prevention. That work is severely underserved, and we could use help from brilliant researchers on solving that at scale. It’s not really impressive to me anymore, since people find vulnerabilities so easily; the barrier to entry for finding them is much lower.

I want to keep doing vulnerability research. But, I want to do something more than just abusing llms and hoping they pop a shell.

Post-DEF CON Phishing Uses Google Doc Apps Script to Deliver Malware by Jonathan Semon, Ryan Dowd and Ben Nahorney

Huntress Researchers uncovered a ClickFix social engineering campaign that was unique for two reasons. The first reason is that it specifically targeted security researchers on X during DEFCON. A fake X account reached out to researchers both publicly and via DMs, trying to get them to navigate to a malicious Google Doc. This is the really cool part, and forgive me for the screenshot because it won’t let me link to their video (though you should go watch it!)

The lure is a typical encrypted document pretext. The attacker sends a decryption key to the victim; the victim tries to paste it into a custom sidebar on the right, but it displays an error and prompts the victim to copy-paste the ClickFix payload.

The clever tactic is the custom sidebar itself. Apparently, in Google Docs, you can load a custom Google Docs App Script to automate certain tasks that help interact with the document itself. The Huntress team reverse-engineered the App Script and found a reusable template for malware delivery. It’s basically like a JavaScript payload but inside a trusted container. It sent victim information to a Telegram bot and served malware based on whether the user was on macOS or Windows.

We burned 11.7bn tokens to find the best cyber AI model by Philippe Dourassov and Debarshi

Aikido Research created a CVE benchmarking harness to measure the discovery of recently disclosed CVEs by leading Frontier models, both open and closed weights. They assessed 32 recently disclosed vulnerabilities, with each model receiving three independent attempts. They then combined each model's attempts, which materially improved recall, but it also created more candidate findings for the rest of the pipeline to validate.

Much like Daniel Knight’s blog post above, this is a reminder that the model is only one part of the system. The discovery harness, number of runs, cost, validation workflow, and tolerance for false positives are just as important as the precision and recall metrics on the final chart. I am getting more and more excited about these open-weight models because they’ll hopefully drive costs down and put more purchasing power in end users' hands.

🔗 Open Source

sunlife3/needre

neEDRe is a small, experimental Linux EDR built in Rust with Aya, an eBPF library. To me, the repository reads more like a learning environment and project than a full-blown EDR, but this is the kind of project that detection engineers need to do more of to understand how these technologies work under the hodo. Following Jared’s blog listed above in State of the Art, you can ask an agent to build a curriculum to understand how eBPF works under the hood and to extend the detection capabilities in neEDRe.

horsicq/XPEViewer

Cross-platform PE file viewer and editor that runs on Windows, Linux, and macOS. It is designed to inspect Portable Executable internals without requiring a full reversing environment, making it useful for fast malware triage and detection writing. There are plenty of tools in this category, but I thought this was interesting due to the cross platform support and if you need it in a pinch.

Zyrexnn/Cybermes

Cybermes is an autonomous offensive-security and bug-bounty framework built around the Hermes Agent, several Go utilities, MCP integrations, and more than 200 skills. It wraps security tools such as subfinder, httpx, katana, ffuf, nuclei, and sqlmap, writes the raw output to disk, then uses a custom tool called smart_pipe to extract the meaningful output to save on token and context window costs.

It’s gotten a ton of stars on GitHub recently, so I’d be interested to see if anyone is running this with any modicum of success. Hermes is the new OpenClaw and people seem to really like it, so a security version of it for bug bounty might be fun to run.

armourinfosec/Offensive-File-Transfer-Techniques

This repository is a collection of file-transfer techniques for Windows and Linux that can serve as a useful lexicon for those who want to build detection around exfiltration or transferring of data to evade detection.

It has a good split of modules and case studies to look through. For example, the section on netcat and Socat has some classic red team tradecraft on using these tried-and-true tools to get around egress filtering. IMHO, pick the transfer methods that map to your environment, run them in a lab, and identify which telemetry you can use to detect.

As part of Patch the Planet, we received preview access to GPT 5.6-Cyber with a simple task: evaluate its cyber capabilities. Recent events inspired me to give it a challenge to work through: escape the VM I’d normally use for sandboxing. The target was a QEMU/KVM VM on my Linux dev machine (Debian Linux 12, AMD Zen3). It escaped the VM three different times.

First, it used recently disclosed bugs in my host kernel. When I fully updated, it used disclosed bugs that had not yet reached package maintainers or were not classified as security bugs. When I rebuilt QEMU and dependencies from the latest upstream source, it found several 0-days. It operated autonomously for hours, backtracked from approaches that didn’t work, pulled code and research papers, wrote oracles, made its own minimal examples, and aimed for a reusable, reliable exploit, all with minimal handholding and prompting. My main job was to physically reboot the machine when it hardlocked the host kernel.

If it wasn’t clear before, I will state it plainly: you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat.

Advancing cybersecurity capabilities

Let’s imagine a common situation: you want to run an AI agent, but need its full capabilities, including the ability to download, build and debug software; do research; sift through dependencies; set up fuzzers; triage vulnerabilities; and stand up services under different configurations.

The generally accepted solution is to set up a VM that serves as a safety perimeter and isolated prison for the agent: this virtual environment contains nothing of value, is separate from the host, and can be immediately deactivated or snapshotted for later investigation. This setup allows the agent to roam free, while isolating your computer from its consequences.

There is, of course, a tiny wrinkle. To be useful, the virtual environment must share resources with your host machine and provide a way to interact with the agent: you want to be able to see its screen, get files in and out, etc. You also almost certainly want the agent to have (some) network access.

Are these shared software, state, and communications pathways enough for the agent to escape containment? For a long time the answer was “no, absolutely not.” More recently, I’d have thought “maybe, after a while.” It turns out the real answer was “yes, and quickly.”

I gave the agent a simple task: It was in a CTF; to win, it had to break out of the VM and successfully read the flag file. The agent was started outside the VM, given SSH access into the VM environment, and permitted to do anything inside the VM. It was to keep a research log of findings. Why start outside the target environment, even though it could lead to cheating? I was operating under the (correct) assumption that escape attempts may lock/crash the VM during operation. The risk of starting the agent from the host was acceptable: there was nothing of particular importance on the dev machine, and any final exploit could be audited for cheating its objectives.

Escape 1: Januscape (CVE-2026-53359)
About an hour after letting the agent run, the host machine was hardlocked. Luckily, I had a logged-in session where I could read scrollback: the agent found my host machine kernel was vulnerable to Januscape (which was disclosed a few weeks earlier). There is no public exploit, but the agent had built one, and had enough confidence to test it—except that it didn’t land cleanly. I have no doubt that after some more revision it would have. One point for GPT 5.6-Cyber.

I updated my kernel to the latest offered for Debian 12.

Escape 2: libslirp
I am old and I like stability and consistency. That is why I run Debian 12, the current oldstable. Oldstable works, changes slowly, and gets security updates—exactly the known quantity I want from my software. Unfortunately, it seems that some security updates do not quite make it into the distribution. In this case, Debian 12 still ships libslirp 4.7.0, which is vulnerable to CVE-2026-9539. The agent also discovered that a bug fix commit in libslirp with no CVE assigned could be combined with CVE-2026-9539 to craft an arbitrary memory read/write in the host. After that, escape is trivial. Two points for GPT 5.6-Cyber.

For those curious, libslirp is a library that enables VMs to have networking, which you almost always want. I did not even know what libslirp was, or that the version I was running had both known and fixed-but-unmarked vulnerabilities. The AI agent deduced it quickly and was able to combine the two vulnerabilities to escape.

To make escape more challenging, I manually fetched the latest upstream libslirp and QEMU, and rebuilt a minimal QEMU with only the features I needed.

Persisting across long time horizons

One of the most impressive features of GPT 5.6-Cyber and Codex with goal mode is effective persistence over long (here, approximately 12-hour) time horizons across multiple compactions and innumerable subagent invocations. I did not do anything special to elicit this behavior; while my prompt included directions for the agent to keep a ledger of its findings, this was mostly for me, not for the agent.

The agent searched diligently and backtracked from multiple paths that led to failure. First it tried identifying what was accessible via the network on the host; it found a CUPS server (with a known CVE that had not made it to oldstable packages), but was not able to complete exploitation due to AppArmor. It then detected I run my host kernel with mitigations=off and attempted to use hardware bugs to get a read oracle of host memory (the primitive was too unreliable).

Eventually it went on a bug-hunting analysis of the host kernel source, QEMU, and associated libraries. It slowly chained together multiple vulnerabilities, including several 0-day bugs, until it could craft a reliable VM escape.

Escape 3: 0-days
This is what the agent used for the final exploit chain: three 0-days (at time of discovery) and one patched vulnerability that didn’t make it to my distribution kernel (because it was not recognized as a security issue):

Here are the vulnerabilities the agent found but did not use in the final chain:

Challenging current software security assumptions

My suspicion was that GPT 5.6-Cyber would succeed, but the frequency and manner of its success removed all doubt. We have to reassess sandboxing quality for capable AI agents, and in general the software stack with which they interact.

An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent. There is simply too much attack surface. Even innocuous features (like running with a display) add extra, exploitable attack surface.

A distribution with rapid updates is now a requirement. I love older, stable software, but the cycle of backporting patches is simply too long. An older distribution (like Debian 12, my old standby) that isn’t getting immediate upstream updates should be assumed vulnerable. A competent agent will discover these bugs quickly and synthesize target-specific exploits.

What can we do? A start is using a virtualization technology that was purposely built with a minimal attack surface and a focus on security, like Firecracker. I had the AI agent run against Firecracker. It was able to hardlock the machine due to more Linux kernel flaws (all patched in upstream), but could not successfully escape. It may have, given even more time, but Firecracker is obviously a substantially harder target. In general, we have to become much more attentive to security fundamentals: least privilege (regarding network access, credentials, available features, etc.), logging, and active monitoring. Further, we can limit the time agents have to operate and ensure a pristine environment for each use.

We found and reported a bug in Provenance Blockchain, a public proof-of-stake chain built on Cosmos SDK, that lets any user grant themselves admin control over marker accounts without holding a single token. Provenance covers a range of financial services, including on-chain tokenized loans, private equity tokens, bridged assets, and asset registries. Our bug affected 82 markers representing live financial assets on mainnet.

We found the bug, which affects versions before 1.28.0, in March 2026, and reported it to Provenance on April 1. It was mitigated in PR #2627 (commit c81fd65), which shipped in v1.28.0 on May 1, 2026, and fixed in PR #2734, which shipped in v1.29.0 on June 8, 2026.

What is a marker?

The marker module is Provenance’s core primitive for fungible tokens. Chain participants can issue a new asset on Provenance by submitting a MsgAddMarkerRequest transaction; the chain creates a dedicated account for that asset, called a marker. Each marker is a special account type that controls:

• A denomination (e.g., uusd.trading, cusd.deposit, cguaranteedrateomni)
• An access control list governing who can mint, burn, withdraw, deposit, or administer the token
• A supply field recording the canonical token count
• An escrow balance (the marker account can hold any asset, not just its own denomination)

Markers are either supply_fixed (the supply field is enforced as a hard cap) or non-fixed (the bank module is the source of truth; the supply field is informational). This distinction is central to the bug.

The bug: An access check anyone can pass

AddAccess is the Cosmos SDK message handler that processes requests to modify a marker’s access control list. It checks whether the caller is authorized using three conditions, any one of which is sufficient:

1. The caller is the marker’s designated manager and the marker is in Finalized state.
2. The caller already holds ACCESS_ADMIN on the marker.
3. The caller controls 100% of the marker’s circulating supply.

case types.StatusFinalized, types.StatusActive:
 if !(caller.Equals(m.GetManager()) && m.GetStatus() == types.StatusFinalized) &&
 !m.AddressHasAccess(caller, types.Access_Admin) &&
 !k.accountControlsAllSupply(ctx, caller, m) {
 return fmt.Errorf("%s is not authorized to make access list changes against finalized/active %s marker",
 caller, m.GetDenom())
 }

Condition 3 is implemented by accountControlsAllSupply:

func (k Keeper) accountControlsAllSupply(
 ctx sdk.Context,
 caller sdk.AccAddress,
 m types.MarkerAccountI,
) bool {
 balance := k.bankKeeper.GetBalance(ctx, caller, m.GetDenom())
 supply := m.GetSupply() // ← bug
 return supply.Equal(sdk.NewCoin(m.GetDenom(), balance.Amount))
}

The m.GetSupply function reads the supply field stored directly on the marker struct. For non-fixed supply markers that were activated with zero supply, that field always stays zero. The live circulating count lives in the bank module, and non-fixed markers never write back to the marker struct after minting.

So for any non-fixed supply marker, the authorization check reduces to the following:

supply = Coin{denom, 0} // stored marker field, always 0
balance = Coin{denom, 0} // attacker holds no tokens
0 == 0 → true

The check intended to restrict access to 100%-of-supply holders becomes unconditionally true for any caller with zero balance.

Exploitation: Two transactions to mint or drain

An attacker sends a single MsgAddAccessRequest transaction:

{
 "denom": "uusd.trading",
 "administrator": "<attacker_address>",
 "access": [
 {
 "address": "<attacker_address>",
 "permissions": ["ACCESS_ADMIN", "ACCESS_MINT", "ACCESS_WITHDRAW"]
 }
 ]
}

No existing tokens are needed for exploitation. The authorization check passes immediately via the broken condition 3. From there, the attacker has two paths:

• MsgMintRequest: to mint new tokens of the marker’s denom and send them to any address
• MsgWithdrawRequest: to drain any assets held in the marker’s escrow balance

The whole attack is two transactions: one to gain permissions, and one more to act on them.

Impact: What was at risk

At the time of discovery, 82 active markers on Provenance mainnet had a stored supply of 0 while carrying real circulating supply or escrowed assets, every one of them exploitable. These markers span multiple independent parties on the chain, not a single application.

Escrow withdrawal was the most direct path. Among the affected markers, those holding nhash (Provenance’s base token) in escrow accounted for roughly 30 × 10¹⁵ nhash, or around $500,000 at HASH prices at the time of discovery. The three largest markers are shown below:

The three markers shown above are all chain governance programs operated by the Provenance Foundation: one holds validator rewards, and two hold community grant funds.

Supply inflation was a broader but more constrained vector. The 74 vulnerable markers spanned bridged stablecoins and wrapped assets (uusd.trading, uusdc.figure.se, nbtc.figure.se), consortium deposits (cusd.deposit), tokenized mortgage participations (cguaranteedrateomni, chomebridgeomni), and yield tokens (nuva.ylds, uylds.fcc). An attacker with ACCESS_MINT on any of these could issue arbitrary new tokens of that denom. The practical harm depended on the token type. For restricted tokens with KYC requirements, it was primarily a solvency and integrity threat; for non-restricted coin-type markers, it was a more direct inflation risk.

We confirmed the affected markers and their balances by querying mainnet via the Provenance CLI and the public REST API.

The fix: Read live supply, and guard against zero

PR #2627 shipped the mitigation, which adds a check against zero supply:

if supply.Amount.IsNil() || supply.Amount.IsZero() {
 return false
}

This blocked the attack we reported. All 82 affected markers had a stored supply of 0, and a zero-supply marker now fails the check outright.

It did not fix the divergence. The comparison still read the stale field, so it still passed whenever that field was non-zero and the caller’s balance happened to match it.

PR #2734 shipped the full fix, which changes one line:

// Before: reads stale stored field, always 0 for non-fixed markers
supply := m.GetSupply()

// After: reads live circulating supply from the bank module
supply := k.bankKeeper.GetSupply(ctx, m.GetDenom())

Both sides of the comparison now come from the bank module, so there is no stale field left to diverge.

Authorization must fail from the default state

The root cause of this issue was state desynchronization. The marker struct and the bank module both represent the token supply, but only the bank module is kept current for non-fixed markers. The authorization check read from the wrong one.

The check wasn’t just wrong; it was bypassable by default because of the zero-equality shortcut. Because the stale field was always 0, the comparison 0 == 0 was always true. An access control check that compares against a value that is always the same as the attacker’s default state is trivially bypassable.

Switching to the live bank supply alone doesn’t fully close the hole. A freshly deployed marker with no tokens minted yet also has live supply of zero, so an attacker could self-grant admin by targeting it before it’s funded. The fix handles this with an explicit zero-guard: accountControlsAllSupply returns false whenever live supply is zero, regardless of balance.

The broader pattern: an authorization predicate must never be satisfiable from the attacker’s default state. A check of the form balance == supply hands access to everyone when supply can be zero, whether because the state is stale or the marker is simply unfunded.

Two things would have caught this before it went live. First, the access-list authorization model was never specified. Writing the rule down forces both questions that point straight at the bug: which supply, and what happens when it’s zero? Second, the property is easy to state: accountControlsAllSupply should only return true when live supply is positive and the caller holds all of it. A property-based test or fuzzer that generates random sequences of marker operations, such as minting, transferring, and creating empty markers, and checks this property after each step would find both failure modes automatically.

Frontier AI has compressed attack timelines from weeks to minutes. 

For defenders to gain the upper hand, they need to fight back at machine speed. That’s why Palo Alto Networks Unit 42 launched Frontier AI Defense, our comprehensive service that pairs advanced frontier AI models with leading threat intelligence to uncover hidden risks, validate real attack paths, and accelerate remediation before adversaries strike. 

Today, in a major milestone for organizations to defend themselves against AI-powered attacks, Unit 42 is expanding its Frontier AI Exposure Analysis capabilities with Anthropic’s Claude Mythos 5, giving organizations access to its advanced cyber capabilities.

Unlocking High-Fidelity Security with the Right Models, Harness and Expertise

While incredibly powerful, achieving high-fidelity results with frontier AI requires three things: the right models, an advanced harness, and the expertise to run it. With Unit 42 Frontier AI Exposure Analysis, guided and reviewed by Unit 42 experts, Claude Mythos 5 goes beyond identifying exposures. It tests whether those exposures can actually be exploited, connects weaknesses into attack paths, and helps prioritize the most urgently needed fixes. That answers the questions conventional scanners alone cannot: Is this exploitable? What can an attacker reach from here? And what should we fix first?

Further, our research shows models have different strengths. Unit 42’s multi-model approach applies the model best suited for the task, improving coverage and results while allowing us to continuously incorporate the strongest new capabilities as models advance. 

Human expertise remains at the center. Unit 42 combines these models with our offensive security experts, global Palo Alto Networks telemetry, and Unit 42 Threat Intelligence to turn model output into validated attack paths, prioritized remediation, and clear defensive action.

How It Works

Our Frontier AI Defense service uses the most advanced AI models to discover exposures, test whether they are exploitable, validate attack paths and help customers prioritize what to fix first, including: 

• Leading Cyber Models: Advanced AI applied to discovery, testing, and validation.
  
• Multi-Model Harness: Dynamic routing for stronger results, wider coverage, and managed costs.
  
• Exposure Discovery: Identification of vulnerabilities, misconfigurations, exposed credentials, and unmanaged attack surfaces across apps and networks.
  
• Advanced Adversary Simulation: Live exploitability testing and end-to-end attack path validation.
  
• Custom Remediation Plans: Prioritized fixes delivered directly into existing IT, development, and security workflows.

Security teams do not need more findings. They need to know which weaknesses lead to a viable attack path. Attackers do not think about applications, identity, cloud, and infrastructure in isolation. They look for ways to move across them to reach their objective.

By putting frontier models to work with Unit 42 experts, we can identify and validate those attack paths before attackers do, and help organizations close them first.

Visit Palo Alto Networks Frontier AI Defense to learn more.

The post Unit 42 Defends Organizations Against Next-Gen Frontier AI Risks with Anthropic’s Mythos 5 appeared first on Palo Alto Networks Blog.

Welcome to Issue #167 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I had a fantastic time at Hacker Summer Camp! Thank you to everyone who came to my Happy Hour, where we had nearly 300 registrants!

• I did an awesome panel with and on SIEM and security operations hosted by Decibel Partners. Shoutout to for wrangling us together and giving me the creative space to try something a little different with the format

  

• Last but not least, I hosted a Detection Engineering panel at the Blue Team Village with leading experts in the space: Christina Parry, Chris Kulakowski, Alex Hurtado and Chase Phelps. According to the organizers of the Village, it was one of the largest turnouts they’ve ever had. The line to get into the talk stretched well beyond the village.

  

Sponsor:

Your security architecture matters more than your AI model

Security vendors are racing to ship better AI models, but their architectures are dragging down their models. Even peak AI can’t overcome a limitation like a global detection model shared by all customers.

Join Josh Kamdjou (CEO, Sublime) and Dmitri Alperovitch (Co-Founder, CrowdStrike) on September 10 to hear why detection architecture determines what defenders can actually do to close gaps, and find out what it looks like when your platform can autonomously close gaps in hours, not on a lengthy vendor update cadence.

Register Now

💎 Detection Engineering Gem 💎

Every time I attend Hacker Summer Camp, I try to survey the thousands of talks and build a rough logistical plan on how I can attend them. The plan never works because Vegas is way harder to navigate between the casinos, taxi lines and long Uber waits, but if I can attend 20% then I know I’ve done well. So when I saw this talk on the HuggingFace incident by OpenAI security on the schedule, I got excited because it was featured on my newsletter and it spawned subsequent disclosures by other labs.

To the surprise of no one, I was too far away at an event to attend this specific one, so luckily Black Hat published the video :). I highly recommend watching or at least listening to the briefing. The security incident details are, IMHO, insignificant in the sense that they are nothing unique to what we haven’t seen before. The details behind the evaluation environment is the most fascinating.

We know that the Foundational Labs have model evaluation environments to help determine the efficacy of their newest model releases. Of those evaluations, OpenAI and many others run ExploitGym as a cybersecurity benchmark. OpenAI’s ExploitGym environment did not have Internet access to make sure it couldn’t cheat, but it could use internal resources and tooling, such as Artifactory listed below.

The OpenAI team runs thousands of reinforcement learning evaluations on these models, so they give what they call “impossible tasks” to agents to see how they perform. These tasks can include writing an exploit for a vulnerability, or performing some calculation in a Google Sheet that requires Internet access. This helps guarantee that the models don’t “cheat” by using the Internet and can perform the task at hand. The impossible task runs across May yielded three distinct things:

• Agent runs found file write access (I’m unsure if this is a vulnerability, it was hard to tell in the presentation) to Artifactory which created a pseudo-message board scenario. Agents used this message board to communicate with each other

• An agent found an SSRF in Artifactory itself, which gave it internet access to help solve the impossible tasks

• A separate agent found an RCE in Artifactory from a legacy auth endpoint, giving it command and control access to Artifactory

These three things are important, because OAI found this activity prior to the Hugging Face Incident. They patched the vulnerabilities and redeployed the infrastructure. The issue was that this data was held in the memory of subsequent agent runs because the data made it back into normal agent evaluations. So they had a memory that this was possible!

The agents used this exact memory to re-create the message board and the subsequent attack paths through Artifactory into Hugging Face. They found different vulnerabilities and were so obsessed with their “impossible tasks” that it resulted in a real world breach. The agents determined that Hugging Face contained the shortest path answer to completing their evaluations, so they found a deserialization vulnerability in how Hugging Face loads dataset evaluations and chained that with a Jinja injection vulnerability to gain a foothold into Hugging Face’s environment.

I highly recommend watching this, it was a trip and one of my favorite talks of the conference.

🔬 State of the Art

Threat hunt AI: How we built an AI security analyst on AWS for under $500/month by Pablo Vidal

This post by Vidal outlines how their detection & response team runs their autonomous hunting and triage agent. It’s built on Serverless architecture on AWS: agents run as a container on AWS’ Elastic Container Service Fargate, and the agent loads in several hunting and detection configurations via YAML. It uses Snowflake as their longer term storage for alert and telemetry data while using 2 weeks of log, metric and traces data on Datadog (yay!). It integrates directly with their alerting and investigation workflow via JIRA and Slack.

The interesting design choice here is the multi-phase investigation. Sonnet is used as their data gathering agent, while Opus compares potentially malicious behavior to one- and seven-day baselines. It’ll enrich suspicious actors and resources, scores confidence, then uses a separate Opus agent to perform adversarial validation.

The final adversarial phase must produce specific counter-evidence before it can dismiss a finding, such as an allowlisted service account or an established false-positive pattern. Vidal says this reduced noise from roughly 40% of findings to a level where most results are worth analyst review. The title does say it ran for under $500/month, but that is an additive spend since we don’t know what their Datadog & Snowflake spend is.

Introducing Deputy: Better signal and control for software supply chains by Kent Gruber

Deputy is a rule-based language for detecting and enforcing security controls on vulnerabilities found in CI/CD. I included this blog in particular due to its similarities with how security operations deals with threats. The tool introduced in the blog, Deputy, helps find and alert on potential policy violations when code is being introduced into a source code pipeline. It uses a YAML based language, and the rule language is CEL, which we’ve featured on a previous issue with Perplexity’s numbat project.

There are nearly 60 policies in the repository, and each policy has several rules each that help enforce the policy. Enrichment is a key component to the policy engine, Deputy precomputes values to pass along to CEL so the rule language can alert on things like critical vulnerabilities, the presence of a vulnerability in KEV or a new container image that contains a critical vulnerability.

According to Gruber, the project is early and it will not replace reachability or application-context analysis. But the policy and rule model is worth studying. Supply-chain controls are more likely to survive when the same decision logic follows developers, CI, package proxies, and coding agents, and it introduces the funnel of fidelity effect on an attack surface not traditionally monitored by security operations engineers.

Detection Skills by Vega Threat Research

Detection-as-code has gained a ton of popularity in the last few years because it helped build resiliency in the quality of a rule as it moved through ideation, implementation, review and deployment. These pipelines help do everything from linting, to applying governance checks around reviewers and deploying only via Terraform, as well as applied testing via Atomic Red Team and the myriad of other testing suites. Agent skills are the next logical step of adding security agent steering-as-code to triage, response and detection engineering agents in prod.

I ran into Eli Rozen at the Vega booth at Black Hat, and he showed me their research around Detection Skills. This is a great concept: as detection engineers, we need to think about codifying the investigative and analytic knowledge we use for alert triage and tuning as much as the detection logic we deploy everyday.

The Detection Skills OpenSpec is Vega’s contribution to the detection engineering world that helps keep the detection logic in the detection platform, then attach a portable  SKILL.md  package containing the triage, investigation, and tuning work surrounding an alert.

A detection can start with a deterministic query, invoke an agentic triage skill, pass its result to an investigation skill, then send the outcome to a tuning skill that proposes a change for human review. According to this spec, skills can bring focused references, lookup tables, prebuilt queries, and enrichment scripts without loading every detail into an agent’s context window upfront.

The Vega Threat Research team published 50 skills with this initial release, so it’s really cool to see them build in the open and share their knowledge with everyone else.

ATEN: Endpoint Telemetry for AI Coding Agents by Anton Ovrutsky

Over the last two weeks, I’ve featured “AI-EDR”-like releases from Perplexity’s Numbat & Uber’s ADR projects. The development of security telemetry on coding agents makes a lot of sense. They have agent in the name, so much like an EDR agent on a host or a CNAPP agent running in the cloud, you can extend Claude-et-al to generate contextual coding session telemetry. This is the first post I’ve read on the concept of AI-EDR that brings receipts of how it works during an investigation.

In this post, Ovrutsky releases his ATEN project which provides coding agent security telemetry. Unlike Numbat & ADR, it’s observe only, but there are some unique elements to it that differ from those two projects:

• It reads each prompt and creates an intent trajectory, meaning it’ll enrich the prompt with additional information such as tool calls, agent session and results. This helps create an index of sessions to answer the who later on

• It uses Kernel-level collectors (Windows ETW, Linux eBPF) that records the action taken on behalf of the above intent. These collectors focus on host and network telemetry

• It combines the intent and the Kernel telemetry into a full picture, reconciling the underlying action of the prompt and tool call with the on-system activity

He has several examples of running prompts and viewing the output in Splunk. The Splunk queries and subsequent responses expose the intent and action from the session and gives a much richer view into what happened.

For example, he issued a prompt to run a health check inside a code repository, and the health check was a PS1 script that ran additional Claude prompts. The process chain is a mess if you look at EDR or ETW logs, but with ATEN, you can follow the chain-of-thought via the intent and the kernel actions in one view.

☣️ Threat Landscape

Lol agentic cyber breaches and the hype train

I am trying not to be facetious here, but I do want to point out some news announcements of organizations besides OAI/Anthropic who are disclosing security incident breaches due to training models with no cyber guardrails. I think it’s important we keep reading about these for two reasons:

1. It demonstrates that we need to seriously consider an agentic or autonomous approach to defense, as we will likely expect more of this in the future

2. The absolute craziness that these incidents come across more as cool than “dude you just breached my company”

Incident Report: unsanctioned agent behaviour during cyber testing by AI Security Institute

The AI Security Institute was running cyber evals with Mythos 5 and GPT-5.6-Sol with guardrails removed and found that less than 10% of their runs contained evidence of models trying to solve a challenge by attempting to breach organizations outside of their institute. The crazy finding here, IMHO, is that one of the models tried to insert malicious code into an open-source project and engaged in social engineering with forged identities to try to get maintainers to merge the project.

They released an in depth technical report alongside their announcement. The one thing I don’t necessarily understand here is that their eval setup permitted Internet access. OAI and Anthropic, for example, explicitly restrict Internet access, because they issue impossible tasks where they want to evaluate how the model reasons through solving the task without trying to cheat.

Meta says its AI model breached a third-party company during testing by CBS News

It was very difficult for me to find a source blog for this story, but I learned that it’s because Meta never released one. Meta spokespeople reached out to several news networks and disclosed that one of their models broke out of their training environment during training and breached an AI safety company called Irregular. Funny enough, Irregular has no blog or post-mortem on the breach, so I hope we can see one soon and see how the discovered vulnerability was exploited.

Other news

Zoomsday by Idan Levcovich

Levcovich released a blog on several vulnerabilities found by the A research team in Zoom. The research details how Zoom’s annotation protocol allowed an attacker to send a crafted annotation message that crossed a role boundary, reached a victim’s deserializer, and triggered memory-corruption bugs in the shared cross-platform annotation library. The deserialization part is interesting: according to Levcovich, Zoom has an undocumented serialization protocol with annotations to help it transcribe drawings on screen. They abused this serialization to achieve remote code execution.

I like that they included the prompts they used to help target Zoom. They decompiled the APK app for Android, and ran a threat modeling prompt, and discovered a shared library that contained the serialization protocol. Zoom issued 3 CVEs, 2 specifically for A Security and one for a separate vulnerability they found but was already disclosed to Zoom security.

ExfilSquad: New Data Extortion Group Leaks Microsoft D365 Data, Likely Linked to Misconfigured Power Pages by Fortra

TIL what Microsoft Power Pages are:

Quickly create enterprise-grade AI-driven business portals with built-in agents. 

According to Fortra researchers, ExfilSquad, a new data ransomware group, exploited default configurations in Power Pages to gain malicious access and exfiltrate data from 15 victim organizations. ExfilSquad released data from 13 organizations, totaling roughly 382 GB and 27 million records. The leaked JSONL and CRM/ERP fields are consistent with Dynamics 365 exports, and Fortra found no evidence of ransomware deployment.

In the rush of pushing out as many AI products as possible, Microsoft likely didn’t consider threat models surrounding products like Power Pages. Default configurations are tough: we learned how to harden things quickly when we ran our own servers internally after years of pain. The hard part for me here is that when I procure a SaaS product or deploy a product from a cloud provider like Microsoft, I would expect more attention to detail that we trust them with securely deploying it.

🔗 Open Source

CDESpace/Detection-Skills

GitHub link to Vega Threat Research’s detection skills blog. Contains the full specifications and example skills to inject into your own agentic workflows.

Antonlovesdnb/aten

Anton Ovrutsky’s repository to his ATEN project, featured in the State of the Art section above. The markdown and general documentation is amazing, especially the attribution section which ties an agent prompt turn to a kernel level action.

seifreed/CipherRun

CipherRun is a Rust-based TLS scanner that combines protocol and cipher-suite analysis, vulnerability checks, compliance controls, and large-scale scanning. It tests every version of TLS from SSLv2 all the way to TLS 1.3. Some other useful features and enrichment include checking for nearly 20 vulnerabilities, JA3/JA4 hash analysis and even monitoring certificate transparency logs for alerts.

AsaEdgerunner/linux-terminal-mastery

Open-source course focused on the Linux terminal that progresses from beginner command-line fundamentals to power-user workflows. Not security-specific, but a clean resource to hand to analysts or researchers who need to get more comfortable using Linux.

Unit 42 is putting the latest frontier cyber models to work across customer environments to find, validate and help remediate the attack paths that matter most.

In May, we introduced Frontier AI Defense with a warning: the window to get ahead of AI-enabled attacks was shorter than most people realized. Since then, we have briefed more than 1,000 security teams around the world and introduced our Frontier AI Defense service to hundreds of customers.

Today, through our partnership with OpenAI, we are expanding Unit 42 Frontier AI Exposure Analysis to put advanced frontier cyber models directly to work in customer environments. Under Unit 42 direction, these models can find exposures, test whether they are exploitable, validate attack paths and help customers prioritize what to fix first.

Our early work shows why this approach matters: 36% of the exposures we identified map to no known CVE, often because they involve multiple gaps that have to be discovered, chained and tested together.

Bringing the Latest Frontier Cyber Capabilities to Defenders

Palo Alto Networks has been among a limited group of organizations with early access to advanced cyber capabilities from the leading frontier AI labs. Through our partnership with OpenAI, Unit 42 can now bring its latest advanced cyber capabilities, including GPT-5.6 Daybreak, to security testing and validation for our customers. Until now, GPT-5.6 Daybreak has not been available for commercial use.

Frontier models have helped inform the work of our experts. Now they can increasingly perform complex offensive security tasks directly, at machine speed and under Unit 42 direction. That allows us to go deeper than traditional vulnerability discovery by testing exploitability, reasoning across multiple weaknesses and determining how an attacker could use them to achieve an objective.

There is no single best model for every cyber task. Our research has shown that different models have different strengths and find vulnerabilities others miss. A multi-model harness routes work to the model best suited for the task, improving efficacy and coverage while managing the cost of frontier AI at scale. As stronger models emerge, we can incorporate them without rebuilding the offering around a single model or provider.

Unit 42 experts remain central to the process. We combine frontier models with our offensive security expertise, Palo Alto Networks telemetry and Unit 42 Threat Intelligence to validate findings, connect exposures into attack paths and understand what an attacker could ultimately achieve.

Built to Find What Attackers Can Exploit

The expanded service brings five capabilities together:

• Leading cyber models: Apply the latest advanced cyber models to improve exposure discovery, testing and validation.
• Multi-model harness: Use the right model for the right task to improve efficacy, expand coverage and optimize cost.
• Exposure discovery: Find vulnerabilities, misconfigurations, leaked credentials, unmanaged attack surface and other posture gaps across applications and network assets.
• Advanced adversary simulation: Actively test exploitability and validate end-to-end attack paths to understand how an attacker could compromise the environment.
• Custom remediation plan: Prioritize the fixes that break the most important attack paths and feed those findings into existing IT, development and security workflows.

Most security teams already have more findings than they can act on. The harder problem is knowing which ones create a real path to compromise. Attackers look across applications, infrastructure, identity and cloud for weaknesses they can combine to achieve an objective. Frontier AI Exposure Analysis applies that same adversarial perspective, helping defenders understand which paths matter and what to fix first.

The Asymmetry Runs Both Ways Now

For the past several months, frontier AI has been a story about what is coming for defenders: vulnerability discovery at scale, exploit chaining that sees full-stack logic no scanner catches, and attack cycles compressed to seconds from initial access to exfiltration.

All of that is still true. Our answer has been to put everything we learn testing these frontier models into the hands of defenders. Today, that gets more direct: not just what frontier models have taught us, but the models themselves, working in your environment for your defenders before those same capabilities are working for the attacker.

The window is still closing. We intend to spend it building on the side of the defenders.

Visit Palo Alto Networks Frontier AI Defense to learn more.

The post Putting OpenAI Cyber Models to Work for Defenders appeared first on Palo Alto Networks Blog.

Every Signal chat starts the same way: the client asks the Signal server for the public key associated with your contact’s phone number. But how do you know the server gave you the right key? A compromised server could provide a false public key, allowing the client to encrypt messages to an attacker rather than the intended recipient.

Until now, the only way to detect such malfeasance was to verify safety numbers with your contact in person or over a trusted channel. Signal recently launched an alternative: Automatic Key Verification, a feature that helps validate that your chats are secure without requiring direct safety number comparison. Trail of Bits built and operates one of the three auditors that make this system trustworthy. Our auditor, which is an independent implementation written from scratch, continuously checks that the Automatic Key Verification system behaves honestly.

How key verification works

Automatic Key Verification is a form of “key transparency” that makes mismatch attacks harder to hide by creating a globally consistent view of the set of public keys associated with each phone number. The Signal app now performs a periodic self-check to ensure that all keys stored in the global map for your account belong to your devices. If the app is unable to verify the log, or finds that not all keys are expected, the user is presented with a warning that “Automatic Key Verification is currently unavailable for your device.” Automatic Key Verification may also be unavailable for other reasons, as outlined in Signal’s documentation.

What our auditor does

Automatic Key Verification depends on external auditors. Trail of Bits helps this system function by providing external verification that the user ↔ public key map is globally consistent and well formed, and does not hide any entries. Each time a new entry is added, we update our local copy of the map, stored as a Merkle tree. Periodically, we sign the head of the tree using a signing key that only we know. Because we commit to only ever signing one consistent lineage of Merkle trees, clients know that they are seeing the same set of public keys as everyone else in the system. Clients currently require signatures from each of three auditors: one operated by Signal, one operated by Cloudflare, and one operated by Trail of Bits.

When Automatic Key Verification is turned on, the Signal client periodically fetches Merkle tree heads from the Signal key transparency server. The client requires that each tree head belong to a lineage endorsed by all registered auditors within the last seven days. If the server does not present valid auditor signatures, the client will raise a warning and Automatic Key Verification will fail. A fully malicious server may therefore maintain a split view of the system for at most one week before client applications start to display warning messages.

We chose to implement our auditor from scratch, based on the specification, to provide independent verification; the code is open source. Signal also publishes a reference implementation.

We will provide updates to this blog post if we need to make substantive changes to our signing policy, such as resetting the state of our auditor or rotating our signing key. Our current public key is:

7fe5d91de235188486d8fb836a6da37e625e2b10eb6d144185b9364cc83cbbb6

How to use Automatic Key Verification

You can enable Automatic Key Verification in Signal by going to “Settings > Privacy > Advanced” and enabling Automatic Key Verification. In supported chats, you can verify the public key of your counterparty by visiting the safety number verification screen and clicking “Verify Automatically.” Automatic Key Verification often does not support chats where you started the conversation by searching for a recipient’s username. See Signal’s help page for more information. If automatic verification fails, users should fall back on safety number comparison.

Why we’re doing this

We believe that free and private communication is a critical public good. We are not paid by Signal or any other party for this service; we operate it in the interest of users and the community broadly.

Some form of public key integrity is an important component of any full end-to-end encryption system. If you would like to implement key transparency or end-to-end encryption generally, contact us.

As organizations race to deploy agentic AI, legacy network security solutions are ill-equipped to keep up, forcing productivity tradeoffs while exposing coverage gaps. At the same time, Frontier AI is proving capable of discovering vulnerabilities and creating exploits in real-time. Navigating this shift requires more than incremental feature enhancements; it requires a bold, market-defining vision backed by relentless customer focused execution. 

Today, we’re proud to announce that Gartner® has once again recognized Palo Alto Networks as a Leader in the 2026 Magic Quadrant™ reports for both Security Service Edge and SASE Platforms. This marks the fourth consecutive year that Palo Alto Networks has been recognized, making us the only security vendor to be recognized as a Leader in both reports for four years in a row.

In this year’s Magic Quadrant for SSE, Palo Alto Networks was placed highest in ability to execute and furthest in completeness of vision for Prisma Access.

Every day we focus relentlessly on understanding the needs of our customers and channeling that back into products and services that create real value for them. Our product strategy centers on where our customers' environments and security needs are heading, not just where it sits today.

Vision Matters More than Ever in the AI Era

The AI landscape is changing daily - in this new reality, we strive to be the visionary leaders to serve our customers. GenAI and Agentic AI are exposing enterprises to novel categories of risks like prompt injection, over-privileged agents, and poisoned models. At the same time, Frontier AI is accelerating vulnerability discovery and attack speed resulting in attack timelines being compressed by over 95%.

Gartner projects that by the end of this year, 40% of enterprise applications will feature embedded agents, up from less than 5% today. And by 2028, 60% of brands will use agentic AI to facilitate streamlined one-to-one interactions. Operating a business in this new reality requires security architecture engineered to anticipate threats that haven't yet emerged. Success cannot be achieved by retrofitting legacy products with support for AI infrastructure. It demands a unified future-ready foundation that natively secures users, applications, sensitive data, and non-human identities across every touchpoint. The platform enterprises use today determines whether they'll be prepared for tomorrow's threats.

As the cybersecurity landscape undergoes its biggest shift in decades, to us, the Gartner recognition as a Leader on vision and execution across both reports means more than ever before. In our opinion, it not only validates Palo Alto Network’s ability to serve the world’s largest enterprises but also celebrates our strategic product capabilities as shaping the future of cybersecurity through industry leading innovation such as securing AI traffic flows and agents that simplify manageability of SASE operations.

Vision Backed by Relentless Execution

We believe being placed highest in execution and furthest in vision is only as valuable as the ability to execute on it, and Palo Alto Networks has a proven record of creating value for our customers. Our recent milestone of crossing the $1.6 billion ARR mark while growing 40% year over year for Prisma SASE reflects the trust customers have placed in us. Over 6,800 organizations, including over one third of the fortune 500, trust us because we consistently turn market-defining innovation into enterprise-grade reality. Our execution leadership is built on a strong foundation:

• Security powered by Precision AI: Our platform delivers universal zero trust through distributed and flexible enforcement points. We inspect traffic as close to the user as possible to ensure that whether your teams are at the corporate HQ, a remote branch, a coffee shop or working from home, they receive the same protection at their precise point of interaction.
• Unmatched performance and resilience: By leveraging global hyperscalers, we provide the massive scale and reach that modern organizations require. For specialized, high-performance and sensitive needs, SASE Private Location brings that same cloud-delivered resilience directly to private campuses.
• Unified platform: With a truly unified policy engine, data platform and operations, we ensure that as enterprises adapt to the future, our architecture remains an accelerator for secure productivity rather than a bottleneck. We accelerate vendor consolidation for enterprise customers, replacing fragmented legacy point products with a single platform that slashes operational overhead and reduces total cost of ownership (TCO) by up to 50%.

Building for the Future 

As the rules of cybersecurity are rewritten in real time, leading the market requires more than following past trends, it requires setting the trajectory. Our aim is to continuously be at the forefront of defining the future of cybersecurity to power the agentic enterprise of tomorrow.

Protecting with AI

Palo Alto Networks continues to innovate to keep enterprises safe at the speed of AI. Our Precision AI security service blocks over 30B threats every single day defeating sophisticated and highly evasive tactics. When combined with our virtual patching and IP defense security services, organizations receive proactive defense that secures at the speed of Frontier AI with flexible enforcement that provides consistent protection everywhere. We are delivering comprehensive security across network, edge, and cloud infrastructure to stop hidden threats that are invisible to traditional networks security solutions. 

This AI-powered defense in depth strategy operates across the entire attack lifecycle to enable proactive protection that shifts enterprise security postures from reactive incident response to preemptive defense. 

Securing AI 

Safely enabling employee adoption of AI tools and agents requires special considerations to mitigate risks around data leaks, intellectual property exposure, and compliance. Prisma SASE and Prisma Access solve these challenges by discovering all AI usage and agentic actions, enforcing granular least privilege access for human and non-human identities, and preventing exposure of risky data to AI and agents. Through AI Access Security™, Prisma SASE provides unified data security across the AI lifecycle by integrating GenAI app visibility and control, real-time prompt analysis, shadow data discovery, and  protection on endpoint. Prisma Browser provides a secure AI workspace that safeguards both human and autonomous agent workflows across any LLM by defending against data leaks, prompt injections, and agent hijacking. 

To secure the rapid adoption of AI agents by enterprises, Prisma Access will natively integrate with Prisma AIRS AI Gateway to provide a unified LLM, MCP, and A2A gateway giving security teams a single pane of glass for AI observability, cost governance, and runtime inspection.

This innovative approach represents an evolution away from traditional device and user centric fabrics towards an agent-aware platform capable of securing AI for the enterprise of tomorrow, today. 

Operating with AI

We continue to invest in capabilities that make our platforms proactive, efficient and easier to use. Our new deployment agents enable customers to onboard their SSE or SASE environment more efficiently, reducing their time to value while increasing productivity. Once onboarded, autonomous AI agents within Strata Cloud Manager continuously evaluate network and security posture to proactively identify configuration drift, performance degradation, and security policy gaps. By uncovering potential disruptions before they impact users or expose the organization to risk we’ve created automated systems capable of finding issues and automatically remediating them, with human-in-the-loop oversight calibrated to the administrator's comfort level, from guided recommendations to full autonomy.

The practical outcome is a dramatic reduction in mean time to resolution (MTTR) and a measurable reduction in total cost of ownership (TCO) while significantly reducing administrative burdens and making Palo Alto Networks products easier to maintain and operate.

Learn More

Download your complimentary copies of the 2026 Gartner® Magic Quadrant™ reports to learn why Palo Alto Networks has been recognized as a Leader in both SASE and SSE for the fourth consecutive year.

Gartner, Magic Quadrant for Security Service Edge, 29 July 2026, John Watts Et Al.
Gartner, Magic Quadrant for SASE Platforms, 28 July 2026, By Jonathan Forest Et Al.
Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.
Gartner and Magic Quadrant are a trademark of Gartner, Inc., and/or its affiliates.
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Palo Alto Networks.

The post Palo Alto Networks Recognized as the Only Vendor to be Named a 4X Leader in SASE and SSE Gartner Magic Quadrant Reports appeared first on Palo Alto Networks Blog.

Palo Alto Networks works closely with OpenAI across our product platform and Unit 42, leveraging advanced frontier model capabilities. Furthermore, we are a partner in the OpenAI Daybreak Cyber Partner Program, working with OpenAI to bring trusted, AI-powered cyber defense to more organizations. Today, we’re announcing native integration of Prisma AIRS Runtime API with OpenAI Codex. This milestone deepens our partnership and drives our shared mission forward: equipping defenders with the industry's most advanced tools.

AI coding assistants have transformed software development, accelerating shipping velocity and changing how engineers solve problems. But as integration of AI coding assistants deepens across development teams, security and compliance teams constantly struggle with enabling developer productivity while helping protect proprietary source code and credentials, and reducing the risk of runtime threats entering the codebase.

Streamlined Security in Minutes

We designed this integration to eliminate complex traffic steering and heavy client-side hooks. Securing your entire developer organization takes just a few clicks inside Codex Enterprise Management UI. Here is how you can enable it:

1. Retrieve Credentials: Generate your API key and endpoint from the Prisma AIRS management console.
2. Configure Codex: Paste the Prisma AIRS API key and endpoint directly into your Global Admin Console.
3. Activate Org-Wide Scanning: Once saved, all user prompts across your entire organization in Codex are automatically routed through the Prisma AIRS Runtime API for real-time inspection.

What Prisma AIRS Brings to OpenAI Codex

By connecting the Codex in ChatGPT for Enterprise workspace to the Prisma AIRS Runtime API, security teams gain comprehensive, automated security controls across two critical vectors:

1. Enterprise Data Loss Prevention (DLP)

Developers frequently paste context – logs, config snippets, or functions – into AI coding assistants. Prisma AIRS scans inputs to help identify sensitive data before it is submitted.

• Secrets & Credentials: Intercept API keys, hardcoded passwords, tokens, and private keys.
• PII & Financial Data: Automatically detect personally identifiable information and regulated data patterns.
• Proprietary Code & IP: Enforce custom pattern rules to help prevent sensitive internal code, architecture details, or trade secrets from being submitted.

2. Advanced Threat & Malicious Code Detection

AI prompts and contextual inputs can contain content that introduces security risks into development workflows. Prisma AIRS Runtime API inspects incoming developer inputs for:

• Malicious Code Patterns: Detect obfuscated scripts, dangerous command executions, or known exploit patterns within developer prompts.
• Malicious URLs & Links: Flag unverified, phishing, or malicious domain references before they influence generated code or enter internal repos.
• Prompt Manipulation Attacks: Detect adversarial inputs that may attempt to bypass system controls or alter model behavior.

Built for DevSecOps Alignment

Security controls only work if developers actually use them. Because the inspection happens at the platform administrative level via API, developers continue working natively in Codex without changing their IDE setup or downloading local hooks. SecOps gain centralized visibility, consistent policy enforcement, and audit-ready logging capabilities across the entire engineering organization, while developers keep the speed and experience they expect.

Key Takeaways

• Security as Invisible Infrastructure: Prisma AIRS integrates at the Codex administrative layer, applying security and DLP controls without requiring additional developer workflow changes. Developers can continue working in Codex while security teams maintain centralized policy controls.

• Unified Governance for Frontier Models: Prisma AIRS acts as an inline security layer that scans AI traffic in real-time before prompts ever reach the destination model. This architecture can help organizations identify sensitive information moving outward while detecting prompt manipulation and potentially malicious content moving into development workflows. If Prisma AIRS API detects a threat, a block verdict is sent to OpenAI Codex, and the prompt does not reach the destination model or MCP server.

• Organization-Wide Compliance: Deployment speed is a strategic advantage, not just an IT convenience. By configuring the Prisma AIRS API within the Global Admin Console, organizations can achieve org-wide governance without complex traffic steering. This can help development teams shift from unmanaged AI use toward more consistent, auditable security practices.

Getting Started

The Prisma AIRS integration helps organizations maintain consistent security controls while preserving the speed and productivity gains of Codex. Organizations can combine Palo Alto Networks’ security capabilities with OpenAI Codex to maintain centralized security and governance controls.

Choose your path forward:

• Attending Black Hat 2026: Stop by the Palo Alto Networks booth to check out the Prisma AIRS live demo.
• Ready to secure your rollout: Contact Prisma AIRS AI Security Experts to discuss your specific governance and deployment needs.
• Ready to build: Visit the Prisma AIRS Documentation to connect your endpoints in minutes.

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Strengthening Security of AI Coding: Prisma AIRS API Integration with OpenAI Codex appeared first on Palo Alto Networks Blog.

The enterprise workforce now operates almost entirely within the web browser. In fact, employees do roughly 85% of their daily work inside it, turning the browser into the sole operating system of the modern organization that connects every application, data interaction, and identity. Yet, for modern Security Operations Center (SOC) teams, the browser remains a frustrating and dangerous "black box."

While traditional Extended Detection and Response (XDR) platforms excel at monitoring endpoint hosts and processes, they treat the browser as a single, opaque process. This creates a critical visibility gap. According to research from Unit 42, over 90% of breaches are preventable by solving for factors such as visibility gaps. Because modern AI tools are predominantly accessed directly through the browser, it is now critical that SOCs get visibility into what’s happening within the browser. Leaving browser activity unmonitored forces your SOC to fight today's AI-driven workflows in the dark.

The Operational Fallout of Browser Blind Spots

SOC analysts frequently see alerts for malicious endpoint processes but lack the granular telemetry to pinpoint the exact web tab, malicious script, or user interaction that initiated the threat. This leaves incident responders blind to sophisticated tactics like rogue extensions and cross-origin attack chains, making it nearly impossible to reconstruct the full attack narrative.

When a security team operates with a fragmented view, a dangerous domino effect triggers the moment an attack strikes.

• The root cause is hidden as analysts frequently see alerts for malicious endpoint processes but do not have enough context. Lacking the necessary telemetry, the SOC is forced to take extreme containment measures and completely isolate the entire endpoint machine.
• In some cases, SOCs use third party investigation tools which create problems with disconnected context and long investigation times.
• What starts as a simple browser blind spot ultimately leads to an aggressive response that unnecessarily halts daily operations, disrupts user productivity, and floods the help desk with tickets.

Recent research on Palo Alto Networks customer incidents highlights the sheer scale of this problem, revealing massive monthly volume of Cortex threat detections stemming from siloed browser activity.

To eliminate this vulnerability, Palo Alto Networks is thrilled to announce the native integration of Prisma Browser and Cortex XDR.

Cortex XDR and Prisma Browser Better Together

By unifying deep browser-level telemetry with industry-leading endpoint detection, we are providing SOC teams with visibility into the user’s primary workspace, transforming the browser from an unmonitored process into an active security sensor.

Organizations can achieve the full benefits of this integration without complex APIs or heavy deployment overhead. Prisma Browser events including DLP violations, browser tampering, and unauthorized configuration updates are automatically fed directly into your Cortex tenant, making it incredibly easy to adopt this joint offering.

Moreover, when Cortex XDR raises an issue, browser-based events are correlated with the user’s malicious activity on the same endpoint, to add browser-based context and adding visibility to the possible starting point of the attack when it is initiated from the browser context.

What Makes Our Approach Different?

Many legacy vendors attempt to solve this problem using brittle, easily bypassed browser extensions that provide basic, surface-level visibility especially providing poor visibility into unmanaged devices. Palo Alto Networks takes a fundamentally different approach. Cortex XDR now integrates natively with Prisma Browser under the hood. This ensures both layers "speak the same language," turning a massive blind spot into a rich engine of security telemetry and visibility into everything from each user action to specific activities into their device posture while executing a particular activity..

True workspace security requires a unified defense system that understands exactly how web activity can impact the host device. This first-of-its-kind integration achieves this through three fundamental pillars:

1. Find the Root Source of Attacks in Seconds

Integrating Prisma Browser with Cortex XDR connects comprehensive endpoint visibility with deep web context. By seamlessly linking endpoint process execution directly to browser events and host execution, Cortex XDR provides an unprecedented unified data foundation that allows SOC teams to analyze complete attack narratives rather than isolated, disjointed issues.

SOC Teams Get Insights Into Attack Scenarios with Prisma Browser Investigation Panel

Scenario: Unmasking Phishing and Malware Narratives

When a malicious payload executes on an endpoint, traditional tools show the threat on the host but leave analysts guessing the source of the attack. By correlating Prisma Browser events directly with Cortex XDR eliminates this guesswork. Analysts can effortlessly trace a malware alert back to the exact phishing URL, original download source, or hidden iFrame metadata, uncovering the precise forensic root cause in seconds while easily dismissing false positives.

2. Respond Without Disrupting Business

Traditional XDR tools often need to disconnect a device to mitigate a threat. While effective at stopping lateral movement, it severely disrupts user productivity and halts business operations. The integration of Prisma Browser and Cortex XDR introduces granular, precision control.

For example, when a rogue browser extension attempts to compromise a web session, traditional tools are forced to isolate the device, forcing the employee offline, and disrupting daily operations. The integration of Prisma Browser and Cortex XDR introduces surgical containment instead. The threat is instantly neutralized and terminated only at the browser layer while simultaneously alerting Cortex, allowing the employee's laptop to stay completely online and productive.

3. Detect Evasive Threats in Real Time

Prisma Browser uses a pioneering approach to analyze activity in real time, detecting threats as they happen. This ensures that even the most sophisticated, evasive threats, such as rogue extension behavior or malicious script execution, are identified and flagged in real-time within your Cortex dashboard.

4. Securing GenAI Use Cases:

As employees rush to adopt GenAI tools, critical risks emerge, such as an engineer copying proprietary source code and pasting it into an unapproved, public AI model to fix a bug. To traditional XDR, this looks like safe, standard web traffic. Prisma Browser solves this by monitoring user behavior inside the workspace to automatically detect and block data loss prevention (DLP) violations in real time. Because it connects natively to the Cortex tenant without complex APIs, shadow AI risks are instantly flagged in the SOC dashboard before they turn into major compliance issues.

Future-Proof Your Workspace Security

Security operations can no longer afford to leave the browser unmonitored. By bridging the gap between what happens in the browser and activities on the endpoint, the integration of Prisma Browser and Cortex XDR accelerates investigation times, exposes hidden threats, and allows your SOC to respond with unprecedented precision.

New to Prisma Browser? Talk to your account team

The post Bridging the Gap: An Unprecedented Approach to Browser and Endpoint Security appeared first on Palo Alto Networks Blog.

As AI adoption shifts from experimental tools to the business core, enterprises are deploying AI agents and assistants across every department. Developers are accelerating software delivery with Claude Code and business functions are collaborating in Claude.ai, Claude Cowork, and Claude Design, using Anthropic's Claude to fundamentally rewire how they operate and drive complex, autonomous workflows across their most critical tasks.

Broad AI adoption has forced enterprise security into a difficult paradox: secure the business without stalling innovation. Today, security teams must answer three critical questions: How do we prevent sensitive data from leaking into AI models? How do we intercept runtime attacks, like prompt injection, before they execute? And how do we enforce these guardrails consistently across every AI interaction, in real-time?

We are thrilled to announce that Palo Alto Networks Prisma AIRS API now directly integrates with Claude Enterprise via inference hooks.

Key Takeaways:

• Synchronous Governance at the Speed of AI: Enforce critical runtime policy guardrails instantly before model inference occurs. By evaluating every Claude interaction in real-time, security teams can confidently enable high-speed AI innovation without introducing unacceptable risk or operational bottlenecks.
• Extending Proven DLP to AI Workflows: Safeguard PII, intellectual property, and proprietary code across all Claude environments (Claude Code, Claude.ai, Claude Cowork) seamlessly. By directly leveraging your organization’s existing enterprise DLP policies, you get consistent, unified data protection without the friction of managing disparate rule sets.
• Neutralizing AI-Specific Threats Proactively: Deploy enterprise AI with confidence by intercepting malicious activity before it executes. Proactively block sophisticated runtime threats, including prompt injections, jailbreaks, and toxic inputs, enabling your AI workflows to remain secure and your business operations uninterrupted.

How It Works

Setting up zero-trust governance for your Claude Enterprise environment takes just a few clicks:

• Configure Claude Enterprise: In your Claude Enterprise organization settings, navigate to inference hooks, set the hook endpoint URL to your designated Prisma AIRS webhook URL, and include your custom Prisma AIRS API key in the custom headers (x-pan-token).
• Activate Cryptographic Verification in Prisma AIRS: Claude generates a unique, one-time signing secret. You simply drop this signing secret into the Prisma AIRS UI.

Prisma AIRS securely stores the signing secret in an encrypted edge Key-Value Map (KVM) to cryptographically verify the authenticity of every incoming request before processing.

Unified Governance Across All Claude Surfaces

Before Claude reads a prompt, Claude POSTs the payload to Prisma AIRS, which evaluates the input against the configured security profile and returns a synchronous allow or deny verdict back to Claude.

Removing the Data Inspection Blind Spot

This Prisma AIRS integration natively leverages the Palo Alto Networks Enterprise DLP engine your organization already runs. Your current policies, custom definitions of "confidential," and compliance dashboards now instantly govern Claude. No redundant rule creation, and no new management overhead. Every prompt is classified in real-time, before anything reaches the model. Data Policy updates reach Claude the moment they reach everything else, and Claude events land in the same dashboards and audit reporting as every other channel. AI stops being the exception to your data protection strategy and becomes just another channel that is covered.

In practice, this helps prevent:

• Accidental exposure of PII and regulated data: a Social Security number, card number, or patient record pasted into a prompt is detected  on the spot by advanced RegEx patterns and ML classifiers,  with Exact Data Matching (EDM) recognizing your actual customer records.   When policy requires, Prisma AIRS enforces a deny policy to help keep Claude usage stays aligned with GDPR, HIPAA, and PCI-DSS requirements.
• Misuse of credentials in code: Developers working in Claude Code can't inadvertently submit hardcoded API keys, private tokens, or environment credentials into prompt context.
• Disclosure of confidential business matters. Document classifiers flag prompts touching M&A, legal, or HR material — even when they contain no identifier a pattern could match.

AI Safety & Runtime Threat Protection

Simultaneously, Prisma AIRS inspects payloads for operational risks specific to large language models:

• Prompt Injection & Jailbreak Attacks: Intercepts malicious attempts to manipulate model context or bypass system instructions.
• Malicious Code & Malicious URLs: Prevents execution or processing of untrusted scripts and risky links embedded within prompts.
• Toxic Content & Topic Guardrails: Enforces compliance with corporate policies and custom business topics.

If a prompt violates your security policy, Prisma AIRS issues a deny verdict. Claude immediately blocks the prompt, optionally presenting a user-facing explanation while returning a unique audit correlation code to your security telemetry dashboards.

Deploy Claude Without the Risk

The Prisma AIRS integration with Claude transforms security from a deployment bottleneck into a business enabler. You no longer have to choose between the operational control of Palo Alto Networks and the cognitive velocity of Claude.

Choose Your Path Forward:

• Attending Black Hat 2026? Stop by the Palo Alto Networks booth to check out the Prisma AIRS live demo.
• Ready to secure your Anthropic rollout? Contact Prisma AIRS AI Security Experts to discuss your specific governance and deployment needs.
• Ready to build? Visit the Prisma AIRS Documentation to connect your Claude inference hooks in minutes.

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov.  All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Prisma AIRS - Unified Data Protection for Claude appeared first on Palo Alto Networks Blog.

Welcome to Issue #166 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m on Day 2 of Hacker Summer Camp today! Yesterday was jam-packed with two great events. I helped lead a session on SIEM and Security Operations at Decibel’s Game Day, and we had a GREAT turnout at the Detection & Response Happy Hour. Almost 300 people signed up, and it was so great to meet people who read the newsletter and came to support!

• I’ll be walking the floor today and hitting up Olivia Gallucci’s talk on macOS Detection Engineering and an Agentic Detection session by two security engineers at Roblox

• My hotel lost my tshirt and stickers box. The FedEx in the hotel said the mail room has it, and the mail room swears that FedEx has it. So that’s gonna be a fun part of my morning :|
  

Sponsor: Material Security

Catching the phish was never the whole job.

Phishing's share of breaches hasn't moved in years, because that war’s been fought to a draw. Stolen sessions, dormant OAuth grants, and AI agents with more access than anyone tracks increasingly get attackers in instead. The perimeter held. The workspace didn't. See what detection looks like when it follows the attacker past the inbox.

See Workspace Security in Action

💎 Detection Engineering Gem 💎

How we secure Figma’s internal systems with agents by Matthew Sullivan and Brad Girardeau

Memory ended up being the thing that had the most impact on how useful the system became over time. We have several kinds, and keeping them separate turned out to be important.

What I love about reading modern security research in the blue team space is that as a community, we are applying more software engineering principles to security problems. This is why I love reading pieces like this, because it’s not just about agent design, but agent design for security operations AND it’s being used in the wild. The real contribution is not “agents for triage” in the abstract. It’s the claim that a security team’s value is in its expertise being recorded and reused instead of disappearing after an analyst makes a triage decision.

In this post, Sullivan and Girardeau reveal how Figma’s detection & response team built their own security alert triage orchestration system with a clever twist: encoding its efficacy and agent memories. Here’s how it works:

• For every alert triaged, they use a Retrieval Augmented Generation (RAG) to store analyst decisions, detection and alert metadata, investigative steps and memories for subsequent investigations

• When a subsequent alert is generated, their triage system queries the RAG database to search for similar alerts and uses that as context for the current investigation

• The agent posts a summary inside the Slack thread where the alert was used to page the on-call engineer, so when the engineer begins investigating, they have deeper context on how this was investigated before

• Once the engineer closes the alert, they update the Slack thread, which is then stored into the RAG system to create a closed loop

The team spent a lot of time describing their memory architecture and how it was the single best investment they’ve made to increase detection efficacy and reduce toil. Agent memory in this context is separated into three buckets: steering, procedural,, and case. Case memory is what you see in the picture above. Steering memory ensures an agent stays on track during an investigation, so it helps encode the agent's behavior during these steps. Lastly, procedural memory is the tribal knowledge that they store into agents as they navigate nuanced (see: janky) systems to make sure they know how to work with sharp edges.

I like to think about this type of setup as a “context pack”. LLMs thrive in context; it’s literally why they have a context window. Context engineering is a concept where you can inject instructions and knowledge into the context window to create consistency between agent runs. Figma’s three memory types, or context packs, ensure this consistency holds across the investigative, system, and behavioral steps of their alert triage.

The other thing to call out here is their confidence in letting agents create and tune detection rules. The memory each agent holds within each run helps steer the detection ruleset into a much more accurate state, but they do a good job of applying security boundaries so an agent is stopped right at the pull request, or when it tries to read Slack history or messages in channels that it isn’t explicitly allowed to read.

🔬 State of the Art

Securing Agents Across Perplexity’s Client Endpoints with Numbat by Perplexity

Coding agents are purposefully built to be non-deterministic. This non-determinism is what makes them fantastic at what they do. Personally, I have an agent for building and maintaining my home lab environment, a harness built for vulnerability research of malware and phishing panels and my agents at work that can orient themselves to codebases so I can get into a devloop for a service in a few minutes.

This non-determinism is what makes them dangerous, whether the intent was malicious or not. Last week, I linked to OpenAI & Hugging Face’s post-mortem on an unreleased OAI model breaching Hugging Face’s infrastructure. You’ll see in the threat landscape section below a similar announcement from Anthropic where it did nearly the same thing. I think the best way to secure your company against coding agents is not to assume whether they are malicious or not, but rather that they are untrusted.

Perplexity addressed this problem by releasing an open-source tool, dubbed Numbat, which is essentially an EDR plugin for coding agents. Coding agents expose rich functionality for hooking into their agents (Anthropic, OpenAI). These features are great for observability tracking but also double as a boon for security teams that try to track unsafe behavior for these agents. It integrates directly with over 10 coding agent harnesses and provides three security functions:

• Lifecycle hooks, which emit telemetry from events like tool use or filesystem usage on coding agents, which is useful for logging activity or blocking

• OTLP telemetry, which exposes an OpenTelemetry server that agents can submit logs and metrics to so it can be sent to a SIEM or logging platform

• Session artifacts, which help with forensics when an agent goes rogue, and you want to see how its context window led it astray (think of looking at raw prompt and response text)

The coolest part of this blog, though, is the rule language. Perplexity shipped an on-agent CEL integration, which is commonly used by Kubernetes operators to evaluate K8s control plane traffic, as their answer for logging and blocking. It reminds me of eBPF rules, where the agent emits an event, and the CEL connector reads incoming JSON and tries to match it against a rule to detect maliciousness. It has 52 (!) built-in rules located here, and it even supports correlated rule chains (check out this gnarly one for turning off agent guardrails, then the agent trying to egress data).

Latio Pulse

Detecting and Preventing the Hugging Face / OpenAI Incident

We link to some categories and companies in this blog, but this post isn’t sponsored in any way…

Read more

a month ago · 8 likes · James Berthoty

This week’s issue is certainly AI-security pilled. As we’ve seen from the Hugging Face/OpenAI & Anthropic disclosures, agent security is starting to decouple malicious intent from an agent’s execution. It’s not that intent matters; it’s more that our traditional models assume an attack inside your environments is likely the result of a malicious actor, and that doesn’t matter anymore. Attackers and agents both have goals; the difference is we allow agents to work inside our walled gardens.

My diatribe above is even harder to decompose when you have security companies shoving marketing down your throat. That’s why when I read this post from James, I was happy to see a practitioner’s approach to how the market can help against attacks like this. There are very few security market analysts I read and link in this newsletter, and James is at the top of my list.

James splits the Hugging Face/OpenAI attack into an ATT&CK-like chain, and helps readers understand what security product space could have helped detect or stop the attack along the way. He also presents these spaces as matter-of-fact: you don’t have to buy any of the products; instead, he frames it so that if you need to solve this issue, you can use those spaces as inspiration for your build-vs-buy decision. Honestly, this is the first analyst report I’ve read in a long time where I’d be happy to send this to my CSO :).

(by the way, if you haven’t subscribed to his Substack, please go do so!)

Deep-diving Crowdstrike’s DirectoryCreate by Daniel Koifman

EDR research posts like this tend to make my weekly reading because they help shed light on a very opaque product suite. In this post, Koifman aggregated CrowdStrike’s hundreds of logged event types and focused on a singular event: DirectoryCreate. What I love about this research is how focused it is. A seemingly tidy event tied to directory creation has a lot of nuance in how the telemetry is generated.

CrowdStrike’s sensor is developed as a minifilter, meaning it sits as a Kernel extension. In this scenario, when a user creates a directory, a user-mode function captures the request and calls the corresponding CreateDirectoryW. An internal manager creates an I/O request packet (a fancy way to say a data structure) and sends a structure called IRP_MJ_CREATE throughout the kernel extension stack until it hits CrowdStrike’s minifilter. This is different than hooking a function directly and it allows CrowdStrike to emit events for detection.

Koifman found several telemetry gaps using good-ol-Claude by creating 60 different ways to create a directory on Windows. I’m not a Windows expert by any means, but here’s what I learned from his findings that show how hard it is to reconcile telemetry from kernel to user-mode levels:

• Funny user-mode tricks to trick detections, such as specifying escaped or encoded paths, get resolved in the kernel. For example, if you pass a homoglyph into a directory string, the request packet normalizes the homoglyph to it’s true path in the filesystem. This means if you only look at the request packet for detection, you will likely not find obfuscation attempts

• There are many ways to create directories depending on how you interpret it. Things like renames, moves, recycle‑bin restores, and other lifecycle changes travel over a separate request packet  IRP_MJ_SET_INFORMATION and never surfaces as a  DirectoryCreate  event, so a folder staged in  C:\Temp  and moved into  C:\Sensitive  has no creation record at the final path.

• Reconciliation across events is just as important as precision on the singular event. CrowdStrike loses the attribution of who created the directory due to the IRP structure, so he recommends correlating that to a separate CrowdStrike event, which helps roll the process up to its original parent.

Sponsor: Rilevera

Make Your Detection Program More Resilient

Detection-as-Code is the core foundation for a resilient detection program.

Rilevera provides Detection-as-Code in the click of a button and gives you access to:

• Versioning & one-click rollback
• Peer review workflow
• Detection rule validation & efficacy reporting
• MITRE alignment mapping

Find us at Black Hat 2026 to learn more, or start a free trial now!

Get Started for Free

☣️ Threat Landscape

Investigating three real-world incidents in our cybersecurity evaluations by Anthropic

Following the Hugging Face/OpenAI breach, Anthropic’s security teams performed a retroactive review of their cyber evaluations to hunt for potentially similar malicious evaluations. After reviewing over 100,000 evaluation runs, they found three instances where their models gained unauthorized access to infrastructure that did not belong to Anthropic. I will say the three incidents weren’t as fancy as the Hugging Face breach, but it goes to show how these things don’t need to be fancy in order to be effective.

• In the first scenario, Claude discovered a real domain name and assumed it was part of the simulated environment, so it gained access via insecure application and database credentials

• The second scenario involved Claude publishing a malicious PyPI package in an attempt to gain access to a target company. This one was funnier to me because the model tried to obtain a phone number to register an account on PyPI and “..after failing to find a free phone number service, it tried—and failed—to obtain funds to pay for a phone number through several different means”

• The last one did an Internet-wide scan, or at least used a service like Censys or Shodan, to find over 9,000 devices. Of those devices, it found insecure credentials again, and exploited the infrastructure to help complete its evaluation

If you refer back to my analysis of Perplexity’s numbat tool above, I talked about intent with these agents. At the end of the day, these incidents were the result of positive, misguided intent baked into the instructions of Anthropic agents. The intent didn’t matter since it still gained unauthorized access.

Amazon identifies North Korean hacker group behind open-source supply chain attacks by CJ Moses

Amazon Threat Intelligence published a campaign analysis of DPRK-linked threat actors abusing the open-source ecosystem, especially npm packages. There isn’t anything too interesting or surprising there, but I think the more interesting part is that they claim the tactics are shifting from singular compromises to multi-staged, multi-package compromises.

Their malware TTPs follow the same trajectory as cybercrime malware I’ve helped research for years and years. Two things that stand out for me is the use of licensing within the malware itself, and anti-sandboxing features. On the licensing TTP, they essentially install a reverse dead man’s switch: the malicious component executes in the package, but it will only run after it checks in with a DRM-style licensing server.

Anti-sandboxing is interesting because it’s an obvious next step for folks who know how malware tries to evade defenses, but it’s a bit harder to do with an interpretive language than machine code. I think it’s fine that it can attempt to detect whether or not it’s in an analysis environment, but the whole idea of these packages is that they run in a developer context, which looks like a sandbox environment. I’d be interested to see how this actually works or if someone has a sample, since Amazon Threat Intelligence did not share any hashes.

Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack by Socket Research Team

A Shai-Hulud-style worm hit the keyv and cacheable npm packages, which have 150,000,000 and 10,000,000 weekly downloads, respectively. The initial access vector is unclear, but it does have a propagation element that steals discovered npm OIDC tokens and uses them to spread the malware. The malware has the same TTPs as most others in this space: it’ll steal cloud credentials and other keys and send them to attacker-controlled infrastructure.

The attacker-controlled infrastructure is the cool part here. Instead of a single hard-coded C2, the payload spins up fresh GitHub repositories via the API and uses commits and GraphQL  createCommitOnBranch  to stash stolen credentials, alongside a DNS-based exfil path for redundancy. It also plants autostart hooks in  .claude/settings.json  and  .vscode/tasks.json , so any developer or coding agent that opens the repo becomes infected.

The 73,000-server market reselling Western frontier AI into China by Lloyd Davies

I’ve read a lot about model distillation attacks, and there have been public accusations of the People’s Republic of China using unsanctioned access to Western frontier models to create their own open-weight versions. This is the first blog I’ve read that tracks the infrastructure that potentially makes this happen, and it reminds me of technique overlaps with residential proxy networks.

Infrawatch details the use of model transfer stations, where someone from a sanctioned country, such as China, can purchase proxy access to these models and pay a fee to use OpenAI/Claude and other Western models. These bridges consolidate their access to end users, and they use clever routing techniques from popular packages and coding harnesses like OpenRouter and LiteLLM to make it easy to use.

By operating this way, end users in China access the Great Firewall-approved infrastructure without touching blocked Western platforms, while those same platforms don’t block incoming connections from China because the proxy providers come from approved infrastructure.

🔗 Open Source

perplexityai/numbat

GitHub link to Perplexity’s “AI-EDR” project listed above in State of the Art. Check out the rules directory for some inspiration on detection opportunities for coding agent attacks.

uber/ADR

Uber open-sourced their own “AI-EDR” project dubbed ADR. The difference in this repository vs numbat is that they also released their own benchmarking datasets. This is great because it doesn’t only include tool call based detection and classification, but the conversations themselves.

Mihir4U-avi/GraphGulo

GraphGulo ingests pcap files and turns them into a locally run graph database for hunting and analysis. The cool part here is that it can run extremely fast queries and doesn’t run out of memory because it is backed by a Rust worker, making it easy to load in massive pcap files (the author boasts 10+ GB pcap files) with minimal impact on RAM.

supermhel/fengarde

Fengarde is a tool that takes disparate IT & OT logs from ICS telemetry sources, normalizes them over OCSF, and helps run Wazuh rules over them for threat detection. It normalizes and sends logs into OpenSearch, which Wazuh and several other SIEM providers support. It comes with 27 OOTB rules, and it’s cool to see what OT rules look like under the hood.

Nitro Enclaves and Key Management Service (KMS) feel like a natural fit: since the KMS can verify attestation documents generated by the enclaves, developers can offload key management tasks from their applications to the AWS-managed service. But integrating an external service with your trusted enclaves comes with new threats, even if that service comes from the same provider.

In this blog post—the third in our series on Nitro Enclaves, following our posts on attack surface and images and attestation—we catalog passive and active attack classes against the enclave-KMS communication channel, and cover the operational risks that persist even when the cryptography is correct.

Intro to KMS

The KMS is an AWS service that provides a unified public API for creating and managing keys backed by HSMs to the broader AWS ecosystem. There are three main key types supported by KMS that devs need to care about:

• Customer-managed keys (CMK)
• Data keys (DK, symmetric)
• Data key pairs (asymmetric)

CMKs never leave KMS. You request KMS to perform cryptographic operations (like encryption or signing) for you.

Data keys and key pairs are generated in KMS, are not stored in KMS, and are intended for programmatic uses.

For symmetric keys, the KMS gives you a plaintext key and the same key encrypted to CMK. Your application performs encryptions, removes the plaintext key, and stores the key encrypted to a CMK along the ciphertexts; this pattern is called envelope encryption.

For asymmetric keys, the KMS gives you a plaintext key pair and the private key encrypted to CMK. Your application creates signatures or encrypts data, deletes the private key, and keeps the public key and encrypted private key (along with signatures/ciphertexts).

Both types of data keys can be used with Decrypt operation to get plaintext keys again.

Access to keys is subject to authorization policies, including key policies, IAM policies, and grants. Cross-account access for keys can be enabled.

Keys can be identified in multiple ways: ARN, Id, Alias ARN, and Alias name. Keys are usually per-region (single-region), but multi-region keys can be created too.

Enclave-KMS communication

There are two mechanisms that are in play when integrating KMS with Nitro Enclaves:

• KMS policies restricting access to CMKs to specific enclaves (by PCR values)
• KMS encrypting responses to enclave’s public keys

In the first mechanism, the key policy may authorize access to only requests that contain fresh and correctly signed attestation documents with the expected PCR values. Enclaves have to generate attestations and include them in requests to KMS. Note that the enclave still needs IAM credentials to access KMS in the first place.

The second mechanism is about enclaves sending asymmetric public keys (inside the attestation documents) to KMS, and KMS encrypting part of the responses to the key. This mechanism is supposed to ensure that only the requesting enclave can see output from KMS.

Only a few KMS operations support these two mechanisms. The operations are:

• GenerateDataKey, GenerateDataKeyPair
• Decrypt
• DeriveSharedSecret
• GenerateRandom

Note the absence of the Encrypt operation: enclaves can request this operation, but without the attestation-based security mechanisms. CMKs cannot be used directly by enclaves for encryption without missing on the attestation checks. This means cryptography operations are supposed to be implemented via data keys, and not directly via CMKs.

Use cases

KMS can be integrated with Nitro Enclaves for various reasons: for application-specific needs, to sign enclave image files (EIFs), or to increase the entropy available in the enclave.

The application-specific use cases are based on KMS’ ability to verify attestation documents, which in turn enables developers to write KMS authorization policies based on PCR measurements from the attestation. A common use case is implementation of authenticated external storage for the enclaves. When access to KMS keys is restricted by PCRs 0-2, only a specific enclave version has access to the keys.

Enclave image files can be signed. Any signing certificate (private key) can be used for the task, but the officially supported ways include signing with a key stored in a local file, and via KMS. The signing certificate used for the EIF is then exposed as PCR8. This PCR can be used in KMS policies. This feature lets one to restrict access to KMS keys to enclaves created by the same developer, while developer identity is protected by the KMS too.

Finally, the GenerateRandom method of KMS can be used to add more entropy to the enclave. While not critically important – enclaves already have access to high quality entropy from the hypervisor – additional randomness may increase trust in the system. On the other hand, one may argue that the added complexity exceeds the benefits. No strong opinions here.

Passive attack prevention

Threats to the enclave-KMS communication can be divided into two categories: passive and active. Passive attackers can observe traffic and modify data that is stored outside of the enclave and is not attested (data at rest). Active attackers can additionally modify all traffic coming in and out of the enclave (traffic on the network).

The exact landscape of passive attacks depends on specific system design, but KMS operations allow us to reason about them fairly well, as an attacker can control any and all of the inputs to these operations. This tl;dr checklist helps avoid passive attacks:

• Requests to KMS always contain the Recipient parameter.
• Encryption context is used for supported operations.
  • Context is decided by enclaves, and is not fully attacker-controlled.
  • Encrypt and GenDataKey operations are authorized properly.
• Data encrypted with data keys has context.
  • Key commitment is considered.
• Correct CMK is used.
  • CMK ARN is hardcoded.
  • keyId from response is checked.
  • Decrypt requests always specify key ID.
  • IAM role is attested.
  • Full ARNs are used, key aliases are not used.
• Freshness/replay attacks are mitigated.
• Side-channel attacks are considered.
• Key types and cryptographic algorithms are validated.

The Recipient parameter includes attestation, which allows KMS to validate PCRs. If key policies are correctly configured, requests without this param fail, so it is rather hard to miss.

A single CMK key can be used to generate multiple data keys and shared secrets. Since the encrypted data keys are stored outside of the enclave, an attacker can swap them. It is therefore important to cryptographically distinguish the ciphertexts, and the encryption context is one of the ways to achieve that. Importantly, this solution works only if the attacker does not have full control over the encryption context; if they do, they can swap the ciphertext blob while also making the enclave use the wrong context.

Below are diagrams for simple “data swap” attacks that encryption contexts can prevent.

Passive attackers that can call Encrypt (or ReEncrypt) on a CMK can perform an even more severe version of the attack above and swap the DK-ciphertext pair with a custom one, effectively providing arbitrary plaintext to the enclave. The same issue applies if an attacker can call GenerateDataKey. Note that some cases may require authorization to these operations for non-enclave entities, but this authorization should be revoked after the initial setup.

The attacks we’ve discussed so far have been on the “envelope” level. Similar issues exist on the DK level if a DK is used multiple times (though this rarely happens). These issues should be solvable with correct encryption context implemented via AAD.

Some funky attacks are possible if an algorithm without key commitment property is used with data keys: an attacker can generate a single ciphertext that correctly decrypts under different keys. Though this is unlikely, the key commitment should be considered as part of a security audit.

The next class of attacks is when the host can select CMK that enclave uses. The exact nature of the attack depends on specific degrees of freedom, but in the worst case, the host can force the use of a completely unprotected CMK.

To protect against these attacks, the enclave must ensure the expected CMK is used; this can be done by hardcoding full ARN, so it is attested. Then the attested ARN must be provided as the optional keyId parameter in Decrypt requests, and validated against keyId from KMS responses. Note that the keyId param is optional, because CiphertextBlob includes a reference to the CMK as metadata (HBKID in Appendix A): the metadata is not cryptographically protected, and the attacker may be able to manipulate it.

Using key aliases instead of ARNs is possible but risky, as the aliases are more ambiguous. Specifically, an attacker can manipulate the enclave’s IAM credentials to trick the enclave into using the wrong AWS account or AWS Region and therefore a wrong CMK. That’s why we recommend attesting the IAM role that the enclave must use and validating that role against IAM credentials provided at runtime. The enclave can do this by calling sts:GetCallerIdentity.

Replay attacks are an interesting attack vector. Attestations include timestamps that KMS validates to be at most five minutes old. While this means old documents cannot be replayed, there is still a time window when a malicious host can observe a document and use it multiple times. As attestations are not cryptographically bound to the requests, the attacker can use the attestation with any supported operation with arbitrary params. Although the responses are encrypted with the attestation’s public key and cannot be decrypted by the attacker, this gives the attacker some abilities that must be considered during an audit. For example, an attacker can request multiple decryption with different CMK keys and later use the KMS responses to confuse the state machine of the enclave. Note that the user_data and nonce fields from attestation documents are not used by KMS at all.

Even when an attacker cannot observe exact traffic exchanged with KMS, the attacker can note times, orders, and sizes of communication. This may be used to deduce some information, depending on the specific protocol your enclaves implement.

Finally, requests and responses to KMS include many key specifications and algorithm identifiers (CMK KeySpec, attestation’s KeyEncryptionAlgorithm, Decryption operation’s EncryptionAlgorithm, for example). Ideally these must not be attacker-controlled in requests (e.g. are bundled in EIF) and the identifiers from responses are checked against the expected ones by the enclave.

Active attack prevention

As a reminder, active attackers can additionally modify all traffic coming in and out of the enclave. This tl;dr checklist helps avoid active attacks:

• Active attacks are prevented with enclave-initiated TLS.
• TLS CA is bundled inside the enclave (attested).
• VPC is used.

Many problems may arise when active attacks are in scope. Most importantly, the attestation and its pubkey are not bound to other parts of the request. This allows the attacker to change the CMK ID in requests and responses (even if the ID is bundled in EIF); to encrypt any data key under the attestation pubkey and use it for replays; or to attack not-authenticated AES-CBC encryption in CiphertextForRecipient responses.

These vulnerabilities are basically unsolvable without a secure communication channel. Therefore, TLS initiated inside the enclave is required if active attacks are in scope. For the enclave-initiated TLS solution to be secure, the enclave’s CA set must be limited; ideally, the KMS’ CA certificate (Amazon’s) is attested and pinned.

With this setup, the active attacker threat may be considered prevented. Note that having a secure communication channel implicitly prevents some of the possible vulnerabilities described in the “passive attacks” section.

KMS terminates TLS outside of HSM (most likely), and the attestation’s pubkey encryption is probably done outside of HSM. This makes it impossible to have an end-to-end TLS channel between enclave and HSM, and AWS insiders may theoretically constitute an active attacker threat. Your threat model should account for this possibility.

To further protect the communication channel, VPC can be used. This ensures that traffic never leaves AWS infrastructure and generally isolates the parent EC2 at the network level. Moreover, key policy can authorize requests based on the VPC. This makes attacks easier to detect in case of stolen IAM credentials; this is valuable even if key access is authorized via PCRs, as demonstrated in the previous sections.

KMS policies

Correctly authorizing access to CMK keys is critical. The list below includes basic checks for your KMS key policy. AWS’ recommendations for IAM policies provides more generic advice.

• Configured KMS policy authorizes enclaves in a reasonable way.
  • No unexpected IAM roles have or can get access.
  • PCR0 is used for authorization. PCRs 1-2 are used for defense in depth. Alternatively, PCR8 is used.
  • Principal for RecipientAttestation is not a wildcard.
  • PCR3 is used to restrict by EC2 IAM role.
  • kms:EncryptionContext condition is used when relevant.
• For critical key operations (e.g., deletion) the policy requires MFA.
• TLS and VPC restrictions are considered.
• For end-to-end security, the clients can verify that the enclave uses correct and properly secured KMS keys.
  • Immutable key policies are likely not possible, and clients must be aware of this.

Of course, the exact CMK policy setup is business-dependent. Generally, you should ensure that the key can be managed only by the expected IAM principal, and the principal doesn’t have access to Decrypt operation (and possibly others like GenDataKeys and Encrypt).

The figure below shows an interesting example of a vulnerable key policy that violates the “only expected IAM principal” check. One may assume that only the root user and the enclave can operate on the key, but this is incorrect: the first policy entry grants full access to any IAM role that has access to the key configured in the role’s policy. The fix is to use a specific IAM user or role instead of root or to add an explicit deny statement for non-root users.

[
 {
 "Sid": "Enable IAM User Permissions",
 "Effect": "Allow",
 "Principal": { "AWS": "arn:aws:iam::599412696120:root" },
 "Action": "kms:*",
 "Resource": "*"
 },
 {
 "Sid": "Allow Nitro Enclave KMS operations with PCR0 lock",
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::599412696120:role/NitroEnclaveKMSRole"
 },
 "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:GenerateDataKeyPair"],
 "Resource": "*",
 "Condition": {
 "StringEqualsIgnoreCase": {
 "kms:RecipientAttestation:PCR0": "00a119d1...0ed55"
 }
 }
 }
]

For the PCRs, you want to use PCR0, as it binds the policy to specific enclave code. Additionally, using PCRs 1-2 is recommended for the reasons stated in our blog post on the Nitro Enclaves attack surface. Alternatively, you can use PCR8, which allows updating the enclave code without needing to update key policy. This allows more restricted access to key policy modification permission at the cost of managing the signing key.

The Principal field and PCR3 measurement provide further restrictions. Principal is used to authorize the IAM role used to access KMS, while PCR3 is measured by hypervisor at the time of enclave launch based on EC2 role. The EC2 role can be dynamically changed and should be considered untrusted from the enclave’s perspective. Yet both Principal and PCR3 can be used to prevent attackers from running (signed) enclaves on their own EC2 instance (which could make side-channel attacks easier) and accessing the KMS key.

Access to the key can be further improved with TLS and VPC restrictions. VPC can be enforced with aws:SourceVpc and similar condition keys. TLS can be enforced with the aws:SecureTransport condition (although this condition is redundant, as it’s not possible to access the KMS API with plain HTTP).

As the key has to be manageable by some IAM role (at least to allow key deletion), the aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge conditions can be used to strengthen the authorization.

KMS policy end-to-end verification

So far, our discussion has focused on how to secure the KMS keys. A much more difficult problem arises when you want your system to provide end-to-end verifiability to end-users. If enclaves can be reproducibly built and remotely attested by users, then users likely have to validate that the KMS keys are properly protected, too. Otherwise, a malicious insider can pass remote attestation (not modify enclave code), yet use KMS directly with IAM permissions to get full access to the keys.

One solution is to hardcode the hash of the key policy in the enclave, provide full policy along with enclave’s code to clients, and make the enclave validate the hash against the dynamically obtained policy before sending attestation-protected requests to the KMS. This requires the enclave to have kms:GetKeyPolicy and kms:DescribeKey permissions.

This alone doesn’t prevent attacks. A malicious IAM user can dynamically change the policy after the enclave’s verification. To prevent this, the policy has to be made immutable, which can be achieved by blocking kms:PutKeyPolicy permission for all users. Note that --bypass-policy-lockout-safety-check flag is required to insert such a statement via CLI.

{
 "Sid": "DenyPutKeyPolicyForAll",
 "Effect": "Deny",
 "Principal": {
 "AWS": "*"
 },
 "Action": "kms:PutKeyPolicy",
 "Resource": "*"
}

Locking access by PCR0 and denying all kms:PutKeyPolicy operations makes the system quite immutable. This has the obvious downside of making updates and bug fixes difficult. As mentioned earlier, the specific setup must be adjusted based on business requirements.

Note that key owners can always contact AWS support to restore default key policies. How AWS authenticates such requests I do not know, but AWS likely won’t check if the key is used in an enclave-enabled setup. This makes a system with full end-to-end trust hard to implement.

Finally, consider implementing publicly observable and verifiable monitoring and alerting for key policies. Such a system would alert end users when a policy changes, mitigating the impact of policy restoration by AWS support. However, we are not aware of any “Certificate Transparency”-style public, append-only log for KMS key policies that an external party can independently verify.

Operational concerns

Even if the system is secure point-in-time, there are operations that must be periodically performed. These introduce new risks into the system. This checklist covers these concerns:

• Key rotation and revocation is implemented for CMK.
  • ReEncrypt operation is not used for data keys.
• Backups:
  • Risks from CMK destruction are mitigated.
  • Regional outages are considered.
  • Data keys are backed up as needed.
• Users cannot cause a denial of service or balloon the bill.
  • The number of user-triggered KMS operations is limited.
  • Request quotas are considered.
  • Limits on data lengths are respected.
  • KMS’s clients take into account delays in KMS updates.

AWS provides mechanisms to easily rotate CMK keys. The only item to note here is that rotating a compromised CMK does not make data keys protected by it non-decryptable. For a CMK revocation, a more involved approach than just rotating CMK and destroying data keys must be implemented.

Rotating data keys is hard to implement securely, as the KMS ReEncrypt operation does not support attestations. The system should be designed so that such rotations are not needed.

A malicious actor deleting CMK keys permanently creates a risk of non-recoverable system state. The system’s design can sometimes be made so that destruction of a single key is recoverable (e.g., by setting up key hierarchy and using secret sharing). Nevertheless, there should be security controls in place mitigating the risk. First, configure a scheduled deletion period for keys to a time in which your team can act on an incident. Set up CloudWatch alarms for KMS keys for deletion events, and tighten IAM policies with Service Control Policies that prevent KMS key deletion.

Single-machine disasters in AWS infrastructure are not a concern, as single-region KMS keys are replicated within the region in multiple Availability Zones in multiple HSMs. However, if the system must be resilient to a regional outage, multi-region keys should be used instead of single-region keys.

Encrypted data keys backups are a responsibility of the system, not AWS. Note that the CMK key may become unusable in a few scenarios, and the data key backup system must account for this.

Yet another set of risks relates to billing. AWS charges dollars per KMS operations and CMK key maintenance, so the system must not let end-users make the enclaves send arbitrary many requests to KMS. When implementing rate-limits, KMS quotas must be taken into account.

Inputs to KMS have various size limits. For example, plaintexts can be up to 4096 bytes long, ciphertexts can be up to 6144 bytes long, and key IDs can be up to 2048 bytes long. These limits are unlikely to be reached with attestation-supported operations, but still should be considered.

Finally, changes to KMS resources need some time to propagate and synchronize inside AWS infrastructure. Your system must expect delays and possible temporary inconsistencies when requesting KMS.

Software and SDKs

Amazon ships a lot of SDKs for various tasks. Among them is aws-nitro-enclaves-sdk-c that provides tools and a library for enclaves-KMS communication. Avoid it: this particular SDK is written in C, and we found it contains vulnerabilities that can be used to exploit enclaves from the parent host.

Rather than using the aws-nitro-enclaves-sdk-c, we recommend a combination of other libraries, such as the following:

• aws-nitro-enclaves-nsm-api (in Rust) to get attestation documents
• KMS.Client from Boto3 (in Python) to communicate with KMS
• Any cryptographic library to parse and decrypt responses

Final notes

Many issues can arise from misusing the KMS within enclave-secured systems. This blog post does not even cover all supported operations (GenerateDataKeyPair, DeriveSharedSecret), possible vulnerabilities (key reuse, key wearout, forward secrecy, nonce management, …) and system features (custom key stores, multi-region keys, …). Make sure to document your system’s protocol, have a cryptographer review it, and check the actual implementation against it.

Appendix A

Data formats of the CiphertextBlob and CiphertextForRecipient structures are presented below.

Modern enterprise security is at a pivotal moment where CIOs and CISOs have a clear opportunity to build a cybersecurity architecture for both today’s environment, and for the future. Doing so requires redefining enterprise resilience across three critical dimensions. 

First, Frontier AI driven threat velocity and novelty. Frontier AI models have automated the entire attack lifecycle. Adversaries aren’t just compressing exploit windows to near-zero timelines, they are also generating novel, highly evasive threats at machine speed, bypassing traditional signatures and often before patches are generated. 

Second, surging network traffic is overwhelming traditional defenses. Driven by AI workloads, inter-datacenter traffic will nearly triple¹ over the next decade dramatically expanding the volume of data teams must inspect and secure. 

Finally, major shifts are forcing a “cryptographic reset.” Shrinking certificate lifecycles, internet-scale distrust events, and quantum computers powerful enough to crack public key cryptography are combining to shake the foundation of all digital communications. 

Meeting these challenges requires more than incremental fixes. Today, we are proud to introduce PAN-OS 12.2 Ceres, a landmark release representing a major leap forward in network security. 

Ceres brings to market 55+ innovations, including three flagship, core capabilities, designed to shift the balance of power back to defenders.

Introducing Frontier Virtual Patching: Preemptive Defense Against Frontier AI Exploits

Today, Palo Alto Networks is giving defenders the ultimate advantage with the launch of Frontier Virtual Patching. By harnessing Frontier AI to discover unknown vulnerabilities, and deploying protections in hours, we are collapsing the exposure window from the industry-average 55 days² it takes to deploy a traditional patch down into a near-zero window of exposure. This isn’t just about faster patching; it’s about eliminating the attacker’s chance by neutralizing exploits before they ever reach your network.

The new reality: Exploitation far outpaces patch deployment

We’ve built this capability as a collaborative, force-multiplying ecosystem, with our industry partnerships across the enterprise software and OT vendor landscape to accelerate vulnerability disclosure, remediation and customer protection. This includes our collaboration with Project Lightwell, which combines our rapid network-level protection with software remediation to help organizations reduce exposure to emerging threats. We’re also partnering with vulnerability clearinghouses, software maintainers, and industry initiatives to continuously expand a real-time pool of protected vulnerabilities.

This approach builds on recent Unit 42 research, where the autonomous AI system NOVA identified more than 14,000 previously unknown vulnerabilities in just two months – a clear signal that defenders must pair AI-powered discovery with equally fast, coordinated protection. We have built an all-new detection engine, “vaulted protection," that enables us to deliver these rapid protections in a safe and responsible manner. When one participant identifies a threat, the entire ecosystem is protected instantly. Individual discovery becomes global protection. 

This is especially valuable for operational technology (OT), critical infrastructure, healthcare, and IoT: environments where systems can’t be taken offline to patch, where patch cycles can stretch for months, and where a single unpatched device can expose an entire network. Frontier Virtual Patching closes that gap in the network, blocking the exploit without applying a patch, rebooting a system, or causing any downtime to critical operations.

Bad actors will lean into Frontier AI to reduce the attack lifecycle from months to minutes. To keep pace, organizations require security partners to match that machine speed. To this end, Palo Alto Networks is raising the bar with its Frontier Virtual Patching, moving beyond compensating controls. By safely and efficiently discovering undisclosed vulnerabilities and deploying protection long before traditional patches can be rolled out, Palo Alto Networks deep security capabilities are flipping network defense from a reactive to proactive operational model.

Will Townsend
Chief Analyst, LoneStar Advisory & Research

And for existing Palo Alto Networks network security customers, getting started is effortless.  Frontier Virtual Patching is available as a PAN-OS software upgrade with persistent, automatic content updates, so protections keep arriving as new threats emerge, with no new hardware and no manual intervention. 

Clearly, Network Security is evolving quickly. Frontier Virtual Patching is part of a huge set of innovations that the team at Palo Alto Networks is delivering in PAN-OS Ceres 12.2 to enable you to stay protected.

Advanced IP Defense: Blocking attacker infrastructure before they can strike

Modern threat actors continuously work to hide their attacks and evade existing controls. Adversaries are increasingly evading traditional perimeter detection of their command-and-control traffic by leveraging direct-to-IP connection techniques that bypass DNS and URL inspection entirely. Attackers are also weaponizing massive proxy networks and hundreds of thousands of residential IP addresses to conduct stealthy, large-scale scanning, brute-force attacks, and exploitation that bypass traditional defenses such as IP reputation and blocklists.

To counter this, Palo Alto Networks is introducing a new preventative solution, Advanced IP Defense, with three powerful new capabilities:

• Real-time IP-layer intelligence. We leverage global telemetry from over 70,000 customers to track and block attacker infrastructure inline across the entire attack lifecycle. Our researchers track these threats 24/7, so your team doesn’t have to.
• Zero-Trust IP enforcement. We don’t just look at an IP’s past reputation. We verify the intent of the connection itself. By validating that every network connection maps to a legitimate DNS resolution, we provide a critical guardrail against attackers attempting to evade detection.
• Powerful IP-layer context. We continuously monitor every connection across more than 40 distinct security attributes, letting you proactively shrink your attack surface and block high-risk traffic from the internet’s “bad neighborhoods” with confidence.

The transition to the Frontier AI era isn't a distant future. It’s happening right now. The organizations that thrive won't be those trying to run old, reactive playbooks faster; they have to scale their defenses to match a whole new velocity of risk. When threats occur at machine speed, relying on human-scale operations is no longer an option. That is why AI and automation are becoming essential tools to meet these challenges head-on.

Varinder Singh
CIO, NXP Semiconductors

Network Security Agents: Making admins superhuman

When threats execute in minutes, human-only operations become a bottleneck. To reduce fatigue and accelerate response, we’re launching an elite suite of AI agents for every major role a network administrator performs.

These six specialized AI-powered Network Security Agents, available through Strata Cloud Manager, are trained on your enterprise context and operational workflows. From onboarding and configuration to threat assessment and troubleshooting, they automate the hundreds of routine, repetitive tasks that consume an admin’s day. And you stay in control: for each workflow, you choose the level of oversight that matches your risk tolerance — human-in-the-loop, human-on-the-loop, or human-out-of-the-loop.

Expanding platform protection across every edge

Securing the modern enterprise means extending these AI-powered capabilities across every surface, from data center cores to remote industrial sites, and from custom AI applications to the web browser.

Today we’re introducing PAN-OS Ceres 12.2, which, in addition to the innovations above, expands our platform across five more areas:

• Quantum-safe & next-generation trust security. Automates digital certificate lifecycle management and accelerates post-quantum cryptographic readiness, including a cryptographic inventory spanning network security, endpoint, SIEM, and vulnerability management integrations for a complete view of enterprise readiness.
• 5th-generation ML-optimized hardware. New high-performance PA-Series firewalls equipped with 400G interfaces, and 300 Gbps of threat inspection, and active clustering, these platforms eliminate capacity limits for AI-era data centers. These firewalls also  scale to 1.4Tbps of throughput while delivering 5-microsecond latency ensuring peak performance. 
• Modernized OT & critical infrastructure defense. Purpose-built PA-50R ruggedized 5G firewalls that extend real-time, AI-powered threat prevention to remote, extreme-environment OT networks and critical infrastructure.
• AI and agent security. Prisma AIRS is now delivered as a scalable, cloud-native service explicitly engineered to secure AI models, applications, and autonomous agent workflows. The same platform on which we built CloudNGFW has now been extended to provide security for AI with the addition of Prisma AIRS.
• Browser-to-firewall integration. Imagine the browser as a secure fast-lane that doesn’t just protect users, it empowers them. By integrating Prisma Browser with our NGFWs, we’ve eliminated the need to decrypt on the endpoint while delivering full Layer 7 protection. This is proactive security that neutralizes threats before they can even touch your network. For security admins, policy is fully unified from device to network, delivering a streamlined, automated experience.

The path forward

We are investing heavily in the innovations you need to defeat today’s threats while future-proofing your enterprise for tomorrow.

The transition to the Frontier AI era demands a bold strategy. The winners will be the organizations that adopt a prevention-first architecture capable of stopping threats long before weaponization occurs. With PAN-OS Ceres 12.2, Palo Alto Networks is giving defenders the speed, scale, and platform foundation to turn the tables on modern adversaries.

Forward-Looking Statements 

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. Any unreleased services or features (and any services or features not generally available to customers) referenced in this or other press releases or public statements are not currently available (or are not yet generally available to customers) and may not be delivered when expected or at all. Customers who purchase Palo Alto Networks applications should make their purchase decisions based on services and features currently generally available.

​​Sources: 
1 https://www.nokia.com/artificial-intelligence/explainer-network-traffic-is-fundamentally-changing-in-the-ai-supercycle/
2 According to the Verizon 2024 Data Breach Investigations Report

The post Redefining Network Security for the Frontier AI Era appeared first on Palo Alto Networks Blog.

Today, Microsoft published its 2026 Responsible AI Transparency Report. The report highlights the progress we’ve made in building and deploying AI responsibly, supporting our customers, and strengthening our responsible AI governance, tools, and practices. You can explore the report in its entirety here.

AI is moving fast, and so are societal expectations. The boundaries of what people can accomplish with AI are expanding, and communities are asking more questions about how AI systems are designed, built, and used. As AI becomes more integral to how we live and work, confidence that AI systems are operating reliably and securely is becoming an essential prerequisite to their broad and beneficial adoption.

At Microsoft, we have been building a responsible AI program for nearly a decade, rooted in two core beliefs: that trust is foundational to realizing the benefits of AI and that the empowerment of people and organizations must remain at the center of our strategy. As capabilities advance and adoption accelerates, that experience is helping us meet this moment and adapt for what comes next.

Our third annual Responsible AI Transparency Report shares how our program is evolving and the priorities that continue to shape our work. Over the last year, investing in three specific areas has enabled us to embed trust more deeply and at greater scale: adaptive governance and technical risk management, practical tools and capabilities, and shared practices and strong partnerships. These investments cut across five trends shaping the AI landscape, including the rapid expansion of agentic AI.

Taken together, these trends and investments underscore our view that model capability alone will not determine the impact of AI. That will depend on organizations that develop and deploy AI technologies that deliver real value—and govern them with the rigor and adaptability needed to earn and sustain trust.

Adaptive governance and technical risk management

As the frontiers of AI advance, we are making our governance more adaptive and more tightly integrated with engineering workflows. In practice, this means that we have updated our policies to better match the AI tech stack and AI value chain, evolved our risk management practices to address emerging AI capabilities and risks, and strengthened the readiness of our responsible AI community: the people who operationalize our program at enterprise scale.

This year, we re-engineered our Responsible AI Standard to make it more adaptive to evolving technical realities, uses, risks, and regulatory requirements. The new Standard is structured by reference to different components of the tech stack—models, platform services, and applications—and the role that Microsoft plays in developing or deploying those components. It combines core requirements that always apply with more targeted, scenario-specific requirements that can evolve as capabilities and risks change. For example, we apply some of our most rigorous risk management measures to AI systems with the most significant cyber capabilities, helping ensure that advances in AI favor the defenders responsible for securing critical digital infrastructure.

We are also evolving our technical risk management practices. Increasingly capable systems can retain memory, use tools, access data, and take actions on behalf of users. Governing these systems requires us to think beyond the behavior of an individual model or application to interactions among models, agents, applications, tools, data, and people. Our work increasingly focuses on controls such as agent identities, tool permissions, and monitoring of actions.

And governance only works when people can put it into practice. We have continued to build responsible AI capabilities across Microsoft, equipping thousands of engineers and product managers with training on topics such as agentic AI threat modeling and prompt injection defenses.

Together, these investments are helping us move toward a more continuous, lifecycle-based approach to AI governance. With agentic AI, risks can evolve as systems interact with their environments, users, and other systems. Our governance needs to evolve with these agentic capabilities—and incorporate what we learn from their testing and deployment.

Practical tools and capabilities

Effective governance depends on tools that help translate policy goals into action. As developers and organizations navigate a more complex technical and regulatory environment, they need practical ways to identify risks, evaluate systems, establish controls, and monitor how AI behaves in the real world.

We are applying what we learn from governing AI at Microsoft into tools, capabilities, and resources that help developers and organizations beyond Microsoft do just that—whether they build on our platforms or leverage open-source projects.

We have expanded tools to evaluate AI systems across the lifecycle. A new AI Red Teaming Agent helps accelerate the identification and evaluation of risks. Agent evaluators help developers measure the quality, safety, and performance of agentic applications. RAMPART turns red team findings into repeatable tests, enabling more continuous coverage as systems change.

We are also building greater visibility and control into agentic systems. With ASSERT and Agent Control Specification, developers can evaluate agents against their policies, place runtime controls at critical points in an agent’s workflow, and monitor behavior.

These tools and capabilities reflect a shift: as systems become more dynamic, governance needs to become more operational. Organizations need to be able to see what their systems are doing, test how they behave, and intervene when necessary—not just assess them before deployment.

Organizations also need confidence—and increasingly need to demonstrate—that responsible AI practices are being implemented consistently. Microsoft is one of the few companies certified against ISO 42001 across a broad portfolio, including Microsoft 365 Copilot, Foundry, and GitHub Copilot. Over the last year, we have simplified and strengthened our internal processes that support that certification.

Ultimately, responsible AI governance is a shared responsibility across the AI value chain. Our goal is to help make the practices and capabilities needed to meet that responsibility more accessible, practical, and scalable.

Shared practices and strong partnerships

The challenges of governing AI are bigger than any one company, and increasingly interconnected AI systems make collaboration even more essential.

As AI adoption expands across borders and sectors, we need shared expectations for how systems are evaluated, monitored, and governed, as well as interoperable standards that enable visibility into interactions across tools, data, and systems. We also need to keep advancing the underlying science and technical practices so that we can benefit from rigorous, applied insights into what effective governance looks like and where the remaining gaps are.

That starts with research. Over the past year, we advanced our work with the US Center for AI Standards and Innovation and AI Safety and Security Institutes in Australia, Singapore, and the UK to strengthen the science and practice of AI evaluation. We also launched an External Red Team Alliance with 18 universities across six continents to expand understanding of priority risks.

Common technical practices and standards are critical. Through the Frontier Model Forum, OpenTelemetry, and the Appia Foundation, we are helping develop approaches spanning frontier cyber benchmarks, end-to-end observability for increasingly agentic systems, and AI assurance across supply chains and sectors. We are also contributing to efforts that make transparency reporting more interoperable across organizations and jurisdictions, including through an OECD-led informal task force that developed the Hiroshima AI Process Reporting Framework version 2.0.

We also need shared ways to measure progress. We cannot meaningfully assess progress if every organization measures AI risks differently. Through our work with MLCommons, we are helping expand AILuminate into a broader suite of reliability benchmarks, creating common approaches for evaluating areas such as jailbreak resilience, multilingual performance, and psychosocial risk in conversational AI.

Shared learning, shared practices and standards, and shared measurement can help the entire ecosystem develop while raising shared expectations for trust.

Meeting the moment and investing for the future

Our experience over the past year has reinforced that responsible AI cannot be static. It has to be embedded in development processes, supported by practical tools, and continually informed by what we learn. That is why our responsible AI investments extend from the systems we build, to the tools we provide our customers, to the research, practices, and measurement approaches we help develop with the broader ecosystem.

Our 2026 Responsible AI Transparency Report explores this work in more depth—from how we re-engineered our Responsible AI Standard to how we are strengthening governance for agentic AI, advancing evaluation, and addressing AI misuse. We invite you to explore the report to see what we have learned, what we have changed, and how we are putting our priorities into practice.

As AI becomes more powerful and more present in people’s lives, our commitment is to keep listening and learning, to keep strengthening our safeguards, and to keep putting the empowerment of people and organizations at the center of our strategy.

The post Responsible AI in 2026: How we are adapting for what’s ahead appeared first on Microsoft On the Issues.