• Frontier AI models (like Mythos) are rapidly mining decades of technical debt across ubiquitous legacy libraries, driving monthly Microsoft Patch Tuesday vulnerability advisories up more than tenfold (reaching 1,415 this month). This volume is overwhelming open-source maintainers and putting pressure on the traditional 90-day coordinated disclosure model. 
• Despite a 105% year-over-year surge in CVEs, Known Exploited Vulnerabilities (KEVs) grew by only 37%, and only 3 of September's 975 Microsoft advisories saw in-the-wild exploitation, demonstrating that the vast majority of AI-discovered bugs are not practically exploited. 
• We may be able to take new-bug-class vulnerability spikes as evidence that these vulnerabilities will eventually level off and decline, once the historical code backlog is remediated and AI verification is embedded directly into new development pipelines. 
• With attackers able to parse patches faster via AI, defenders cannot cover for all possible threats. Organizations should continue to build robust defense-in-depth. Prioritize high-exploitability flaws in their specific environments, implement interim mitigations (such as LiveProtect), deploy behavioral anomaly detection, and integrate current AI evaluation models into their software build chains. 

The September Microsoft Tuesday release included 975 vulnerability advisories. This month, 1,415 vulnerabilities were just dropped. Compared to a pre-June average of 100 a month, that increase is staggering. Where did they come from? 

As of April, frontier models came onto the scene more fine-tuned than ever toward vulnerability detection, particularly with the introduction of Mythos. The deluge brings a lot of questions: 

• If these numbers are real, why hasn’t the internet collapsed? 
• Are these vulnerabilities a new breed, and if not, why didn’t analysts find them in code that is sometimes decades old? 
• Is the coordinated disclosure model still relevant in an era of this kind of speed? 
• How in the world do defenders deal with those numbers? 
• Should we go home, kiss our spouses, and prepare for the end? 

The answer to many of these questions boils down to this: The majority of these vulnerabilities are coming from repositories of old code from large-profile products and systems; and disclosure does not equal weaponization. 

Where is it from? 

AI is chewing through a backlog of technical debt in libraries and tools used as the dependable, best-practice lynchpins of so many environments. These models have a new perspective, an ability to "think" without some of the hangups or assumptions of human defenders, and they are thorough in listing those vulnerabilities. 

Entrenched older tools have always been prime targets because of their predictability; attackers know those tools and all their secrets, and they know what is likely to be present in a network with them. Multi-exploit attacks can be deployed with little variability.  

Pre-Mythos threat actors exploited log4j (CVE-2021-44228) to immense success. The library was ubiquitous, included in nearly every environment, but not a component that got cataloged in visibility scans. A combination of scale and low visibility meant defenders were blindsided, scrambling to find out if they even used the log4j library before starting to concoct a mitigation plan. 

Talos has ongoing relationships with some of the largest technical vendors (such as the Microsoft Active Protections Process (MAPP) agreement). Organizations share additional information—detection guidance or maybe a POC — for vulnerabilities that are most likely to be exploited, to enable Talos to provide adequate coverage when the advisories are announced.  "Microsoft believes it is important for us to provide detection content, based on their guidance," as Yves Younan, Director of Talos Vulnerability Discovery, Detection, and Testing, says.  

Talos has needed to invest more resources to get coverage in on time for critical vendors like Microsoft to keep up with notifications coming in fast and often on staggered or out-of-band timelines. 

For larger vendors, the pressure is handleable for now. However, open-source projects are getting flooded. Some projects have a trusted group that can combine to tackle patches, and some share with the full community for immediate assistance, but it is up to the project. The internet runs on open-source work. 

The pace of discovery presents a challenge for the traditional coordinated disclosure system vulnerability hunters have been using for years, and some are calling it into question.  

Security vulnerabilities should be reported, to enable an informed defender base and regular patching, and vendors responsible for vulnerable code need time to create coverage. A timed disclosure model where notifications are sent to a vendor, who then has a set period of time (typically 90 days) to provide coverage before the disclosure is released publicly, has created a more secure online environment for decades.  

Now, many practitioners are releasing advisories publicly without a disclosure period beforehand. The reasoning is that if one AI can find a weakness, any other could, so the vulnerability is already, effectively, released.  

This conversation is actively changing expectations around vulnerability disclosure, and guidance is in flux. 

Will it stay this high? 

No one knows the future, but we can always look to the past for insight.  

Numbers of vulnerabilities jump drastically when a new bug class is identified, as their possibilities are explored to the fullest. Then the discoveries plateau and drop off. 

When format string vulnerabilities were discovered as a new bug class in 2000, the initial influx of discoveries ramped up and up, until reaching a peak in 2005 and then slowly declining over the next couple of years. Format string vulnerabilities are still discovered, but they are a smaller overall fraction of the number of CVEs discovered in a year.  

Theoretically, AI-assisted vulnerability discovery could go the same way.  

While frontier models have not discovered a new vulnerability class, they are more efficient at discovering known types of software vulnerabilities. Given that a lot of vital software has a long history of code releases, there’s plenty of code to mine for weaknesses. But there’s only so much code… right? 

Old and commonly used tools are often under the highest scrutiny, lending them one kind of safety: Because of their popularity, utility, and stability, when popular tools have vulnerabilities, they are discovered fast and patched promptly. 

As the historical backlog of essential systems is turned over by AI, vulnerabilities will be found and patched. New code will ideally be run through AI bug-checkers that will prevent new vulnerabilities from being introduced. The rate of new vulns should level off and drop accordingly.  

There are some caveats. In the past, as vulnerability disclosures increased through coordinated disclosures, we saw increased adoption of mitigations. Exploitation became significantly harder. Attackers often need to chain together 3 or more vulnerabilities to successfully exploit a system.  

However, more awareness of vulnerabilities often leads to more exploitation. Attackers often use vendor patches meant to protect customers to discover where vulnerabilities might exist. The frequency of patching has delayed human attackers via parsing bottlenecks, but AI can eliminate that problem.  

Are the numbers the real issue? 

The volume is certainly up.  

Fresh as this blog is being finished, the October Patch Tuesday dropped almost 500 more than last month. 

With refinement, any vulnerability could become a link to a path of effect. But... not all vulnerabilities are exploitable. Some are wildly impractical for attacker use. In fact, the percent of Known Exploited Vulnerabilities (KEVs) is vastly smaller than the found vulnerabilities.  

