The three reference points most enterprises use for AI governance — the EU AI Act, the NIST AI Risk Management Framework, and ISO/IEC 42001 — give no operative definition of an "agent" or a dedicated model for autonomous, multi-step AI systems. The AI Act defines an "AI system" broadly enough to cover systems that act with autonomy, but it does not provide an agentic-AI accountability model; NIST's RMF 1.0 discusses autonomy and human oversight without an agent-specific treatment; and ISO/IEC 42001 supplies a management-system wrapper, not an operating model for agents. They were written for AI conceived as tools that produce outputs, not as actors that take actions. Autonomous agents differ in kind: they act on external systems, access tools dynamically, execute multi-step plans in which errors cascade, maintain persistent memory that can be manipulated, and delegate across agent boundaries in ways that fragment accountability.

Why it matters: You cannot govern with a framework by pointing at the clause about the thing you are doing, because the clause does not exist. Until agent-specific guidance and standards land, enterprises must derive agent controls from the principles of the frameworks — human oversight, risk management, auditability — and apply them to behaviours the frameworks never described. That derivation is governance work that falls on you, not on Brussels or NIST. Watch: CEN-CENELEC harmonised standards and the AI Office's 2026 guidance for the first official agent vocabulary. Source: arXiv — AI Agents Under EU Law · Zenity — Deploying agentic AI under EU & UK regulations

The AI Act assigns obligations through the provider/deployer distinction across Articles 16–29, with value-chain and role-transformation logic layered on top (notably Article 25). The structure works for a system deployed into a defined context to do a defined thing. It strains when an agent becomes a tool-selector at runtime: tool selection, delegation, and memory-driven behaviour make it harder to show who controlled the system, who authorised the action, and whether the deployment stayed within its intended purpose. The roles were not designed for a component that assumes new roles during execution.

Why it matters: This is the structural reason agent accountability is hard, not a technicality. If your compliance model assigns AI Act obligations by asking "are we the provider or the deployer?", that question has an unstable answer for an agent that acts autonomously. The practical fix is not to wait for the Act to be amended; it is to impose a governance layer that fixes accountability by design — a named human owner for every agent, regardless of how the legal roles resolve. Source: EU AI Act — Article 25 (value chain responsibilities) · Medium — Agentic tool sovereignty: the AI Act problem nobody saw coming

When an autonomous agent takes an action that causes harm — executes a bad trade, sends an unauthorised communication, modifies critical data — the liability question is genuinely open: is it the model developer, the deploying organisation, the instructing user, or the agent itself? The agent has no legal standing, so liability must land on a human or corporate party; but the Act's text does not cleanly assign it for autonomous action, and case law does not yet exist. This is the accountability vacuum agents create.

Why it matters: Vacuums get filled by whoever is closest when something goes wrong — usually the deploying enterprise, because it is the identifiable party with assets. Assuming the model provider carries the liability for what your agent did with its autonomy is an unsafe default. Until the liability picture settles, the deploying organisation should assume it is accountable and govern accordingly: constrain authority, require oversight at consequential thresholds, and keep the evidence to show control. Source: The Future Society — How AI agents are governed under the EU AI Act · arXiv — AI Agents Under EU Law

A recurring enterprise error is to file agents under Article 50 transparency — "it's a chatbot, we'll disclose it's AI" — and stop there. But high-risk status follows the use case, not the architecture: an agent operating in an Annex III domain (critical infrastructure, employment, essential services, law enforcement, justice, and the rest) or as a safety component of a regulated product should be treated as high-risk until proven otherwise — triggering human oversight, logging and auditability, risk management, and conformity assessment. Transparency is a floor, not a ceiling, for an agent that acts rather than merely converses.

