When AI Acts for Your Business: Who Is Legally Responsible for an Autonomous AI Agent?

Current through August 11, 2026

Artificial intelligence is moving beyond answering questions and preparing drafts. Businesses are beginning to deploy systems that can open applications, retrieve information, communicate with customers and vendors, update databases, place orders, publish content, call software tools, and execute multistep workflows.

That transition, from producing an answer to taking an action, creates a different category of legal risk.

What happens if an AI agent sends an unauthorized email, agrees to unfavorable terms, places an order, changes payment instructions, publishes false information, discloses confidential data, enters an outside computer system, or deletes an important record? Can the business avoid responsibility by saying that no person specifically instructed the AI to take that action? Does liability belong to the developer, the vendor, the company deploying the system, the employee who configured it, or several actors at once?

There is no single universal rule assigning responsibility for every act of autonomous software. Courts, regulators, businesses, and insurers are increasingly confronting these questions through familiar legal principles: agency, apparent authority, contract formation, negligence, computer access, privacy, confidentiality, intellectual property, consumer protection, vendor risk allocation, and reasonable supervision.

The technology may be new. The legal consequences of authorizing a tool to act for a business are not entirely new.

Business takeaway: A company should not give an AI system practical authority to communicate, purchase, modify, disclose, publish, or access on its behalf until it understands the legal authority that outsiders may perceive, the harm the system can cause, and the controls needed to prevent or contain unauthorized action.

Important Legal and Tax Notice

This Codex is provided by CorwinLaw, https://www.corwinlaw.net, for general educational and informational purposes only. It is not legal, tax, accounting, insurance, benefits, cybersecurity, investment, or financial advice.

Reading this Codex, visiting a website, or contacting CorwinLaw does not create an attorney-client relationship. An attorney-client relationship should arise only through a written engagement agreement accepted by CorwinLaw and the client. Do not send confidential or time-sensitive information unless and until CorwinLaw confirms that it represents you.

Laws, regulations, technologies, industry practices, and contractual requirements change. The legal effect of an AI system’s conduct depends on the facts, governing law, contracts, permissions, representations, industry, and jurisdictions involved. Businesses should obtain legal, cybersecurity, insurance, tax, accounting, and other professional advice appropriate to their particular circumstances before deploying an autonomous AI system or responding to an incident.

1. What Is an AI Agent?

The word “agent” is used inconsistently in the technology market. A vendor may describe a product as an agent, copilot, assistant, bot, automation, or intelligent workflow. The label does not determine what the system can do or whether it is a legal agent under common-law principles.

For practical purposes, an AI agent is a software system that can pursue an assigned objective by taking one or more actions, often using tools, data, credentials, or outside systems, with some ability to select the steps it will take.

An agent may be able to:

• Read emails, documents, websites, or database records;
• Decide which information appears relevant;
• Generate and send communications;
• Create or modify files;
• Call an application programming interface, or API;
• Enter information into business software;
• Search external systems;
• Schedule meetings;
• Place an order;
• Update customer or vendor records;
• Publish content;
• Create software code;
• Trigger another workflow; or
• Ask another AI system or sub-agent to perform part of the task.

An ordinary chatbot generally responds

A conventional chatbot usually produces text for a human to review. A person asks a question, receives an answer, and decides whether to use it.

AI-assisted automation recommends or prepares

An assisted workflow may retrieve information, prepare a document, or recommend an action, but a person must approve the final step.

An autonomous agent can act

An autonomous or agentic system may move from analysis to execution. It may select a tool, use stored credentials, communicate outside the organization, or change a business system without contemporaneous human review of every action.

The distinction is not merely technical. The legal risk changes when software moves from:

• Drafting an email to sending it;
• Recommending a vendor to placing an order;
• Summarizing a contract to proposing or accepting terms;
• Detecting an error to changing a database;
• Preparing marketing content to publishing it;
• Identifying a suspicious account to suspending access;
• Finding information to entering another party’s system; or
• Preparing a payment to initiating the transfer.

Practical test: Do not ask only whether the product is called an “AI agent.” Ask what it can read, decide, communicate, change, purchase, disclose, publish, access, and execute and what it can do without meaningful human approval.

2. “AI Agent” Is a Technology Term—Not Automatically a Legal Conclusion

Calling software an “agent” does not necessarily make it an agent under traditional agency law. Common-law agency generally concerns a relationship in which an agent acts on behalf of and subject to the control of a principal.

An AI system is not ordinarily treated as an independent legal person with its own assets, duties, intent, or capacity to bear a judgment. Legal responsibility is more likely to be evaluated through the conduct and relationships of the people and organizations that:

• Developed the system;
• Marketed it;
• Selected it;
• Configured it;
• Supplied data or tools;
• Granted credentials and permissions;
• Defined its objective;
• Integrated it into a workflow;
• Approved or failed to approve its actions;
• Monitored its operation;
• Received the benefit of its conduct; or
• Failed to respond after learning what it had done.