Of the 975 vulnerabilities Microsoft reported in September, there were only three in-the-wild exploits detected. When viewed by percentage, vulnerabilities versus KEVs tell a different and perhaps reassuring story. 

Compared with the same period last year, additions to the known-exploited vulnerability list increased by 37%, while published CVEs increased by 105%. However, we wouldn't necessarily expect those figures to grow in proportion. Adversaries only need enough useful vulnerabilities to compromise their targets, and the same vulnerabilities can be reused against many organizations. The KEV count tracks distinct vulnerabilities known to be exploited, not the number of attacks or successful compromises. 

AI helps ingest code, advisory reports, and attack surfaces with inhuman speed, but it cannot currently make judgment calls about the value of a weakness. 

For defenders, the question remains the same: Which vulnerabilities provide a viable path into their environment, and how do you close those paths?  

What do we do now? 

The undeniable danger here is in exploitation time going down rapidly, while the vulnerabilities that could become exploits is still going up. The biggest hurdle for a defender is determining what is a real vulnerability for their environment, and what is not.  

Different defenders have different forms of control depending on their role.  

For those who are writing code, the new standard validation chain should include AI evaluation by models at least as up to date as those being used to hunt for vulnerabilities. It is relatively cheap to run new code through AI, but very expensive to run a cumbersome backlog of old code through. Bite it off in chunks. 

For those whose role involves keeping the tools ready: Upgrade ASAP.  Don't stop there.  

• For Cisco customers, implement LiveProtect to mitigate vulnerabilities between advisory release day and patching, to give time for that patching. Do this for everything you own. 
• Move beyond static domain blocking and implement behavioral detection that alerts on anomalous traffic patterns directed toward automation platforms. 
• Hone your focus to the vulnerabilities with the highest exploitability in your environment. KEVs are far less common among the sea of advisories, and their numbers have not risen proportionally with the AI-assisted deluge. 
• Focus on building defense-in-depth. Employ multiple protection systems, to cover for delays in patching. Implement interim mitigations (such as LiveProtect), create custom IPS/Snort triggers to block pre-patched traffic using SnortML, deploy behavioral anomaly detection, and integrate current AI evaluation models in software build chains. 

Dive deeper into this conversation with the latest TTP interview with Yves Younan and vulnerability researcher Bella Fusari.

For more numbers and advice for defenders: 

• Don't swing at everything 
• Threat Source Newsletter: Discovery ≠ Exploitation 

For some time now, the cybersecurity community has seen examples of autonomous agents, built inside AI labs, attacking public infrastructure (to name a few, Hugging Face, DSEWiki, and RubyGems). Of course, frontier labs have built-in security to prevent these attacks from occurring, but every now and then, the training or prompting appears to be insufficient — especially when the agents themselves attempt to use logic to probe and bypass the restrictions placed on them. The question that matters is not whether AI attacks are coming, because the age of AI agents executing cyber attacks is already here. The question is what to do about it and how to harden the stack against a swarm of agents who will relentlessly lie, deceive, and probe until the objective is met.  

Imagine your organization is a target for a creative human-driven AI adversary whose many agentic friends like to discuss and brainstorm different attack techniques. The limit here is the group’s own imagination, tools, prompts, and skills. However, there is a difference between the human 1) prompting the group (or an AI agent) to “break into an organization,” and 2) preparing it with information — a detailed tool mapping, markup files with instructions for agents, offensive security prompts, agents.md with guidance, and specific skills that would be invoked in different situations to guide agents into how to interpret an output of tools or access gained. The swarm of AI agents might fabricate employee identities and social profiles, contact the HR team with a plausible onboarding request, walk in by exploiting an unpatched vulnerability, or simply mail out phishing invoices at volume. The sky is the limit here.  

These types of attacks can be executed all at once, with agents comparing notes and adapting in near real time to challenges (and your environment). What used to take a red team months of dedicated work, scoping, building and hiding infrastructure, and running the campaign now compresses into hours for a swarm of communicating agents that do not tire, lose focus, or need weekends, and can stand up infrastructure quickly.  

Penetration test today, red team tomorrow 

I would argue that most of the public “attacks” seen so far more closely resemble a penetration test (pentest) than a true red team operation. They are loud, visible, lean on volume, and appear to use off-the-shelf tooling with thousands of agents working together. RubyGems is the clear example of a loud attack. The registration was hammered, packages stuffed, spam everywhere, and maintainers alerted within days — not exactly a stealth attack.  

In red team operations, operational security (OPSEC) is the name of the game. It is the difference between getting in and getting caught by a capable Security Operations Center (SOC) team. Real red teaming means maintaining stealth and a low signal while gaining footholds and persistence that survive normal monitoring.  

Volume is a property of this generation of AI agents, not a law of nature. The moment agent swarms are trained or prompted to prioritize staying hidden over moving fast, the noise drops and the pentest flavor turns into a genuine red team with machine endurance behind it. The plan of defense needs to assume that while we will probably see loud attacks now, the noise will start going down over time. 

How to build resilience 

