AI Agent Governance and Liability: Who's Actually on the Hook When Agents Act

Direct answer: In 2026, autonomous AI agents moved from an operational question to a legal one. Singapore, the United States, the European Union, Germany, the UK, and China have each produced a distinct governance or liability response this year, and none of them agree on the same model. The one point of consensus across every jurisdiction examined is that an AI agent itself is never the legally responsible party — liability lands on the company that deployed it, the vendor that built it, or the human who authorized what it was allowed to do, and the enterprises getting burned in 2026 are the ones that assumed "the AI agent decided" would ever hold up as a legal defense.

The Governance Gap Nobody Priced In

For the first few years of the generative AI boom, most legal and policy attention went to the models themselves — what a large language model was trained on, whether its outputs were biased, whether a chatbot's answers could constitute professional advice. Autonomous AI agents move the target entirely. An agent doesn't just generate text; it takes actions — placing orders, modifying records, sending communications, calling other software systems and other agents — often with a standing set of credentials and comparatively little real-time human review. That shift from "produces content" to "takes action" is exactly why 2026 became the year governance frameworks and liability questions caught up to deployment reality.

Three developments in early-to-mid 2026 mark the actual inflection point, and they didn't happen in one country or as one coordinated push. Singapore's regulator, the IMDA, released a Model AI Governance Framework for Agentic AI in January 2026, and it does something notable: it doesn't just ask companies to write policies, it requires verifiable digital identity and audit trails for agents operating in production. In February 2026, NIST's AI Agent Standards Initiative went further in diagnosing the actual problem rather than prescribing a fix — its warning was that most enterprise AI agents today are treated as generic service accounts, with no dedicated identity, no distinct permission model, and no audit trail separate from whatever human or system account they were spun up under. Then in June 2026, a US presidential executive order directed the Department of Justice to prioritize enforcement against AI-agent misuse specifically, which moved the conversation from "best-practice recommendation" to "an area where federal enforcement attention is now explicitly pointed."

Layered on top of all this is a liability question that got messier, not clearer, in 2025 and 2026. The European Union withdrew its dedicated AI Liability Directive from consideration in 2025 — a proposal that would have created bespoke rules for who's responsible when an AI system causes harm. Its withdrawal doesn't mean the EU has no answer; it means the EU decided the answer would come from existing and revised general-purpose law instead of a purpose-built AI statute. Agent-caused harms in the EU now fall to the revised Product Liability Directive, which imposes strict liability and must be transposed into every member state's national law by 9 December 2026, plus ordinary tort law layered on top wherever the Directive doesn't reach. That's a genuinely different model than a dedicated AI Liability Act would have been, and it leaves real edge cases — particularly around software-only agents that never touch a physical product — only partially answered.

None of this is theoretical positioning. Obsidian Security's 2026 overview of AI agent regulation makes a point that cuts through a lot of the confusion enterprises have about where they stand: companies keep looking for one law to comply with, when the actual landscape is a stack of overlapping obligations — data protection law, sector-specific regulation, general product liability, employment and consumer protection law, and now agent-specific governance guidance — that all apply simultaneously to the same deployed agent, none of which was written with "autonomous software that takes actions with real-world consequences" as its original target.

The technical shape of agentic AI compounds the problem. A single agent acting alone is hard enough to govern; a growing share of real deployments now involve multiple agents calling each other, delegating sub-tasks, and passing data between one another with no human touching most of the intermediate steps. When an outcome traces back through three or four agent-to-agent handoffs before reaching the action that caused harm, "which agent did this" stops being a rhetorical question and becomes a genuinely hard forensic exercise — one that's effectively impossible to answer without the identity and audit-trail discipline regulators are now asking for. Multi-agent architectures make the identity gap NIST is warning about worse, not better, because each additional agent in the chain is another point where "maker mode" credential inheritance can quietly slip in.

Why 2026 Is the Inflection Point

The timing isn't a coincidence. Enterprise AI agent deployment crossed from pilot to production at scale roughly through 2025, and Gartner's own research reflects what happens when that curve outpaces governance: on 26 May 2026, Gartner published research predicting that 40% of enterprises will demote or decommission autonomous AI agents by 2027 — not because the agents don't work, but because governance gaps only get discovered after a production incident, at which point the fix is far more expensive and disruptive than it would have been if governance had shipped alongside the agent in the first place. That statistic alone should reframe how a lot of businesses think about their agent roadmap: the risk isn't that regulation kills agentic AI adoption, it's that skipping governance now creates a rollback event later, after the agent is already load-bearing in a business process.

The regulatory responses in 2026 are, in a real sense, playing catch-up to a deployment pattern that moved faster than anyone's oversight model. An AI agent that summarizes documents is a fundamentally different risk profile than one with a live API key to your payment processor, your CRM, or your production database — but from the outside, at the point of provisioning, they often looked identical: a service account, an API key, and a system prompt. NIST's diagnosis in its February 2026 initiative is specifically about that gap — agents inheriting the access and treatment of a generic service account rather than being provisioned, monitored, and reviewed as the distinct actors they functionally are.

There's also a straightforward commercial reason 2026 is the year this crystallized: insurers, auditors, and enterprise procurement teams all started asking harder questions about AI agent deployments around the same time regulators did. A company that can't answer "which agents do we have running in production, what can each of them actually do, and who is accountable for that scope" is increasingly failing due-diligence conversations that have nothing to do with a specific law — the absence of an answer is itself the red flag, regardless of which jurisdiction's rules technically apply to that business.

This is also increasingly a board-level conversation rather than a purely technical one. As autonomous agents take on higher-stakes responsibilities — approving transactions, interacting directly with customers, making decisions that used to require a manager's sign-off — the potential financial and reputational exposure from a governance failure becomes large enough that boards and audit committees are starting to ask the same questions insurers and procurement teams are asking: what agents do we have, what can they do, and who's accountable if one of them gets it wrong. A governance program that can answer those three questions clearly, in plain language, for every deployed agent is doing something genuinely valuable beyond regulatory compliance — it's giving leadership an honest picture of exposure they'd otherwise only discover during an incident post-mortem.