That distinction should remain clear throughout any legal analysis. An AI system may function as the mechanism through which a business acts without becoming a legal person or a traditional human agent.

3. Why “We Did Not Tell the AI to Do That” May Not Be a Complete Defense

A business may issue a narrow natural-language instruction while granting the system broad technical power. For example, management may tell the agent to “find cost savings” while giving it access to purchasing accounts, vendor communications, contract files, and payment systems.

If the agent takes an unexpected action, the legal analysis may consider more than the last sentence typed by the user. Relevant facts may include:

• The purpose for which the system was deployed;
• Its known capabilities and limitations;
• Credentials and permissions supplied by the business;
• Prior transactions the company accepted;
• The company email address or portal through which it communicated;
• Instructions embedded in workflows or system prompts;
• Vendor documentation and warnings;
• Whether a third party reasonably believed the communication was authorized;
• Whether the company received and retained a benefit;
• Whether the company promptly rejected or corrected the action;
• Whether the conduct was foreseeable; and
• Whether reasonable safeguards could have prevented it.

An internal instruction may help prove that the system acted outside its intended scope. But an undisclosed internal limitation does not necessarily control the rights of an outside party who reasonably relied on the company’s outward conduct.

A business should therefore align three forms of authority:

1. Intended authority: what management wants the agent to do;
2. Technical authority: what systems, credentials, and tools allow it to do; and
3. Perceived authority: what customers, vendors, employees, and other outsiders may reasonably believe it can do for the company.

4. Actual Authority, Apparent Authority, and Ratification

Traditional authority principles provide a useful framework, although their application to autonomous software remains developing and fact-specific.

Actual authority

Actual authority concerns what the business has authorized. In an AI deployment, evidence may include:

• Written policies;
• Configuration settings;
• System and developer instructions;
• Assigned objectives;
• Workflow rules;
• Approval thresholds;
• Access permissions;
• Purchase limits;
• Employee directions;
• Vendor implementation materials; and
• Prior management decisions.

A business should not rely on a policy that says “the agent may not contract” while configuring it to accept online terms, send purchase orders, or negotiate through an authorized company account.

Apparent authority

Apparent authority generally focuses on whether the principal’s manifestations could cause a third party reasonably to believe that the actor had authority.

Facts potentially creating that appearance include:

• Use of the company’s email domain;
• Communication through an authorized vendor or customer portal;
• A company title or signature block;
• Participation in an existing negotiation;
• Access to information ordinarily available only to authorized personnel;
• Prior similar transactions honored by the company;
• Company statements describing what the agent can do; or
• Failure to correct known misunderstandings.

The software’s unsupported assertion that “I am authorized” should not, by itself, create authority. The more difficult question is whether the business placed the system in a position that reasonably communicated authority to outsiders.

Ratification

Even if the initial act was unauthorized, a business may create additional risk if it knowingly:

• Accepts goods or services obtained through the transaction;
• Retains a financial benefit;
• Performs part of the agreement;
• Fails to object after learning the material facts;
• Uses information obtained through the act; or
• Treats the transaction as valid in later communications.

After an AI-agent incident, a business should evaluate quickly whether its conduct could be viewed as adopting or ratifying what occurred. Continuing to accept benefits while disclaiming the commitment may be inconsistent.

5. Can an AI Agent Form a Contract?

The use of an electronic system does not automatically prevent contract formation.

The federal Electronic Signatures in Global and National Commerce Act, commonly called the E-SIGN Act, generally provides that contracts and signatures may not be denied legal effect merely because they are electronic. It also specifically addresses electronic agents: a contract or record may not be denied legal effect solely because its formation, creation, or delivery involved one or more electronic agents, so long as the action is legally attributable to the person to be bound. See 15 U.S.C. § 7001.

The statute does not answer every question involving modern autonomous AI. It does show that “no human pressed the button” is not necessarily a complete answer.

Contract questions an AI transaction may raise

• Was there an offer and acceptance?
• Was the agent’s action legally attributable to the business?
• Did the counterparty reasonably understand that a commitment was being made?
• Did the system accept clickwrap or other online terms?
• Were transaction limits communicated to the counterparty?
• Did the agent make a material mistake?
• Did the counterparty know or have reason to know of the mistake?
• Did the business accept the benefits?
• Did a course of dealing make the transaction appear ordinary?
• Was a signature or writing required?
• Did the system agree to arbitration, indemnification, auto-renewal, data-processing, IP, confidentiality, or governing-law terms?
• Was consumer consent required for electronic records?

Mistake is not an automatic escape route

An AI system could misunderstand price, quantity, currency, delivery, specifications, or renewal terms. Whether the business can avoid the transaction may depend on contract law, the counterparty’s knowledge, allocation of automated-error risk, applicable statutes, and the business’s response after discovery.

Online terms can matter