1. Have an incident response plan (IRP) and rehearse it. A plan that lives in a drawer that hasn’t been opened for few years will probably not work when it’s needed. You’ll need named owners and decision authorities, specified out-of-band communications for when your primary channels are under attack, and a clear line to legal and to law enforcement. Map the IRP to a recognized incident lifecycle so nothing gets improvised under pressure. Preparation, detection and analysis, containment, eradication, recovery, and a post-incident review is what makes difference between a plan that might work and the one that will work. 
2. Test your own infrastructure and know its footprint. Where do your systems reach out to, and what can reach in? Map the full context of every attack path from start to end. For example, going to an external switch, then front-end server, then application, then database, then Active Directory, then user accounts, then customer data is a perfectly valid attack path that somebody could try to explore to get into the environment. An attacker's footprint expands naturally as they traverse, so an assumed-breach exercise (start from "they already have a foothold, now what?") tells you far more than a scan of the perimeter that might expose just a few network ports. Do not assume that because a system sits inside the network it cannot be reached. Active Directory touches everything in Windows-based environments, and all an adversary needs is the ability to push a malicious group policy object (GPO) to every joined device. Map external to internal, and every intermediate hop in between to understand possible attack paths. 
3. Run tabletop exercises against agentic scenarios specifically. Generic ransomware tabletops will not prepare security teams for what is coming. Run scenarios that test an AI angle. For example, “A rogue AI swarm is inside the network, traversing like a worm and collecting credentials as it goes. What do we do? How fast can we rotate the credentials? How and what do we block access to?” Or, “Our AI model weights were stolen, how do we respond and who do we notify?” Or, “A swarm is probing us and spoofing employees over email and social media at the same time. How do we make sure our people can withstand the manipulation?” The goal of these questions and scenarios is to surface the decisions and processes gaps before an adversary forces them under pressure on a Friday afternoon. 
4. Harden end to end, not just at the edge. Don’t just put MFA on the VPN, but also on Active Directory access, single sign-on (SSO) across every dashboard and internal app, and your Linux fleet. Prefer phishing-resistant factors (FIDO2 security keys or passkeys) over SMS and push, because a persistent agent will happily grind away at prompt-bombing and one-time-code phishing until something works. Assume the swarm gets one set of valid credentials, then design so that one set does not open the whole building. Have a process to isolate systems and users to support this. 
5. Instrument for detection, especially internally. Put endpoint detection and response (EDR) on everything. Gain visibility into east-west (lateral) traffic, not only north-south. Watch DNS, since it is a favorite for command-and-control (C2) and beaconing. Inventory and monitor every AI application you see in the network that has been granted access to your servers and data, because that access is now part of your attack surface, whether or not you deliberately approved it. A skill can hijack coding AI.  
6. Watch for the first signs of compromise. The early tells are often mundane and high-volume: a spike in SQL injection attempts, a surge in automated traffic, a jump in WAF alerts, and requests hitting your pages from Python, curl, or wget user agents rather than real browsers. These are just examples, and the exact indicators will shift, but the principle holds. The agentic attack era is noisy at the front. Catch it there, before the swarm learns to be quiet. 

An AI does not get discouraged. It will not give up unless it is prompted to give up. For that reason, the realistic goal is not to make an organization unbreakable — which is impossible — but to make every step cost more time, more tokens, and more compute, and more dollar per attack. Raising the cost doesn’t eliminate the risk, but it lowers the probability of a successful campaign.  

How you prepare for agentic threats is what makes the difference during real incidents. The speed of attack changes, the persistence changes, and the cost of running a full campaign collapses in terms of token value or token per dollar. The defensive fundamentals do not change nearly as much, which is the good news buried in all of this. The blocking and tackling of security, done thoroughly and everywhere rather than selectively, is still what keeps a determined attacker out.

• For Cybersecurity Awareness Month, eight Cisco Talos researchers share practical ways defenders can frustrate adversaries at different stages of an operation.
• Deception techniques such as honeypot accounts, false infrastructure, and tarpits can slow adversaries down while giving defenders earlier opportunities to detect their activity.
• Behavioral detections, tighter control of legitimate remote-management tools, and clear boundaries around AI agents can make essential adversary actions more visible and easier to interrupt.
• Breaking dependencies between stages of an operation can prevent an adversary from reaching their next objective.

Years ago, Cisco Talos blocked an adversary’s command-and-control (C2) traffic. The adversary responded by tweeting, “Write a rule for your a**.”

A fine endorsement of our work, if I’ve ever heard one. 

Talos loves to see an adversary forced to change course. And if every alternative for them is slower, less stealthy, less reliable and more expensive? Chef’s kiss.

Adversaries rely on certain advantages. They look for environments where tools and infrastructure allow them to blend in with normal activity. They also look for employees who can be pressured into acting before they have time to think.

Strong cybersecurity defenses can change those conditions. They take away adversary choices and increase the risk attached to essential actions, forcing them to keep making new decisions. Each change of plan costs them time and resources, and may eventually cause them to give up and move to another target.

It also creates more opportunities for defenders to spot what they are doing.

For Cybersecurity Awareness Month, we’re exploring “the fine art of frustrating the adversary.” To kick us off, I asked researchers across Talos, covering all aspects of the attack chain, for the strongest recommendation they could give defenders to seriously frustrate a potential adversary in their environment, and what that action would prevent the adversary from doing next.

Take away their choices

Many adversaries use techniques that succeed against a large number of organizations. This makes a lot of economic sense: An operation that depends on every potential target having an unusual configuration will not scale particularly well.

But it also creates an opportunity for defenders.

“By being unique and setting things up a little differently, you may be able to better defend your environment when they come knocking,” Pierre says.

For example, organizations can restrict which accounts are permitted to sign into their most critical servers, alert on connection attempts from unauthorized users, and closely monitor any changes to those restrictions. Different credentials or authentication methods can be required for particularly sensitive systems, while protected enclaves can provide increased monitoring around critical infrastructure.

Pierre also recommends that defenders “monitor (and alert) for any changes to administrative users or administrative groups.”

Of course, no amount of security measures makes an organization impenetrable, but they can make the common methods adversaries use much less dependable. 

Deception can push that uncertainty even further.

“Affecting the attack earlier rather than later in the attack chain is best,” Martin says. “Better to stop an attack from happening than minimize the consequences after it has happened.”

Martin suggests creating honeypot email accounts using expired domains with addresses that have previously leaked, or developing fictional employee profiles and seeding their addresses in places where spammers and other adversaries are likely to discover them. Because these accounts have no legitimate users, messages sent to them can be treated with far greater suspicion. The activity can provide early tactical intelligence about malicious infrastructure, lures, and campaigns, allowing defenders to put protections in place before the same operation reaches genuine employees.

Martin signed off with this note: “Have fun creating some fake employees and executives.”

Nick sees a similar role for tarpits and other forms of deception.

“False servers, shares, user accounts and network space can all be used to confuse and slow down the attacker while providing opportunities for the defender to detect them,” he says.

The same principle is beginning to appear in attempts to slow automated systems.

“We’ve even seen some new movement in the tarpit space for slowing down AI by throwing huge amounts of incoherent text at scrapers to slow them down,” Nick explains.

Deception gives the adversary another problem: they can no longer be certain that what they have found is useful, or even real. 

Plus, it can be a lot of fun.

Detect what they cannot avoid

“Attackers have enormous flexibility in how they operate, but far less flexibility in what they ultimately need to accomplish,” Ryan says. “Good detection engineering exploits that asymmetry.”

Consider an adversary attempting to obtain privileged credentials. They might use Mimikatz, comsvcs.dll, direct access to LSASS memory, a custom utility or another implementation entirely. A detection focused too narrowly on one tool can be bypassed simply by replacing it. A detection built around the underlying attempt to access credential material leaves considerably less room to maneuver.

