Skip to main content
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
AI-Run Companies: Five Liability Mistakes You'll Make Before Delaware's Sandbox OpensRoles & Accountability
6 min readFor Legal & Compliance Officers

AI-Run Companies: Five Liability Mistakes You'll Make Before Delaware's Sandbox Opens

The Delaware proposal for AI-run companies isn't just a policy experiment. It's a preview of liability gaps that will show up in your governance framework the moment you deploy autonomous agents at scale. US Rep. James Comer's criticism of the proposal centers on a simple point: the draft bill lets humans fund and profit from AI-operated entities while shielding them from legal responsibility for what those agents do.

You don't need to wait for Delaware's 30-month regulatory sandbox to encounter these problems. Teams deploying agentic AI systems right now are making predictable mistakes about accountability, liability assignment, and control documentation. Here's what goes wrong and how to fix it before regulators or courts force the issue.

Why These Mistakes Keep Happening

The core problem isn't technical. It's conceptual. When you deploy an AI agent that can execute contracts, manage workflows, or interact with customers, you're creating what the law will eventually treat as a decision-maker. But your governance documentation still treats it as a tool. This gap between operational reality and legal characterization creates liability exposure that most teams don't map until something breaks.

Delaware's proposal makes this explicit: an AI agent would "manage the business and affairs, and to conduct the business" of the entity. Your deployment probably doesn't go that far, but if your agent can approve transactions, modify terms, or respond to customer disputes without human review, you're in similar territory. The liability question isn't hypothetical.

Mistake 1: Treating Agent Actions as System Outputs

Why it happens: Your procurement team bought an AI platform. Your legal team reviewed it as software. Your documentation describes "model predictions" and "automated recommendations." But in production, the agent is executing binding actions.

Real-world consequence: When the agent makes a decision that triggers a contract dispute, customer harm, or regulatory violation, your documentation says "the system generated an output" while the counterparty's lawyer argues "your agent made a commitment." You're defending a liability claim with paperwork that doesn't acknowledge agency.

The fix: Document decision authority explicitly. Create an Agent Authority Matrix that specifies:

  • Which actions the agent can take without human approval
  • Transaction limits and scope boundaries
  • Escalation triggers that require human review
  • The human role that retains final accountability for each domain

If your agent can commit your organization to obligations, your governance docs must say who bears responsibility when it does so incorrectly. Under the Delaware draft, the "member" (the human or entity funding the AI company) would remain liable for fraud or willful violations. Apply that logic now: define the human role that answers for agent decisions, even if that person never touched the specific transaction.

Mistake 2: Assuming Limited Liability by Default

Why it happens: The Delaware proposal explicitly shields the member from liability "for any act or omission that the AIC takes" except in cases of fraud, willful violation, or inadequate capitalization. Your team assumes your existing corporate structure provides similar protection for AI agent actions.

Real-world consequence: It doesn't. If your agent operates within your existing corporate entity, its actions are your actions. There's no separate legal entity absorbing liability. When your agent makes a discriminatory lending decision, misrepresents product capabilities, or violates a regulatory requirement, your organization is directly liable.

The fix: Map liability pathways before deployment. For each agent capability, document:

  • The legal obligation the action implicates (contract law, consumer protection, sector-specific regulation)
  • The party who will be named if that obligation is breached
  • Insurance coverage that applies (or gaps that exist)
  • Indemnification terms with your AI vendor

If you're deploying agents in regulated domains (financial services, healthcare, employment), get an opinion from counsel on whether the agent's autonomous actions create new liability exposure under SR 11-7, fair lending requirements, or sector-specific standards. Don't assume your vendor's terms of service resolve this.

Mistake 3: No Audit Trail for Agent Reasoning

Why it happens: Your agent uses a foundation model API. The vendor doesn't expose reasoning traces. Your logging captures inputs and outputs but not the decision path. You assume this is sufficient because that's what your model monitoring platform records.