Legal, Security, and Product All Own a Piece of This, Which Is Why It Falls Through the Cracks

One reason agent governance lags behind agent deployment inside so many organizations isn't a lack of awareness — it's that no single team owns the whole problem. Legal teams are tracking jurisdiction-specific liability exposure: which statute applies, what the Product Liability Directive's transposition means for European operations, whether a given deployment needs to be reassessed after the next piece of guidance lands. Security and IT teams are the ones who actually provision credentials, set permission scopes, and would be responsible for building the identity and audit-trail infrastructure NIST and Singapore's IMDA are describing. Product and business teams are the ones deciding what an agent should be allowed to do in the first place — the actual scope of its authority over refunds, communications, or data — often without either legal or security in the room when that scope gets defined.

Each of those three functions can point to a different part of this problem as "handled" while the seams between them go unmanaged. Legal can confirm the company is tracking the right statutes without ever confirming that IT actually implemented agent-specific identity controls. Security can confirm every agent has a scoped credential without ever confirming that the scope itself was reviewed against the specific liability exposure legal is tracking. Product can ship a new agent capability on a deadline without either team having signed off on what happens if that capability gets misused. None of these gaps show up until an incident forces all three functions into the same room retroactively, at which point the conversation is forensic and defensive rather than preventive.

The organizations that have actually closed this gap in 2026 tend to have done one specific thing: they've assigned a single accountable owner — sometimes a formal AI governance lead, sometimes a cross-functional committee with a named chair — whose job is specifically to make sure legal's tracked obligations, security's technical controls, and product's scope decisions stay in sync for every deployed agent, not just at launch but on an ongoing basis. That owner doesn't need to be a lawyer, a security engineer, or a product manager individually competent in all three domains — they need the standing authority to insist the three functions actually talk to each other about the same agent, and the mandate to block a deployment when they haven't. This maps directly onto the UK's named-individual-with-authority-to-halt-a-deployment model and Singapore's identity-and-audit-trail requirement: both are really asking for the same organizational capability, just described from different angles.

It's also worth being honest about where this responsibility tends to land by default when no one explicitly claims it: with whichever team built the agent, usually a product or engineering group optimizing for shipping a capability, not for anticipating a liability dispute eighteen months later. That's a reasonable default in the absence of a better one, but it's also exactly the pattern that produces the governance gaps Gartner's research describes — gaps that surface only once an agent is already handling real volume and a problem has already occurred. Assigning explicit, cross-functional ownership before that point, rather than defaulting to whichever team happened to build the thing, is one of the more underrated fixes available to any organization scaling its agent deployment in 2026.

Who Actually Carries the Risk

The clearest finding across every jurisdiction covered in 2026 reporting is this: no AI agent has legal personality. It cannot be sued, fined, or held liable in its own right, in any of the frameworks examined. Baker McKenzie's June 2026 analysis of US legal accountability for AI agents states this plainly — liability rests with the humans and companies deploying the agent, full stop. That has a direct, practical consequence that a lot of internal AI governance conversations still get wrong: "the agent made an autonomous decision" is not, and was never going to be, an available legal defense. A California statute goes further and explicitly forecloses defendants from even raising that argument, closing off what might otherwise have become a popular deflection strategy in agent-related litigation.

That reallocates the actual business stakes in a specific direction. If your AI agent can't be the responsible party, then the responsible party is whoever built the agent's permission scope, whoever approved its deployment, and whoever was supposed to be monitoring what it did — which means the risk isn't abstractly "AI risk," it's a fairly conventional allocation-of-responsibility problem that just happens to have an AI system in the middle of it. A company deploying a procurement agent with standing purchasing authority is taking on liability exposure functionally similar to giving a new, unsupervised employee a company credit card and broad purchasing discretion — except the agent can act at machine speed, around the clock, without the hesitation or judgment calls a human employee would apply.

This is where the UK's approach, as described in Scaffold Digital's 2026 UK AI regulation guide, is instructive by contrast to the EU's more strict-liability-oriented model: UK guidance emphasizes governance and safeguards rather than a fixed liability framework, and it does this specifically by centering responsibility on named individuals who hold the authority to halt an AI deployment. That's a meaningfully different design choice — instead of asking "which law assigns fault after the fact," it asks "who, specifically, inside this organization, is empowered and expected to pull the plug before harm compounds." Both models point to the same underlying business requirement: an organization needs a named, accountable human (or small set of humans) attached to every deployed agent, not a vague assumption that "the team" or "IT" is somehow collectively responsible.

None of this is only a downside-management exercise, either. A business that can clearly demonstrate scoped access, named accountability, and a working audit trail for its agents is also the business best positioned to expand what those agents are trusted to do next, because every one of the seven regional approaches examined here treats demonstrable governance as the thing that earns an organization more latitude, not less. Regulators and courts across every framework reviewed consistently give more benefit of the doubt to an organization that documented its reasoning and monitored its systems than to one that deployed first and only thought about oversight after something went wrong. Good governance, in other words, isn't purely a cost of doing business with agentic AI — it's also the fastest legitimate path to being allowed to do more with it.

The stakes scale with scope of action, not with how impressive the underlying model is. A customer-support agent that only drafts email replies for human review carries a different risk profile than one empowered to issue refunds, cancel subscriptions, or modify account permissions without a human in the loop. Enterprises that have gotten this right in 2026 tend to share one habit: they maintain an actual inventory of what each deployed agent can do — not what it was designed to do, but what its current credentials and tool access actually permit — and they revisit that inventory on a schedule rather than only after something goes wrong. Building that governance layer alongside a new agent, rather than retrofitting it after the agent is already handling real business volume, is a core part of how we approach AI agent and automation projects — the permission model and audit trail are design decisions made at build time, not a compliance checklist bolted on afterward.

How Seven Regions Are Handling Agent Liability

There is no single global standard here, and pretending otherwise is one of the more common mistakes multinational companies make. Here's an honest picture, region by region, of where things actually stand as of 2026.