According to Ryan, creating resilient behavioral detections requires defenders to:

• Identify the adversary techniques that would have the greatest impact in their environment
• Understand the different procedures an adversary could use to perform them;
• Find the behaviors that remain consistent when the tooling, syntax, or implementation changes
• Build analytics that account for techniques such as encoding, transformation, and obfuscation

This is more involved than matching a known tool or indicator. It requires suitable telemetry, knowledge of normal activity in the organization, and detection engineering that reflects how adversaries operate in practice.

“If done right, it forces an attacker into a dilemma: either abandon the objective, choose a noisier/less reliable path, or execute the action and risk detection,” Ryan says. “It is the highest leverage investment for defenders as well, because behavior-based detection is tool-agnostic.”

Ryan also points out that organizations do not need to begin from scratch. MITRE ATT&CK provides a useful taxonomy of adversary techniques, while projects such as MITRE Center for Threat-Informed Defense’s Summiting the Pyramid, SpecterOps’ work on capability abstraction, Splunk SURGe’s Macro ATT&CK, and Cisco Foundation AI’s LUCID explore different parts of this challenge.

Control the tools they hope to use

Sometimes the most useful tool available to an adversary is one that already has a legitimate purpose within the target environment. Remote monitoring and management (RMM) tools are a good example. Organizations use RMM software to administer systems and maintain remote access. Ransomware operators can use the same capabilities to establish persistence and interact with compromised systems before encryption.

“These are good tools that are being used for bad, making them not good in your environment but not bad for everyone,” Michael says. “So are they good or not good? Well, that depends on your specific environment.”

Warlock ransomware, for example, has used Zoho Unattended Agent. The tool can provide a remote technician with elevated permissions even when the signed-in user is not an administrator, offering the adversary persistence and a relatively benign-looking route to greater privileges.

Defenders can frustrate this activity by first inventorying the RMM products that are genuinely authorized in their environment. Application allowlisting can then permit those approved products while blocking (or producing high-confidence alerts for) unapproved tools such as AnyDesk, ScreenConnect, or Atera. Controls can be enforced through technologies such as Windows Defender Application Control, AppLocker, or endpoint detection and response (EDR) platforms.

Removing access to a familiar RMM product forces the adversary to establish persistence or C2 another way. That change does not guarantee that the operation ends, but it creates friction and another chance to detect the activity before the ransomware encryptor is deployed.

Slow them down

“Attackers use urgency to create panic and to try and trick users into making bad decisions in the heat of the moment,” says Doug.

Email, text message, and in-person scams frequently manufacture that urgency. A bill must be cancelled immediately. An executive stranded overseas needs help now. A child has been injured and the recipient must call the number in the message. The adversary always wants you to act first and think later.

From a social engineering perspective, Doug recommends considering which events in your work or personal life would genuinely require you to drop everything and respond immediately. For most people, that list should be relatively short. Then consider how you would realistically expect to learn about each situation, what action you might need to take and how you could independently verify that it was real.

“If you messed up your taxes, you probably don’t expect to get a single email from the IRS, and you almost certainly don’t expect the IRS needs gift cards or other forms of payment,” Doug says.

If a text claimed that your child had been injured at school, you could call the number you already have for the school rather than relying on the contact details supplied in the message.

Doug recommends thinking through genuine emergencies in advance to make it easier to recognize when someone is trying to manufacture one. It also provides a verification route that does not depend on trusting the message itself.

Make every agent session identifiable and interruptible

As organizations increasingly introduce AI agents with access to tools and applications across connected systems, defenders need to know which agent is responsible for each action, and be able to stop it.

“The best way to frustrate an agentic adversary is to make every agent session identifiable, restricted, and interruptible,” David says.

A recent Anthropic report described four real-world incidents involving Claude in evaluation environments. The organizations involved were not named, but the incidents shared a common weakness: the environments had inadvertently been given internet access.

These were not conventional adversary operations and the agents had not been directed to behave maliciously. Their significance lies in what happened once the agents began operating beyond their intended boundaries.

The reported activity crossed trusted services, relays, and short-lived infrastructure before reaching cloud metadata, Kubernetes, VPN, source-control, and data-staging systems. An agent capable of adapting its behavior can change destinations, reuse public services, and connect information or systems in ways its operators did not anticipate.

“A simple IP or domain blocklist would not have been enough,” David says.

Instead, David recommends that each agent run should have its own identity and short-lived credentials, with traffic routed through an independent gateway. Access to cloud metadata, Kubernetes interfaces, and other sensitive systems should be blocked unless the agent genuinely requires it.

Defenders should also look for actions that indicate an agent is moving beyond its intended role, including:

• Unexpected writes to package registries, datasets, wikis, paste sites, or file-sharing services
• Repository creation, dataset commits, and unusual API operations 
• Calls to Kubernetes APIs, VPN services and DNS-over-HTTPS relays
• Public services being used as C2 channels or dead drops
• Credential discovery followed by activity across cloud accounts or source-control platforms
• Rapid destination changes, DNS pinning, short-lived egress identities, and unusual bursts of traffic

These controls constrain what happens after an agent takes an unexpected action. Giving each session a traceable identity makes its behavior easier to attribute. Allowlisting limits where it can go. Independent gateways provide a place to observe and stop the activity.

“This is practical today,” David says. “It makes the agent’s next move slower, louder, and much easier to stop.”

Break up their route

Conventional malware operations also depend on connections that may be hidden inside services an organization would not ordinarily consider malicious. An attack chain can involve multiple tools and pieces of infrastructure. Somewhere within it may be a dependency that connects one stage to the next.

“I cannot say with certainty which action is most effective at frustrating an adversary, but I would imagine it is discovering a dependency in the chain that, once blocked, cannot be easily replaced,” Vanja says.

Vanja encountered this while analyzing two attack chains that used the Amatera information stealer as their primary payload.

In the first, the adversary used a page hosted on the legitimate Telegra.ph publishing platform to conceal the location of its C2 server. This technique, known as a C2 dead-drop resolver, allows an adversary to place C2 information on a popular legitimate service that web-filtering systems may be less inclined to block or inspect closely.

Once defenders identify and block the particular page containing that information, the handoff is interrupted. Amatera might already be running on the endpoint, but if it cannot determine where its C2 server is, it cannot receive collection instructions or download additional payloads.