Why it matters: The classification determines the obligation set, and misclassifying an agent as a low-risk chatbot understates the governance you owe by a wide margin. The high-risk obligations are the heavy tier — deferred to December 2027 for stand-alone systems under the Omnibus, but the classification work and the control design should start now, because retrofitting oversight and audit into an agent already in production is far more expensive than building it in. Source: Salt Security — EU AI Act compliance: what high-risk systems must do · Nandann — EU AI Act compliance for autonomous agents: a CTO's guide

The EU AI Office has indicated its 2026 guidance will focus on high-risk classification, provider/deployer obligations, substantial modification, value-chain responsibilities, post-market monitoring, and Article 50 transparency. Every one of those themes is an agent pressure point: classification (are agents high-risk?), provider/deployer (the runtime breakdown), substantial modification (an agent that changes its own behaviour), and value chain (delegation across agents and tools).

Why it matters: This is a roadmap of where the regulator's attention is going, and it maps almost perfectly onto the hard problems of agent governance. "Substantial modification" is the one to watch: an agent that adapts, fine-tunes, or materially alters its own operation may trip the provision that turns a deployer into a provider — inheriting the heavier obligation set. Read the guidance agenda as a preview of the questions an auditor will ask about your agents. Watch: Publication of the substantial-modification and value-chain guidance — these define agent obligations more than any single article. Source: European Commission — Guidelines for GPAI providers · Artificial Intelligence News — Agentic AI's governance challenges under the AI Act

On January 22, 2026, Singapore's IMDA launched the Model AI Governance Framework for Agentic AI — the world's first governance framework aimed specifically at autonomous agents — and updated it on May 20 with case studies for multi-agent systems and third-party agents. Compliance is voluntary, but the framework is explicit that organisations remain legally accountable for their agents' behaviours and actions. It is built on four dimensions: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility.

Why it matters: When the first mover in agent-specific governance makes "humans remain legally accountable" the centre of gravity, that is a strong signal of where the EU and others will land — and it is exactly the point the AI Act's accountability model leaves unresolved for agents. European enterprises can borrow the template now rather than wait for a local equivalent: bound the risk, name the accountable human, build the technical controls, set end-user responsibility. Doing so pre-builds what the AI Act's oversight principles will require of agents. Source: IMDA — Singapore launches Model AI Governance Framework for Agentic AI · Bird & Bird — Singapore introduces new framework for agentic AI

On February 17, 2026, NIST's Center for AI Standards and Innovation launched an AI Agent Standards Initiative, and its NCCoE published a concept paper — "Accelerating the Adoption of Software and AI Agent Identity and Authorization" — that puts authentication and identity infrastructure at the centre of secure human-agent and multi-agent interaction. The framing addresses a critical gap: how organisations authenticate and govern agents that act autonomously on behalf of users. In enterprise terms, it points to one immediate control: stop letting agents disappear behind shared service accounts.

Why it matters: This is a control you can fix this quarter, independent of any regulation. If your agents authenticate as generic service accounts, your audit trail cannot attribute actions to specific agents or to the humans who authorised them — which means you cannot demonstrate oversight to a regulator or reconstruct an incident. Promoting agents to first-class identities is the foundational move; almost every other agent control depends on it. Source: NIST — AI Agent Standards Initiative · NIST NCCoE — Accelerating adoption of AI agent identity and authorization (concept paper)

On June 30, the US Department of Commerce lifted the export controls it imposed on June 12, ending a 19-day global shutdown of Anthropic's Fable 5 and Mythos 5. Fable 5 returned worldwide on July 1 across Anthropic's platforms; Mythos 5, the less-restricted sibling, is being restored to a set of trusted US organisations after government approval. The trigger had been an Amazon-reported technique for bypassing Fable 5's safeguards that could prompt the model to identify a software vulnerability and, in one case, generate exploit-demonstration code. In its redeployment post, Anthropic said it had trained an improved safety classifier that blocks the specific technique in over 99% of cases, routes blocked requests to Opus 4.8, and — a real trade-off — flags more benign coding and debugging requests as a result.