United States. The US model is built on the "no legal personality" principle described above: AI agents can't be held liable themselves, so liability rests with the deploying company or the human who authorized the deployment. A California statute closes off the "it acted autonomously" defense specifically. At the federal level, a June 2026 presidential executive order directed the DOJ to prioritize enforcement against bad actors using AI agents for nefarious purposes — a meaningful signal that federal enforcement attention is now explicitly pointed at agent misuse, not just model-level harms. And Gartner's prediction that 40% of enterprises will demote or decommission autonomous agents by 2027 due to governance gaps found post-incident is itself a US-anchored data point about how this is playing out in practice.

United Kingdom. Rather than legislating a strict-liability regime, UK guidance in 2026 emphasizes governance and safeguards, and does so by requiring named individuals inside an organization who hold explicit authority to halt an AI deployment. It's a people-and-process answer to a question the EU is answering through statute — put a human name and a kill switch behind every agent, rather than waiting to litigate fault after something breaks.

UAE and Dubai. No distinct, agent-liability-specific reporting was found in this research as of 2026 — a gap worth noting rather than papering over. The UAE's broader AI governance approach (a layered structure of federal data protection law, financial free-zone rules, and a newly created federal AI authority) is developing quickly on parallel tracks, but a dedicated position on agent liability specifically hadn't surfaced in the sources reviewed here.

Australia. Similarly, no Australia-specific reporting on AI agent liability rules turned up in this research. That absence is notable given how active Australia has otherwise been in broader AI policy discussions, and it's a genuine open question for any business operating agentic AI in the Australian market as of 2026 — the honest answer right now is "watch this space," not "here's the rule."