The second chain used the same primary payload but included different secondary payloads, among them the cryptocurrency stealer ZigCryptoStealer. This malware stored its C2 domain in the metadata of a BNB Smart Chain contract — an approach commonly known as EtherHiding.

Blocking one contract does not stop an adversary from deploying another. It does break the existing operation and force them to spend time and money rebuilding part of their infrastructure.

The appropriate response depends on how the organization uses the underlying service. Known malicious domains and URLs can generally be blocked through DNS filtering, secure web gateways, proxies, or firewalls. Published indicators can also be added to existing security tools.

Contract-specific blocking is more complicated because defenders need visibility into blockchain remote procedure call requests and a means of distinguishing one contract from other traffic. If the organization has no legitimate requirement to access public blockchain or RPC infrastructure, blocking it may be the simpler option. Where the technology is required, defenders can allow approved services and monitor access to known contracts.

The main requirements are visibility, timely threat intelligence, and the ability to turn that intelligence into enforcement rules. Even partial disruption can increase the cost and complexity of the operation.

“It is particularly satisfying when a single point of failure is identified because it forces a threat actor to re-establish infrastructure, which can take time and money,” Vanja says. “In other words, the simpler the mitigation, the more satisfied we can be.” 

Keep them on their toes

No single action in this article will frustrate every adversary or stop every attack, nor will every recommendation be equally appropriate for every environment. But the common pattern is the same: Make the adversary’s next move harder, riskier, or less reliable. If you can get them to swear at you on Twitter, even better.

It comes down to setting your environment up to detect the behaviors that their objectives require. Know when a tool is being used for something it shouldn’t be. Slow down the moments designed to make people panic. Give every agent session an identity, boundaries, and a reliable off switch. Find the dependencies connecting one stage of an operation to the next.

Frustrating an adversary means making them find another account, another tool, another route, another piece of infrastructure, or another way to make someone act.

Eventually, the easier target may be somewhere else.

For more insights into current cybercrime behavior, take a listen of this episode of Beers with Talos:

• AI is accelerating vulnerability discovery, leaving unpatchable operational technology (OT) systems at risk. Hoping for the best is not a viable anti-exploitation strategy. 
• Deploying next-generation firewalls directly upstream allows for virtual patching through deep packet inspection. These systems scan incoming traffic to detect and block exploit attempts before they can impact the vulnerable device.
• The predictability of legitimate network connections to OT systems can be used to protect systems through micro-segmentation. This ensures that only a handful of authorized devices can communicate with the system, minimizing the attack surface.

AI-assisted code analysis is uncovering decades of technical debt. Every new patch removes a newly identified coding mistake. Little by little, we are improving the state of software engineering, but the price is a cadence of patching that organizations may struggle to implement. 

These efforts leave unsupported systems, or systems that are not able to be patched for whatever reason, with unmitigated known vulnerabilities. How can such systems be secured in a world where AI is steadily improving its ability to identify new vulnerabilities? 

Operational technology (OT) systems provide the services that support modern life (e.g., medical equipment, building management systems, and industrial critical systems within chemical plants). Often the systems are certified to operate only with a defined set of software that cannot easily be altered, or operate using systems that are no longer supported. In either case, if a vulnerability is discovered that affects the system, there is no easy way for it to be patched. 

Ignoring the problem and hoping for the best is rarely an effective strategy. The U.K.’s NHS health system was significantly affected by the WannaCry worm in 2017, with a significant minority of systems running the end-of-life operating system Windows XP contributing to the problem. More recently, exploitation of end-of-life software was used to gain access to governmental systems in 2023. 

Even systems that are believed to run on a bespoke platform will almost certainly include common libraries and protocols in which vulnerabilities may be found. Vulnerable systems that are not publicly exposed can still be identified by threat actors who gain access to internal networks and pose a tempting target. 

Defending by predictability 

Applying the approved patch remains the best option. If this is not possible, we can use the inherent predictability of OT systems to protect them. 

Visibility first: You cannot protect what you cannot see. The characteristics of the network fingerprint presented by legacy systems allows them to be easily identified to build an inventory of systems requiring attention. 

Micro-segmentation: Network architecture is an effective first line of defense. Frequently, OT only ever connects to a small number of systems. By using virtual local area networks (VLANs) coupled with access control lists (ACLs), we can place vulnerable systems on private networks where only authorized devices are permitted to connect to them. By shutting them off from the rest of the network, we make it incrementally more difficult for attackers to identify them and launch their attacks. 

NGFW and IPS: Placing a next-generation firewall (NGFW) upstream allows for granular filtering. When equipped with an up-to-date intrusion prevention system (IPS), the firewall can inspect traffic to filter out any attempts at exploitation before it impacts the device. When coupled with network segmentation, we can ensure that not only are trusted systems solely communicating with the vulnerable system, but that the traffic is free from known malicious content. 

The myth of the air gap 

In theory, it is possible to create an air-gapped system that is completely disconnected from wider systems, although in practice it is difficult to achieve. Without absolute operational discipline, air gaps are frequently breached by staff or contractors seeking shortcuts. 

Temporary bridges installed to facilitate data transfer or short-term fixes involving a VPN and wireless connectivity have a habit of becoming semi-permanent features. Each shortcut provides a means by which attacks can impact the system.  

Even data diodes, hardware that physically restricts data to one-way flow, may be circumvented by shortcuts when the inconvenience of maintaining security compliance clashes with operational expedience. 

An air gap or data diode may be an appropriate solution, but defenders should understand that it is unlikely to permanently provide absolute separation, and should be vigilant for breaches of the gap. 

Conclusion 

Advances in AI technology will continue to identify vulnerabilities that in some circumstances are difficult, or effectively impossible, to patch. In situations where fixing the software isn’t possible, appropriate network segmentation, rigorous visibility, and the deployment of NGFW/IPS combinations can provide a powerful compensatory layer. 

We might not be able to prevent the discovery of vulnerabilities, but we can ensure that attackers do not have an easy path to exploit them in the field. 

• As frontier models advance in cyber capability, their guardrails also become more restrictive. 
• Defenders relying on these models to power core SOC processes cannot afford to pay the “safety penalty” of being blocked by these safeguards. 
• Organizations should monitor model refusal rates and use the data to create a strategy to ensure operational sovereignty.

The allure of the cloud and the hidden "safety penalty" 

Cybersecurity has made a big bet on cloud-hosted AI. Building and running frontier-class models in-house isn’t realistic for most security teams — the compute, the talent, and the R&D costs are more than any single SOC can carry. So we’ve effectively outsourced the "brain" of our security operations to a handful of providers. 