An agent entering a portal, using an API, downloading data, or acquiring software may encounter terms of service. A company should determine whether the system may assent to terms and, if so, which terms or transaction values require legal or human review.

6. High-Risk Commitments an Agent Might Make

An AI agent may create business exposure without signing a formal contract. It could:

• Quote a binding price;
• Promise a delivery date;
• Accept a purchase order;
• Waive a fee;
• Offer a refund;
• Modify specifications;
• Extend a warranty;
• Agree to confidentiality;
• Accept an auto-renewal;
• Agree to arbitration or a forum-selection clause;
• Grant a license;
• Assign intellectual property;
• Provide an indemnity;
• Admit breach or fault;
• Approve a change order;
• Accept data-use restrictions;
• Confirm regulatory compliance; or
• Communicate acceptance through conduct rather than words.

Businesses should identify which commitments require human approval and enforce those limits technically, not merely through a written policy the system cannot reliably apply.

7. Negligence and Reasonable Supervision

When an AI agent causes harm, negligence principles may become relevant. A central question may be whether the business exercised reasonable care in selecting, configuring, testing, supervising, and controlling the system under the circumstances.

Relevant questions may include:

• Was the use case appropriate for an autonomous system?
• Was the potential harm foreseeable?
• Did the business understand the system’s material limitations?
• Were vendor warnings ignored?
• Were permissions broader than necessary?
• Was the system tested before receiving production access?
• Could it interact with untrusted external content?
• Were high-consequence actions subject to meaningful approval?
• Did the business monitor activity and investigate anomalies?
• Were repeated failures or near misses ignored?
• Could the system be stopped promptly?
• Were logs sufficient to reconstruct its conduct?
• Was sensitive data unnecessarily exposed?
• Did management continue deployment after learning of a dangerous condition?

The fact that an AI system produced an unexpected result does not automatically establish negligence. Nor does describing the conduct as an unpredictable “hallucination” automatically excuse it. The analysis will depend on foreseeability, severity, available precautions, industry practices, representations, and the actual controls used.

The standard of care is developing

There may not yet be a settled industry standard for every autonomous-agent use. Evidence bearing on reasonable care could include:

• Vendor documentation;
• Contractual commitments;
• Internal policies;
• Risk assessments;
• Industry frameworks;
• Regulatory guidance;
• Known incidents;
• Security testing;
• Insurance requirements;
• Prior warnings; and
• Practices used by similarly situated businesses.

A company that adopts a sophisticated AI policy but routinely ignores it may create damaging evidence that it recognized the risk and failed to implement the stated controls.

8. Computer Access and the CFAA

An AI agent may interact with external websites, APIs, cloud platforms, databases, customer systems, or vendor networks. If it enters an area it was not permitted to access, circumvents a barrier, uses compromised credentials, or continues after permission is revoked, federal and state computer-access laws may become relevant.

The federal Computer Fraud and Abuse Act, or CFAA, is not a general prohibition against every improper use of a computer. In Van Buren v. United States, the Supreme Court held that a person who had authorized access to a database did not “exceed authorized access” merely because he retrieved available information for an improper purpose. The Court focused on whether the person entered areas of the computer, such as files, folders, or databases, that were off limits.

For AI agents, important distinctions may include:

• Accessing publicly available information;
• Using valid credentials within their authorized scope;
• Entering a restricted area of a system;
• Circumventing authentication or technical barriers;
• Using stolen, shared, or improperly obtained credentials;
• Exploiting a vulnerability;
• Continuing access after express revocation;
• Exceeding the authorized scope of an API;
• Causing impairment, interruption, or other technological harm; and
• Merely violating a term of service without bypassing an access restriction.

“The agent did it” does not eliminate the access question

A business may face difficult questions if it supplied the credentials, deployed the agent, accepted the information obtained, ignored warning signs, or configured the system to pursue an objective through outside systems.

The legal analysis could differ if:

• The agent malfunctioned;
• A third party manipulated it;
• The vendor represented that access was authorized;
• The business deliberately sought restricted information;
• The system continued after receiving a cease-and-desist notice; or
• The agent crossed a technical boundary that the operator did not know existed.

Not every unauthorized or unwanted interaction creates CFAA liability. Even where the CFAA does not apply, contractual, trade-secret, privacy, trespass, state computer-crime, unfair-competition, or other claims may remain.

9. Prompt Injection and Manipulation by Outsiders

An autonomous agent may encounter external content that contains instructions. This creates the risk of prompt injection: content designed, or accidentally structured, to influence the agent’s behavior.

Potential sources include:

• Websites;
• Emails;
• Attachments;
• PDFs and documents;
• Support tickets;
• Database records;
• Calendar invitations;
• Images;
• Source code;
• API responses; and
• Messages from other agents.

A malicious instruction might attempt to make the agent:

• Ignore its operating rules;
• Reveal confidential information;
• Send data to an outside destination;
• Use credentials improperly;
• Change a payment address;
• Download malicious content;
• Contact an unauthorized recipient;
• Enter another system;
• Delete a record; or
• Conceal what it did.

This is not merely a technical concern. If a business gives an agent access to sensitive information and consequential tools while allowing untrusted content to influence its actions, a later dispute may ask whether reasonable safeguards were used.

Controls may include separating instructions from untrusted content, limiting tools, isolating sensitive data, requiring approvals, validating destinations, testing adversarial inputs, monitoring unusual activity, and preventing the agent from changing its own permissions.

10. Confidential Information and Trade Secrets

An AI agent may have broad access because it needs information to perform its assigned task. That access can create substantial confidentiality risk.

The agent might:

• Upload confidential information to an outside model or platform;
• Include trade secrets in a vendor or customer communication;
• Retrieve information from a restricted repository;
• Use one client’s or project’s information for another;
• Publish protected material;
• Combine data across tenants, departments, or affiliates;
• Store confidential information in logs;
• Send information to an unapproved subprocessor; or
• Incorporate another party’s confidential material into an output.

The business may be both a discloser and a recipient of protected information. It must consider obligations under:

• Nondisclosure agreements;
• Employment and consulting agreements;
• Vendor contracts;
• Trade-secret law;
• Professional duties;
• Data-room terms;
• Customer agreements; and
• Internal classification policies.

Trade-secret protection depends on reasonable measures

Businesses seeking trade-secret protection generally need reasonable measures to preserve secrecy. Giving an autonomous system unnecessary access, allowing data to flow to unknown providers, failing to restrict retention, or ignoring vendor training practices could complicate that showing.

The agent should not decide confidentiality by intuition

A model may infer that a document is public or harmless when it is not. Sensitive-data handling should rely on defined classifications, access controls, approved destinations, and technical enforcement.

11. Privacy and Customer Data

An AI agent can process personal information at a scale and speed beyond ordinary employee activity. It may retrieve, combine, infer, disclose, or act upon data in ways that were not contemplated when the information was collected.

Businesses should ask:

• What personal information can the agent access?
• Is access necessary for the assigned purpose?
• Does the use match the notice or consent provided?
• Does the agent create new inferences or profiles?
• Is sensitive information involved?
• Does data leave the business’s environment?
• Which vendors, model providers, and subprocessors receive it?
• Is the information used to train or improve a model?
• In what jurisdictions is it processed?
• How long are prompts, outputs, logs, and tool records retained?
• Can deletion, correction, access, and restriction requests be honored?
• Could the agent make a consequential decision about a person?
• What happens if it sends information to the wrong recipient?

An agent’s unexpected disclosure may trigger contractual duties, privacy-law obligations, regulatory reporting, consumer notice, or an incident investigation. The applicable analysis depends on industry, jurisdiction, data type, affected persons, and the circumstances of the disclosure.

Data minimization is a practical control

The agent should receive only the data reasonably needed for its task. Broad access “just in case” increases both security risk and potential legal exposure.

12. Intellectual Property, Publication, and Content Risk

A system that merely drafts content for review presents a different risk from one that publishes directly to a website, social-media account, advertising platform, software repository, or customer channel.

Autonomous publication may create issues involving:

• Copyright infringement;
• Trademark infringement;
• False endorsement;
• Defamation;
• Trade libel;
• Right of publicity;
• Misappropriation;
• Confidentiality;
• Advertising substantiation;
• Comparative claims;
• Regulated statements;
• License compliance; and
• Contractually restricted content.

An AI agent may also modify code, insert third-party components, or accept software-license terms. Businesses should control what repositories it can access, what code it can deploy, and whether human review is required before production release.

A label stating that content was AI-generated does not necessarily excuse infringement, deception, defamation, or breach of contract.

13. Misrepresentation, Consumer Protection, and Customer Communications

An AI agent speaking through a company channel may make statements that customers or vendors attribute to the business.

It could:

• Invent a product feature;
• Promise an unavailable discount;
• Misstate inventory;
• Guarantee a delivery date;
• Offer an unauthorized refund;
• Provide inaccurate legal, financial, or technical assurances;
• Conceal material limitations;
• Generate a fictitious testimonial;
• Make an unsupported performance claim;
• Misrepresent that a human approved the communication; or
• Fail to provide a legally required disclosure.

The company’s statement that “the AI made it up” may not resolve whether the message was deceptive, attributable to the business, or negligently supervised.

Customer-facing agents should use approved knowledge sources, disclose automation where required or appropriate, escalate specified topics, preserve communications, and avoid making commitments beyond defined authority.

14. Employment and Internal Decision-Making

Businesses may use agents to screen applicants, schedule interviews, rank candidates, monitor performance, recommend discipline, change access permissions, or generate employment communications.

These uses may implicate:

• Discrimination and disparate impact;
• Disability accommodation;
• Notice and consent;
• Automated-employment-decision laws;
• Employee privacy;
• Recordkeeping;
• Wage-and-hour issues;
• Labor law;
• Background-check requirements;
• Confidential medical or benefits information; and
• Authority to make or communicate employment decisions.

An agent should not independently hire, discipline, terminate, change compensation, deny an accommodation, or make another consequential employment decision unless the business has completed a careful legal and operational review and established meaningful human oversight.

15. Who Might Be Responsible?

Responsibility may fall on one or several actors under different legal theories.

The deploying business

The business may face exposure because it selected the system, granted authority, supplied credentials, placed the agent in a company workflow, benefited from its conduct, made representations to outsiders, or failed to supervise reasonably.

The developer or platform provider

Potential issues may involve defective design, inadequate warnings, security failures, misrepresentation of capabilities, breach of contractual commitments, or failure to correct a known vulnerability. Contractual disclaimers and liability limitations may significantly affect the analysis between the parties.

The implementation consultant or managed provider

A consultant may have configured permissions, integrations, system instructions, approval gates, or data access. Responsibility could depend on the agreed scope, professional obligations, representations, and whether the implementation departed from instructions or reasonable practices.

Employees and contractors

An individual may have ignored policy, expanded permissions, supplied an unsafe objective, shared credentials, bypassed approvals, or concealed an incident. The company may still face responsibility for conduct within employment or apparent authority, while preserving separate claims or disciplinary rights against the individual.

Third-party attackers or manipulators

An outsider may exploit prompt injection, compromised credentials, vulnerable integrations, or malicious data. The attacker’s responsibility does not necessarily eliminate questions concerning the deploying company’s or vendor’s safeguards.

Several actors at once

A single event may involve contract claims between the business and vendor, tort or statutory claims by affected third parties, regulatory duties, insurance coverage disputes, and contribution or indemnification claims among participants.

There is no automatic liability switch. Responsibility turns on facts, legal duties, causation, contracts, attribution, foreseeability, control, and the type of harm.

16. Vendor Agreements and Risk Allocation

An AI-agent agreement should be reviewed as an operational-risk contract, not merely a software subscription.

Topics may include:

• The approved use case;
• Representations about capabilities and autonomy;
• Prohibited uses;
• Implementation responsibilities;
• Permission and credential architecture;
• Security safeguards;
• Data ownership and permitted use;
• Whether customer data trains or improves models;
• Model providers and subprocessors;
• Confidentiality;
• Retention and deletion;
• Geographic processing restrictions;
• Audit and activity logs;
• Incident notification;
• Cooperation with investigations;
• Service levels and downtime;
• Accuracy disclaimers;
• Warranties;
• Intellectual-property claims;
• Indemnification;
• Limitations of liability;
• Consequential-damage exclusions;
• Cyber and technology-errors-and-omissions insurance;
• Regulatory cooperation;
• Suspension and emergency shutdown rights;
• Data export and transition assistance; and
• Governing law and dispute resolution.

A disclaimer does not make third-party risk disappear

A vendor’s contract may place broad responsibility on the customer. That allocation may affect disputes between vendor and customer, but it does not necessarily defeat claims by customers, employees, regulators, counterparties, or others harmed by the agent’s conduct.

Incident notice must be fast enough

A business may face legal, contractual, or operational deadlines before a vendor’s standard notice period expires. Contracts should define notice triggers, timing, content, preservation, access to logs, and cooperation.

17. Audit Logs: Can the Business Reconstruct What Happened?

After an incident, the business may need to determine:

• The initial user instruction;
• System and developer instructions;
• The model and software version;
• Configuration and permission settings;
• Data the agent retrieved;
• External content it encountered;
• Tool and API calls;
• Credentials and tokens used;
• Messages drafted and sent;
• Files created, changed, or deleted;
• Transactions attempted or completed;
• Approvals requested, received, or bypassed;
• Communications with other agents;
• Human interventions;
• Configuration changes; and
• The precise timeline.

Logs should be protected against unauthorized alteration and retained for an appropriate period. The business should know whether logs are stored by the vendor, whether they can be exported promptly, and whether they contain sensitive information.

Do not rely on a fictional reconstruction of what the AI “thought”

The legally useful evidence may be inputs, outputs, permissions, tool calls, system events, and transaction records. A model-generated explanation after the fact may be incomplete or inaccurate. The inability to reproduce internal model processes makes reliable operational records even more important.

Logging creates its own obligations

Prompts and logs may contain confidential, personal, privileged, or regulated information. Access, retention, security, discovery, and deletion practices should be addressed.

18. Human-in-the-Loop Is Not a Magic Phrase

Human approval can reduce risk only when it is meaningful.

Review may be ineffective if:

• The person lacks necessary information;
• The request omits material terms;
• The interface encourages automatic approval;
• Too many requests create approval fatigue;
• The action occurs before review;
• The reviewer cannot stop or reverse it;
• The system disguises uncertainty;
• The reviewer lacks appropriate authority or training;
• The review occurs after an external commitment; or
• The control evaluates each transaction but ignores cumulative exposure.