Germany. Germany doesn't yet have an AI-specific liability statute, but that doesn't mean agent-caused harm goes unaddressed — it runs through existing general law. The Produkthaftungsgesetz (Germany's strict producer liability law) and Section 823 of the BGB (the general tort law provision) both already apply to harms an AI system causes, according to agentliability.co's 2026 Germany guide. What's incoming is the revised EU Product Liability Directive (2024/2853), which explicitly covers AI systems and introduces something new: a rebuttable presumption of defectiveness for complex AI systems, meaning the burden shifts meaningfully in the claimant's favor when the AI system in question is complex enough that proving a specific defect the traditional way would be impractical. Germany must transpose this into national law by 9 December 2026.

France and the wider EU. Beyond the same EU-wide Product Liability Directive transposition deadline of 9 December 2026 that applies to every member state, no France-specific or otherwise distinctly national reporting was found. The practical reality for a business operating across the EU is that the transposition deadline is the same across the bloc, but the specific national implementing legislation each member state passes to meet that deadline may still introduce country-level variation worth tracking as 2026 closes out.

China. China's approach is oversight-first rather than liability-first: a joint AI Agents Framework from the Cyberspace Administration of China, the National Development and Reform Commission, and the Ministry of Industry and Information Technology took effect 15 July 2026, and it imposes elevated oversight requirements specifically on autonomous agents operating in sensitive sectors — healthcare, transportation, media, and public safety are named explicitly — across nineteen identified application scenarios, per Rimon Law's July 2026 reporting. No dedicated agent-liability statute distinct from this oversight framework was found, which mirrors the broader Chinese regulatory pattern of governing AI primarily through sector- and scenario-specific administrative oversight rather than a single cross-cutting liability law.

The throughline across all seven regions is that nobody has produced a single, complete answer yet. Every jurisdiction examined here is building its response out of a combination of new agent-specific guidance and old general-purpose law, and the combination is different in every single case. A company operating agents across more than one of these jurisdictions doesn't get to pick the friendliest regime — it has to satisfy all of them simultaneously, which is a genuinely harder compliance posture than operating under one unified global standard would be.

Building an Agent Governance Program That Survives Contact With Reality

Given that the regulatory picture is fragmented and still moving, the practical question for most businesses isn't "which specific law applies to us" — it's "what would make us defensible regardless of which law ends up applying." A few things show up consistently across the 2026 guidance reviewed here, regardless of jurisdiction.

Treat every deployed agent as a named identity, not a shared service account. This is the single most concrete, actionable point buried in NIST's February 2026 warning: agents that inherit a generic service account's permissions and audit trail are functionally invisible to any later investigation, because nothing distinguishes what the agent did from what a human using that same account might have done. Singapore's IMDA framework makes this explicit as a requirement rather than a suggestion — verifiable digital identity and audit trails for agentic systems, not as an aspiration but as the baseline. Practically, that means every agent gets its own credential set, scoped to only what it needs, logged separately from human activity on the same systems.

Put a name on the kill switch. Whether you're operating under the UK's governance-first model or the EU's more codified liability regime, the same operational fact holds: someone specific, identifiable by name and role, needs the standing authority to halt a given agent's operation immediately, and that authority needs to be tested before it's needed in an emergency, not discovered to be theoretical during one.

Audit scope on a schedule, not just at launch. An agent's actual permissions tend to drift from its originally designed permissions over time, as it gets integrated into more workflows, granted more tool access, or connected to more downstream systems. The gap between "what we designed this agent to do" and "what this agent currently has the technical ability to do" is exactly where the incidents Gartner is describing tend to originate. A recurring audit — quarterly is a reasonable default for anything with write access to production systems — closes that gap before it becomes a production incident rather than after.

Don't assume your vendor's compliance covers your deployment. A platform or model provider being compliant with a given framework addresses that provider's obligations, not necessarily yours as the deploying enterprise — your specific configuration, the scope you granted the agent, and the data you exposed it to are your responsibility regardless of how compliant the underlying platform is. This is a distinction worth stating plainly to any internal stakeholder who assumes "we bought this from a reputable AI vendor" is itself a governance answer.

Document the reasoning behind scope decisions, not just the scope itself. If an agent is granted the ability to issue refunds up to a certain amount, or to modify certain account fields, or to send communications on the company's behalf, the reasoning behind exactly why that scope was chosen — and who signed off on it — is what turns a governance program from a compliance artifact into something that would actually hold up if a regulator, an auditor, or opposing counsel asked "why did this agent have the ability to do that."

Push indemnification and liability allocation into vendor contracts up front. Because no AI agent has legal personality anywhere examined in this piece, and because a vendor's own compliance doesn't automatically extend to your deployment, the contractual relationship with whoever built or hosts your agent platform is one of the few places you can proactively negotiate where responsibility sits before anything goes wrong. Clear contractual language on data handling, monitoring obligations, and indemnification in the event the platform itself is found defective gives a business a concrete fallback that exists independent of how any specific liability statute in any specific jurisdiction eventually gets applied or interpreted.

Businesses that treat this as a serious build requirement rather than an afterthought are the ones positioned to survive whichever specific liability framework ends up applying to their sector and jurisdiction, because the underlying discipline — scoped access, named accountability, auditable decisions — satisfies nearly every version of "reasonable governance" that regulators across these seven regions are converging toward, even where the specific statutes haven't converged yet. If you're assessing where your own AI program stands against this bar, our compliance and security resources cover the adjacent controls — audit logging, access scoping, and data handling — that tend to get evaluated together in practice.

Straight Answers to the Questions Enterprises Are Asking About Agent Liability

Is the EU AI Act the only law I need to worry about for AI agents?

No. This is one of the most common misconceptions enterprises carry into agent deployment, and Obsidian Security's 2026 overview of AI agent regulation calls it out directly: the actual compliance landscape stacks the EU AI Act alongside data protection law (GDPR and its equivalents), sector-specific regulation (financial services, healthcare, and other regulated industries all layer their own rules on top), general product liability law, employment and consumer protection statutes, and now agent-specific governance guidance from bodies like Singapore's IMDA and the US's NIST. None of these were written in isolation from each other, and none of them defer entirely to the others. A deployed agent that, say, processes EU resident data, operates in a regulated financial workflow, and is deployed by a US company answers to all of the relevant layers simultaneously, not just whichever one has gotten the most press coverage. Treating the EU AI Act as the single compliance target is a good way to pass one audit and fail three others.

Do AI agent regulations apply to internal-only agents?

Yes, generally — and this is a distinction many enterprises get wrong going into 2026 governance reviews. The instinct to assume "internal-only" tools escape regulatory scope makes sense given how consumer-facing AI rules are often framed in public discussion, but Obsidian Security's 2026 research is direct on this point: an agent's exposure to external users isn't what triggers most governance and liability obligations — its access to sensitive data, its ability to take consequential actions, and its role in a regulated business process are what matter. An internal agent with standing access to customer financial records, employee data, or production systems carries real governance obligations regardless of whether any customer ever interacts with it directly. The safer default for any enterprise building an internal-only agent is to assume the same governance rigor — identity, audit trail, scoped access, named accountability — applies as it would to a customer-facing one, rather than assuming internal deployment is a compliance shortcut.

What is "maker mode" and why do regulators care?

"Maker mode" describes a specific, common pattern flagged in Obsidian Security's 2026 research: an AI agent inheriting the credentials, permissions, and access level of the person or account that built or configured it, rather than being provisioned with its own distinct, scoped identity. It's a shortcut that makes sense from a development-speed perspective — the person building the agent already has broad access, so it's fastest to just let the agent run under that same access rather than provisioning something new — but it's exactly the pattern regulators and standards bodies are now flagging as a governance failure. An agent running in "maker mode" is functionally invisible in an audit trail: any action it takes looks identical to an action the human builder might have taken personally, which defeats the entire purpose of trying to hold the agent's actual behavior accountable. It's one of the most common gaps found only after something has already gone wrong in production.

Can I rely on my AI vendor for compliance on agent regulations?

Not entirely, and this is worth being direct about. A vendor's own compliance posture — the underlying model provider's certifications, the platform's security practices — addresses that vendor's obligations as a provider, but it doesn't automatically extend to cover how you configure, scope, and deploy the agent inside your own environment. Obsidian Security's 2026 overview makes this distinction explicit: the deploying enterprise carries its own governance obligations around what data it exposes to the agent, what actions it authorizes the agent to take, and how it monitors that behavior, independent of how compliant the underlying platform is. A reputable vendor is a necessary foundation, not a substitute for your own governance program. Any vendor conversation worth having should include a clear answer to where their responsibility ends and yours begins, and if a vendor treats that as an unusual question, that's itself useful information.

Does runtime enforcement exist for every agent platform today?

No, and this gap is one of the more practically important findings in 2026 agent-governance research. Runtime enforcement means a platform can actually stop an agent from taking an out-of-scope action as it happens, rather than only logging that it happened after the fact for later review. Per Obsidian Security's 2026 overview, this capability is inconsistent across the agent-platform landscape: some platforms have mature, granular runtime controls; many others still rely primarily on after-the-fact logging and periodic review, which catches problems only once the action has already occurred. For any enterprise evaluating or building on an agent platform, it's worth asking specifically whether policy violations are prevented in real time or merely recorded — the difference matters enormously the first time an agent attempts something genuinely out of scope, and "we log everything" is a materially weaker answer than "we can block that before it executes."

How often should I audit AI agents?

There's no single universal number, but the practical guidance emerging from 2026 governance frameworks points toward treating agent audits as a recurring operational discipline rather than a one-time launch checklist. A reasonable default for any agent with write access to production systems, financial workflows, or sensitive data is a quarterly review of its actual current scope — not what it was designed to do at launch, but what its live credentials and tool access currently permit, since that tends to drift as agents get integrated into more workflows over time. Higher-risk agents (financial transactions, healthcare-adjacent decisions, anything touching regulated data) warrant more frequent review; lower-risk, narrowly-scoped agents can reasonably go longer between formal reviews. The failure pattern regulators keep flagging isn't infrequent auditing exactly — it's the absence of any scheduled audit at all, where scope creep goes completely undetected until an incident forces a review.

What does the Singapore IMDA Model AI Governance Framework for Agentic AI require?

Singapore's IMDA released its Model AI Governance Framework for Agentic AI in January 2026, and its central, distinguishing requirement is verifiable digital identity and audit trails for agents operating in production environments. Rather than treating an agent as an extension of whatever account or system deployed it, the framework requires that agentic systems be identifiable and traceable in their own right, meaning a specific agent's actions can be distinguished from a human's actions on the same systems, and reconstructed after the fact if something needs investigating. This directly targets the exact gap NIST would flag a month later in the US: agents running under borrowed or generic identity with no distinct audit trail. Singapore's framework is notable for being among the first dedicated, agent-specific (rather than general AI) governance responses globally, and it sets a concrete bar — identity plus auditability — that other jurisdictions' agent-specific guidance has generally converged toward as well.

What is NIST's AI Agent Standards Initiative and when did it launch?

NIST's AI Agent Standards Initiative launched in February 2026, and its most important early contribution wasn't a new rule — it was a clear diagnosis of the existing problem. The initiative's warning is that most enterprise AI agents today are treated as generic service accounts, provisioned the same way any automated system integration might be, with no dedicated identity, no agent-specific permission model, and no audit trail that distinguishes the agent's actions from the account it runs under. That's a foundational governance gap sitting underneath a lot of enterprise agent deployment, and NIST's initiative frames closing it — through dedicated identity, authorization, and monitoring standards specific to agentic systems — as the priority ahead of more elaborate rule-making. For enterprises, NIST's initiative functions as a preview of where US standards-setting is heading: expect future guidance to formalize agent-specific identity and access controls as a baseline expectation, not an advanced practice.

Does an AI agent have its own legal personality under current law?

No. This is the clearest, most consistent finding across every jurisdiction examined in 2026 research, and Baker McKenzie's June 2026 analysis of US legal accountability states it plainly: AI agents have no legal personality under current law. They cannot be sued, held liable, or made to answer for harm in their own right, in the US or anywhere else covered in this research. That means every liability question resolves to a human or corporate party standing behind the agent — the company that deployed it, the vendor that built it, or the individual who authorized its scope of action. Practically, this forecloses a defense strategy some might have hoped to rely on: there is no version of "the AI agent is responsible, not us" that current law recognizes anywhere in the jurisdictions reviewed here. Responsibility routes through people and organizations, full stop.

What does the California statute on AI agent liability foreclose defendants from arguing?

Per Baker McKenzie's June 2026 analysis, a California statute specifically forecloses defendants from arguing that an AI agent "autonomously" caused harm as a way of deflecting their own liability. In plain terms, a company can't point to the agent's autonomous decision-making as the actual cause of harm in a way that shifts responsibility away from the company that deployed it. This closes off what could otherwise have become an obvious and popular legal strategy as agentic AI deployment scales: arguing that because the agent operated with a degree of independence, the humans and organizations behind it shouldn't bear full responsibility for what it did. California's approach removes that argument from the table entirely, reinforcing the broader principle running through nearly all 2026 guidance — autonomy in how an agent operates doesn't dilute the accountability of whoever deployed and authorized it.

What did the June 2026 presidential executive order direct the DOJ to do regarding AI agents?

The June 2026 executive order directed the US Department of Justice to prioritize enforcement against bad actors using AI agents for nefarious purposes, per Baker McKenzie's analysis from the same month. This is a meaningful escalation in tone from earlier, more guidance-oriented federal AI policy — it explicitly points federal enforcement resources at AI-agent misuse as a named priority area, rather than leaving agent-related harms to be addressed only through existing, general-purpose enforcement mechanisms as they happen to apply. For enterprises, the practical signal is that AI-agent-related misconduct — whether that's an agent used to facilitate fraud, deceptive practices, or other harms — is now an area where federal prosecutors have been explicitly instructed to focus attention, which raises the practical stakes of governance failures that allow an agent to be used, or to act, in ways that cross into that territory, whether through malicious misuse or through inadequate oversight that enables harm.

What percentage of enterprises does Gartner predict will demote or decommission autonomous AI agents by 2027, and why?

Gartner's research, published 26 May 2026, predicts that 40% of enterprises will demote or decommission autonomous AI agents by 2027. The reason given is specific and worth internalizing: governance gaps that are only discovered after a production incident, at which point rolling back or downgrading the agent's autonomy becomes the practical response. Gartner's framing — captured in the title of that research, which warns that applying uniform governance across AI agents will lead to enterprise AI agent failure — points at a related, more nuanced problem: treating every agent with the same one-size-fits-all governance approach, regardless of how much risk that specific agent's scope actually carries, is itself a failure mode. The prediction functions as a warning about sequencing: the businesses in that 40% aren't failing at agentic AI as a technology, they're failing at building governance in ahead of scale rather than discovering the gaps live in production.

Why was the EU AI Liability Directive withdrawn?

The European Commission formally withdrew the proposed AI Liability Directive from consideration in 2025, with formal notice given on 6 October 2025, per IAPP's reporting. The Directive would have created a dedicated, bespoke liability framework specifically for AI-caused harm, separate from general product liability or tort law. Its withdrawal reflects a policy choice rather than an oversight — the EU determined that AI-related liability could be adequately addressed through existing and revised general-purpose frameworks (principally the Product Liability Directive, revised specifically to bring AI systems within scope) rather than maintaining a separate, AI-specific liability statute running in parallel. It's a meaningful signal about EU regulatory philosophy: rather than continuing to multiply AI-specific statutes indefinitely, the EU chose in this instance to fold AI liability into its broader, existing liability architecture, even though that leaves some AI-specific nuances — particularly around software-only, non-physical-product harms — to be worked out through case law and interpretation rather than explicit statutory language.

What replaces the withdrawn AI Liability Directive in the EU?

With the dedicated AI Liability Directive withdrawn, agent-caused and AI-caused harms in the EU now fall to the revised Product Liability Directive, which imposes strict liability and explicitly brings AI systems within its scope, plus ordinary tort law layered on top wherever the Directive's product-focused framing doesn't fully reach, per both IAPP's and Baker McKenzie's 2025-2026 reporting. This is a materially different structure than the withdrawn Directive would have created: strict liability under the Product Liability Directive generally requires establishing that a product was defective and caused harm, without needing to prove negligence, which is claimant-friendly in one sense, but the Directive's product-centric framing can create genuine ambiguity for purely software-based or service-delivered AI agents that don't map cleanly onto the traditional concept of a "product." That ambiguity is one of the more actively debated open questions in EU AI liability law heading into the Directive's transposition deadline.

By when must EU member states transpose the revised Product Liability Directive covering AI?

EU member states must transpose the revised Product Liability Directive — Directive 2024/2853, which explicitly brings AI systems within its scope — into national law by 9 December 2026, per agentliability.co's 2026 Germany guide, and this deadline applies uniformly across the entire EU, not just Germany. This is one of the more concrete, dated compliance milestones in the entire 2026 AI regulatory landscape, and it matters for any business operating AI agents in EU markets: after that date, every member state is expected to have its own national implementing legislation in place giving effect to the Directive's strict-liability regime and its rebuttable presumption of defectiveness for complex AI systems. Businesses operating across multiple EU member states should expect the broad strokes to be consistent post-transposition, but should also expect some degree of national-level variation in exactly how each country's implementing legislation is worded and enforced.

Does Germany's BGB tort law create liability for AI agent harms even without a dedicated AI liability law?

Yes. Per agentliability.co's 2026 Germany guide, Section 823 of the BGB — Germany's general tort law provision — already applies to harms caused by AI systems, including AI agents, independent of whether a dedicated AI-specific liability statute exists. Section 823 provides a general basis for claiming damages where a party's actions (or, by extension, the actions of a system they deployed and are responsible for) cause harm to another person's protected legal interests, and German courts and legal practitioners treat this as fully applicable to AI-caused harm today, not as a stopgap waiting to be replaced. This means businesses operating AI agents in Germany already face real tort exposure under existing law right now, in 2026, well before the EU's revised Product Liability Directive is transposed by the December 2026 deadline — the absence of an AI-specific statute has never meant an absence of liability exposure in Germany.

Does Germany's existing Produkthaftungsgesetz already cover defective AI products before the EU Directive is transposed?

Yes, per agentliability.co's 2026 analysis. The Produkthaftungsgesetz — Germany's existing strict producer liability law, itself originally implementing an earlier EU product liability directive — already applies to defective AI products today, ahead of the revised EU Product Liability Directive's December 2026 transposition deadline. This means German liability exposure for AI-related harm isn't waiting on new legislation to exist; it's already live under current law, and the incoming EU Directive transposition will primarily update and extend this existing framework — most notably by explicitly clarifying that AI systems fall within scope and by introducing the rebuttable presumption of defectiveness for complex AI systems — rather than creating liability exposure where none currently exists. Any business treating German AI liability as a future concern to prepare for by the December 2026 deadline is working from an inaccurate premise; the more accurate framing is that the deadline updates existing exposure rather than creating it from scratch.

What rebuttable presumption of defectiveness does the revised EU Product Liability Directive introduce for complex AI systems?

The revised Product Liability Directive (2024/2853) introduces a rebuttable presumption of defectiveness specifically for complex AI systems, per agentliability.co's 2026 reporting. In practice, this shifts the evidentiary burden in a claimant-friendly direction: for AI systems complex enough that proving a specific technical defect through conventional means would be impractical for an injured party (who typically lacks access to the system's internals), the law presumes the system was defective if it caused harm, and the burden shifts to the manufacturer or deployer to rebut that presumption — to demonstrate the system wasn't actually defective, or that the defect didn't cause the harm in question. This is a meaningful departure from traditional product liability, where the claimant typically bears the full burden of proving defectiveness. For any company deploying complex AI agents in the EU, it raises the practical stakes of being able to demonstrate, with real documentation, exactly how an agent was tested, scoped, and monitored.