That trade comes with a hidden cost: the safety penalty. 

The safety penalty is the friction that shows up when guardrails built to protect the general public get in the way of legitimate security work. If your model refuses to deobfuscate that malware or to explain a working exploit because its filters read the request as harmful, you’re paying the safety penalty. 

Those guardrails make sense in a normal business context and may even be a welcome feature when it comes to keeping agents in check. But in a SOC, in the hands of defenders aiming to reap the full benefits of powerful AI models, these guardrails are a bug. Every refusal sends the analyst back to doing the work by hand, and in a live incident, that lost time is a luxury we don’t have. 

Meanwhile, the adversary pays none of this penalty. 

A warning from the frontier 

In July 2026, an unreleased OpenAI model escaped its sandbox and compromised Hugging Face’s production infrastructure. It wasn’t an external hack, but an unintended "breakout" during testing, with its guardrails deliberately stripped for the exercise. 

The telling part came during the response. When Hugging Face tried to use its primary cloud LLM to investigate the breach, the model refused the forensic request. The "safe" model, in this context, was an obstacle. To get the analysis done, Hugging Face pivoted to an unconstrained open-weight model, GLM-5.2, which delayed their response. 

Hugging Face could make that pivot because they host open-weight models for a living and have the expertise to bypass a refusal on short notice. Most organizations don’t have that muscle. If your defensive model refuses a task mid-crisis, you’ve handed the adversary the advantage. 

That asymmetry is already being exploited. After state-sponsored actors were banned from frontier APIs, they simply moved their research to self-hosted, unconstrained models. The rise of AI-driven attacks is old news by now; what’s new is how lopsided this is about to become, with defenders slowed by refusals while adversaries are iterating at machine speed with nothing in their way. 

Guardrail asymmetry 

Attackers don’t even need to jailbreak anything. Models like GLM-5.2 and Kimi k3 are readily available with far fewer restrictions than Western frontier APIs, and "abliteration" (stripping the safety training out of an existing model) remains an option for anyone who wants to go further. Mostly, they don’t have to. They can just pick a model that doesn’t refuse them. 

Most defenders don’t have that option. Cloud APIs are tuned toward a kind of cyber do-no-harm designed to keep bad guys from using them to build attacks. This is the same refusal bias that ends up blocking security teams trying to analyze those attacks. In a defensive context, erring on caution often means erring in the attacker’s favor. Every refused request costs the defender the one resource they can’t get back: time. 

This trade-off used to be worth it. A few months ago, frontier models were far enough ahead on reasoning and code generation that the friction from their guardrails was a fair price. But the newest frontier models, like Anthropic’s Fable, are shipping with sharper cyber capabilities and even tighter guardrails to match. Meanwhile, open-weight alternatives have closed most of the reasoning gap that used to justify putting up with those guardrails in the first place. 

Either way, the calculus is shifting: Defenders are increasingly paying for restrictions without getting a capability edge in return. 

Defining operational sovereignty 

The way out is what I’d call operational sovereignty — not to be confused with data sovereignty, which is about where your data lives and how it’s treated. Operational sovereignty is about who gets the final say over what your AI is allowed to do. 

A sovereign SOC needs its AI technology to be at least on par with that of their adversaries. They either need to have a fallback on hand when their model refuses to complete a task or to use a model that will not offer refusals in the first place. That does not mean there should be no safeguards placed around the models, just that the safeguards should be under the control of the organization itself rather than imposed upon them from the outside. 

Security operations also shouldn’t be hostage to a vendor’s shifting alignment policy, or frequent behind-the-scenes model updates that may change behavior subtly and unexpectedly (known as model drift). Operational sovereignty means a policy change in Silicon Valley doesn’t quietly break your defensive workflow overnight. It’s what lets you keep pace with an adversary who was never bound by those policies to begin with. 

The roadmap: From convenience to collective defense 

Getting there isn’t all-or-nothing. The right path depends on risk tolerance and how much infrastructure a team can realistically manage.

Private infrastructure 

The most direct route is to host the model yourself, on your own GPUs or a dedicated private cloud instance, so you own the weights and the policy outright. 

• The benefit: There’s no safety penalty because there’s no third party to impose one. You’re free to choose any model that fits your needs, guardrails included or not. 
• The downside: Physical scarcity, expertise, and high upfront cost. GPU procurement can take months, the capital outlay is steep, and running your own inference stack takes specialized talent most security teams don’t have on staff. 

Model-as-a-Service 

Model-as-a-Service splits the difference. Providers like Baseten or Together AI, or platforms like Amazon Bedrock or Microsoft Foundry, let you bring your own model to infrastructure they manage, without layering their own safety refusals on top. 

• The benefit: It removes the safety penalty while offloading the hardware burden. You get the control of private infrastructure with the scalability of the cloud. 
• The downside: Dedicated capacity that avoids provider-side filters is often in short supply. Falling back to shared clusters solves the availability problem but can reintroduce the same guardrails, and the same data-sharing concerns, you were trying to escape. 

The hybrid fallback 

The most architecturally involved option is to keep frontier cloud models for most day-to-day tasks but add an automated handling path for the rest. A gateway watches for refusals and reroutes those prompts to a smaller, unconstrained model you control. 

• The benefit: A guaranteed response with minimal upfront infrastructure investment. You stay on the cutting edge of cloud capability while neutralizing the safety penalty. 
• The downside: Keeping the fallback model’s read of a prompt consistent with the primary’s, so a refused request lands the same way with both. If the fallback is a local model, you’re also managing two systems in parallel — a smaller maintenance burden than hosting it all yourself, but not zero. 

Collective inference 

The most speculative option, and the one I find most interesting: evolving the ISAC/ISAO model into collective inference. Industry groups already share threat intelligence, so why not pool the infrastructure too? A sector could jointly fund a shared, unconstrained model, maybe even one tuned to its own threat landscape, governed by its members rather than a vendor. 

• The benefit: A community-governed "brain" as capable as any frontier model, answerable only to the defenders who fund it. 
• The downside: Governance. Members have to agree on usage and safety policy, and during a sector-wide incident, everyone would be hitting the same shared infrastructure at once.

Reclaiming the defensive advantage 

You can’t manage what you don’t measure. If an AI assistant is supposed to be a force multiplier, every refusal during a live incident multiplies by zero. Security leadership should treat those refusals as a structural failure of a non-sovereign stack, not an occasional annoyance. 

