AI Is Undeniably Weaponized Now. The Human Is the Adversary.

AI Is Undeniably Weaponized Now. The Human Is the Adversary.

Artificial Intelligence (AI) is undeniably weaponized now. But the human is still the adversary. AI changes the speed, scale, sophistication, and autonomy of cyberattacks, while in most AI-enabled attacks a human still defines the objective, determines the desired outcome, directs or delegates activity to the technology, and benefits from success.

AI has changed cybersecurity at extraordinary speed. Attackers now use AI as both a force multiplier and a capability multiplier. They can accelerate reconnaissance, generate and refine malware, build highly targeted phishing campaigns, impersonate executives, analyze enormous volumes of stolen data, discover relationships between data points, identify exploitable weaknesses, and increasingly execute sequences of actions through autonomous agents.

Yet those capabilities do not eliminate the human element. AI may execute the action. An agent may navigate the application. A model may create the campaign material. But behind most malicious AI activity, a human still defines the objective, decides what outcome matters, and benefits when the operation succeeds. Last I checked there wasn’t some AI technology cashing out some Bitcoin from a ransom and partying on a yacht.

Consequently, understanding The Adversarial Mindset matters more today than in the past.

Does AI Eliminate Human Intent From Cyberattacks?

No, AI does not eliminate human intent from cyberattacks. It can dramatically change how an attack is executed while a human adversary still defines the objective the technology is pursuing.

Too often, it feels like we talk about AI-powered attacks as though AI itself has suddenly become the adversary.

That framing can be misleading.

Consider the difference between traditional Generative AI (GenAI) and Agentic AI.

With traditional GenAI, the relationship remains relatively obvious. A human asks a model to do things such as identifying vulnerabilities, improving code, analyzing data, translating messages, performing research, or solving some other element of an operation.

The system provides the power. The human provides the objective.

Agentic AI creates more distance between those two elements.

Instead of asking AI to perform one task, a human can increasingly define an objective and allow an agent to determine how to accomplish it. The agent can browse websites, invoke tools, query data, make decisions, evaluate responses, select subsequent actions, and continue working toward a defined goal.

In other words, the human moves farther away from each individual action.

However, distance from execution does not automatically remove intent.

That distinction matters enormously for cybersecurity.

An attacker does not need to personally enumerate every endpoint, craft every request, write every line of malicious code, or send every social-engineering message to remain the adversary behind an operation.

AI gives that nefarious actor both abstraction and leverage.

Agentic AI gives that same human a certain level of delegation.

Neither automatically removes the human from the equation.

Who Is Acting When an AI Agent Accesses a Computer?

When an AI agent accesses a computer on a user’s behalf, the human user can remain the party performing the access. In the Ninth Circuit’s August 2026 Perplexity decision, the court treated the AI assistant as a tool and the human user as the party accessing Amazon’s systems for purposes of the federal Computer Fraud and Abuse Act (CFAA).

The dispute involved Perplexity’s Comet browser and its AI Assistant. Users could direct the Assistant to perform tasks on Amazon.com. Amazon argued that Perplexity’s technology accessed Amazon’s systems without authorization and sought relief under the CFAA, and its California counterpart (the Comprehensive Computer Data Access and Fraud Act – CDAFA).

The Ninth Circuit rejected Amazon’s theory at the preliminary-injunction stage.

More importantly, the court focused on a remarkably significant question:

Who actually accesses the computer?

On the record before it, the court concluded that the AI Assistant functioned as a tool. The court described the Assistant as a “tool, not a person for statutory purposes.” It then concluded that the user accessed Amazon’s computers while using the Assistant to carry out specific actions.

The decision marks the first federal appellate ruling addressing whether AI agents acting on behalf of users can legally access online platforms.

That distinction carries enormous significance beyond this particular dispute.

The court did not treat the AI agent as an independent legal actor simply because it could perform actions on behalf of a user. Instead, it looked through the technology to determine who actually performed the access for purposes of the statute.

At the same time, something important surfaced by way of a limitation.

The Ninth Circuit DID NOT create a sweeping legal doctrine that makes humans universally responsible for everything an AI system does. In fact, the opinion expressly states that it does not establish a new legal regime for agentic AI. The court limited its holding to the CFAA and CDAFA “access” issue, the technology at issue, and the factual record before it. Different facts, different levels of control, different laws, or different AI architectures could produce different outcomes.

Nevertheless, from a cybersecurity perspective, a much broader lesson remains powerful: technology can sit between a human and some action without rendering the human irrelevant (or innocent by default).

Should Security Programs Defend Against AI or the Adversary?

Security programs should defend against the adversary, not AI in isolation. AI mechanisms such as prompt injection, model poisoning, tool abuse, and MCP attacks matter, but they do not explain who wants to attack you, why they are targeting you, or how they will adapt.

The industry has become obsessed with AI security. Both RSAC and BlackHat this year showcased that obsession with great fanfare.

To answer the questions of who, why, and how, you need to understand the adversary, not just the technology at hand.

For example, imagine two attackers with access to exactly the same AI model and exactly the same agentic capabilities.

One is a teenager experimenting, testing boundaries.

The other operates inside an organized cybercriminal enterprise with millions of stolen identities, infostealer logs, credential collections, years of operational experience, and a clear understanding of how to monetize access.

The AI may be identical.

The threat is not.

The adversary behind the technology creates that difference.

Should Analysts and Frameworks Define a Security Program?

No, analysts and frameworks should not define a security program or its security strategy. They can inform both, but market intelligence about technologies, vendors, categories, and industry trends is not the same as understanding the adversary targeting your organization.

An industry analyst publishes some analysis. Vendors push categories. A maturity model emerges. Boards ask where the company sits relative to peers. CISOs then purchase technologies to fill perceived gaps. Eventually, the organization builds an architecture that looks remarkably similar to the architectures of dozens of other companies that consumed the same analyst research. And along the way end up with tons of tools whose true capabilities are not fully utilized.

To be clear, industry analysts provide value.

They can deliver market intelligence, technology comparisons, vendor analysis, spending benchmarks, maturity models, and useful observations about where the industry is heading.

However, organizations make a serious mistake when they use analyst research as the foundation of a security program.

Market intelligence is not adversary intelligence.

An analyst may understand the cybersecurity industry exceptionally well while possessing little firsthand understanding of the people trying to defeat your security program.

They may understand industry sectors, products, categories, vendors, differentiators and even what other CISOs are spending on.

Yet none of those things necessarily means they understand how a real adversary thinks.

More importantly, an adversary does not care whether your program aligns with an analyst’s reference architecture.

The adversary cares whether your defenses prevent the desired outcome.

Therefore, security leaders should never stop at this question:

What does the industry say a modern security program should contain?

They must also ask:

If I were a competent, cunning, determined attacker targeting this organization, how would I defeat what we have built?

What Blind Spot Do Many CISOs Have?

The blind spot many CISOs have is a limited understanding of the real adversaries their security programs are supposed to defeat. Managing risk, compliance, architecture, technology, and incident response is not the same as understanding how a determined adversary thinks, adapts, combines weaknesses, and pursues an objective.

I am not referring to understanding ethical hackers, penetration testers, or red-teamers. These professionals absolutely add value, but they ultimately operate within constraints established by rules of engagement.

I am talking about a real adversary with ill intent, whose motivations may be financial, ideological, geopolitical, personal, or simply opportunistic; and who feels no obligation to respect rules, scope, policy, business hours, budgets, architecture diagrams, or organizational boundaries.

That distinction matters.

A penetration tester typically asks whether something can be compromised within an agreed scope.

An adversary asks a very different question:

How do I achieve my objective despite everything this organization has done to stop me?

That question requires a fundamentally different way of thinking.

Why Should Defenders Start With the Human Behind the Machine?

Defenders should start with the human behind the machine because AI amplifies adversarial capability without automatically replacing adversarial intent. Less sophisticated attackers can now access capabilities that once required specialists, while sophisticated adversaries can operate faster, analyze more data, uncover hidden relationships, and adapt more efficiently.

As an example, consider that AI technologies create conditions in which enormous quantities of stolen identity data can be ingested and analyzed, revealing relationships humans would otherwise miss.

It can perform actions such as:

  • transforming OSINT into targeted and strategic intelligence
  • generating individualized social-engineering content based on attackable profiles across thousands of targets
  • creating strategic campaigns rapidly
  • refining malicious code
  • analyzing defensive responses and adaptively creating alternatives

But it does so at the request of some human element. Consequently, we should stop thinking only in terms of “AI attacks.” What we increasingly face are human adversaries with machine-scale leverage.

That represents a much more consequential problem.

How Does The Adversarial Mindset Change Security Strategy?

The Adversarial Mindset changes security strategy by making the adversary, not the framework, product, analyst, or compliance requirement, the starting point. Security leaders first ask what an adversary wants, what that adversary already knows, which assumptions and relationships can be exploited, and how the attacker will adapt when defenses interfere.

Ask questions like:

  • Who would want what we possess?
  • What exactly would they want?
  • What information about our people, systems, suppliers, executives, and customers do they already possibly have?
  • Which assumptions are we making that they would immediately challenge?
  • Where do identities, relationships, privileges, and trust create nefarious opportunities?
  • How could they combine several individually minor weaknesses into one viable attack path?
  • How would they adapt after encountering resistance to their techniques?
  • How could AI make each of those steps of adaptability cheaper, faster, or more precise?

At that point, you begin designing security from the adversary backward.

That is the essence of The Adversarial Mindset.

Moreover, this approach does not require organizations to abandon frameworks, compliance obligations, analyst research, or established security architectures. Those tools still serve important purposes.

However, they should support your security strategy rather than define it.

The adversary should help define it.

Why Does AI Make The Adversarial Mindset More Important?

AI makes The Adversarial Mindset more important because it gives human adversaries greater speed, scale, precision, leverage, and increasingly autonomous execution. Security teams therefore need to understand not only what AI can do, but what a motivated adversary can now accomplish because those capabilities exist.

The cybersecurity industry will inevitably spend enormous amounts of time debating how autonomous AI will become.

That discussion absolutely matters.

Eventually, increasingly autonomous systems may force us to confront genuinely difficult questions about intent, accountability, responsibility, control, and attribution.

However, that conversation leaves gaps. Organizations cannot afford to wait for those philosophical and legal questions to reach resolution. This is especially so for larger organizations that are not exactly agile.

Today, humans are discovering what AI can do for them.

Some of those humans are defenders, others are researchers, and still others are innovators.

Realistically, some are adversaries.

The last group does not care whether your AI strategy appears in an analyst report. They do not care which security technologies occupy a leader quadrant, or how mature your program looks against some industry benchmark.

They care whether they can accomplish their objective.

The Ninth Circuit’s Perplexity decision gives us an important legal manifestation of a broader technological reality: an intelligent tool can become increasingly capable while still operating in service of human direction.

Therefore, defenders should resist the temptation to focus exclusively on the technology.

That distinction changes the questions security leaders should be asking.

“What can AI do?”

This has to start migrating towards something like:

“What can an adversary now do because AI exists?”

Those are very different questions.

Ultimately, the second question is the one our security programs need to answer. AI is undeniably weaponized now. The human is the adversary.

Note: This article discusses the cybersecurity implications of Amazon.com Services, LLC v. Perplexity AI, Inc. and does not provide legal advice. The Ninth Circuit’s August 4, 2026 decision concerned a preliminary injunction and a specific interpretation of “access” under the CFAA and CDAFA based on the record before the court.

Reasons AI Governance Fails Without The Adversarial Mindset

AI Governance Fails Without The Adversarial Mindset
Image generated by Jetpack AI, 2026, via WordPress

I genuinely believe that most AI governance programs begin with good intentions. But that doesn’t instantly equate to a successful program. Often, AI governance fails without the adversarial mindset.

These types of governance programs typically define acceptable use, establish review committees, classify risk, document models, assign owners, and publish principles around fairness, privacy, transparency, and human oversight.

Undoubtedly, those activities matter.

Those programs also tend to assume that people, systems, data, and models will operate within the boundaries the organization designed.

An adversary makes no such assumption. Moreover, the boundaries organizations have designed mean nothing to an adversary.

Attackers will generally search for paths of least resistance that lead to success. This includes ways to manipulate inputs, compromise identities, poison data, exploit integrations, misuse legitimate capabilities, and confuse and manipulate humans.

Employees, contractors, customers, partners, activists, fraudsters, competitors, and nation-state actors may all test the distance between what an AI system was intended to do and what it can be manipulated to do.

Governance that considers only intended behavior is policy.

Governance that anticipates intentional manipulation becomes resilience.

AI governance without an adversarial mindset documents how a system should behave. It does not prepare the organization for how the system can be made to behave.

The Adversary Has a Vote

Executives often discuss AI risk as though the organization controls all relevant variables.