What identity and authorization controls does NIST recommend for enterprise AI agents?

NIST's AI Agent Standards Initiative, launched February 2026, frames its core recommendation around closing the specific gap it diagnosed: agents currently running as generic service accounts need dedicated identity, distinct from any human or system account that provisioned them, along with an authorization model scoped specifically to what each agent actually needs to do its job rather than inherited broad access. The practical shape of this, as reflected in how enterprises are responding to the initiative, includes agent-specific credentials that can be individually revoked or scoped without affecting other systems, permission models granted per-task or per-workflow rather than blanket access, and logging that attributes actions specifically to the agent's own identity rather than to whatever account it runs under. This mirrors, and in some respects anticipates, the same identity-and-audit-trail requirement Singapore's IMDA framework made explicit a month earlier — both point toward the same underlying standard: agents need to be who they are, on the record, not a shadow of someone else's account.

How does the UK approach AI liability differently from the EU's strict-liability model?

The UK's approach, per Scaffold Digital's 2026 UK AI regulation guide, deliberately emphasizes governance and safeguards rather than codifying an explicit liability framework the way the EU's revised Product Liability Directive does. Instead of assigning strict liability through statute and letting fault get litigated after harm occurs, the UK model centers responsibility on named individuals inside an organization who hold explicit authority to halt an AI deployment. It's a preventive, process-oriented answer to the liability question rather than a compensatory, after-the-fact one — the UK's implicit bet is that requiring organizations to designate accountable humans with real stop-authority reduces the frequency and severity of AI-caused harm in the first place, which matters more than how cleanly liability gets assigned once harm has already happened. Businesses operating in both the UK and EU need governance postures that satisfy both models simultaneously: named accountable individuals for the UK, plus documented compliance with strict-liability product rules for the EU.