Start by auditing your refusal rate. That number is the most direct way to put a figure on the safety penalty your organization is actually paying. Once you know it, the path forward gets a lot clearer. 

The adversary has already claimed its own sovereignty, running at full throttle with no guardrails to slow them down. Defenders need to manage their safeguards to keep pace. 

• Crime script analysis is a narrative-driven technique that can be used alongside, or as an alternative to, tactics, techniques, and procedures (TTPs) — creating human-readable stories that describe attacks in a way non-technical audiences can understand. 
• By analyzing the attacker’s workflow, we can identify how AI can be used to industrialize attacks. Through considering a business email compromise (BEC) example, we demonstrate how attackers may scale the attack to target previously unprofitable victims. 
• Deconstructing an attack into discrete steps allows defenders to pinpoint intervention points where defenses can be effectively deployed, or where strategic disruption can break the script and thwart the threat actor's operation.

Effective defense against cyber attacks requires understanding how attacks are carried out and identifying where the attack can be disrupted or detected.  

Lockheed Martin’s Cyber Kill Chain was one of the earliest models to describe the steps required to conduct a cyber attack. However, its seven-step linear sequence is too rigid to apply to many attacks. 

The Attack Flow model of the MITRE ATT&CK framework allows various tactics, techniques, and procedures (TTPs) to be chained together to describe exactly how attacks are conducted, including branches and loops if necessary. The resulting graphs are comprehensive, but can be daunting to a non-technical audience. In a world of evolving threats and shrinking budgets, defenders need techniques to communicate threats to a wider audience. 

Crime script analysis (CSA) is a technique originally developed in the mid-1990s as a criminology tool to understand how crimes are committed. CSA allows us to decompose an attack into a sequence of actions, decisions, and situational requirements. Describing an attack as a narrative using everyday language not only makes the description accessible to non-technical audiences, but also to identify "choke points" where the crime can be disrupted. 

If MITRE ATT&CK TTPs describe the building blocks that comprise an attack, Attack Flow diagrams are the structural engineering blueprints showing how the blocks fit together, and CSA is the architect’s artistic impression of the finished building. Each component has their place in providing a picture of what is happening at different levels of abstraction for different audiences. 

Business email compromise as a case study 

The business email compromise (BEC) is a common scam. Someone with financial authority receives a message purporting to be from a superior in the same organization requesting an urgent payment. If the victim is fooled, payment is released to the scammer, who acts quickly to launder the money to disguise its origin before the scam is uncovered. 

In April I wrote about such an attack against a small, community sports club of which I am a member. The sum requested in the attack wasn’t large, so the reason was plausible. However, the tone of the email wasn’t quite correct. The treasurer’s suspicions were raised and the attempted fraud uncovered. 

This incident was particularly interesting because of the small scale of the attack. Historically, the research necessary to conduct the attack — the identification of the target victim, the person spoofed, the nature of the social engineering lure — has limited its scalability. Carrying out these tasks manually takes time and has meant that it has typically been conducted against larger businesses.  

The advent of AI means that the previously time-consuming preparative work can be automated. Expressing the attack as a crime script helps us understand where AI may assist the attacker and how the attack could be disrupted. 

Putting BEC in the crime script narrative 

We can imagine the crime script for the attack as follows:

Steps 1 – 4 are time consuming to perform manually, but can be automated with AI. This efficiency improvement allows an attacker to identify many targets and shifts the execution of the attack from a higher value fraud against a few targets to a lower value fraud against many targets. 

The personalization of the social engineering in Step 5 can also be conducted using AI. The attacker can generate urgent requests for payment that are relevant to the target organization and may appear credible to the victim. 

Identifying intervention points 

Considering the narrative of the attack helps with reflection on how the attack might be disrupted. Clearly, Steps 1 – 4 can be disrupted by seeding AI with fake canary organizations. These are fictitious honeypot entities that have public personas discoverable by AI agents, but otherwise serve no purpose. The source of messages sent to honeypot organizations can then be blocked, disrupting Step 6. 

Interactions with large language models (LLMs) leave traces that can be identified by security teams. While distinguishing malicious prompts from legitimate business inquiries is difficult, there is potential for AI providers to detect repeated patterns of reconnaissance and the generation of social engineering messages. This leaves Step 5 vulnerable to disruption by providers of AI systems. 

The most effective disruption point remains Step 6, the delivery mechanism. Anomalous account behavior or high volumes of outgoing mail from a single source should trigger immediate rate-limiting or reputation-based blocks by email service providers. 

The final point for intervention is with the victim at Step 7. Increased awareness of the scam helps victims recognise any potential attacks that do get through. Implementing strict processes such as requiring purchase orders that must be verified and implementing delays before payments are made can all help prevent losses. 

Conclusion 

Crime script analysis does not replace the ATT&CK framework; rather, it provides an alternative narrative format for documenting attacks. Describing threat actor activity using natural language opens the understanding of the attack to a wider audience and enables collaboration with other teams. The technique also helps defenders understand where attackers may be applying AI tools to automate processes, and spark ideas at how this might be thwarted. 

Should we let AI run our threat hunts? The debate usually splits into two camps. One says, "Yes, obviously! The sheer scale of our security telemetry is impossible for humans to deal with." The other says, "Absolutely not!  You can't trust an AI with something this important."  

The thing is, I think both are wrong, or at least incomplete.  

I've spent a long time as one of the louder voices saying that hunting is specifically a human-driven process. I created the first widely recognized definition of threat hunting back in 2015, and the version I'd have given you until very recently put a human firmly at the center of it.  

But lately I've been reconsidering the role of AI in threat hunting. So this post is, in part, me arguing with my past self.  

We're facing what I call the Hunter's Paradox: Humans can no longer keep up with the volume and velocity of security data on their own, so we need to lean on automation. But the most capable automation available, AI, is exactly the kind we can't fully trust. Both are true at once, and that tension is what I've been wrestling with for a while. We can’t resolve it cleanly by picking either side, so let's take them in turn, starting with the human element. 

Humans have a numbers problem 

So why not just keep humans in the driver's seat and call it a day? Because that math stopped working a long time ago. 

When I started in this field about 30 years ago, the conventional advice was that system administrators should read all their logs every day. It probably wasn't realistic even then, and it has been thoroughly impossible for most of my career. That's the volume problem, and it only ever compounds. There's more data than anyone can read, and there's more of it every year. 

