An agent that reads a process and an agent that changes a process carry different governance weight, even when they share the same model. A capture agent that watches a controller close the books produces an observation, and the worst case for a wrong observation is a bad recommendation a person reviews before acting on it. An agent that posts the journal entry, releases the payment, or sends the dunning letter produces a state change in a system of record, and the worst case is money out the door or a regulator's question with the company's name on it. Once an agent acts, the governing question stops being whether the model is accurate on average across a test set, because an average tells you nothing about the specific entry it posted at 11pm on the last day of the month. The question becomes whether that one action was logged, attributable to a decision, reversible if it was wrong, and subject to a human's approval where the stakes warranted one. That is a narrower and more answerable question, and three published frameworks now define what an operator should require before granting an agent the right to act.
What the frameworks require, briefly
The EU AI Act, Regulation (EU) 2024/1689, carries enforcement, which is what separates it from the other two. For systems it classifies as high-risk, it requires a risk-management process maintained across the system's life (Article 9), technical documentation sufficient to assess conformity (Article 11 and Annex IV), human oversight designed into the system from the start (Article 14), and post-market monitoring after deployment (Article 72). The high-risk obligations were due to apply from August 2, 2026, until the simplification package the European Parliament approved in June 2026 deferred them to December 2, 2027 for stand-alone high-risk systems. The penalty ceiling for the most serious violations is the higher of 35 million euros or seven percent of worldwide annual turnover. Whether a given finance or operations agent falls inside the Act's high-risk list is a legal question specific to the use, and we will return to it. The Act's structure (documentation, oversight, monitoring) holds regardless of classification, and it is a sensible bar to build to.
The other two frameworks are not laws and impose no fines, which is what makes them useful as engineering scaffolding. The NIST AI Risk Management Framework, published by the US National Institute of Standards and Technology as AI 100-1 in 2023, with a Generative AI Profile (AI 600-1) following in 2024, organizes the same goals into four functions: Govern, Map, Measure, and Manage. Govern sets the policy and accountability, Map identifies where the system can cause harm, Measure quantifies how it actually behaves, and Manage acts on what the measurement shows. ISO/IEC 42001:2023 takes those goals and makes them auditable. It is the first certifiable management-system standard for artificial intelligence, the AI counterpart to the ISO 9001 quality standard a manufacturer already knows, with ISO/IEC 42006:2025 setting the rules for accrediting the auditors who certify against it. A certificate is not a guarantee that an agent behaves well. It is evidence that a process for governing the agent exists and is being followed, which is what a procurement team or a PE operating partner needs to see before signing.
Excessive agency is the failure mode to name
The OWASP Foundation, the body behind the long-standing web-security list, publishes a Top 10 for Large Language Model Applications, updated for 2025, and one entry on it is the specific risk that separates an acting agent from a reading one: excessive agency. An agent has excessive agency when it holds more permission, more functionality, or more autonomy than the task in front of it requires. An agent built to email a customer about an overdue invoice does not need write access to the payments ledger, and an agent that reconciles a bank feed does not need the ability to delete records. The same list names prompt injection, where an attacker plants instructions inside the data the agent reads, and sensitive-information disclosure, where the agent leaks something it should have kept. Prompt injection is dangerous in proportion to agency, because an injected instruction can only do what the agent is permitted to do, so capping permission caps the exposure of the attack. Naming excessive agency as a category does the useful work of moving the conversation from whether the model is safe to what exactly the agent is allowed to do, which is a question an engineer can answer with a permission scope.
Translating the frameworks into four controls
The frameworks converge, and they translate into four controls an operator can inspect. The first is an append-only action log. Every state-changing action the agent takes is written to a record that cannot be silently edited, capturing what was done, when, against which record, on what input, and which model decision triggered it. This is the literal mechanism behind Article 11's documentation and NIST's Measure function, and it is what makes an action attributable after the fact, the same property what a capture agent records gives you on the observation side and the same lineage the employee-monitoring laws that govern an observation agent demand.
The second is scoped permissions, the direct answer to excessive agency: the agent gets exactly the access its task requires and nothing adjacent, enforced in the system it writes to rather than requested in a prompt. The third is reversibility by default for state-changing operations. Where the underlying system supports it, an action is structured so it can be undone, a posted entry reversed, a queued payment held before it clears, so that a wrong action is a recoverable event rather than a permanent one. The fourth is a human approval step bounded by a value or risk threshold. Low-value, low-risk, high-confidence actions run unattended, and anything above the line routes to a person before it commits. This is Article 14's human oversight rendered as a number an operator sets, and it is the control that lets autonomy and caution coexist instead of forcing a choice between them. Together the four are also what makes drift visible after launch, which is the subject of monitoring an agent after it ships.
A reasonable counter, answered
A reasonable counter is that this is governance overhead for a problem accuracy will eventually dissolve, that as models improve, error rates fall, and an elaborate control surface becomes a cost protecting against a failure mode that has mostly gone away. There is something to the premise. Models do improve, and the unattended threshold should rise as measured reliability rises, which is the entire point of setting it as a number rather than a fixed rule. But the controls are not priced against the average error rate. They are priced against the cost of a single wrong action that touches money or a regulatory record, and that cost does not fall just because the error became rarer. A payment released to the wrong account is the same loss at a one-in-ten-thousand rate as at one in a hundred. The frameworks exist because the consequence of the tail event, not the frequency of the typical one, is what sets the requirement, and that is also why the regulatory trajectory for enterprise AI agents points toward more documentation of actions, not less.