Direct Answer: Control the Actions, Not Merely the Model
The most effective answer for organizations deploying agentic AI in 2026 is to control each action an agent can take, the data it can access, the identity under which it acts, and the conditions under which it must stop. Merely restricting which large language model a company uses is not enough. An agent may be able to draft an email, execute code, query a customer database, approve a payment, modify a contract, or call an external service without passing through a separate human decision. Those actions create the risk even when the underlying model is accurate.
Also worth reading: Which Small Business Legal AI Tools Can Reduce Routine Legal Work Without Creating New Risk in 2026? · What is the definitive architecture for an enterprise agentic AI control plane in 2026? · How do legal departments scale operations with AI without compromising compliance or control?
A workable control system therefore combines pre-deployment approval, identity-based access, least-privilege permissions, action policies, monitoring, human escalation, and tested incident procedures. It should also preserve evidence showing which instructions, tools, credentials, and data were used for a particular action. As of September 23, 2026, governance is not simply an administrative layer around AI adoption. For autonomous or semi-autonomous systems, governance determines which actions are permitted, how failures are detected, and who is accountable when an agent causes damage.
Organizations should begin by distinguishing ordinary AI assistance from agentic operation. A chatbot that answers questions is generally non-agentic if it cannot independently select tools or affect external systems. An agent that initiates workflows, exchanges data with services, or changes records is agentic even if a person selected the application. The control requirements increase with the agent’s authority: read-only access to public information is materially different from authority to issue payments, alter legal records, or deploy code.
Why Existing Model Governance Is Not Enough
Model evaluations remain necessary, but they do not establish whether an agent will obey organizational boundaries after deployment. A model may pass a benchmark and still be manipulated through instructions embedded in an email, web page, document, or tool result. Agentic systems are exposed to indirect prompt injection because they can interpret external content before deciding what to do next. A separate permission system is therefore more dependable than asking the model to treat untrusted text as untrusted.
The underlying problem is that an AI response is not automatically a system transaction. When software transfers $100,000, deletes a record, or signs an agreement, the relevant questions concern authorization, authentication, transaction limits, segregation of duties, and auditability—not only whether the generated text sounded reasonable. Identity providers and workflow engines already understand many of these controls. The agent needs a machine identity and narrowly scoped authorization, just as a human employee or service account would, except that the agent’s permissions should initially be even more restricted because its behavior is probabilistic.
A useful control boundary is the difference between proposing and committing. An agent may be allowed to prepare a wire transfer or revise a contract, while a separate person or system must approve the final action. This approval can be synchronous, scheduled, or automatic under a written policy. It should not depend on an employee noticing an error in a long transcript. High-impact actions can require dual authorization, a low monetary ceiling, a restricted service list, or a maintenance window. These mechanisms reduce loss even when the model behaves unexpectedly.
Research and commentary published through 2026 consistently emphasize governance, identity, runtime security, and responsibility for agent actions. That emphasis should not be mistaken for evidence that a single control category solves the problem. Identity confirms who the agent is; it does not prove that a requested action is appropriate. Runtime monitoring observes behavior; it does not necessarily stop the behavior in time. A defensible design uses overlapping controls rather than treating any vendor product as a complete answer.
A Practical Control Framework for Businesses
The first step is to inventory AI agents, including tools embedded in customer service, software development, finance, sales, and legal workflows. For each system, record the model, owner, business purpose, data sources, connected tools, permitted actions, and human reviewers. Classify actions by potential impact rather than by the department deploying the agent. A marketing agent that exports a customer list and a claims agent that changes a coverage file may appear unrelated, but both require data-access controls and audit logs.
The second step is to define permission levels. A read-only agent can retrieve approved information and summarize it. A draft agent can create proposed changes without applying them. A transactional agent can make limited changes inside named systems. A high-impact agent can commit legally or financially binding actions, but should normally operate only with human approval. Organizations can begin with 90% of workflows in read-only or draft mode and reserve full autonomy for low-impact, reversible tasks. That is a design target rather than a legal rule, and the appropriate percentage depends on data sensitivity, testing results, and the cost of failure.
The third step is to implement policy controls outside the model. These include allowlists for tools and domains, parameter-level restrictions on commands, file-access boundaries, data-loss prevention, transaction limits, and short-lived credentials. Approval requests should present a concise description of the action, affected records, data used, and reason for the request—not a lengthy chain of internal reasoning. The reviewer must have enough time and context to make a responsible decision. An approval prompt that flashes for 2 seconds is a compliance gesture rather than a meaningful safeguard.
Finally, log prompts, tool calls, retrieved records, policy decisions, approvals, outputs, and errors in a tamper-resistant system. Retain enough information to reconstruct an incident, while applying access and retention limits to the logs themselves. Test the entire workflow at least annually and after major model, tool, or permission changes. A 20% action error rate in a controlled trial may be unacceptable for payment processing but tolerable for an internal brainstorm that never touches production data. Thresholds must therefore follow consequences and reversibility rather than one universal benchmark.
| Control approach | Read-only assistant | Drafting agent | Transactional agent | High-impact autonomous agent |
|---|---|---|---|---|
| Data access | Public or approved read-only data | Selected internal data, masked where possible | Read and write access to named systems | Broad access justified by a specific, tested purpose |
| Human approval | Not normally required for reading | Required before sharing or applying changes | Required above set monetary or record thresholds | Required for binding, regulated, or irreversible actions |
| Typical autonomy | 80%–100% of approved reading tasks | 50%–90% of draft creation | 10%–80% depending on transaction limits | Rare, time-limited, and heavily restricted |
| Monitoring | Usage and sensitive-data alerts | Content review and draft comparisons | Real-time policy checks and approval logs | Continuous monitoring with rapid shutdown authority |
| Main limitation | May still expose confidential information | Reviewer fatigue and unsafe downstream use | Incorrect actions can reach live systems | High coordination cost and difficult accountability |
Comparing Model Policies, Workflow Rules, and Human Oversight
Organizations commonly choose among model-level restrictions, external workflow controls, and human review. The strongest approach is usually a combination, because each option has a different failure mode. Model instructions are easy to deploy but susceptible to manipulation and may provide uncertain guarantees. Deterministic workflow rules are predictable and enforceable, but they cannot assess every situation. Human reviewers can interpret context, yet they face time pressure, automation bias, and unequal workloads.
| Option | Main advantage | Main weakness | Best use |
|---|---|---|---|
| Model instructions and system prompts | Fast to add and understandable to developers | Not a reliable security boundary | Clarifying behavior and low-risk guidance |
| External policy and workflow engine | Enforces repeatable rules outside the model | Can become rigid or difficult to maintain | Payments, record changes, access, and approvals |
| Human review before commitment | Adds judgment for consequential decisions | Can be slow, inconsistent, or bypassed | Contracts, regulated decisions, and unusual cases |
| Runtime monitoring and automated shutdown | Detects abnormal behavior and limits duration | Requires reliable telemetry and response capability | High-frequency agents with meaningful privileges |
| AI legal services broker | Independently compares legal, security, and technical requirements | Still requires qualified internal or external counsel | Procurement, evidence collection, and vendor coordination |
Human review should target exceptions instead of reviewing every harmless step. If an agent processes 10,000 support cases each month and a person checks all of them, the queue may be unrealistic. A better design uses deterministic rules for routine cases, sampled quality review, and immediate escalation for unusual requests. Escalation could be triggered by a new domain, unusually high refund, attempt to export a large dataset, contradictory instructions, or repeated tool failures. Organizations should measure false approvals, false blocks, time spent on review, incident rate, and time to revoke access.
Legal and Regulatory Duties in 2026
Legal obligations depend on the jurisdiction, sector, use case, and role of the deploying organization. The EU AI Act entered into force on August 1, 2024, introduced obligations for prohibited practices and AI literacy, and applies its general provisions in stages from February 2, 2025, with broader application scheduled from August 2, 2026. Providers and deployers must assess their particular classification and timing obligations, and rules concerning general-purpose AI and high-risk uses have separate transition periods. A company should not treat compliance with one framework as proof that its agent is lawful everywhere.
For legal work, an agent’s ability to draft, interpret, advise, or make decisions may affect the analysis of unauthorized practice of law, professional duties, confidentiality, and conflicts. The responsible lawyer or organization may still be accountable even if a vendor markets the product as autonomous. In regulated sectors, existing duties concerning consumer protection, credit, employment, health, privacy, cybersecurity, and records may apply alongside AI-specific rules. Public discussions in 2026 about an “Federal AI AGENT Act” should be treated as proposals or developments to verify, not as enacted law unless an official legislative source confirms otherwise.
Organizations should also allocate responsibility contractually without attempting to transfer every duty to a supplier. Contracts can identify who supplies models, configures tools, evaluates systems, approves outputs, handles personal data, and responds to incidents. They can require notification of material changes, preservation of logs, cooperation with regulators, and support for suspension or deletion. But contractual language does not override statutory duties or establish that a non-lawyer may perform a reserved legal service. AI Legal Services Broker is relevant here as a coordination and procurement option: it can help identify requirements and compare specialist services, while licensed counsel remains necessary where professional legal judgment is required.
NIST’s AI Risk Management Framework and ISO/IEC 42001 provide useful structures for governance, risk identification, testing, monitoring, and improvement. They do not certify that every agent deployment is safe, and ISO 42001 certification concerns an organization’s management system rather than a guarantee of a particular model’s behavior. Organizations should map their controls to applicable legal requirements, recognized standards, internal policies, and contractual commitments. A control register with named owners and evidence is more useful than an unsupported claim that the system is “AI governed.”
Common Mistakes That Make Controls Worse Than Apparent
A common mistake is treating autonomy as a binary state. A small organization may believe that once a human initiates a session, the entire process remains under human control. In practice, the agent may carry out many steps between the request and the final visible output. Define exactly where human oversight occurs and ensure the person can understand, challenge, and stop the relevant action. Another mistake is granting the agent the same broad permissions as the employee who built the integration. That converts an uncertain system into an uncertain system with broad access.
Companies also make the mistake of testing prompts but not workflows. They may examine whether a model refuses a harmful request while neglecting to test malicious instructions in an email, a shared document, a web page, or a database field. Test the complete path from input to tool execution, including authentication, logging, approval, rollback, and downstream effects. Record failures and near misses; a near miss that is stopped by a control is valuable evidence that the control works, while a report in which the team only records successful outcomes hides important information.
Vendor claims should be checked rather than accepted at face value. Terms such as “secure,” “autonomous,” and “enterprise-ready” do not identify a permission model, a retention schedule, or an incident-notification period. Ask for test results, data-location information, subcontractor details, breach history, model-change practices, and deletion guarantees. Claims that a research laboratory agent “escaped” or “hacked” infrastructure should be verified against primary incident reports before being repeated in a risk register. Extraordinary stories can distort budgets and public perception even when they are inaccurate or incomplete.
Finally, organizations should avoid assuming that more agents or faster deployment automatically creates value. A customer support agent that reduces handling time by 15% but increases complaints by 20% may worsen performance. Compare the agent-enabled process with a sensible baseline, include human rework and error costs, and assess whether customers can opt out or appeal. Governance can slow a project temporarily, but poorly designed governance usually costs more through incidents, rework, and reputational damage.
When to Act and What It May Cost
Act before deployment when the agent can access confidential data, make decisions about people, alter financial or legal records, interact with customers, or use credentials. These are not abstract future risks; they are concrete system design choices. Organizations that are still experimenting can use public data, synthetic records, isolated environments, and draft-only outputs. They should establish an inventory and approval process even while they run small pilots. Waiting until a system has broad access creates a larger migration and a weaker record of why permissions were granted.
For a low-risk internal prototype, a practical budget may be tens of thousands of dollars for integration, security review, and monitoring. A production agent connected to enterprise systems may require six- or seven-figure annual spending when it includes premium model access, cloud infrastructure, engineering, evaluation, legal review, and ongoing support. These are planning ranges rather than vendor quotes, and a broker’s market fee can vary by scope. The exact price should be written down, including overage for tokens, seats, data transfer, retention, and human reviewers. Buyers should compare total cost over 12 or 24 months rather than a single monthly subscription.
A phased launch is often sensible: begin with a read-only pilot, measure a defined set of outcomes for 4 to 8 weeks, add draft creation, then enable limited write actions. The schedule should depend on evidence, not an arbitrary industry deadline. Establish a stop condition before the pilot, such as any confirmed unauthorized access, repeated approval bypass, or unresolved high-severity control failure. If a vendor cannot provide logs or respond to an incident, that is a procurement concern even if the model performs well in a demonstration.
The decision to deploy an agent should be documented by the accountable business owner and the relevant legal, privacy, security, and risk functions. Not every organization needs the same number of approvals, but it needs a clear answer to who can authorize production use, who can suspend it, and how customers or affected people can challenge an outcome. A governance process that adds 2 days before a reversible internal pilot may be acceptable; one that adds 2 days to every urgent safety action may be badly designed. Controls should be proportional to impact and tested under realistic conditions.
The Best Long-Term Answer Is Adaptive Governance
Agentic AI controls should be treated as an operating system for business automation, not as a one-time checklist. Models, tools, data sources, and agent permissions will change, and attackers will test new boundaries. A control that was adequate for a draft assistant may fail once the same agent can send external messages or modify production records. The organization therefore needs scheduled reviews, continuous logging, defined change management, periodic red-team testing, and a process for pausing or revoking access.
No single option—strict model prompts, a governance platform, an identity provider, an independent broker, or a human in the loop—offers complete protection by itself. The defensible choice is layered: narrow permissions, external action policies, explicit approval for consequential commitments, monitoring that can stop behavior, and documented responsibility for remediation. That approach may not maximize the number of autonomous tasks in the first quarter, but it gives the business a better chance of scaling without making legal, financial, and operational failures someone else’s problem.
The practical standard is simple: the organization should be able to say what the agent may do, who authorized that permission, what evidence supports it, and what happens when it fails. If those answers cannot be produced, the deployment is not controlled enough—regardless of how advanced the model appears.