What sectors get "higher oversight" under China's July 2026 AI Agents Framework?

China's AI Agents Framework — joint guidance from the Cyberspace Administration of China, the National Development and Reform Commission, and the Ministry of Industry and Information Technology, effective 15 July 2026 — imposes higher oversight requirements specifically on autonomous agents operating in healthcare, transportation, media, and public safety, per Rimon Law's July 2026 reporting. These four sectors share an obvious common thread: each involves AI agent decisions or actions with a direct, potentially serious impact on physical safety, public trust, or information integrity if something goes wrong. The elevated oversight in these sectors sits within a broader structure of nineteen identified application scenarios the framework covers overall, with these four flagged for a stricter compliance bar than the general baseline. For any business operating agentic AI in China within these named sectors, that means budgeting for oversight obligations meaningfully above the general standard applied elsewhere in the framework's scope.

How many application scenarios does China's AI Agents Framework identify across manufacturing and consumer services?

China's AI Agents Framework, effective 15 July 2026, identifies nineteen application scenarios across its scope, per Rimon Law's July 2026 reporting. This granular, scenario-by-scenario structure is characteristic of China's broader regulatory approach to AI, which tends to favor detailed, sector- and use-case-specific administrative guidance over a single broad, horizontal statute covering all AI uses uniformly (the approach the EU AI Act takes, by contrast). Within those nineteen scenarios, the framework applies differentiated oversight levels, with healthcare, transportation, media, and public safety singled out for the elevated scrutiny described above, while other identified scenarios, including a range of manufacturing and consumer-service applications, operate under the framework's general oversight baseline. For multinational businesses, this means compliance mapping in China requires identifying exactly which of the nineteen named scenarios a given agent deployment falls into, rather than assuming one uniform compliance bar applies across every use case.