Why it matters: The mundane ending does not undo the lesson — it sharpens it. A frontier model was removed from the global market for 19 days over a bypass that was ultimately handled with a classifier update. Enterprises that had a tested fallback rode out the shutdown; those that did not lost 19 days. The continuity risk was real regardless of how the capability question resolved. Keep the fallback discipline from the June 18 edition; the next suspension may resolve less tidily. Source: Anthropic — Redeploying Fable 5 · CNBC — Trump admin lifts export controls on Fable 5 and Mythos 5

An April 2026 IAPP commentary drawing on Stanford HAI research reports 17% growth in AI governance roles in 2025 — but flags that headcount growth is outrunning the maturity of the underlying governance programmes. More people carry AI-governance titles; fewer organisations have the runtime controls, audit infrastructure, and accountability models to back them. Agents widen this gap, because they demand controls (identity, authorisation lineage, reconstructable audit) that most programmes have not built.

Why it matters: Hiring a governance lead is not the same as having governance, and agents expose the difference fastest. The maturity gap is where enforcement risk concentrates: a well-staffed programme that cannot reconstruct what an agent did is exposed despite the headcount. Invest the next hire's budget in the audit and identity infrastructure the agents need, not only in another seat on the governance council. Source: IAPP — AI governance roles surge (Stanford HAI data) · Cyberhaven — How to build an agentic AI governance framework

Deep Dive

Autonomous agents are the deployment story of 2026. The frameworks meant to govern them don't define them. The gap between the two is where enterprise accountability now lives — and it is a gap you have to close yourself.

Two things happened at once, and their collision is the story. First, agents crossed from demo to production. Enterprises are now running systems that do not merely answer questions but take actions: select and call tools at runtime, execute multi-step workflows, hold memory across sessions, and hand work to other agents. Second, the AI Act's enforcement machinery came fully online for 2026, with the AI Office signalling that its guidance will address high-risk classification, provider/deployer obligations, substantial modification, value-chain responsibilities, and post-market monitoring.

The collision is that the second thing was designed without the first in mind. The AI Act, like the NIST AI RMF and ISO/IEC 42001, treats an AI system as a configured tool that produces outputs within a defined use. None of them give a dedicated operating model for an autonomous agent that reconfigures its own behaviour mid-task. So enterprises are now deploying a pattern the frameworks do not describe, into an enforcement environment that is actively tightening. The definitional gap is not academic; it is the space in which real obligations have to be discharged with no dedicated clause to point to.

The gap concentrates in one place: accountability. The AI Act's entire obligation structure hangs on knowing who the provider is and who the deployer is. For a static system, that is answerable. For an agent, it gets harder. When an agent selects a tool it was not pre-configured to use, the provider/deployer split does not cleanly resolve who controlled the system or authorised the action. When an agent takes a consequential action autonomously and causes harm, the liability does not cleanly attach to the developer, the deployer, the user, or the agent — because the agent has no legal standing and the others did not directly choose the action.

This matters because vacuums get filled by proximity. When something goes wrong and the legal question is unsettled, the party that gets held to account is usually the identifiable one with assets and a role in the harm — which, for an agent you deployed, is you. The comfortable assumption that "the model provider is responsible for what the model does" does not survive contact with an agent that did something autonomous inside your environment, under your instruction, with your data, calling your tools. The deploying enterprise should assume it is accountable until the law says otherwise, because the alternative is discovering the answer during an incident.

Three failure modes, each rooted in treating an agent like a conventional system.

First, dynamic tool selection fragments the audit trail. A conventional system's actions are bounded by its configuration; you can enumerate what it can do. An agent's actions are bounded only by the tools it can reach and the plan it constructs at runtime, which means the set of things it might do is not fully knowable in advance. Governance built on "here is what the system is configured to do" fails, because the agent's behaviour is emergent. The control that works is not pre-enumeration but attribution: every action tied to an agent identity and an authorising human, reconstructable after the fact.