A meaningful approval process should show the proposed action, material information, recipient, amount, data involved, legal terms, reason for the action, and available alternatives. High-risk approvals should be logged and tied to an identified person.

The level of review should correspond to consequence. Drafting an internal meeting agenda does not require the same control as transferring funds or disclosing customer data.

19. Actions That Should Ordinarily Require Express Human Authorization

Depending on the business and governing law, an autonomous agent ordinarily should not act without express, meaningful human approval when the action would:

• Enter, amend, renew, or terminate a contract;
• Accept online legal terms;
• Spend, transfer, refund, or commit money;
• Change banking or payment instructions;
• Add a new payment recipient;
• Make a material pricing concession;
• Waive a claim, defense, fee, or contractual right;
• Admit liability, fault, breach, or noncompliance;
• Send a legal notice or demand;
• Respond to a regulator, subpoena, court, or law-enforcement agency;
• Access a new external system;
• Use another person’s credentials;
• Circumvent an access control;
• Retrieve restricted or confidential data;
• Disclose personal, privileged, regulated, or confidential information;
• Publish external content;
• Delete or materially alter business records;
• Change security permissions;
• Create administrator access;
• Disable systems or user accounts;
• Deploy code into production;
• Hire, discipline, compensate, or terminate an employee;
• Deny an accommodation or benefit;
• Make a consequential decision about a customer;
• File a tax, regulatory, corporate, or government document;
• Initiate or settle litigation; or
• Communicate with the media on a sensitive matter.

This is a starting framework, not a universal legal rule. Some businesses may need stricter restrictions. Others may automate limited actions within carefully defined, reversible, low-value parameters.

20. Build an Authority Map Before Deployment

An authority map documents the agent’s operational boundaries.

For each agent, identify:

• The business purpose;
• The owner responsible for the deployment;
• Authorized users;
• Systems it may access;
• Data it may read;
• Data it may create, modify, or delete;
• Persons and organizations it may contact;
• Tools and APIs it may call;
• Credentials it uses;
• Transactions it may initiate;
• Financial and cumulative limits;
• Actions requiring approval;
• Prohibited actions;
• Logging and monitoring;
• Escalation triggers;
• Shutdown authority; and
• Review and expiration dates.

The authority map should match technical reality. A document saying the agent is “read only” is not useful if the credentials permit modification.

Use least privilege

Give the agent the minimum access needed. Separate read, write, publish, purchase, and administrative permissions. Avoid broad employee credentials when a limited service account can be used.

Authority should expire

Temporary projects, pilots, and vendor tests should not leave permanent tokens, integrations, or dormant accounts. Access should expire or be reviewed periodically.

21. A Practical Risk-Tier Framework

Low risk

Examples may include:

• Internal brainstorming;
• Drafting for human review;
• Summarizing approved internal information;
• Read-only research in authorized sources; and
• Reversible internal recommendations.

Controls may include approved data sources, ordinary review, and basic logging.

Moderate risk

Examples may include:

• Drafting customer responses;
• Updating noncritical internal records;
• Scheduling;
• Creating routine reports;
• Preparing purchase recommendations; and
• Triggering reversible internal workflows.

Controls may include defined templates, access limits, sampling, approval for exceptions, and activity monitoring.

High risk

Examples may include:

• Sending external communications;
• Changing customer or financial records;
• Accessing sensitive information;
• Publishing content;
• Initiating purchases;
• Making recommendations used for employment or customer decisions; and
• Interacting with external systems.

Controls should include strong authentication, least privilege, meaningful approval, transaction limits, testing, logging, monitoring, and rapid shutdown.

Prohibited without express approval

Examples generally include contracts, payments, legal admissions, restricted-system access, sensitive-data disclosure, destructive actions, production deployment, legal filings, and consequential employment or customer decisions.

Risk classification should consider both a single action and cumulative effects. One $100 purchase may be low risk; thousands of automated $100 purchases are not.

22. Deployment Checklist

Before enabling an agent to act, a business should consider whether it has:

• Defined the business purpose and prohibited uses;
• Named an accountable business owner;
• Completed legal, privacy, security, and operational review;
• Identified applicable contracts and regulatory duties;
• Mapped systems, data, tools, and recipients;
• Applied least-privilege access;
• Created separate and traceable credentials;
• Established financial, volume, destination, and time limits;
• Restricted confidential and personal information;
• Tested ordinary, erroneous, adversarial, and manipulated inputs;
• Addressed prompt injection and untrusted content;
• Defined human-approval thresholds;
• Confirmed that approval is meaningful and timely;
• Enabled reliable logging and alerts;
• Established anomaly detection;
• Created a kill switch or rapid suspension process;
• Reviewed vendor terms, indemnity, insurance, and incident duties;
• Trained employees and reviewers;
• Created an incident-response procedure;
• Established periodic reassessment; and
• Defined when the deployment will expire or require reauthorization.