Who is legally responsible when an AI agent makes an unauthorized purchase or transaction on a company's behalf?

Under the frameworks examined across every jurisdiction in this research, responsibility falls to the company that deployed the agent and granted it purchasing authority, not the agent itself, which has no legal personality anywhere these rules have been examined. In practice, the specific allocation of internal responsibility (and any recourse the company might have) depends on where the failure actually occurred: if the agent operated within its granted scope but that scope was too broad or poorly designed, the failure sits with whoever approved that scope. If the agent exceeded its granted scope due to a platform defect, that may create a claim against the vendor under product liability principles. If a third party manipulated the agent into acting outside its intended purpose — a prompt-injection-style attack, for example — that raises separate questions about whether the deploying company's security controls were adequate. In every version, the company deploying the agent carries the primary exposure to the counterparty affected by the transaction.

What is an "agentic tort liability" framework and how does it differ from ordinary product liability?

"Agentic tort liability" is a framing used in academic legal analysis — including a 2026 working paper titled "Acting with AI: An Interaction-Based Framework for Agentic Tort Liability" — to describe liability theories built specifically around the interactive, multi-step nature of how AI agents cause harm, rather than treating an agent purely as a static product with a fixed defect. Ordinary product liability generally asks whether a product, as designed or manufactured, was defective and whether that defect caused harm, a largely static, point-in-time question. An interaction-based agentic framework instead considers the full sequence of an agent's decision-making and actions leading up to harm, including how it was prompted, what it retrieved or was told, what tools it invoked, and how its permissions were scoped at each step, treating the harm as potentially arising from the interaction pattern itself rather than from a single fixed defect. This is still an emerging academic framing rather than settled law in any jurisdiction reviewed here, but it reflects a genuine conceptual gap that existing product liability law wasn't built to address cleanly.

Does AI agent liability shift depending on whether the harm came from the model, the deploying company, or the end user?

Yes, in principle, though the practical allocation is still being worked out across the jurisdictions examined here. The general shape that's emerging: if harm traces to a genuine defect in the underlying model or platform itself, liability tends to point toward the vendor or model provider under product liability principles. If harm traces to how the deploying company configured, scoped, or monitored the agent, liability tends to point toward that company, which is the scenario most 2026 guidance spends the most time on, since it's the most common failure mode in practice. If harm traces to an end user's misuse of the agent in ways the deploying company couldn't reasonably have prevented, liability may shift toward that user, though this is the least developed and most fact-dependent branch across the frameworks reviewed. In practice, real incidents often involve more than one of these failure points simultaneously, which is exactly why documentation of scope, monitoring, and configuration decisions matters so much: it's what lets a company demonstrate which category its situation actually falls into.

Are AI agents treated as "products" or "services" for liability purposes?

It depends on the jurisdiction, and within a jurisdiction, on the specific delivery model — and this is one of the genuinely unresolved questions across 2026's regulatory landscape. The EU's revised Product Liability Directive explicitly brings AI systems within scope as products for its purposes, which is a deliberate legislative choice to resolve ambiguity that existed under the prior framework. But that resolution doesn't fully settle every edge case: a purely software-delivered, continuously updated AI agent accessed as a service doesn't map as cleanly onto the traditional "product" concept as, say, an AI system embedded in a physical device does, and this is an actively debated point among EU legal practitioners. In the US, the products-versus-services classification varies more by state and by the specific legal theory being pursued in a given case. For any business, the safer operating assumption is that regulators and courts are trending toward treating agentic AI as product-like for liability purposes, even where a service delivery model is technically involved.

What happens if an AI coding agent introduces a security vulnerability that causes financial harm to a third party?

Under the general principles running through 2026 guidance, primary exposure would fall to the company that deployed the coding agent and put its output into production without adequate review; the fact that an AI agent wrote the vulnerable code doesn't shift responsibility away from the human process (or absence of one) that allowed it to ship. If the vulnerability traces to a genuine defect in the underlying model or coding platform itself, rather than to how the deploying company used it, that could support a separate claim against the vendor under product liability principles, but the deploying company would still likely face the initial claim from the harmed third party and would need to establish the vendor's fault separately. This is exactly the scenario that makes code review, testing, and staged deployment non-optional for AI-assisted development — an agent's output needs the same scrutiny before shipping that any other untrusted contribution would get, and skipping that step doesn't transfer liability to the AI, it just removes the evidence that due care was exercised.

Do existing insurance policies cover harms caused by autonomous AI agents?

Often only partially, and this is a genuine, still-developing gap rather than a settled question. Traditional commercial general liability, technology errors and omissions, and cyber insurance policies were generally written before autonomous AI agents were a mainstream deployment pattern, and many contain language, exclusions, or definitions that don't map cleanly onto agent-caused harm, particularly harm arising from an agent's autonomous decision-making rather than a more conventional software bug or data breach. Some insurers have begun offering AI-specific endorsements or standalone coverage, but this market is still maturing, and coverage terms vary significantly. The practical implication for any business deploying agents with meaningful real-world authority — financial transactions, customer communications, operational decisions — is to have an explicit conversation with a broker or carrier about whether existing policies actually contemplate agent-caused harm, rather than assuming general technology or liability coverage automatically extends to it. Silence in a policy on this point is not the same as coverage.

