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.