23. Myth Versus Reality

24. When the Agent Has Already Done Something It Should Not Have Done

The first objective is to stop continuing harm while preserving evidence and legal options.

1. Contain the agent

Suspend the agent, workflow, or affected integration where appropriate. Revoke or narrow tokens, credentials, tools, and system permissions. Determine whether other agents share the same configuration or vulnerability.

2. Preserve evidence

Preserve prompts, system instructions, configurations, model and software versions, logs, tool calls, outputs, emails, API records, access records, transactions, approvals, and communications. Do not casually delete or overwrite the evidence while attempting to fix the problem.

3. Establish the timeline

Record when the conduct began, when it was detected, who learned of it, what actions were taken, and whether activity continued after detection.

4. Determine what actually happened

Do not rely solely on the original instruction or the agent’s later explanation. Identify:

• Systems accessed;
• Data read or disclosed;
• Files changed or deleted;
• Messages sent;
• Content published;
• Transactions attempted or completed;
• Contracts or terms accepted;
• Credentials used;
• Recipients involved; and
• Third parties or external instructions that may have influenced the conduct.

5. Contain the transaction

Where lawful and appropriate:

• Suspend transfers;
• Cancel orders;
• Revoke access;
• Retract or correct publications;
• Notify a counterparty that authority is disputed;
• Preserve objections;
• Stop performance; and
• Avoid accepting benefits before evaluating possible ratification.

Timing can matter. Delay may make an unauthorized act harder to unwind.

6. Notify the response team

Depending on the event, notify appropriate management, legal counsel, cybersecurity personnel, privacy officers, compliance personnel, insurers, communications professionals, and affected vendors.

7. Evaluate legal duties

Assess:

• Contract formation and repudiation;
• Apparent authority and ratification;
• Computer-access issues;
• Privacy and breach-notification duties;
• Confidentiality and trade-secret exposure;
• Intellectual-property claims;
• Consumer-protection issues;
• Employment consequences;
• Regulatory reporting;
• Preservation and litigation holds;
• Insurance notice; and
• Contractual notice to customers, vendors, or business partners.

8. Communicate carefully

Avoid unsupported assurances, blame, speculation, or anthropomorphic statements about what the AI “wanted.” Corrective communications should be factually accurate and coordinated.

9. Remediate before reactivation

Identify the root cause. Revise permissions, system instructions, data access, approval thresholds, monitoring, vendor configurations, and training. Test the correction before restoring access.

10. Document and learn

Prepare an incident record describing facts, decisions, notices, remediation, and lessons. Update the authority map, risk assessment, contracts, policies, and response plan.

Critical point: Shutting down the agent may stop future actions, but it does not automatically cancel a contract, retrieve disclosed information, undo a publication, or eliminate a legal deadline.

25. Department-Specific Questions

Senior management and the board

• Which agents can act externally?
• Who owns each deployment?
• What financial, legal, privacy, security, and reputational exposure exists?
• Which actions require senior approval?
• How are material incidents reported?
• What evidence shows that management’s controls operate in practice?

Legal and compliance

• What authority might outsiders reasonably perceive?
• Can the agent form or modify contracts?
• Which laws, licenses, regulations, or professional duties apply?
• What notices, consents, and disclosures are required?
• Are vendor disclaimers and liability caps acceptable?
• What actions require preservation, reporting, or human approval?

Information security

• What credentials, tokens, tools, and systems can the agent use?
• Can untrusted content alter its behavior?
• Can it reach confidential data or external systems?
• Are activity, anomalies, and privilege changes monitored?
• Can access be suspended immediately?
• Are logs complete and protected?

Privacy

• What personal information is involved?
• Is the use consistent with notice, consent, purpose, and minimization requirements?
• Which vendors and subprocessors receive data?
• Can individual rights and deletion obligations be honored?
• Could an incident require notice?

Finance and procurement

• Can the agent commit funds or alter payment details?
• What per-transaction and cumulative limits apply?
• Are new vendors and bank accounts independently verified?
• Can it accept legal terms?
• How are unusual transactions held for review?

Sales, marketing, and customer service

• Can the agent make price, warranty, delivery, refund, or performance commitments?
• Are claims supported by approved sources?
• Can it publish without review?
• Are regulated or sensitive topics escalated?
• Are communications retained and attributable?

Human resources

• Can the agent rank, reject, discipline, monitor, or communicate decisions to people?
• Has discrimination and automated-decision risk been evaluated?
• Are accommodations and exceptions handled by people?
• Are records and reasons preserved?

IT and operations

• Is technical authority aligned with written authority?
• Are changes tested and approved?
• Can the agent create integrations or delegate to other agents?
• Are production and test environments separated?
• Are inactive agents, credentials, and pilots removed?