Second, persistent memory is an ungoverned attack surface. Agents that carry memory across sessions can be manipulated through that memory — a poisoned instruction planted in one interaction that shapes behaviour in a later one. Most governance programmes have no concept of memory integrity, because conventional systems do not have manipulable persistent state in the same way. If your agents remember, your threat model has to include memory poisoning, and your audit has to cover what entered and shaped the memory.

Third, delegation across agents dissolves accountability unless identity is preserved through the chain. When agent A hands a task to agent B, which calls tool C, the accountability question is whose authority ran through that chain. If the agents share a service account, the chain is invisible: you see actions with no attributable actor. Shared service accounts are exactly the gap NIST's agent-identity work targets — and the single most common and most fixable failure. Preserve identity and authorisation through every delegation, or accept that you cannot answer "who did this."

The striking thing about the emerging agent-governance work — Singapore's IMDA model's insistence that humans stay accountable, NIST's focus on agent identity and authorisation, the enterprise security vendors — is how tightly it converges on the same enterprise controls: give every agent an identity distinct from any human or shared account; record the authority each action was taken under, through every delegation; and make the audit reconstructable at the level of data lineage, not just event logs. "Agent X accessed file Y at time Z" is not enough; you need what data was accessed, what happened to it, and where it went.

That convergence is a gift, because it tells you what to build before the EU AI Act's own agent guidance exists. Identity, authority, and reconstructable audit are not merely best practice; they are the operational form of the AI Act's own principles — human oversight (Article 14), logging and record-keeping (Article 12), risk management (Article 9) — applied to systems that act. Building them now is not speculative compliance; it is discharging obligations the Act already imposes in principle, in the only way that will work for agents. ISO/IEC 42001 supplies the management-system wrapper to document and demonstrate the whole thing to a regulator.

Start with an inventory: which agents are in production, what can each of them actually do, and whose authority does each act under. Then close the identity gap first — promote every agent from shared service account to a first-class identity — because every other control depends on it. Set human-oversight thresholds for consequential actions, build audit at the level of data lineage, and name one accountable human owner per agent. Do not wait for the guidance; build what every framework is converging toward, and you will be ahead of it when it lands. The matrix below is the instrument.

Complete one row per agent in production or pilot. The goal is that for every agent, you can name its identity, its authority, its limits, its oversight thresholds, its audit basis, its AI Act classification, and one accountable human. An agent with blanks in this row is an ungoverned agent.

How to use it: Sort by "consequential autonomous action = yes." Those rows are your priority — they are the agents most likely to be high-risk and most likely to create the accountability vacuum. Any priority row missing an identity, an audit-lineage basis, or a named owner is a finding to close before you scale that agent.

Before next Thursday, pick the most autonomous agent you have in production — the one that takes the most consequential actions with the least human review — and answer one question in writing: who is the single human accountable if it does something harmful? Reply to this email with how many agents you have in production.

Why this, not the other twenty things you could do: The Deep Dive argued that the AI Act's accountability model doesn't cleanly resolve where agents act autonomously, and that the vacuum gets filled by whoever is closest — usually you. Naming the accountable human is the one control that does not depend on the guidance being written, the standards being published, or the liability question being settled. It is the floor of agent governance, and most organisations have not laid it.

If you cannot name one person: That is the finding, and it is the most important one in this edition. An agent taking consequential actions with no accountable human owner is the exact configuration regulators and litigants will punish first. Assign the owner; it costs nothing and closes the largest gap.

If you skip it: The agent keeps acting, the deployment scales, and the first time the accountability question gets asked in earnest is when something has already gone wrong — at which point "we assumed the vendor was responsible" is not an answer anyone will accept.

Until next Thursday, João

OnAbout.AI delivers strategic AI analysis to enterprise technology leaders. European governance lens. Vendor-agnostic. Actionable.

If this landed in your inbox from a forward — subscribe here to get the full picture every week.