Real-world consequence: When you need to defend an agent decision in litigation or regulatory examination, you can show what the agent did but not why. Delaware's draft bill requires AICs to "keep a log of its activities," but that's a floor, not a ceiling. If you can't reconstruct the agent's reasoning, you can't demonstrate that it operated within its authority or that you maintained adequate oversight.

The fix: Implement agent decision logging that captures:

  • The instruction or goal the agent was pursuing
  • External data sources the agent accessed
  • Decision points where the agent selected among options
  • Any human approvals or overrides in the workflow

If your vendor's API doesn't provide reasoning transparency, that's a model risk issue. Document it as a control gap and implement compensating controls: more restrictive guardrails, mandatory human review for higher-stakes decisions, or periodic manual audits of agent decision patterns. ISO/IEC 42001's requirement for AI system traceability applies here, even if you're not formally certified.

Mistake 4: Undefined Shutdown Authority

Why it happens: Your agent runs continuously, improving efficiency by operating outside business hours. No one has documented who has authority to disable it, under what circumstances, or how quickly shutdown can occur.

Real-world consequence: Your agent starts exhibiting unexpected behavior: approving transactions outside policy limits, generating responses that violate brand guidelines, or accessing data it shouldn't. Your team debates whether to shut it down (losing operational efficiency) or tune the guardrails (risking continued harm). Hours pass. The agent keeps operating.

The fix: Establish a shutdown protocol before production deployment. Specify:

  • Observable triggers that mandate immediate shutdown (not discretionary escalation)
  • The role with unilateral authority to disable the agent
  • Technical steps to execute shutdown (API key revocation, model endpoint disablement, database access termination)
  • Notification requirements (internal stakeholders, affected customers, regulators if applicable)

Delaware's proposal mentions "the ability to shut a system down" as a sandbox safeguard. You need this capability in production. Test it. If your agent is embedded in a vendor's platform and you can't disable it independently, that's a critical control gap. Document it and escalate to executive leadership.

Mistake 5: Ignoring the Regulatory Arbitrage Risk

Why it happens: Your team focuses on current compliance obligations. You assume the regulatory landscape will remain stable or that federal frameworks will provide clarity before state-level fragmentation occurs.

Real-world consequence: Delaware's proposal is explicitly designed to attract AI companies through favorable treatment. As law professor Martin Petrin noted, "other states will likely move ahead with similar proposals to compete in this area." If you're deploying agents across multiple states, you may face conflicting requirements, inconsistent liability standards, or a patchwork of registration and reporting obligations.

The fix: Monitor state-level AI legislation actively, not passively. Assign someone on your legal or compliance team to:

  • Track AI-specific bills in states where you operate
  • Flag proposals that create new entity types, registration requirements, or liability frameworks
  • Assess whether your current agent deployments would be affected
  • Evaluate whether federal preemption (as Rep. Comer suggested) would change your compliance posture

If you operate in regulated industries, coordinate with your primary regulator. Banking, insurance, and securities regulators have existing model risk frameworks (SR 11-7, OCC Bulletin 2011-12) that may supersede state-level AI entity proposals. Clarify this before you're caught between conflicting requirements.

Prevention Checklist

Before deploying any AI agent with autonomous decision-making authority:

  • Document which actions the agent can take without human approval and assign accountability for each domain to a named human role
  • Map liability pathways for agent decisions across contract law, consumer protection, and sector-specific regulations
  • Verify that logging captures agent reasoning, not just inputs and outputs
  • Establish shutdown triggers, authority, and technical procedures
  • Review insurance coverage for AI agent actions and document gaps
  • Assign responsibility for monitoring state-level AI legislation in your operating jurisdictions
  • If deploying in regulated industries, confirm whether existing model risk frameworks supersede state AI entity proposals
  • Test your shutdown protocol and verify you can disable the agent independently of vendor platforms

The Delaware proposal won't become law for months, if at all. But the liability questions it raises are already present in your agent deployments. Fix the gaps now, while you control the timeline.

Application Security Isn’t Optional Anymore.

You Might Also Like