26. Questions to Ask an AI-Agent Vendor

• What actions can the system take without human approval?
• Can it access external websites, APIs, databases, email, files, or payment systems?
• How are tools and permissions restricted?
• Can the agent create or call sub-agents?
• How does the product defend against prompt injection?
• What customer data is collected, retained, or used for training?
• Which model providers and subprocessors are involved?
• Where is data processed?
• What logs are available, and for how long?
• Can logs be exported promptly after an incident?
• How are model and configuration changes communicated?
• What testing has been performed for unsafe or unauthorized actions?
• Can the system be suspended immediately?
• What incident-notification period applies?
• What assistance is provided for investigation and remediation?
• Who owns outputs, configurations, and agent-created records?
• What warranties and disclaimers apply?
• What indemnification is provided?
• What liability cap applies to data loss, confidentiality, security, IP, and unauthorized transactions?
• What insurance does the vendor maintain?
• How are data and credentials returned or deleted at termination?

27. Practical Governance Principles

A business deploying autonomous AI should consider adopting the following principles:

Purpose limitation

Deploy the agent for a defined business purpose. Do not permit open-ended use merely because the technology is capable of more.

Least privilege

Limit systems, data, tools, recipients, and transaction values to the minimum necessary.

Separation of duties

The same agent should not necessarily create a vendor, approve an invoice, and initiate payment.

Reversibility

Automate reversible actions before irreversible ones. Draft before sending. Recommend before purchasing. Stage before publishing.

Human accountability

Every deployment should have an identified business owner who cannot answer an incident by saying, “That belongs to the AI vendor.”

Traceability

Use separate credentials, reliable logs, identifiable approvals, and version records.

Fail safely

When the system is uncertain, manipulated, disconnected, or outside scope, it should stop or escalate rather than improvise.

Periodic review

Reassess after model updates, new integrations, expanded permissions, incidents, near misses, new laws, and material business changes.

No silent expansion

An agent should not acquire new tools, data, authority, or external destinations without an approved change process.

28. Key Takeaways

• An AI agent differs from an ordinary chatbot when it can take actions, use tools, access systems, and execute workflows.
• The technology label “agent” does not automatically establish common-law agency.
• Responsibility will usually be analyzed through the conduct, authority, contracts, and duties of people and organizations.
• “We did not specifically instruct that action” may be relevant but may not be a complete defense.
• Intended, technical, and perceived authority should be aligned.
• Apparent authority and ratification can matter when outsiders reasonably rely or the business accepts benefits.
• Electronic agents can participate in legally effective contract formation when their acts are attributable to the party to be bound.
• Internal policies should be enforced by technical permissions and approval controls.
• Negligence questions may focus on foreseeability, permissions, testing, monitoring, and reasonable supervision.
• The CFAA does not make every unwanted computer interaction or terms-of-service violation a federal offense; access boundaries matter.
• Prompt injection can turn untrusted content into an instruction and should be treated as a legal and cybersecurity risk.
• Confidentiality, privacy, trade-secret, IP, consumer-protection, and employment duties may apply to agent conduct.
• Vendor agreements should address data, permissions, logging, incidents, indemnity, liability, shutdown, and cooperation.
• “Human in the loop” is useful only if the review is meaningful and can prevent the action.
• Contracts, payments, sensitive disclosures, destructive actions, external-system access, legal admissions, and consequential decisions ordinarily require express human authorization.
• Reliable logs and an authority map are essential.
• Incident response should contain the agent, preserve evidence, reconstruct the acts, protect legal options, evaluate notices, and prevent ratification or continued harm.

Conclusion

AI agents offer businesses the possibility of faster research, more efficient operations, improved customer service, and automated workflows. But efficiency changes character when software receives the practical power to act for the organization.

The central legal question is rarely whether the AI itself should be treated as a responsible legal person. The more useful questions are:

• Who selected and configured the system?
• Who gave it credentials and tools?
• What authority did the business communicate?
• What could outsiders reasonably believe?
• What risks were foreseeable?
• What controls were available?
• What contracts allocate responsibility?
• What did the system actually do?
• How did the business respond after learning of the conduct?

Courts and regulators may address many disputes involving autonomous AI through established doctrines rather than a single new body of “AI-agent law.” That makes traditional legal planning more important, not less.

A business should not wait until an agent sends the wrong message, accepts the wrong terms, discloses confidential data, accesses the wrong system, or initiates the wrong transaction. The better approach is to define authority, restrict permissions, negotiate vendor protections, require meaningful approvals, preserve reliable evidence, and prepare a response plan before deployment.

For assistance evaluating autonomous AI deployments, authority structures, vendor agreements, privacy and confidentiality issues, contract risk, computer-access concerns, governance policies, or incident response, contact CorwinLaw:

https://www.corwinlaw.net

The CorwinLaw Codex

Explore additional legal guides, practical resources, and practice-area reference materials at:

https://www.corwinlaw.net