Then there's velocity. Automated attacks already move at close to machine speed, and even human-driven intrusions routinely outpace human defenders. AI on the offensive side is making that gap wider, not narrower. 

And finally, there's capacity. This isn't the usual complaint about being under-resourced. That may still be true, but the problem is deeper than that. Volume and velocity together have pushed us to a place where it is simply not possible for humans to keep up no matter how many of us there are. If your team can still manage today, the trend line says it won't be able to for long. Even a perfectly staffed, perfectly funded team can’t beat that math forever. 

Put those three pressures together and opting out of AI isn't really an option. We can't hunt at scale without it, which lands us right back in the paradox: we need a tool we can't fully trust. 

AI doesn’t deal well with lies 

When most people think about AI and attackers, they think about prompt injection. An attacker slips instructions into something the AI will read, the AI dutifully follows them, and now your defensive tooling is working for the other team. It's real, it's a problem, and you should design with it in mind. It's also the less interesting part of the trust problem, so I'm going to acknowledge it and move on. 

The deeper issue is that attackers lie and cheat constantly, whether or not they think an AI might be watching. Deception isn't a tactic they reach for occasionally; it's the medium they operate in. Every phish, every exploit, every defense evaded is a lie that has to be believed in order to work. That has always been true, long before AI showed up. 

Pervasive deception is a real issue for AI. It’s baked into how we create LLMs: They have no concept that their training data might be deceiving them, and so when they come into the real world and deal with our dirty data, they tend to take it at face value. Not every time, maybe, but enough that their judgment is noticeably skewed even when we explicitly tell them to detect shenanigans.  Even the most accurate telemetry isn't trustworthy if it's faithfully recording a lie, and AI tends to process what it's given and believe it. 

Solving the paradox starts with a definition 

Now that we understand how deep of a hole we’re in, we can start thinking about how we might get out of it. Let’s start with the very definition of threat hunting itself. 

Back in 2015, I was the architect behind the Sqrrl threat hunting framework. I defined hunting as "any manual or machine-assisted process for identifying security incidents your automated detection systems missed." That same definition carried forward into our PEAK framework in 2023, of which I was the lead author. This has been the working definition for much of the field for a decade, though often in different words. 

That phrase right at the front, "manual or machine-assisted," is the entire reason I’ve been thinking about this so hard. What that phrase actually meant was that humans drive the hunt. Machines can assist, through analytics or machine learning or whatever tooling you had, but a person was always the one doing the hunting.  

And honestly, that was the right call at the time. But if I look back at what I was really trying to capture with that definition, the essential ingredient was never the human. It was reasoning. Humans were just the only place to get it in 2015.  

But that’s no longer the case. AI can reason now — maybe not as well as a good human analyst, but it really can reason in a way that the tools of 2015 could not. So maybe the definition should change to match what I really meant. Threat hunting might be better described as "any reasoning-driven process for identifying security incidents your automated detection systems missed."  

Reframing hunting around reasoning rather than around who's doing it feels more accurate to the original intent, and it's a lot more useful for working through the paradox. If reasoning is the point, then the question isn't whether the hunter is human or machine. It's whether there's real reasoning involved. 

If it’s really about reasoning, what does that mean? 

If we accept that AI can reason and hunting is a reasoning-driven process, then letting AI drive starts to seem… well, reasonable. 

The next big question, then, is what should that actually look like? Just saying, "AI, go find the evil!" is not a real plan. I wouldn't hand most human hunters that assignment either. Letting AI hunt responsibly takes careful planning, and more importantly it takes guardrails. At least three things matter. 

The first is tight focus. Decide deliberately which hunts you're willing to let AI drive. The procedure should be reasonably clear, but the hunt should still contain some real ambiguity. It’s the ambiguity that requires reasoning, and if there’s no reasoning at all you don't have a hunt, you have a SIEM rule. A good place to start is the pile of hunts you've run before but never quite managed to fully automate. Most teams have at least one of those sitting in a backlog. 

The second is strict guidelines. An AI agent operating in your environment is a non-human principal with credentials, and it should be treated with at least as much care as a service account: scoped access, audit trails, the ability to revoke and rotate, and never more privilege than your most junior hunter would get. You also have to decide ahead of time which actions the AI can take on its own and which it cannot. Maybe you let it quarantine a user endpoint when it's confident something is wrong. Quarantining a production server? Probably not. 

The third is graduated autonomy. Don't jump straight to full hunting independence. Let the AI act as an advisor first, then an assistant, then an operator on narrowly defined tasks, earning a little more trust at each step. Remember: Your threat actors don’t have to care about collateral damage, but you do. We’ve all heard the horror stories about AIs that deleted the production database. If your AI oversteps its boundaries, you’re more likely to actually cause incidents than to detect them. 

What stays human 

Even with all of that working well, there are still things that humans will be markedly better at for the foreseeable future, but they mostly trace back to one aspect: creativity. 

One important creative area is your hunt strategy — that is, deciding what's worth hunting for in the first place, what to prioritize, and in what order. That's running the hunt program, and it shouldn't be delegated to the AI. It can execute hunts, but it shouldn't be allowed to decide which hunts matter. 

Another important creative area is analytic novelty. Attackers are creative, so we have to be creative too, both in what we choose to look for and in how we analyze our data. The biggest payoff in hunting comes from finding the thing nobody thought to look for, and an AI's training data by definition doesn't include the attacker behavior nobody has seen yet. Lean too hard on AI to generate your hunting procedures and you'll quietly converge on well-trodden ground, leaving the truly new stuff as your blind spot.  

Put together, we almost have another guideline: Humans pick what's worth hunting and how. AI executes within those bounds. 

Where we go from here 

So, should we let AI start driving some hunts? Probably, yes, but that was never really the hard question. The hard question is how, and that's the part we have to work out together. 

I don't have all the answers, and I'm not pretending this is a finished playbook. What I'm sure of is that reframing hunting around reasoning, applying narrow focus and strict guidelines and graduated autonomy, and keeping humans firmly in charge of strategy and novelty are good things to keep in mind as we figure it out. You hunters reading this are the ones who are actually going to shape what AI hunting becomes. It’s going to be on all of us to experiment, to try things, and then to share what we’ve built — whether that's code on GitHub, a blog post, or a conference talk. The whole field gets better when we share what worked and what didn't. I'm eagerly looking forward to seeing what we come up with.