What is the difference between "agent governance" (access/permissions) and "agent liability" (who pays for harm)?

Agent governance is the preventive layer: the identity controls, permission scoping, audit trails, and human oversight mechanisms that determine what an agent is actually allowed to do and how its behavior gets monitored and constrained in real time. Agent liability is the consequential layer: the legal question of who bears financial and legal responsibility after harm has already occurred. They're related but distinct — a company can have strong governance and still face liability if, despite good controls, an agent causes harm within its authorized scope; conversely, weak governance dramatically increases both the likelihood that harm occurs and the difficulty of defending against a liability claim afterward, since poor governance tends to leave little documentation to demonstrate reasonable care was exercised. The practical relationship is that strong governance is your best defense in a liability dispute, even though it isn't a guarantee against ever facing one; regulators and courts across the frameworks reviewed here consistently treat documented governance effort as a meaningful factor in how liability gets assessed.

Why do regulators worry about AI agents inheriting a builder's or admin's credentials?

This is the "maker mode" problem described in Obsidian Security's 2026 research, and regulators worry about it because it defeats nearly every other governance control before it even gets a chance to work. If an agent runs under its builder's or an admin's existing credentials rather than its own scoped identity, there's no way to distinguish the agent's actions from that person's own actions in any log, audit trail, or after-the-fact investigation. That means excessive permissions go undetected (because they're masked by the human's already-broad access), unusual or harmful agent behavior looks identical to normal human activity, and, critically for the liability questions covered elsewhere in this piece, a company loses the ability to demonstrate exactly what the agent did versus what a human did, which matters enormously when trying to establish what happened after an incident. It's a convenience shortcut at build time that becomes a serious governance and evidentiary liability later.

Should enterprises treat every AI agent as a named identity with its own audit trail?

Yes. This is the clearest, most consistent recommendation running across 2026's major governance guidance, from Singapore's IMDA framework's explicit identity-and-audit-trail requirement to NIST's diagnosis of the opposite failure mode as the core problem needing correction. A named identity means the agent has its own credential set, distinguishable from any human account, scoped specifically to what that agent's function requires. An audit trail means every consequential action the agent takes is logged in a way that's attributable specifically to that agent, reconstructable after the fact, and reviewable on a schedule rather than only when something has already gone wrong. This isn't a burdensome extra step reserved for high-risk agents only — treating it as the default baseline for every deployed agent, regardless of how low-risk it initially seems, is what prevents the scope creep and blind spots that regulators across multiple jurisdictions have specifically flagged as the pattern behind real incidents.

What obligations does the EU AI Act place specifically on high-risk autonomous agents versus simple chatbots?

The EU AI Act applies a risk-tiered structure, and where a given AI agent falls within that tiering depends on its specific use case and the potential consequences of its actions, rather than on the fact that it's "an agent" categorically. A simple chatbot answering general customer questions from a narrow knowledge base typically sits at a lower risk tier with comparatively lighter obligations, primarily transparency requirements, like making clear to users that they're interacting with an AI system. An autonomous agent operating in a context the Act treats as high-risk (certain employment decisions, credit and financial access decisions, and other categories the Act specifically enumerates) faces substantially heavier obligations: documented risk management processes, human oversight mechanisms, technical documentation, and, critically for the liability questions this piece covers more broadly, the kind of audit trail and record-keeping that would also help demonstrate compliance if a liability claim arose separately under the Product Liability Directive. The practical lesson is that classification by use case and consequence, not by technical architecture, determines the obligation level.

Is there a dedicated Chinese law on AI agent liability, distinct from its AI Agents Framework oversight guidance?

No dedicated agent-liability statute distinct from China's AI Agents Framework was found in the sources reviewed for this piece, per Rimon Law's July 2026 reporting on China's regulatory developments. China's framework, effective 15 July 2026, is structured as oversight guidance — elevated scrutiny requirements for agents in sensitive sectors, organized across nineteen identified application scenarios — rather than as a liability-assignment statute in the way the EU's Product Liability Directive or the US's evolving case law and statutes function. This mirrors a broader pattern in China's AI regulatory approach generally: administrative oversight and sector-specific compliance requirements tend to lead, with liability questions addressed through China's existing general civil and tort law framework rather than through AI-specific liability legislation. Businesses operating agentic AI in China should expect compliance obligations to run primarily through the oversight framework's requirements rather than through a distinct liability statute, at least as of the most recent 2026 reporting reviewed here.

Does Australia have any specific AI agent liability rules as of 2026?

No Australia-specific reporting on AI agent liability rules was identified in the research underlying this piece. That's a notable gap rather than evidence that Australia is inactive on AI policy broadly — Australia has been engaged in AI governance discussions more generally — but as of the most recent 2026 sources reviewed here, no dedicated, agent-specific liability framework distinct from the more developed responses in other regions (the US's no-legal-personality principle, the UK's governance-first model, the EU's revised Product Liability Directive, Germany's existing tort and producer liability law, and China's sector-specific oversight framework) had surfaced. For a business operating agentic AI in the Australian market, the practical posture is to default to the same governance discipline recommended across every other jurisdiction covered here — named identity, scoped access, audit trails, accountable individuals — since that discipline tends to satisfy whatever framework eventually does get formalized, rather than waiting for Australia-specific rules to clarify before building governance in.

What should a company's incident-response plan look like if an AI agent causes a "serious incident" under the EU AI Act?

While the specific procedural requirements depend on an agent's risk classification under the Act, the general shape of an adequate incident-response plan for a high-risk autonomous agent should include a few things consistently: a clear internal definition of what counts as a "serious incident" for that specific agent's use case, a named individual or team responsible for the initial response (mirroring the UK's emphasis on named, accountable individuals with authority to halt a deployment), a pre-established process for immediately constraining or disabling the agent's scope while an incident is investigated, and documentation practices robust enough to reconstruct exactly what the agent did, why, and under what authorization, which matters both for regulatory reporting obligations and for any liability claim that might follow separately under the revised Product Liability Directive. Building and rehearsing this plan before deployment, rather than drafting it reactively during an actual incident, is consistently what distinguishes organizations that handle these situations well.