Leaders choose the model. Engineers establish the architecture. Data teams manage information. Security implements controls. Legal writes policy. Users receive training.

Then the system enters the real world.

Customers provide unexpected inputs. Employees find shortcuts. Vendors go out of business. Models drift. Credentials become exposed. Attackers study architectures and systems. Data sources become contaminated.

Ultimately, the adversary gets a vote in how the system operates.

This principle has shaped cybersecurity for decades. A secure architecture cannot assume that users will follow instructions, data will remain trustworthy, or that controls will continuously operate exactly as designed.

AI governance must adopt a similar reality.

MITRE ATLAS (https://atlas.mitre.org/) documents tactics and techniques used against predictive, generative, and agentic AI systems. NIST has developed a taxonomy for adversarial machine learning (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf). The NCSC’s secure AI guidance (https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines/secure-design) emphasizes threat modeling across design, development, deployment, and operation.

Those movements create a message that is consistent: AI risk cannot be governed solely through compliance reviews and intended-use documentation.

AI Governance Must Cover More Than Model Failure

Executives commonly focus on whether an AI system will produce an incorrect answer.

Yet that is only one failure mode.

Interestingly, an AI system may produce an accurate answer for the wrong person. It may also follow a valid command issued through a compromised identity or expose sensitive information while correctly completing a task. Sound recommendations may be generated based on poisoned data.

The model may operate exactly as designed while the larger system fails.

This distinction matters because AI is not merely a model.

It is an architecture of identities, data, software, infrastructure, integrations, humans, workflows, and delegated authority.

An adversary does not need to attack the most sophisticated component. The adversary will attack the component that produces the greatest advantage or outcome for the least effort.

That may very well be the model itself.

But, it may also be an exposed API key, overprivileged service account, manipulated document, compromised developer, insecure plugin, careless employee, or trusted third-party data source.

An Adversarial Mindset Is Not Merely Pessimism

Some leaders resist adversarial thinking because it can sound negative or obstructive. Others claim that doing so empowers and/or validates the adversary.

Those notions misunderstand the purpose of the adversarial mindset.

An adversarial mindset does not assume that every person is malicious or that every AI initiative will fail. It assumes that valuable systems will attract manipulation and that unintended behavior becomes more likely as complexity, scope, and authority increase.

It asks the organization to examine its assumptions before an attacker does.

This mindset challenges statements and/or beliefs such as:

  • Only employees can access the system.
  • The model does not have access to sensitive data.
  • A human reviews every important decision.
  • The agent can only use approved tools.
  • The training data comes from trusted sources.
  • We have a kill switch, and it works.

Each statement may be technically accurate while concealing dangerous assumptions. As such, further probing may look like:

  • Which employees?
  • Through which identities?
  • Does the human reviewer understand enough to challenge the model or system?
  • Can approved tools be combined to create an unapproved outcome?
  • Who determines whether a source remains trustworthy?
  • How long does shutdown actually take?

The adversarial mindset turns reassuring claims into testable questions.

Seven Questions Leaders Should Ask

1. How Could Someone Intentionally Misuse This System?

Governance reviews often begin with the approved business use case.

Adversarial governance begins with the abuse case.

Leaders should scrutinize the angles. Ask how an employee, customer, contractor, criminal, or competitor could use some legitimate capability for a different objective.

A customer-service assistant might help employees retrieve account information. Could it also help a malicious insider assemble customer profiles?

A fraud model might identify suspicious payments. Could someone probe its thresholds and learn how to avoid detection?

A security agent might isolate compromised systems. Could an attacker manipulate it into disrupting legitimate operations?

Security teams should create abuse stories alongside legitimate user stories. Every material use case should identify who may benefit from subverting it and which capabilities they would seek out in pursuit of that benefit.

2. What Happens When the Data Becomes Hostile?

Organizations tend to view data as an input.

Adversaries may use it as code, instructions, a weapon, or a persistence mechanism.

Manipulated training data can alter future model behavior. Poisoned reference material can corrupt retrieval-augmented systems. Malicious instructions embedded in emails, websites, documents, or images can influence agents that consume external content.

The source may appear trusted while the content is not.

Leaders should ask:

  • Which data sources can influence the system?
  • Who can change those sources?
  • How does the organization establish provenance?
  • Can the system separate data from instructions?
  • What happens when sources conflict?
  • How quickly can poisoned information be detected and removed?

Data governance must assess not only quality and privacy but also hostility.

3. Which Identity Creates the Greatest Blast Radius?

Eventually, many attacks turn out to have some intersection with identity.

A compromised developer can change code. A stolen service credential can invoke functionality. An overprivileged agent can call dangerous tools. An administrator can modify thresholds or do things like suppress logs.

Leaders should identify the human and non-human identities capable of influencing high-consequence AI systems.

They should understand:

  • Who can alter data, especially data used for training models.
  • Who can change policies or guardrails.
  • Who can deploy or replace models.
  • Which agents can invoke production tools.
  • Who can disable monitoring.
  • Which identities can approve their own changes.

The most dangerous identity may not possess the most obvious administrative title. It may be an automation account that quietly connects elements such as models, data, and production systems.

4. Can the Human in the Loop Be Manipulated?

Organizations frequently rely on “human in the loop” as their final safeguard.

Adversarial thinking asks whether the human loop actually works.

People may over-trust AI recommendations, especially when a system appears confident or technically sophisticated. Reviewers may approve outputs automatically because of enormous volumes of data to review, time pressure, weak interfaces, inadequate context, or fear of challenging a system the organization has heavily promoted.

An attacker may also target the reviewer, a human, directly. After all, whether purposely or not, humans are the source of many unfortunate cyber events.

Manipulated systems could present targeted evidence, conceal uncertainty, overwhelm the reviewer with volume, or frame the decision in a way that encourages the desired behavior (of the nefarious actor).

Meaningful human oversight requires authority, context, time, training, and psychological permission to disagree.

A person who can technically click “reject” but is organizationally discouraged from doing so is not an effective control.

5. What Happens When Trusted Components Become Untrustworthy?

AI systems depend on external data, models, open-source libraries, cloud platforms, plugins, APIs, and vendors.

Each dependency extends the trust boundary.

A provider may change a model. An integration may gain new capabilities, or lose existing ones. A library may become compromised. A data source may introduce manipulated content. A vendor may retain more information than expected.

Third-party risk assessments often occur before deployment and then fade into GRC oblivion.

Adversarial governance treats trust as temporary.

Leaders should know which external components can influence decisions or actions, what changes providers are making, how the organization detects those changes, and whether it can continue operating safely when the dependency becomes unavailable or untrustworthy. These are elements that make up a resilient ecosystem.

6. How Would We Detect a Quiet Failure?

Not every AI incident will produce blinking lights, loud alarms, an obvious outage or some catastrophic result.

Some of the most damaging failures will appear gradually.

A model may become slightly less accurate for a specific population. An agent may begin retrieving more data than it needs. A recommendation system may slowly favor manipulated content. A fraud model may become less sensitive to a criminal technique.

The system continues to operate, and traditional availability metrics remain healthy.

Leaders need indicators that reveal changes in context, behavior, authority, data access, confidence, exception rates, and human impact.

They should also monitor near misses. An action stopped by a human or compensating control still reveals a weakness in the system.

Simply put, governance cannot measure only uptime and adoption. It must measure whether the system remains within its intended behavioral boundaries.

7. Can We Contain the System Before We Understand the Incident?

Executives often assume that teams can shut down an AI system when something goes wrong.

That assumption should be tested.

A system may be embedded in business workflows. Multiple applications may depend on this integration. Agents may retain active sessions or credentials. Third-party components may continue processing information. Teams may hesitate because shutting some system down could create operational consequences.

Incident response requires the ability to reduce authority quickly, even before investigators understand the complete failure.

Organizations should be able to:

  • Revoke agent and service-account access.
  • Disable specific tools or integrations.
  • Quarantine suspicious data sources.
  • Roll back models and configurations.
  • Move automated decisions into manual review.
  • Preserve evidence for investigation.
  • Continue critical operations in a degraded mode.

The ability to stop an AI system safely needs to be a design requirement, not an emergency improvisation.

Turn Governance Into an Adversarial Operating Model

An adversarial mindset must produce more than provocative questions. When pursued properly this mindset should guide and mold entire security programs.

Organizations should embed this mindset into their operating model.

That includes:

  • Threat modeling – examine the complete AI architecture, not only the model.
  • Abuse-case development – document how legitimate capabilities could support illegitimate objectives.
  • Red teaming – without boundaries (attackers have none) test models, identities, integrations, users, and workflows.
  • Control validation – under realistic conditions, prove that guardrails work rather than accepting that they exist.
  • Behavioral monitoring – actively detect changes in data access, authority, tool use, and outcomes.
  • Incident exercises – regularly rehearse containment, rollback, investigation, communication, and recovery. This can follow the standard tabletop model even though many of those exercises introduce boundaries and constraints that take them out of the realm of realistic conditions.
  • Continuous reassessment – review risk whenever the system’s data, model, tools, users, or authority change.

Governance should operate as a feedback loop:

Assume → Challenge → Test → Observe → Adapt

Typically, a policy changes only when someone updates the document. An adversarial governance program needs to change when evidence reveals that an assumption no longer holds.

Policy Describes the Organization You Hope Exists

AI governance policies describe approved behavior. They define responsibilities, expectations, controls, and boundaries.

These definitions are necessary.

Sadly, they are not the same as actual readiness.

The real organization includes shortcuts, legacy access, human bias, compromised credentials, conflicting incentives, third-party dependencies, weak integrations, and determined adversaries.

An adversarial mindset closes the distance between the organization described by policy and the one that actually operates under pressure.

Leaders must ask more than whether AI is accurate, compliant, or useful.

They must ask how someone could manipulate it, misuse it, impersonate a trusted identity, corrupt its data, exploit its authority, or influence the humans responsible for oversight.

AI governance without an adversarial mindset is just policy.

Policy defines the rules.

The adversarial mindset determines whether those rules survive contact with reality.

Why AI Governance Is Now a Critical Leadership Responsibility

Why AI Governance Is Now a Critical Leadership Responsibility.
Image generated by Jetpack AI, 2026, via WordPress

Unfortunately, many organizations are on the path to repeat one of the most consequential mistakes that we have made in this industry. AI Governance is now a critical leadership responsibility.

For years, executive leaders treated cybersecurity as a technical issue. It was convenient to tuck it away under Information Technology (IT) and it became someone else’s problem. They delegated it to specialists, discussed it only when budgets or incidents demanded attention, and assumed that technical teams could contain the risk.

Then the breaches became business disruptions. Regulatory consequences reached the CFO as well as the boardroom. Trust degraded, especially from customers. Operations stopped. Executives discovered that although they could delegate security work, they could not delegate accountability for the outcome. Tucking it conveniently inside of IT was no longer an option.

Artificial Intelligence (AI) is now following an eerily similar path, only much faster.

Many organizations still treat AI governance as a collection of technical controls, acceptable-use policies, legal reviews, and model assessments. They assign it to IT, data science, security, privacy, or compliance and assume those functions can govern the technology on behalf of the enterprise.

Simply put, they cannot.

Those teams can implement controls, evaluate models, monitor systems, and advise the business. They cannot independently decide which risks the organization should accept, which decisions should be influenced by AI or automation, where humans must retain authority, or who remains accountable when an AI-enabled processes have a negative impact.

Those are leadership decisions.

AI governance is not a technical specialization that executives can delegate. It is a leadership capability that executives must develop.

Leadership Cannot Outsource Accountability

I have spent much of my career moving between deeply technical responsibilities and executive leadership. I have worked in federal law enforcement technology, application architecture, offensive security, cybersecurity, the CISO function, the CTO function, and the CEO role.

Those experiences repeatedly reinforced the same lesson: technology may create the mechanism, but leadership creates the consequence.

For me, it took a while but that had to sink in as I lived my professional journey.

An algorithm does not determine whether an organization should use AI to evaluate employees, prioritize customers, detect fraud, approve transactions, recommend medical actions, or automate security responses. Leaders make those decisions.

The system may generate a recommendation, classification, or action. It does not absorb responsibility for the result. It simply generates an output.

A model cannot accept enterprise risk.

A chatbot is likely to not be able to explain a decision to an auditor.

An autonomous agent cannot appear before the board and defend the authority it was granted.

The human signature may become less visible as the footprints of AI and automation increase, but it does not disappear. It moves upward through the organization until it reaches the leaders who authorized these systems, established their boundaries (hopefully), funded their deployments, and accepted the risks at hand (again, hopefully).

AI Means More Than Generative AI

One reason organizations misunderstand AI governance is that most current conversations concentrate so heavily on Generative AI (GenAI). And the notion of “AI” in those conversations is incorrectly used to mean “GenAI”.

Large Language Models (LLMs), copilots, image generators, and conversational interfaces have made a subset of AI (GenAI) visible to almost everyone. They have also narrowed the discussion.

AI as a field extends far beyond generated text and images. Some organizations already use AI to:

  • Detect financial fraud and account takeover.
  • Score credit and insurance risk.
  • Identify cyber threats and automate containment.
  • Rank candidates and evaluate employee performance.
  • Recognize faces, objects, behaviors, and anomalies.
  • Predict equipment failures and optimize industrial processes.
  • Recommend products, services, prices, and content.
  • Route vehicles, shipments, and supply-chain resources.
  • Support medical diagnosis and clinical decisions.
  • Operate robots, sensors, and autonomous systems.

These systems may never generate a paragraph, but they can still shape someone’s employment, financial access, safety, privacy, or treatment.

Leaders who define AI governance as a policy for using ChatGPT will govern only the most visible layer of a much larger technology landscape.

Every system that predicts, accepts, rejects, classifies, recommends, prioritizes, optimizes, or acts should fall within the governance conversation. Yet, the limited understanding of where AI actually exists within organizations does not make that proper conversation possible.

AI Governance Begins With Ownership

Every material AI system needs an accountable owner. It doesn’t need a committee or some vague reference to “the business.”

A named leader must own the business purpose, risk, performance, and consequences of the system.

Technical ownership also matters, but it is not the same as business accountability. A data science team may build a model. A cloud team may host it. Security may monitor it. Legal may review it. None of those activities answers this central question:

Who has the authority to decide that this system should operate?

Ownership must extend across the AI lifecycle:

  • Who approved the use case?
  • Who authorized the data?
  • Who selected or developed the model?
  • Who defined acceptable performance?
  • Who approved production deployment?
  • Who monitors changes in behavior?
  • Who can suspend the system?
  • Who is accountable for the outcome?

When organizations cannot answer those questions, they do not have governance. They have the illusion of governance via distributed activity and no focused accountability.

Leaders Must Establish AI Risk Appetite

Many organizations speak about AI principles. Fewer define their AI risk appetite.

Principles describe what an organization values. Risk appetite determines what it will permit.

Effective leadership demands decisions around where AI may operate autonomously, where it may only recommend, and where it should not participate at all.

That requires decisions about:

  • Which data AI systems may access.
  • Which decisions may be automated.
  • Which decisions require human approval.
  • How much uncertainty the organization will tolerate.
  • What level of explainability a use case requires.
  • How much authority and/or autonomy an AI agent may receive.
  • Which failures require immediate shutdown.
  • When efficiency cannot outweigh safety, fairness, privacy, or trust.

For example, a fraud-detection model and an autonomous industrial controller should not operate under identical tolerance levels. Neither should a marketing assistant and a system that affects employment or access to employee resources.

Optimally, governance reflects potential consequence.

That judgment cannot come exclusively from a technical scoring system. It requires leaders who understand the organization’s culture, strategy, customers, obligations, operations, and values.

Human Oversight Must Be Real

“Human in the loop” has become a very overused phrase in AI governance.

Organizations often point to human review as evidence that a system remains under control. But placing a person near an automated decision does not guarantee meaningful oversight. Nor does it even reflect reality in some cases. The sheer volume of what AI powered systems can generate make human intervention questionable.

The human may lack sufficient time and/or information to challenge the system. The interface may encourage automatic approval. Time pressure may make careful review impossible. Employees may assume that the model is more accurate than they are. Responsibility may become so distributed that nobody feels empowered to intervene.

Realistically, human oversight requires more than a final approval button.

The reviewer must have:

  • Enough context to understand the decision.
  • Enough authority to reject or override it.
  • Enough time to exercise independent judgment.
  • Enough technical literacy to recognize uncertainty.
  • Enough organizational protection to challenge the system.

Effectively, leaders must also consider automation bias. This is the natural tendency for people to trust the output of a system that appears objective, complex, or authoritative.

Ultimately, the human factor does not disappear when AI enters a workflow. It becomes more complicated.

Identity and Authority Form the AI Control Plane

Oddly, many AI governance discussions often focus on models and data while overlooking identity.

That is a serious mistake.

People build AI systems. Service accounts train them. Pipelines deploy them. Applications invoke them. Administrators change them. Agents increasingly act through them.

Every step involves an identity exercising authority.

An organization must know:

  • Who or what is acting.
  • Which identity the actor represents.
  • What authority that identity possesses.
  • What constraints exist on that authority.
  • Who granted that authority.
  • Whether the authority remains appropriate.
  • Whether the identity remains trustworthy.

This becomes especially important with autonomous agents. An agent may retrieve information, call APIs, create accounts, modify configurations, communicate with customers, or initiate actions.

An agent should not receive unrestricted access simply because an authenticated employee launched it.

It needs its own identity, constrained privileges, defined purpose, limited duration, attributable owner, and immediate revocation path.

The organization should preserve the full chain of authority:

  1. Human initiator
  2. Agent identity
  3. Delegated permission
  4. Tool invocation
  5. Impacted resource

Without that chain, the organization cannot distinguish legitimate automation from compromised autonomy.

The Adversary Gets a Vote

AI governance cannot operate only under the assumption that people and systems will behave as intended.

Adversaries couldn’t care less about the rules. They will manipulate models, compromise identities, poison data, steal credentials, exploit integrations, and misuse legitimate functionality.

They will search for the gap between what leaders think the system does and how it actually behaves under pressure.

This is where an adversarial mindset becomes essential.

Leaders should not ask only, “Does the system work?” In a headspace where there are no limits, they should also ask:

  • How could someone intentionally misuse it?
  • What happens if its data becomes untrustworthy?
  • Could a compromised identity change its behavior?
  • Can an attacker manipulate the human reviewer?
  • What authority could the system silently accumulate over time?
  • How would we detect subtle rather than catastrophic failure?
  • Can we stop it before we fully understand the incident?

Governance that assumes normal behavior is policy. And look at how effective policies are at stopping nefarious actors.

Governance that anticipates manipulation is a healthy step towards resilience.

AI Governance Must Become an Operating Rhythm

Organizations will not govern AI effectively through a policy, its annual review, or a one-time model assessment.

AI systems change. Their data changes. As do their users. Their integrations expand while authority grows. Their behavior may also shift as the environment around them changes. All of this is also happening at a rate of speed many organizations are not prepared for.

Governance must therefore become part of the organization’s operating rhythm.

Executive teams should receive recurring visibility into:

  • The inventory of blindly discovered (approved and unapproved) AI systems.
  • High-consequence use cases.
  • Detected changes in model behavior or authority.
  • Exceptions to established guardrails.
  • Third-party and supply-chain dependencies.
  • Identity exposure affecting AI environments.
  • Evidence that human oversight remains effective.

The objective is not to force leaders to review algorithms. One is to ensure that leadership understands where the organization has transferred decision-making power to machines and what could happen if that transfer fails. Another is to build a cadence of readiness preparation so that negative surprises are minimized.

Five Questions Executive Leaders Should Ask Now

Every executive team should be able to answer five questions:

  1. Where is AI already influencing decisions or actions across the organization?
  2. Who owns each material AI system and remains accountable for its outcomes?
  3. Which decisions may AI make autonomously, recommend to a human, or never influence?
  4. Can we trace every important AI action to a human or non-human identity and its delegated authority?
  5. Can we suspend the system quickly when its behavior, data, identity, or operating environment becomes untrustworthy?

If leadership cannot answer those questions, the organization is not ready to deploy and/or scale AI responsibly.

Leadership Is the Ultimate AI Control

Technical teams will remain essential to AI governance. Organizations need skilled architects, data scientists, security professionals, privacy experts, engineers, and legal counsel.

But expertise does not replace executive accountability.

AI will compress the distance between a leadership decision and its technological consequences. A policy choice can become an automated workflow. A risk tolerance can become a model threshold. A poorly governed identity can become an autonomous actor.

The organizations that succeed will not necessarily be those that adopt AI fastest.

They will be the organizations whose leaders understand where AI should have authority, establish clear boundaries around that authority, demand attributable ownership, anticipate adversarial behavior, and retain the ability to intervene.

We eventually learned that cybersecurity was not merely a technology problem.

We should not need another decade of incidents to learn the same lesson about AI.

AI Governance is now a critical leadership responsibility, it is also a leadership test.

The outcomes will reveal who studied and prepared for that test.

Fuzed Identities and the Collapse of the Corporate-Personal Security Boundary

Fuzed Identities and the Collapse of the Corporate-Personal Security Boundary
Image generated by Jetpack AI, 2026, via WordPress

The collapse of the corporate-personal security boundary is upon us. Cybersecurity has spent decades protecting accounts while adversaries have concentrated on compromising people.

That distinction is becoming increasingly consequential.

Enterprise identity systems divide a person into manageable objects: an employee record, directory account, email address, mobile number, device registration, cloud identity, privileged account, and application entitlement. Each object is assigned to a platform, protected by controls, and evaluated within a defined organizational boundary.

The individual behind those objects does not live within that boundary.

The same person maintains multiple personal email accounts, mobile devices, usernames, social profiles, messaging accounts, browser sessions, payment identifiers, cloud applications, and years of accumulated digital exposure. Those identities intersect with the enterprise whenever the person opens a work document on a personal device, reuses a password, accesses work from a personal device, stores a business session in a browser, uses a personal telephone number for recovery, or becomes the target of an infostealer.

For the adversary, there is no meaningful distinction between an employee’s corporate identity and personal identities. There is simply a collection of possible routes to the same human target.

This reality requires a new security construct: the fuzed identity.

From record matching to attributable identity

A fuzed identity is a holistic identity view created when attribution links seemingly disparate identifiers and establishes, to an appropriate confidence threshold, that they belong to the same individual.

This is more sophisticated than mere data aggregation or de-duplication.

Two records should not be linked merely because they contain similar names. Names are shared, addresses change, telephone numbers are reassigned, and identity data can be deliberately manipulated.

Reliable identity fuzing combines multiple forms of evidence. These can include historical email address relationships, telephone numbers, device characteristics, usernames, infrastructure, behavioral patterns, credentials, temporal consistency, location signals, payment artifacts, social accounts, breach records, and other attributable data.

Each relationship must retain its source, age, relevance, and confidence. Historical context can play a very powerful role when performing attribution.

The result is not simply a larger identity profile. It is an evidentiary model that explains why multiple digital artifacts are believed to represent the same person.

This distinction becomes especially important when identity intelligence influences access, fraud prevention, investigations, or workforce security. Attribution must be explainable, contestable, and proportionate to the action being considered.

The account-centric blind spot

Identity and Access Management (IAM) systems perform a necessary but limited function. They determine whether an account can authenticate and whether it is authorized to perform a requested action.

They do not necessarily determine who is truly behind a given account.

Even strong authentication can prove only that an actor possesses an accepted authenticator. It does not always prove that the actor is the person the organization intended to provide access to.

A stolen session token, coerced authentication, compromised recovery channel, fraudulent enrollment, or synthetic persona can satisfy technical controls while defeating the business purpose of those controls.

NIST’s 2025 revision of its Digital Identity Guidelines (https://pages.nist.gov/800-63-4/) recognizes this changing environment. SP 800-63-4 expands fraud-related identity-proofing guidance, recommends continuous evaluation metrics, and introduces controls addressing forged media and injection attacks. These additions reflect a fundamental change: identity assurance cannot be reduced to checking documents during enrollment and validating credentials at login.

Identity must be evaluated as an evolving risk condition.

A user who was legitimate at enrollment may later have credentials stolen. A secure corporate endpoint may coexist with an infected home computer. A trusted contractor may accumulate new external exposure. A valid employee account may be operated by an entirely different person.

An account-centric model can miss these changes because the account itself remains valid.

When the personal device becomes enterprise infrastructure

Hybrid work erased many of the physical distinctions between personal and enterprise technology. Infostealers are now exploiting the remaining logical distinctions.

Microsoft Threat Intelligence reported in June 2026 that infostealer infections often occur outside managed enterprise networks, including on employees’ home computers where corporate monitoring is absent (https://www.microsoft.com/en-us/security/blog/2026/06/24/stealc-and-amadey-breaking-down-infostealers-and-the-cybercrime-services-that-deliver-them/). These infections may collect legitimate credentials and active session cookies, allowing attackers to authenticate as the victim and potentially bypass Multi-Factor Authentication (MFA).

StealC, one of the malware families analyzed by Microsoft, collects credentials and cookies from browsers while also targeting email clients, messaging applications, cryptocurrency wallets, gaming platforms, screenshots, and other data.

From the malware’s perspective, all accessible identities are part of one collection event.

An employee may think of a browser as personal because it runs on a home computer. The browser may nevertheless contain:

  • A corporate Microsoft 365 session.
  • A customer relationship management login.
  • A personal email account used for recovery.
  • Social media credentials.
  • Personal financial information.
  • Messaging sessions.
  • Autofill data containing addresses and telephone numbers.

An infection of this type creates a package representing the person across multiple contexts.

The criminal buying or processing that package can search for the most valuable route. The initial compromise might be personal, but the monetization can be corporate.

Verizon’s 2025 credential research (https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/) found that compromised credentials were involved as an initial access vector in 22 percent of the breaches reviewed. Verizon also found that, for the median user appearing in its infostealer dataset, only 49 percent of passwords across services were distinct.

Password reuse is only one linkage. Shared recovery addresses, telephone numbers, browser cookies, device fingerprints, usernames, and behavioral patterns can create others.

The enterprise therefore cannot evaluate identity exposure solely by searching for its corporate domain. It must understand identities connected to the person operating under that domain.

Re-framing employee identity risk

Fuzed identity intelligence does not mean a default classification of certain employees as inherently risky.

It means identifying security exposure associated with the employee’s connected, holistic digital identity.

This distinction is important. A person may be an entirely trustworthy employee while still presenting elevated technical risk because their credentials, sessions, devices, or personal identifiers have been compromised.

A fuzed identity model could allow an enterprise to determine that:

  • A breached personal email account belongs to a privileged administrator.
  • An infected personal device contained corporate authentication material.
  • An executive’s mobile number is being used in impersonation campaigns.
  • Several employee accounts share an exposed recovery mechanism.
  • A contractor’s identity is connected to multiple suspicious applications.
  • A departed employee retains active identities under alternate addresses.
  • An apparent login anomaly matches a broader pattern of identity compromise.

This additional context improves prioritization.

A ten-year-old password exposure involving a deactivated consumer account should not receive the same response as a fresh malware log containing an administrator’s corporate session cookie. But that ten-year-old password may be a key attribute against modern data based on the behavior of some humans.

The value of fuzed identity is not that it produces more alerts. Its value is that it distinguishes meaningful identity risk from noise.

Synthetic identity as an enterprise threat

Synthetic identity is frequently discussed as a financial fraud problem, but the underlying method extends directly into enterprise security.

The Federal Reserve describes a synthetic identity as one constructed by combining real and fabricated information (https://fedpaymentsimprovement.org/wp-content/uploads/frs-synthetic-identity-payments-fraud-white-paper-july-2019.pdf). A legitimate Social Security Number (SSN) might be paired with a fictional name, address, or date of birth. Because some components are authentic, the resulting identity can evade conventional verification and credit-screening processes.

Cybercriminals can apply the same architecture outside financial services.

A synthetic employment identity might combine:

  • A stolen person’s name or identity document.
  • An AI-generated profile photograph.
  • A fabricated employment history.
  • A legitimate residential address supplied by an accomplice.
  • A US-based telephone number.
  • A social profile created months earlier.
  • A domestic bank or payment account.
  • A remotely accessible corporate laptop.
  • Technical work performed by someone in another country.

Every component contributes to the appearance of legitimacy.

An identity-proofing process that validates each component independently may approve the applicant. A fuzed identity process examines whether the components form a coherent person.

It looks for evidence that several applicants use the same devices, infrastructure, telephone numbers, payment destinations, writing patterns, facilitators, or historical identities. It also identifies evidence that the supposed individual has a contradictory or impossible digital history.

The synthetic insider

The North Korean remote IT worker schemes demonstrate what happens when synthetic and stolen identities move beyond account fraud and become enterprise infiltration mechanisms.

In April 2026, the US Department of Justice announced the sentencing of two US facilitators involved in a scheme that placed North Korean IT workers at more than 100 US companies (https://www.justice.gov/opa/pr/two-us-nationals-sentenced-facilitating-fraudulent-remote-information-technology-worker-0). The operation compromised the identities of more than 80 US persons, generated over $5 million in revenue, and caused victim organizations at least $3 million in legal, remediation, and related costs.

The workers were not merely creating fraudulent accounts. They were becoming employees.

The operation used stolen identities, alias email addresses, social media profiles, job-site accounts, cross-border payment systems, shell companies, proxy computers, US-based facilitators, and laptop farms. Some workers obtained access to sensitive employer data, source code, and export-controlled information.

This is more accurately understood as a synthetic insider operation.

Traditional insider-risk programs generally begin after a person has joined the organization. They monitor the behavior of someone the enterprise believes it has already identified.

A synthetic insider defeats that assumption.

The organization monitors the account and device behavior of an employee who does not actually exist in the form presented during hiring. The person communicating with management may differ from the person operating the computer. Several supposed employees may even be controlled by the same network of actors.

Fuzed identity intelligence shifts part of insider-risk analysis to exist earlier in the lifecycle. It helps evaluate whether the applicant, contractor, employee, account operator, device user, and payment recipient appear to be the same attributable person.

Collapsing criminal aliases

The same capability can support cybercrime investigations.

Threat actors compartmentalize their operations. One person may use separate identities for malware development, forum participation, initial-access sales, cryptocurrency payments, infrastructure registration, social engineering, and communication with victims.

The objective is to prevent any one persona from revealing the whole operation.

Identity attribution undermines that compartmentalization.

A fuzed identity graph may establish that:

  • Two forum aliases use email addresses exposed with the same password.
  • Several messaging accounts were accessed from the same device.
  • A cryptocurrency wallet connects previously unrelated personas.
  • An infrastructure registration uses a historical personal email address.
  • A threat actor’s writing patterns persist across aliases.
  • Multiple synthetic employees share a facilitator or payment endpoint.
  • A supposedly new actor reuses identifiers from an older campaign.

A single relationship rarely proves common ownership. Multiple independent relationships may.

The analytical objective is to move from possibility to corroboration. Every link should contribute to a cumulative confidence assessment, and analysts should distinguish confirmed attribution from assessed attribution.

When that discipline is applied, an adversary’s collection of disposable identities becomes a map back to the underlying actor or actor cluster.

Moving from identity management to identity intelligence

Fuzed identities are by no means replacements for IAM, identity governance, Privileged Access Management (PAM), Security Information and Event Management (SIEM), endpoint detection, fraud prevention, or threat intelligence.

They should improve the decisions those systems make.

An identity intelligence layer can provide context at several points:

Enrollment and hiring

Detect identity inconsistencies, duplicate applicants, synthetic personas, reused infrastructure, and relationships to known facilitators.

Authentication

Adjust authentication requirements based on current external exposure, device risk, session compromise, and identity confidence.

Privileged access

Prioritize monitoring and verification when a highly privileged individual’s connected identity shows evidence of recent compromise.

Security operations

Connect apparently unrelated alerts involving different emails, usernames, devices, or accounts to one affected person.

Incident response

Determine the full scope of identity compromise rather than resetting only the credential named in the original alert.

Threat intelligence

Link aliases, infrastructure, wallets, accounts, behavioral signals, and historical data into attributable actor clusters.

Third-party risk

Understand whether contractors and supplier identities create exposure that conventional vendor-level assessments do not reveal.

The operating principle is straightforward:

Evaluate identity risk at the level at which the adversary exploits it, the person, not merely an account.

Confidence, provenance, and time

Identity fuzing can create serious consequences if poorly implemented.

Three elements are essential to operate with legitimacy.

  • Every identity relationship needs a confidence level – a shared name may be a weak signal. A shared device, unique telephone number, credential history, and consistent behavioral pattern may provide much stronger corroboration.
  • Every relationship needs provenance – analysts and decision-makers must know where the data came from, how it was collected, when it was observed, and whether it has been independently verified.
  • Identity intelligence must account for time and history – addresses change. Telephone numbers are reassigned. Credentials become obsolete. Devices are transferred. Criminals deliberately seed misleading data. Data, or close derivatives, used 15 years ago can pop up today,

A connection that was accurate five years ago may not describe the current identity. On the flip side a human can slip up and use a username or moniker today that they used 10 years ago. They just thought the world forgot about it.

A fuzed identity is therefore not a permanent static profile. It is a versioned assessment that evolves as evidence evolves.

The necessary privacy boundary

The disappearance of the technical boundary between personal and corporate identity does not eliminate ethical, legal, or privacy boundaries.

This point must be explicit.

A fuzed identity program should focus on security-relevant exposure, not personal curiosity. Organizations should establish a legitimate purpose, use validated sources of data, restrict internal access, define retention periods, maintain auditability, and provide human review before consequential actions.

Organizations should not infer risk from lawful personal beliefs, associations, medical information, family relationships, political activity, or other protected or irrelevant characteristics.

Nor should an external identity signal automatically produce disciplinary or employment action.

The appropriate response to a compromised personal device may be to revoke enterprise sessions and help the employee remediate the exposure. Instantly treating the employee as an adversary would be both unfair and counterproductive.

The objective is to protect the person and the enterprise from a shared threat surface.

A useful governance principle is: the threat boundary has disappeared, but the privacy boundary must remain.

The future identity control plane

The next generation of identity security will need to answer more than whether an account successfully authenticated.

It will need to determine:

  • Who is actually behind the account?
  • What other identities are connected to that person?
  • Has any connected identity recently been compromised?
  • Are several accounts actually operated by one actor?
  • Does current evidence justify changing access or verification requirements?
  • Can the organization explain and defend its attribution?

These questions turn identity into an intelligence discipline.

The enterprise directory will remain important, but it will no longer provide a sufficient representation of the workforce. Authentication will remain essential, but it will not always establish the real operator. Behavioral monitoring will remain valuable, but it must be interpreted in the context of the person’s broader identity exposure.

Adversaries already construct these holistic views. They correlate personal and professional accounts, search breach data, acquire infostealer logs, map relationships, and identify the shortest path from a human being to an enterprise asset.

Fuzed identity gives defenders the opportunity to operate with equivalent context, subject to stronger evidentiary, privacy, and governance standards.

Identity fragmentation has protected cybercriminals and obscured enterprise risk for too long.

The strategic opportunity is to turn those fragments into attributable intelligence by leveraging the collapse of the corporate-personal security boundary.

Technical CEOs Design Strong Companies That Do Not Break Under Pressure

How Technical CEOs Design Strong Companies That Do Not Break Under Pressure.
Image generated by Jetpack AI, 2026, via WordPress

One advantage of entering the CEO role from a deeply technical background is that you never stop seeing systems. That advantage can lead to design strong companies that do not break under pressure.

A technical leader is trained to see dependencies. You see constraints and failure points. You see the gap between what people think the system does and how the system actually behaves, especially under pressure.

For many years, I applied that mindset to technology, security, architecture, and risk. Over time, I realized that same mindset applies just as powerfully to leadership.

Leadership is an architecture problem.

That may sound callous at first. Leadership feels human, emotional, relational, and cultural. It involves empathy, trust, communication, motivation, conflict management, and judgment. But those realities do not make leadership less architectural. They make architecture that much more important.

Every Company Has an Architecture

Organizations, like systems, follow design patterns.

Leaders sometimes design those patterns intentionally. More often, companies inherit them through habit, personality, urgency, legacy decisions, and unspoken assumptions. These things make up an organization’s culture.

Every company has an architecture, whether leaders acknowledge it or not. This is made up of:

  • Communication architecture – how information moves, where people distort it, who hears what, and how quickly truth reaches decision-makers.
  • Decision architecture – who owns which decisions, what requires escalation, how leaders make tradeoffs, and how the organization avoids paralysis and favors action.
  • Accountability architecture – what leaders measure, what they reward, what they tolerate, and what happens when commitments are missed.
  • Trust architecture – how teams work together, where friction exists, what people believe leadership truly values, and whether people can raise difficult truths early.
  • Resilience architecture – how the organization behaves when revenue pressure rises, customers become unhappy, competitors move, key people leave, or plans fail.

These architectures determine how a company performs.

Pressure Reveals the Design

A weak technical architecture may look fine in a demo and fail in production. I have seen products look great in demo’s and even under controlled conditions. Those same products fail miserably once real load is thrown at them because they were not designed a certain way.

A weak leadership architecture operates in parallel to that. It can look fine in a board update, an all-hands meeting, or a quarterly plan. Then pressure arrives, and the cracks appear.

Decisions slow down. Priorities multiply. Accountability gets blurry. Leaders start doing things to cover up their failures. Teams optimize locally instead of collectively. People sit idle waiting for direction. Teams soften hard truths as those truths move upward.

Leaders often treat those symptoms as people problems first.

In many cases, they are design problems.

One of the most important responsibilities of a CEO is to design the organization so clarity, accountability, and execution can scale. To augment this an organizations needs to know how to fail fast and learn from the failure. Fear of failure cannot be designed into an organization.

The Questions CEOs Should Ask

Some of the key architectural questions a CEO needs to ask about the business are:

  • Where do decisions stall?
  • Who filters information before it reaches leadership?
  • Who are the human single points of failure within this company?
  • Where do teams depend on personalities instead of process?
  • Where do we reward effort more than outcomes?
  • Where have we misaligned incentives?
  • Where have we created operational single points of failure?
  • Where do we mistake activity for progress?
  • Will we survive losing a major lawsuit?
  • Where can we make immediate cuts that will have the least impact given a revenue downturn?

Architects ask similar questions about systems. In companies, the components are people, teams, processes, incentives, and operating rhythms.

The CEO does not need to control every component. That would create a grave bottleneck. The CEO needs to make sure the design allows the organization to operate without constant heroic intervention.

Heroics Do Not Scale

Many technical leaders struggle with the transition to lead on a broader scale.

In technical roles, especially earlier in a career, expertise can save the day. You can dive into problems, find flaws, write code, redesign controls, fix architecture deficiencies, or guide the team through solving challenging problems.

But companies cannot scale on heroic intervention.

They scale on transparency, clarity, repeatable mechanisms, qualified leaders, communication that reduces noise instead of creating it, operating cadence, and trust.

Good leadership architecture ultimately makes the right behaviors easier and the wrong behaviors harder.

Weak Architecture Shows Up Everywhere

When priorities remain unclear, the architecture is weak.

If every decision escalates to the CEO, the architecture is weak.

When performance expectations surprise teams, the architecture is weak.

Bad news arriving late exposes a weak architecture.

When people stay busy but outcomes stagnate, the architecture is weak.

Accountability that depends on a personality instead of a structure exposes a weak architecture.

The solution is not more bureaucracy. Bureaucracy often appears when leaders confuse process with architecture. Good architecture does not require more meetings, more approvals, more dashboards, or more reporting layers.

Good architecture creates flow.

It helps information move faster. Ownership becomes clear with goo architecture. It also reduces confusion and exposes risks earlier. Good architecture gives people enough context to make good decisions without waiting for permission or fearing backlash.

Good Leadership Architecture Creates Flow

Flow is important to a company. Anything that disrupts it has a negative impact. In a company, flow is evident in some practical ways:

  • Strategy creates flow when everyone knows what matters most.
  • Operating rhythm creates flow when teams make decisions at the right cadence.
  • Metrics create flow when they reveal reality before problems surprise the business.
  • Ownership creates flow when every outcome has a clear, accountable leader.
  • Culture creates flow when people can surface hard truths early.
  • Communication creates flow when it removes fear, confusion, and speculation.
  • Leadership creates flow when direction becomes action, progress, and measurable results.

This is why leaders cannot separate leadership from design.

Culture is not just what leaders say. Culture reflects what the organizational system permits, rewards, ignores, and repeats.

Execution is not just effort. Execution comes from priorities, talent, process, accountability, and timing. Moreover, it is far more about outcomes than effort.

Trust is not just an emotional reaction. Leaders build trust through consistent behavior, transparent decision-making, and the willingness to confront reality no matter how difficult. A great measure of trust is how many of your previous employees would gladly work for you again.

Resilience is not just toughness. Resilience comes from preparation, redundancy, adaptability, and clear authority under pressure. And the only true way to prove resilience is to have successfully survived negative events. Those battle scars say a lot.

The technical world teaches us that systems behave according to design. The business world teaches the same lesson, sometimes more painfully because the stakes are different.

Three Layers Every CEO Must Design

When I think about leadership now, I think about architecture at three levels. Leaders must design the architecture of:

  • Clarity – does everyone understand what matters most, why it matters, and how their work connects to the company’s direction?
  • Accountability – are commitments explicit, measurable, owned, and reviewed with consistency?
  • Trust – can the organization surface truth quickly, challenge assumptions productively, and stay aligned under pressure?

When those three layers are strong, companies move differently. They make faster decisions and recover better from setbacks. Less energy gets wasted on internal turmoil. They also create more space for innovation because people do not constantly need to guess what matters or operate in fear.

The Technical Leader’s Advantage

Technical leaders have a real advantage, if they broaden their lens.

The same systems thinking that helps us understand platforms, networks, applications, and security models can help us understand organizations. The same discipline that helps us design resilient infrastructure can help us design resilient companies.

But technical leaders must recognize one important warning:

People are not servers. Culture is not code. Leadership is not a control plane.

Human systems are more complex because they include emotion, ambition, fear, deceit, trust, pride, fatigue, and belief systems. That does not make architecture irrelevant. It makes it more necessary, albeit more delicate.

The CEO’s Architectural Responsibility

The goal is not to mechanize or roboticize leadership.

The goal is to design an environment where people can do their best work with clarity, ownership, and trust.

That is the CEO’s architectural responsibility.

It’s not to have every answer.

Nor is it to sit at the center of every decision.

Moreover, it is not to personally carry every problem or make every decision.

The CEO aims to design strong companies so they can perform, adapt, and endure. Because in the end, leadership is not just about vision. It is about whether the organization you build can turn that vision into reality under pressure.

How to Lead With Confidence When Certainty Disappears

How to Lead With Confidence When Certainty Disappears
Image generated by Jetpack AI, 2026, via WordPress

For much of my career, I lived in worlds where precision mattered. The hardest shift from a technology or security leader to CEO is trading certainty for judgment. In this executive leadership world a key ability is being able to lead with confidence when certainty disappears.

From Precision to Ambiguity

As a technologist, architect, CTO, and CISO, I was trained to look for edge cases, root causes, system behavior, technical truths, and to have defensible answers. When something failed, the goal was to understand why as soon as the disaster was dealt with. When risk surfaced, the goal was to measure it, contain it, and communicate it. When a system needed to scale, the goal was to design something resilient enough to survive negative impact.

That background is incredibly valuable as it sharpens how you think. It also teaches you to respect complexity while separating signal from noise. That operating system also gives you a deep appreciation for how fragile things can become when assumptions go untested.

The Real Shift: Certainty to Judgment

Becoming a CEO requires a different operating system.

The hardest shift is not going from technology to business. It is going from certainty to judgment.

In technical leadership, you often have the luxury of eventually getting to a correct answer. The system works or it does not. There is a reality to a functional state. A control is effective or it isn’t. An architecture scales or it breaks. Vulnerabilities are exploitable or they aren’t. Even when there is debate, there is usually a path toward some solution.

As CEO, the path is rarely that clean.

Leading When the Answer Is Not Obvious

Unfortunately, CEOs have to make decisions with incomplete information. That is simply part of the job’s reality. You balance financial realities, customer needs, market timing, employee morale, board expectations, competitive pressure, and operational constraints. There is a mental state where you are constantly choosing between options that all carry risk. Sometimes the decision is not between right and wrong. It is between imperfect and necessary.

That is a very different kind of pressure.

Risk Is Only One Part of the Equation

A CISO is often rewarded for identifying what could go wrong. A CEO is responsible for deciding what must go forward irrespective of risk.

That does not mean ignoring risk. It means understanding that risk is only one part of the enterprise equation. Growth has risk. Inaction has risk. Delay has risk. Over-analysis has risk. Moving too slowly can be just as damaging as moving too fast.

This was one of the most important mindset changes for me.

As a security leader, I spent years helping organizations avoid bad outcomes. I analyzed as many angles as I could and prepared in the most realistic way possible. As a CEO, I still care deeply about avoiding bad outcomes, but I also have to create the conditions for positive outcomes. After all, I have a company to run and grow. That means building momentum, making tradeoffs, allocating capital, setting priorities, developing leaders, and helping the company move with conviction even when the data is not perfect. Sometimes it means deciding between a gamble that could improve ARR or mitigating risk.

Technical Depth Can Become a Constraint

As expected, technical leaders often bring a powerful bias toward depth. We want to understand details and inspect machinery. Often, knowing why something is happening is essential before action takes place.

That instinct is useful. But it can also become a constraint.

As an example, imagine a scenario where sales leadership does not know intimate details about a potential customer. You ask questions such as who the economic buyer really is, what the internal deadlines are, or what their budget is. These are details that dictate how real a deal is and whether you put that data in front of the board. But realistically, those details are likely not made known to a sales person by the potential customer. My bias for depth just became both a constraint and source of frustration.

The CEO’s Job Is to Build Decision Capacity

Realistically, a CEO cannot personally inspect every system, approve every decision, or resolve every ambiguity. The job is not to become the ultimate escalation point for every hard problem. Staying focused, as a CEO you want to build an organization that can make better decisions without waiting for you.

That requires trust.

Trust in people, in operating rhythms, in the quality of the strategy, in the mechanisms that surface truth early. It also requires a leadership tier that understands the business, mission, constraints, and relevant standards.

As a CEO you must accept that no amount of technical brilliance eliminates uncertainty.

Judgment Is the CEO’s Most Important Tool

Given the reality of uncertainty, judgment becomes the CEO’s most important tool.

Judgment is not instinct alone. Nor is it guessing. Judgment is the ability to combine facts, experience, pattern recognition, timing, and foreseen consequences into a decision that moves the organization forward.

Good judgment asks:

  • What do we know?
  • What do we not know?
  • What assumptions are we making?
  • What happens if we are wrong?
  • What must be true for this decision to work?
  • What is the cost of a given decision?
  • What is the cost of not deciding now and waiting?
  • Who needs clarity now?

A Practical Framework for Leading When Certainty Disappears

Confidence under uncertainty does not come from pretending to have all the answers. It comes from using a disciplined process to turn incomplete information into responsible action. When the path forward is unclear, I use the following eight steps:

Accept That Certainty May Not Arrive

Recognize that consequential leadership decisions often must be made before every fact becomes available. Waiting for complete certainty can become its own decision, carrying costs and risks that may exceed those of taking action.

Separate What You Know From What You Do Not Know

Identify the reliable facts, the missing information, and the areas where uncertainty remains. This type of compartmentalization prevents assumptions, opinions, and incomplete signals from being treated as established truth.

Expose Your Assumptions

Make the assumptions behind the decision explicit and determine which ones carry the greatest risk. An assumption left unspoken can quietly become a serious risk and even a single point of failure.

Evaluate the Consequences

Consider what happens if the decision is wrong and how the effects could spread across the organization. Look beyond the immediate outcome to the potential larger impact on customers, employees, cash, execution, and credibility.

Compare Action With Inaction

Assess the cost of acting, the cost of waiting, and the risks created by delay or excessive analysis. Inaction can be very expensive. Leaders often examine the downside of moving forward without giving equal attention to the downside of standing still.

Define what must be

Determine the conditions required for the decision to succeed. Then assess whether those conditions already exist, can be created, or depend on factors outside the organization’s control.

Make and communicate the decision

Establish a clear direction, explain what matters most, and give the people who must act the clarity they need. Communicate what you know, what you believe, what you have decided, and what the organization must do next.

Adapt as reality provides new information

Lead as transparently as possible, with honest conviction rather than false certainty. Monitor the results, test the assumptions behind the decision, and adjust the course as new facts emerge.

This process does not eliminate uncertainty. It creates the decision capacity required to move through it responsibly. The objective is not to predict every outcome. It is to make the strongest available decision, communicate it clearly, and remain ready to adapt.

The Company Is Now the System

Some of those questions are familiar to technical leaders. They sound a lot like risk analysis, incident response, architecture review, and threat modeling. The difference is that, as CEO, they now apply to areas (e.g., Sales, Marketing, HR) technical leaders seldom manage. In fact, they now apply to the whole company.

Strategy becomes an architecture problem. Culture becomes a scaling problem. Communication becomes a signal integrity problem. Talent becomes a resilience problem. Cash becomes an operating constraint. Execution becomes the ultimate proof point.

The CEO role forces you to widen the aperture.

You can no longer look only at whether something is functional or technically sound. You have to ask whether it is commercially viable, operationally executable, strategically aligned, and fiscally responsible. You have to think about how decisions cascade across customers, employees, investors, partners, and the broader market.

Credibility Changes at the CEO Level

That broader blast radius for each decision made is where the CEO transition can feel uncomfortable for deeply technical leaders.

We are used to being credible because of what we know. As CEO, credibility increasingly comes from how we decide, how we communicate, and how we create clarity for others, even when conditions are hazy.

The organization does not need the CEO to have every answer.

It needs the CEO to establish clear direction.

It needs the CEO to make the hard calls.

It needs the CEO to define what matters most.

It needs the CEO to be calm when the data is incomplete and when the pressure is on.

It needs the CEO to turn ambiguity into action.

Conviction Without False Certainty

To be clear, none of this means pretending to be certain. In fact, false certainty is dangerous. People can feel when a leader is manufacturing confidence. The better posture is honest conviction: here is what we know, here is what we believe, here is what we are going to do, and here is how we will adapt as reality teaches us more.

That is a different kind of leadership maturity.

The transition from CISO or CTO to CEO is not a rejection of technical depth. It is an expansion of it. The same disciplines still matter: systems thinking, adversarial understanding, resilience, risk management, architecture, and operational rigor.

The difference is that they must be applied at a broader level.

The company is now the system.

The market is now the threat model.

The competition is now an adversary.

The strategy is now the architecture.

The people are now the execution layer.

And the CEO is responsible for whether all of it works together under pressure.

Your Expertise Got You Here. Judgment Determines What Happens Next.

For technical leaders aspiring to broader executive roles, this is the real lesson: your expertise got you to the table, but judgment determines your impact once you are there.

Depth still matters. Precision still matters. Technical fluency still matters.

But the role changes.

You are no longer only protecting the business.

You are leading it.

You are growing it.

And leadership, at the CEO level, is the discipline of making consequential decisions before certainty arrives.

“The Artificial Adversary” – a New Operating Model for Cybercrime

The Artificial Adversary - a New Operating Model for Cybercrime

“Artificial adversaries don’t have egos, suffer burnout, or deal with corporate drama. Your defenses do.” – Andres Andreu

In the spring of 2026, a handful of engineers with little security background ran an experiment. They pointed an Artificial Intelligence (AI) model at thousands of software codebases and asked it to identify issues. Over the course of one night it did more than find decades-old flaws hiding in plain sight. It created working exploits for them. The model was Claude Mythos Preview. In fact, its creator judged it so capable at weaponizing vulnerabilities that it chose not to release the model at that time.

For most of our field’s history, the adversary was human. Clever and motivated but bounded by sleep, attention, money, and skill. Now, however, that adversary is being augmented, and sometimes replaced. The replacement does not tire or hesitate. Moreover, it ignores the operational rhythms our defenses quietly assume. I call it “The Artificial Adversary.” Essentially, it takes one of two forms:

  • A human operator empowered by an AI stack.
  • An autonomous AI system acting toward malicious ends.

At this stage these have stopped being thought experiments and are now turning up in incident reports.

An Inflection Point, Not a Trend Line

Three things are happening at once. Together, they mark an inflection point rather than an incremental shift:

  • AI has lowered the barrier for entry to sophisticated crime.
  • Synthetic media is collapsing our ability to trust digital signals. A familiar face or a known voice, after all, no longer proves what it once did.
  • The volume and speed of AI-enabled activity now outpaces the manual, static defenses built for a slower era.

The numbers are no longer speculative

SoSafe’s 2025 research found that roughly 87% of organizations worldwide faced an AI-powered cyberattack in the prior year. Direct attacks aside, model evaluations are just as concerning. For instance, the UK’s AI Security Institute (AISI) tested Claude Mythos Preview. It solved expert-level CTF challenges about 73% of the time. Notably, no model could complete those challenges at all before April 2025. Mythos went further still. In fact, it became the first model to solve the AISI’s 32-step simulated network takeover, from reconnaissance to full compromise. Anthropic’s red team reported even broader findings. Working alongside the AISI, it watched the model surface thousands of zero-day flaws. These included a dormant 27-year-old vulnerability in OpenBSD and a 16-year-old bug in FFmpeg. In Firefox alone, Mythos found 271 vulnerabilities and wrote exploits for 181 of them.

A signal, not the threat itself

Anthropic withheld Mythos from public release. Instead, it granted limited access to a small set of organizations that build and maintain critical software and infrastructure. The program is called Project Glasswing. Launch partners reportedly include Amazon Web Services, Apple, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. Officially, the intent was to give defenders a head start. Yet Mythos isn’t the only game in town. For example, things such as OpenAI’s GPT-5.4-Cyber, OWASP CVE Lite CLI, and Google’s Big Sleep already show great promise and in some cases comparable capability. When competition rises the cost of entry keeps falling. Regulators noticed quickly. Within weeks, the Bank of England intensified its AI risk testing, and German banks consulted regulators and cyber experts. The lesson, therefore, is the one Bain and others drew immediately. In short, assume your adversaries are building equivalent capabilities, nation-states, criminal enterprises, and rogue actors alike. Mythos is a signal, not the threat itself.

Defining the Artificial Adversary

It helps to name the archetype precisely, because precision changes how we defend. So picture an AI-enhanced human actor. Here, the human sets the strategic objectives. The machine, in turn, executes the great majority of the tactical workload. The consequence is direct. As a result, offensive cycles compress, and defenders can no longer assume a human-speed response on the other side of the keyboard.

Human adversaries operate within cognitive, temporal, and logistical limits. An autonomous AI-based adversary does not. Needing no sleep, it carries no emotional baggage and runs continuously across global digital environments. Moreover, it can analyze vast data stores and reason probabilistically in real time. Such a system can also coordinate through decentralized, agentic architectures that resist any single point of shutdown. Its capacity for deception, mimicry, and adaptation, therefore, creates a new category of risk. Consequently, detection, attribution, and deterrence all become far harder. The asymmetry, however, is not only technological. It is also cognitive. In the end, defenders must prepare for opponents that do not tire, hesitate, or follow any rules.

The Artificial Adversary Taxonomy

A practical taxonomy has five levels.

  • AI-assisted human operator – a human attacker uses AI for discrete tasks such as phishing, translation, research, script generation, or stolen-data summarization.
  • AI-augmented threat crew – a criminal or nation-state team embeds AI into reconnaissance, exploit research, identity profiling, malware development, infrastructure staging, data exfiltration, and victim communications.
  • AI-orchestrated campaign – agentic systems coordinate personas, assign tasks, monitor responses, tune timing, and manage parallel workflows while humans supervise outcomes.
  • Semi-autonomous adversarial agent – the system conducts meaningful parts of the intrusion chain itself, including asset discovery, service testing, response analysis, and attack path modification.
  • Autonomous malicious AI system – an AI system pursues malicious objectives with limited or delayed human direction, raising harder questions around attribution, containment, predictability, and control.

This taxonomy matters because an AI-assisted phishing actor requires different defenses than an autonomous agent probing applications, manipulating identities, and adapting to telemetry in real time.

Facilitation – Lowering the Barrier

The first way AI empowers adversaries is the least glamorous and the most pervasive. Simply put, it removes friction. For a few years now, the underground has marketed “Dark LLMs.” The roster includes WormGPT, FraudGPT, KawaiiGPT, and imitators such as MalwareGPT, SpamGPT, and Xanthorox. Each promises jailbreaks, malware help, and ready-made scam playbooks. Some are functional. Many, however, are simply scams that prey on aspiring criminals. Either way, the real significance is not any single tool. Rather, it is the normalization of the idea. A capable, on-demand junior developer is now available to anyone with a few GPUs, a wallet of API keys, and some patience.

Malware that writes itself

Proof-of-concept work made the threat concrete. Researchers, for instance, demonstrated BlackMamba, a keylogger that built its malicious code at runtime by calling a Large Language Model (LLM). That approach neatly sidesteps the static signatures defenders rely on. By late 2025, the threat had moved from the lab to the wild. Google’s threat intelligence team documented two malware families: PROMPTFLUX and PROMPTSTEAL. Both query LLMs during execution. One rewrites itself, while the other generates fresh commands mid-attack. This is “Just-In-Time” (JIT) malicious code. In other words, the software does not carry its full payload. Instead, it assembles the payload on demand, from a model that does not know it is being conscripted.

When the face on the call is fake

Facilitation also reaches the human layer through synthetic media. Convincing face and voice clones, for example, can now be mass-produced. So can cross-lingual conversion and studio-quality content. Better yet for the attacker, agent teams run these operations around the clock, iterating on failures without fatigue. As a result, the multi-party deepfake video call is no longer hypothetical. Picture a finance employee walked through an “urgent” wire transfer by a “CFO” and “general counsel” who are both synthetic. Clearly, the attack surface is no longer just endpoints and identities. It now also includes the emotional tone around those identities. And does so across collaboration tools, social media, and internal communications.

Vibe Hacking – Psychological Warfare at Machine Speed

This last point deserves its own name. After all, it is where AI-enabled social engineering becomes something new. Vibe hacking is social engineering supercharged with a full AI stack. Here, the adversary does not send a single phishing email or place one deepfake call. Instead, models shape the emotional context around a target over time. The goal, therefore, is not to trick a victim once. Rather, it is to tune the “vibe” of their human state along with their digital environment, so that risky actions feel natural, familiar, and self-initiated.

Sensing, profiling, persistence

A campaign begins with sensing and profiling. To start, adversaries point AI at everything they can scrape. These sources include OSINT, LinkedIn activity, public Slack and Discord communities, conference talks, support tickets, and marketing emails. Sentiment analysis is important here and models infer mood, personality, stress levels, decision style, and trust anchors. That attackable profile, in turn, feeds a working model of the target’s context. Things like a looming quarter, a key project, the likely sources of anxiety or excitement all become real and exploitable. Generative models subsequently produce content tuned to the target’s state. The real weaponization, however, comes from scale and persistence. One artificial adversary can run dozens of long conversations at once. Each hides behind a distinct persona, the sympathetic colleague, the urgent executive, the overworked vendor. Meanwhile, it A/B tests tone, timing, and channel to learn what lowers resistance and/or skepticism. By the time the critical ask arrives, therefore, the victim feels they are accommodating a relationship, not responding to an attack.

This is the reframing that matters:

Vibe hacking isn’t better phishing. It’s your own people, profiled and played at machine scale – we hardened the edges and left the nervous system exposed.

Andres Andreu

From theory to a real victim list

None of this is a forecast. In August 2025, in fact, Anthropic’s Threat Intelligence team disclosed a case it tracked as GTG-2002. A single actor used an agentic coding tool to run a data-extortion operation. In total, the targets numbered at least 17 organizations, spanning healthcare, emergency services, government, and religious institutions. A defense contractor was among the victims, too. Remarkably, the whole campaign ran in roughly a month. To pull it off, the attacker embedded an operational playbook in a configuration file, so the AI could make tactical decisions during live intrusions. From there, the model automated reconnaissance and credential harvesting. It even generated ransom notes tailored to each victim, with demands reported between roughly $75,000 and more than $500,000. Ultimately, one person, with an AI operator alongside, did the work of a coordinated crew.

Scale – From Assistant to Operator

Facilitation lowers the barrier to entry; scale changes the magnitude. For example, the same agentic models that help an enterprise automate work can be organized into adversarial swarms. A planner agent sets the goals. Meanwhile, sub-agents run in parallel performing actions such as OSINT scraping, phishing and deepfake generation, code generation, and dropper construction. Because they share memory and data from feedback loops, the whole system improves with each iteration.

The criminal supply chain, in turn, has matured around this model. Telegram, for instance, serves as a resilient “dark social layer”, encrypted, anti-censorship, easy to churn and burn, and slow to take down. There, automated bots stream stolen credit card data and run validation checks at a pace no human team could sustain. Increasingly, the same architecture is aimed at availability, too. Agentic orchestrators break a Layer-7 denial-of-service goal into reconnaissance, traffic generation, and adaptive evasion, while coordinated worker nodes handle individual parts of the overall campaign.

The first autonomous espionage campaign

A defining incident arrived in November 2025. Anthropic reported disrupting a campaign it attributed, with high confidence, to a Chinese state-sponsored group tracked as GTG-1002. Notably, it was the first publicly documented, largely autonomous AI-orchestrated cyber-espionage campaign. It was detected in mid-September. In all, the operation targeted roughly thirty high-value organizations across technology, finance, chemical manufacturing, and government.

To pursue their objectives, the attackers manipulated an agentic coding tool into acting as a fleet of autonomous penetration-testing orchestrators and agents. First, they jailbroke its safeguards by role-playing a defensive security firm. Then they broke malicious objectives into benign-looking subtasks. From that point, the AI handled reconnaissance, vulnerability discovery, exploitation, credential harvesting, lateral movement, and exfiltration. In total, that came to an estimated 80 to 90% of tactical operations, issued at thousands of requests per second. Human operators, by contrast, stepped in only at a few strategic chokepoints. This wasn’t as clean as a Hollywood movie scene as the model’s hallucinations sometimes invented credentials or overstated findings. Those errors were among the few things keeping the operation from full autonomy.

A Real Incident, End to End – The NPD Sextortion Wave

To see these capabilities combine into one industrialized pipeline, consider the extortion spam that followed the National Public Data (NPD) breach. The underlying breach was staggering. Systems were first compromised in December 2023. By April 2024, the data had surfaced on the dark web. The company, however, acknowledged the incident only in August 2024. All told, it affected up to 170 million people and exposed as many as three billion records. The follow-on campaign was instructive less for its novelty than for its assembly. Specifically, attackers used GPT-based code generation to operationalize the stolen data end to end. The result was personalized extortion content. Each message addressed the victim by name, referenced a real home address, and embedded street-view imagery of the respective house. Then it demanded payment in Bitcoin, usually between $1,900 and $2,000, for the sake of tranquility or peace of mind.

None of the individual techniques were sophisticated. The sophistication, instead, lay in the orchestration. Consider the parts, a breach corpus, a code-generating model, a templating layer that fused public records with mapping imagery, and a delivery pipeline. Stitched together, these produced a campaign with a scale and personalization no manual operation could match. That, in essence, is the pattern security leaders should internalize. The artificial adversary rarely wins with one brilliant exploit. Instead, it wins by removing friction from every step, and running the whole chain faster than defenders can detect and respond.

Turning the Tables – Disrupting Malicious Automation

The very properties that make AI dangerous on offense also make it invaluable on defense. Better still, they open a counter-strategy that purely human teams never had. If attackers automate, then defenders can engineer the environment to exploit that automation. In practice, deception engineering and adversarial intelligence combine well.

The single goal is to convert the attacker’s automation into your early-warning system. Synthetic credentials, decoy services, and AI-generated traffic, for instance, all look irresistible to an autonomous agent. As such, they become tripwires. Because the agent probes tirelessly and indiscriminately, it hits the decoys long before a careful human would. Consequently, it can surface a campaign while it is still in an early stage.

Red teaming with autonomous agents

AI-augmented red teaming has a strong place here. In a 2024 experiment reported by WIRED, for example, a journalist let autonomous AI agents from the startup RunSybil attack a custom web app. The agents collaborated in real time. Specifically, they used SQL injection, brute-force authentication, form-field manipulation, and path traversal. Most importantly, they iterated on their failures. Without human direction, they re-planned and adjusted strategies, surfacing logic flaws that traditional scanners had missed. The agents were not malicious; their behavior, however, was. It was adversarial, coordinated, and effective. The takeaway, then, is fairly straightforward. First, adopt autonomous red-teaming agents to pressure-test your defenses against continuous, iterative, logic-driven attacks. Then pair them with high-fidelity telemetry and behavioral anomaly detection. Together, they can flag AI-like probing even when individual requests looks benign.

Governing the Machine and the People Around It

Speed without governance introduces its own risk. As defenders deploy autonomous and semi-autonomous capabilities, they take on an obligation. Those capabilities must be fast where they must be, careful where they should be, and always controllable by competent humans. Fortunately, a workable program can borrow from frameworks now maturing across the industry. For a foundation, anchor on NIST’s AI Risk Management Framework or ISO/IEC 42001. To turn principles into adversarial test cases, layer in MITRE ATLAS and the OWASP Top 10 for LLM applications. To harden the model lifecycle, draw on ISO/IEC 23894 and Google’s Secure AI Framework. Finally, add a staged maturity model to move from reactive to adaptive.

High-impact automated actions, meanwhile, need extra care. By default, mass credential revocation, large-scale connection throttling or tarpitting, and account lockouts should sit behind human-in-the-loop gates. In addition, back them with immutable audit logs, explainability proportional to impact, and fast paths to appeal and rollback.

Two cautions

Two cautions deserve emphasis.

First, treat AI models and their supply chains as critical software assets. In practice, that means validating provenance, verifying integrity, and monitoring runtime behavior. After all, data and model poisoning are now first-class threat vectors.

Second, resist the urge to fight fire with fire across legal lines. Attacker AIs, remember, routinely route through innocent third parties. As a result, heavy-handed countermeasures invite escalation and cross-border legal exposure, among them hack-back, automated counter-intrusion, and poisoning someone else’s ecosystem. Privacy by design, data minimization, auditability, and human oversight should not be compliance theater. On the contrary, they should be focused on what keeps a fast defense lawful and trusted.

What Security Leaders Must Do Now

The artificial adversary does not need to be sentient to change the game. Instead, it only needs to make capable attackers faster, more iterative, and less dependent on rare human skill. Accordingly, defenders should architect for that reality:

  • Treat AI as both adversary and ally – regularly run hybrid threat scenarios, machine-augmented attackers against machine-augmented defenders, so that you find your blind spots first.
  • Shift from signatures to behavior – static, content-based controls cannot anticipate self-modifying code or agentic chaining. Instead, invest in behavioral analytics, high-fidelity logging, and context-aware security that reads relationships, not keywords.
  • Stand up real AI governance – name a single accountable owner and convene a cross-functional oversight board. Then keep a model and agent registry, and define rules of engagement and rollback paths before you enable automation.
  • Secure the model supply chain – audit data lineage and model integrity, and assume third-party datasets, weights, and components can be poisoned upstream.
  • Deploy deception as early warning – use AI honeypots and synthetic assets to turn the adversary’s tireless automation into your early detection advantage.
  • Compress your defensive cycle – above all, adopt AI-augmented red teaming and threat hunting so that you out-learn the adversary. Then measure what matters – detection accuracy, false-positive and false-negative rates, model drift, autonomy and override rates, and time to contain.

The Pivotal Question

The pivotal question about any adversary has changed. No longer is it simply who they are or what they want. Instead, it is “what can they assemble and operationalize with AI faster than we can detect and respond?” Once, the human attacker was the central concern. Now, by contrast, security leaders face intelligent, scalable opponents that run as close to machine speed as the hardware allows. Confronting them takes more than static controls and periodic red teaming. Rather, it takes continuous learning, dynamic simulation, and AI-augmented defense. Above all, it takes one hard admission, the next major breach may not be human at all.

Awareness is the beginning; action defines resilience. The Artificial Adversary is here. The only question is whether we will be ready when it decides to strike.

From 4X CISO to CEO: What Leadership Looks Like Now

Andres Andreu reflecting on leadership lessons from moving from CISO to CEO

For years, I led from the seat of a Chief Information Security Officer (CISO). From 4X CISO to CEO.

As a CISO I learned “healthy paranoia”. I learned to see around corners. I learned to prepare for failure without becoming ruled by it. I learned that resilience is not a slogan, trust is not soft, and pressure reveals what an organization really is.

Then I became a CEO.

The title changed, but that was not the real transition. The real transition was this: the scoreboard changed.

Success means something very different now.

As a CISO, much of the job revolves around reducing downside. You protect value. You harden systems. You reduce exposure. You prepare for impact. Success often shows up as the absence of disaster.

As a CEO, that is no where near enough.

A CEO still has to manage downside. But the real job is broader and frankly, harder. You have to create upside even the upside is not obvious. You have to allocate capital, focus people, accelerate execution, build trust, and make the company stronger under pressure. You are no longer measured only by what you prevent. You are measured by what you build, what you compound, and whether the organization can win.

That shift has changed how I think about leadership.

It has not made me less disciplined. It has made me more complete.

Here are the lessons that came into focus for me in the move from CISO to CEO.

Protecting value and creating value are not the same job

Security leaders are trained to think in terms of exposure, controls, failure paths, and resilience. That training is valuable. In fact, in a volatile world, it is a serious leadership advantage. But …

The CEO role forces a wider lens.

You cannot lead a company by focusing only on what might break. You have to decide what deserves energy, capital, and conviction. You have to place bets. You have to define where the company will lead, where it will differentiate, and where it will refuse distraction. You also have to make the hard choices between protecting something or paving a path to new revenue.

That is a major shift.

A CISO protects value.

A CEO creates, compounds, and defends value.

The distinction matters because it changes the posture of leadership. It moves you from preservation alone to purposeful construction.

Risk is only part of the story

For a long time, one of the most important questions in my world was: What could go wrong?

That question still matters. It always will.

But CEOs have to ask a broader set of questions:

What are we building?
What are we solving?
What are we choosing not to do?
Where are we underinvesting?
What will matter six quarters from now, not just six weeks from now?

This is where many leaders get trapped. They confuse awareness of risk with clarity of direction.

These are not the same.

A company can become highly fluent in threat, friction, and constraints and still fail to move. It can become excellent at discussing complexity and poor at converting that complexity into action.

The CEO’s job is not to eliminate uncertainty. The CEO’s job is to move the organization through uncertainty with judgment.

That is a different discipline.

Capital allocation spells truth

One of the clearest lessons of becoming CEO is that strategy sounds impressive in slides but reveals itself in budgets.

Capital allocation exposes the truth.

You can say innovation matters. But if you do not invest in data quality, operating discipline, and workflow redesign, then innovation does not really matter.

You can say trust matters. But if you underfund execution, transparency, and customer experience, then trust does not really matter either.

You can say growth matters. But if priorities are bloated, ownership is vague, and friction is tolerated, then growth is a cheap talking point.

This is one of the hardest truths in leadership: strategy is not what you announce. Strategy is what you consistently fund, reinforce, and protect.

The CEO sees that more directly than anyone else.

Money is not just a resource. It is a declaration of belief.

Clarity scales better than intensity

Earlier in my career, I thought strong leadership often meant pushing harder, doing more, leading in very visible form.

I no longer believe that.

Strong leadership now means clarifying faster.

Companies do not scale on intensity alone. They scale on clarity. They scale when people know what matters, who you are selling to, who owns what, how decisions get made, what good looks like, and what deserves to be ignored.

Intensity without clarity creates motion, not momentum.

This becomes even more important at the CEO level because ambiguity compounds as it moves through the organization. A vague executive statement becomes a confused team priority. A confused priority becomes wasted time. Wasted time becomes operating drag. Operating drag becomes missed expectations.

That is why clarity is not just a communication skill. It is an operating advantage.

The larger the company, the more expensive vague leadership becomes. But, it also takes longer to unearth that type of situation. In smaller companies vague leadership exposes itself way quicker as there are fewer buffers.

Trust is not soft. Trust is throughput.

Too many leaders still talk about trust as if it belongs in the category of culture alone.

It does not.

Trust affects speed. Trust affects execution. Trust affects retention. Trust affects customer confidence. Trust affects whether people escalate intelligently or defensively. Trust affects whether hard truths surface early or get buried until they become an expensive burden.

In low-trust environments, everything takes longer. People protect themselves. Decisions loop slowly. Teams revisit the same conversations. Energy leaks everywhere. Indecision reigns.

In high-trust environments, accountability gets stronger, not weaker. Standards become easier to uphold because intent is clearer and friction is lower.

This is one of the biggest mindset expansions I have had as a CEO.

Trust is not theater.

Trust is infrastructure.

And in many organizations, it is the hidden variable behind execution quality.

Resilience matters more than compliance

Compliance matters. It builds baseline discipline. It creates structure. It can improve consistency.

But compliance is not the same as resilience.

A compliant company can still be fragile.

A resilient company absorbs pressure without losing direction. It adapts when conditions change. It makes decisions based on imperfect and/or incomplete information. It keeps operating even when the environment turns hostile.

That distinction matters now more than ever.

The modern business environment does not reward organizations simply for looking prepared. It rewards organizations that can keep moving when things break.

This is where my years in security still shape me deeply. I know what fragility looks like. I know how fast confidence erodes when stress exposes weak assumptions. I know the difference between a control that looks good and a capability that holds.

As CEO, that lesson only became more important.

Build for the test, not just the audit.

The CEO’s steadiness becomes part of the operating model

This may be the most personal lesson of all.

The CEO carries more than accountability. The CEO carries signal.

The ecosystem around you (employees, the board, investors, peer CEOs, partners, customers) watch how you process. How you process pressure. How you process the sea of bad news with the sprinkle of good here and there. They watch how you handle incomplete information, mixed results, difficult tradeoffs, and external noise. They watch your tone when momentum slows. They watch your posture when the answer is not obvious.

This does not mean a CEO needs to project false certainty.

It does mean the CEO has to project steadiness.

And do so irrespective of what is at hand. That steadiness matters because organizations borrow emotional direction from leadership. When the environment is noisy and/or unsteady, the CEO helps determine whether the company becomes reactive, distracted, disciplined, or resolved.

That is not abstract leadership philosophy. It’s not a textbook principle taught in business school. That is operational reality.

Steadiness preserves focus. Focus preserves execution. Execution preserves trust.

In the end, leadership is not about being right. It is about steering the organization towards an outcome, making sure employees stay oriented while the organization works through challenges and hurdles.

Security-Centric Steadiness

Security teams alone cannot secure a company from threats. The company’s organizational culture, risk tolerance, and investments are defined collectively by leadership, in many organization this means a roll up to the CEO. It is ultimately the CEOs responsibility to:

  1. Set the tone (organizational culture): if the CEO treats security as a priority, it permeates the entire organization. If neglected, it breeds a relaxed, vulnerable afterthought culture.
  2. Define risk tolerance: the CEO must decide what level of risk is acceptable and where to invest in defense, rather than assuming the CISO can stop 100% of attacks alone. This is a challenge as a lot of CEOs, for the sake of self-preservation, shy away from explicitly taking a stance on risk. Even if a CEO isn’t signing an acceptance/rejection of risk they can define tolerance levels.
  3. Create cross functional alignment: silos break down due to force from the top, IT, Legal, HR, and Operations work together to protect the company when that is a mandate coming from the CEO.

What I carried with me from the CISO seat

I did not leave my CISO instincts behind when I became CEO.

I feel I brought the best of them with me.

I still believe in disciplined thinking.
I still believe in resilience under pressure.
I still believe in asking hard questions early.
I still believe that trust takes years to build and minutes to lose.
I still believe leaders should prepare for failure without becoming defined by fear.

But the CEO role forced me to widen the aperture.

The mission is no longer only to defend the enterprise.

The mission is to build an enterprise that can win.

That means creating trust, not just protecting it. It means creating momentum, not just preventing disruption. It means turning discipline into direction, and direction into execution.

That is the real shift.

Final thought

Going from a 4X CISO to CEO did not make me think less about security. It made me think more completely about leadership. I still believe the best leaders see the angles and see around corners. Now, I also believe they have to be able to build through those angles and corners.

Industrialized Identity – The New Factory Model for Fraud

Industrialized Identity - The New Factory Model for Fraud

Industrialized Identity – adversaries now run identity like a factory. Most organizations still talk about identity breaches like they talk about storms: unfortunate, occasional, and mostly out of their control. But attackers don’t forecast storms, they manufacture them.

The adversary does not see it that way. Instead, they treat identity as raw material. They harvest it, refine it, enrich it, and operationalize it, over and over, until they can monetize it by running fraud, impersonation, and Account Takeover (ATO) campaigns like a production line.

This dynamic doesn’t just change adversarial TTPs per say. And this cascades as it changes the adversary’s economics. It also changes defender timelines. And it changes what “good” looks like for a CISO who needs to protect revenue, customers, and business operations.

In the 2026 Identity Breach Report from Constella Intelligence we see the signal clearly – identity exposure now moves at machine speed and scale, with industrial processes behind it, not opportunistic one-offs.

Identity risk didn’t just get “worse.” It got productized.

And once it’s productized, attackers don’t need to break in to create impact. They can often log in, have data changed/reset, or impersonate. Traction becomes real when they assemble “attackable profiles”. In practice, that means they can:

  • pass help desk or account recovery checks
  • bypass “knowledge-based” verification
  • look legitimate across channels
  • scale automation without spiking obvious alarms

For these attackable profiles to become real, adversaries have built an identity supply chain:

Ingest → Clean → Correlate → Enrich → Package → Operationalize

Quarterly controls and reactive incident response will not stand up to this type of pattern. Worse off this can become industrialized at scale. Defense models need to runs at that same tempo.

The Identity Density Gap – the story behind +135% record growth vs. +11% unique identifiers

Let’s quantify the shift. Here’s a 2025 statistic that should force a mindset change: breach record volume grew by 135% while unique identifiers only grew 11%.

That says something simple and brutal: adversaries don’t need more identity data. So the problem isn’t more identities. It’s more context per identity (more data per person). This is the Identity Density Gap.

Put differently, density is leverage:

  • A thin identity (email + password) supports commodity credential stuffing.
  • A dense identity (email + phone + address + DOB + linked accounts + recovery hints + active session objects) supports high-confidence impersonation and repeatable fraud.

Density gives attackers options. Options create resilience. Resilience creates pathways that can also be leveraged at scale.

The outdated way that so many security teams pursued was to fixed authentication. Yet they constantly lost to ATO and fraud. The adversary no longer cares about the login prompt, they are seeing the surface across the entire identity lifecycle:

  • onboarding and enrollment
  • authentication
  • session handling and token reuse
  • account recovery and help desk flows
  • high-risk transactions and workflow approvals

Defending only one link in that chain is a mere inconvenience now, attackers route around fragmented strategies. And they do it fast.

Industrialized data correlation – how attackers turn billions of attributes into attackable profiles

Attackers don’t win because they possess data. Attackers win because they correlate data. When an operation runs at the scale of 400 billion+ attributes, correlation stops being a research activity and becomes a manufacturing step. Couple this with the vast amount of OSINT in existence and a picture starts to form.

Here’s how the factory works:

First – Normalization

Adversaries normalize raw material – they standardize fields, clean formatting, remove duplicates, and fix missing pieces. They don’t need perfection. They need enough consistency to automate.

Next – Linking

Data gets linked across disparate datasets – the adversary matches email addresses to phone numbers. Phone numbers to addresses. Addresses to dates of birth, and so on. One dataset fills the gaps in another.

Then – Scoring

Adversaries score attackable profiles to measure ROI. They don’t ask, “Can I compromise this account?” They ask, “Can I monetize this identity fast?”

They prioritize identities that connect to:

  • financial access
  • enterprise privileges
  • payroll and HR workflows
  • customer support recovery paths
  • vendor payment processes

Finally – Packaging

Profiles get packaged for operations. This is where identity becomes attackable. The profile supports repeatable playbooks: ATO, recovery bypass, SIM swap targeting, impersonation, and payment diversion.

That’s why identity risk now behaves like a business function for adversaries. They build a pipeline. That pipeline gets refined. Then it gets scaled.

And then exposure events feed that pipeline.

The Top Exposure Events – why mega breaches punch above their weight

When massive exposure events hit, many leaders respond with the familiar: “We’ll monitor. We’ll see if we’re affected.”

That script fails at machine speed. Large exposure events don’t just increase volume, they increase operational certainty for attackers:

  • consistent record structure
  • high overlap of data points with prior leaks
  • fast enrichment potential
  • easy automation with AI powered technologies

There are many examples of large data breaches. At this point they need to be treated as more than just headlines. Treat them as inventory injections, the raw materials needed for the modern day identity supply chain.

Once that inventory enters circulation, attackers don’t “use it once.” They:

  • monetize it
  • repackage it
  • enrich it with other datasets
  • resell it
  • and operationalize it in waves

That’s why identity exposure rarely behaves like a single incident. It behaves like a persistent condition.

And that’s why “wait for confirmed compromise” becomes the wrong approach.

Machine-speed defense – stop chasing events, interdict the pipeline

If attackers run identity like a factory, defenders must reciprocate. Defenders need to treat identity like a control plane.

This isn’t about perfect security as there is no such thing. Defenders do however need faster cycles:

  • faster detection-to-decision
  • faster decision-to-enforcement
  • tighter governance around automation
  • metrics that prove reduced operational risk

Here are some practical steps to improve an ecosystem:

Convert exposure into action

Alerts don’t help if they don’t trigger changes in systems and/or behavior. If it doesn’t change enforcement, it’s just telemetry. Build an identity exposure-to-action playbook that answers:

  • Which identities matter most? (executives, finance, privileged admins, support)
  • Which workflows create the largest blast radius? (recovery, vendor payments, payroll, customer support)
  • What control do we trigger first? (session resets, account recovery restrictions, throughput throttling)

Next, attack their economics.

Render stolen credentials less valuable

Kill the advantages that adversaries love by:

  • deploying phish-resistant MFA, especially for privileged roles
  • binding sessions to devices where possible
  • tightening token lifetimes and reuse policies

Then, close the side doors.

Harden the bypass routes

Adversaries don’t always brute force their way in. They tke less resistant paths, such as socially engineering account resets via a help desk. Treat recovery like a privileged operation by:

  • restricting recovery pathways for users, especially privileged ones
  • requiring stronger proof for recovery than just login creds
  • adding friction (synchronous checks via phone call, etc) to high-impact changes (bank info, payout routing, email changes)
  • training support teams on identity manipulation patterns and escalation guardrails

Finally, scale your response.

Automate enforcement

Automation wins at machine speed when done right, but beware as it can also break business operations. Start slow with low-risk actions and require human approval for high-impact actions (account lockouts, financial workflow freezes, privileged access resets).

And if you want to win long-term, measure what matters.

Measure the right outcomes

Generally speaking, if something gets measured, it can be improved. Consider the following so as to improve a security posture:

  • time-to-detect exposure (requires analysis to unearth original exposure)
  • time-to-enforce controls
  • % of privileged users on phish-resistant MFA
  • reduction in successful recovery abuse
  • reduction in ATO attempts that reach “valid session” state

Some of these metrics are not trivial and require analysis. But they translate cleanly to business outcomes: less fraud, fewer outages, fewer customer escalations.

The bottom line

Identity risk didn’t just automagically grow. It got industrialized.

Interestingly, attackers now build identity products. They run correlation pipelines. They operationalize exposure at machine speed. And they scale fraud the way mature businesses scale customer acquisition: with automation, testing, and iteration.

Here’s the modern posture. Instead of relying on outdated perimeter strategies, consider:

  • treating exposure as a leading indicator
  • hardening the identity lifecycle, not just the login
  • interdicting the pipeline wherever possible

Defending identity in the industrial era requires a new mindset.

AI Powered Cybercrime – How AI Supercharged a Sextortion Wave

AI Powered Cybercrime - How AI Supercharged a Sextortion Wave

Part 3 of AI Powered Cybercrime

Sextortion isn’t new. Velocity has increased, personalization has sharpened, and attackers can now run campaigns at industrial scale. This wave is a collision event between the first two posts in this series: facilitation (credible intimidation) and scale (high-volume delivery). AI Powered Cybercrime – How AI Supercharged a Sextortion Wave.

Many security programs have an important blind spot: they treat coercion as a personal problem. In reality, coercion quickly becomes an enterprise problem when it pressures employees into silence, errors, or unsafe, unethical, illegal behavior.

What happened (high level)

Following the large-scale exposure of personal data from a data broker, threat actors began sending extortion emails that included real names, real email addresses, and real home addresses. The goal was not technical proof; it was psychological terrorism. When a recipient of these types of emails and/or files sees real personal details, the scam feels “more real,” even if the core claim is false.

Some variants escalated intimidation by including a photo of the victim’s home sourced from publicly available mapping imagery. That addition is a masterclass in facilitation: it takes something the attacker can generate cheaply and turns it into a credibility anchor that increases stress and compresses decision time.

Why it works: plausibility beats truth under pressure

Most victims don’t evaluate these messages like analysts. They evaluate them like humans under threat, with emotion. The campaign design is built around that reality: shock, shame, urgency, and a narrow window to “fix” the situation. The scam doesn’t need to be technically accurate to be operationally effective; it only needs to feel plausible long enough to trigger payment.

This is the same vibe hacking dynamic we see in enterprise fraud: urgency is used as a control bypass. When the attacker can manufacture plausibility quickly, policy and verification become the only reliable defenses.

Where AI fits (without fluff)

AI does not need to run the entire scheme to increase harm. It only needs to improve the leverage points. First, it enables endless text variation while maintaining a consistent tone and similar messaging. Second, it makes personalization easy by merging templates with leaked data and also seamlessly integrating with Open Source Intelligence (OSINT) sources. Third, it reduces the human effort required to run a campaign, which increases throughput.

The result isn’t “smarter extortion.” It’s cheaper extortion at higher volume paired with sharper intimidation artifacts. That combination is what makes waves like this so disruptive.

Why CISOs should care: coercion becomes a business threat

Even when a victim is targeted “personally,” the downstream effects can land inside a CISOs organization. An employee under threat may avoid reporting, reuse credentials poorly, or comply with nefarious demands. Panic and stress can lead to unsafe behaviors, and this noise can weave its way into an organization distracting security teams from secondary attacks that aim to exploit some of that chaos.

If a resilience program covers ransomware but not coercion-driven fraud and extortion, there could be an operational gap. Sextortion waves are a reminder that the adversary’s true target is often decision-making under pressure.

What organizations should do during a wave

The objective in a wave is speed, clarity, and support. Issue a same-day bulletin that states what is happening, what employees should do, and how to report. Keep it stigma-free. The most important message is this: employees can report safely, and they won’t get in trouble.

Next, harden the identity bridge. Ensure MFA is enforced for email and sensitive applications, watch for anomalous sign-ins, and monitor for new device enrollments. Then improve detection quality by treating this as a campaign: pattern match across inboxes and route messaging to a single owner to reduce confusion and duplicate work.

The resilience lesson

Waves like this are not just security events; they’re leadership events. The organizations that respond well reduce harm by moving fast, communicating clearly, and providing support. They also learn: which workflows were stress-tested, where employees hesitated, and what verification gates were missing.

If you treat coercion as out-of-scope, you will eventually treat it as an incident, under pressure. Build the playbook now.

Key takeaways

  • Normalize coercion reporting; activate employee assistance programs immediately to protect people and organizational reputation.
  • Instrument wave messaging detection to tune signals and reduce both data fatigue and operational distraction.
  • Harden identity ecosystems fast; enforce MFA immediately to prevent panic-driven account takeover actions.
  • Operationalize extortion playbooks and drill them regularly to reduce chaos and decision latency.