The Agentic Liability Gap MSPs Are Not Ready For

AI agents get the same data access as the employee who configured them. They just act on it faster. That framing, from a Wall Street Journal investigation into AI agents and insider risk, captures the liability problem in one sentence: the exposure is not theoretical, it is inherited.

For MSPs deploying agentic tools in client environments, or evaluating them now, the liability gap is in the frameworks. The insurance, compliance, and regulatory frameworks MSPs rely on were written before autonomous AI systems existed as a deployment category. E&O policies, SOC 2 attestations, ISO 27001 certifications, and HIPAA Business Associate Agreements all have a human in the middle. When you remove the human and replace them with an agent that acts across systems without step-by-step approval, the coverage that MSPs assume they have becomes conditional on documentation work most have not done.

This describes the current state of the frameworks your clients and auditors are relying on today.

Where the E&O Coverage Question Gets Complicated

If your client has a security incident tied to an agentic tool you deployed, the first thing you check is your Tech Errors and Omissions (E&O) insurance. E&O was written for professional services delivered by humans, and that assumption is embedded in how policies are worded.

Carriers have noticed. GenAI exclusions are appearing in standard E&O and cyber policy endorsements: language that removes coverage when an AI system, rather than a human professional, is the direct cause of the error. Specialty brokers are explicit about the gap. Coverage clarity collapses where tasks are completed without human review, which is precisely how AI agents are designed to operate.

The emerging response from the insurance market is its own evidence of the gap. Carriers offering dedicated AI liability products (AI E&O, AI performance warranty, rogue-agent coverage) are filling space that standard policies leave open. The specialty AI liability market now covers model errors, hallucinations, algorithmic bias, and autonomous agent actions (categories that standard E&O treats as contested or excluded). A new insurance market forming around a risk category is a reliable signal that the existing market does not cover it cleanly.

For MSPs, the practical question is: have you checked whether your current E&O policy has any language around AI-generated outputs or autonomous system actions? Most have not. And most are deploying tools that could trigger those exclusions. A January 2026 investigation found companies discovering between one and 17 agents per employee in security scans, most without documented access scopes.

Where Your SOC 2 Attestation Has a Gap for Agentic Systems

If you carry a SOC 2 attestation, that report is the checkpoint your clients look to for security maturity. The Trust Services Criteria (TSC) that define a SOC 2 engagement were not written for AI agents, and that gap is visible in the specific criteria auditors apply.

Trust Services Criterion CC6.1 requires logical access provisioning for authorized users. The underlying assumption is that the “user” taking an action is a person whose access can be scoped, reviewed, and revoked. An AI agent that inherits a service account’s credentials and acts autonomously across systems is not a user in any sense CC6.1 was written to address. An MSP whose agentic deployment relies on inherited credentials, without separate access scoping and a documented approval model for agent-initiated actions, has a control gap that an auditor can surface (even if the audit passes).

Criterion CC8.1, which covers change management, has a similar problem. Change management controls assume a human initiates a change, a review process approves it, and the change is logged with attribution. An agent that modifies configuration files, updates records, or adjusts settings as part of an automated workflow is initiating changes. If those changes are not individually logged with the agent’s identity, scope, and authorization chain, the CC8.1 control is not satisfied in the way it was designed.

A common scenario: an MSP uses an agentic tool to automate client onboarding tasks, including updating user access records and sending configuration confirmations. The agent acts on a service account. Its actions are logged in the agent’s own console but not in the MSP’s central audit system. When a SOC 2 auditor reviews CC8.1 change management evidence, the onboarding changes appear with no human initiator and no attribution to the agent’s scoped identity. The auditor flags the gap. The underlying process was working; the documentation was not.

SOC 2 audit guidance for AI controls is evolving, and auditors are beginning to ask the right questions: how are agent outputs validated, how are hallucinations prevented from causing client impact, what human oversight exists for high-risk decisions. The MSPs who can answer those questions with documented controls are in a different position than those relying on the assumption that their existing SOC 2 posture covers agentic deployments.

ISO 27001:2022 and the Documentation Gap

If you hold an ISO 27001:2022 certification, your existing controls are broad enough to cover agentic AI governance: identity and access management, audit logging, change management, supplier risk, data protection. The framework does not exclude AI agents; it simply does not name them.

The gap is in implementation. Each AI agent should be treated as an auditable identity within your Information Security Management System (ISMS): scoped permissions, traceable actions, documented authorization chain, defined scope of operation. ISO 27001:2022 Annex A includes controls for logical access (A.5.15), system access control (A.8.2), and information backup and logging (A.8.15), all of which apply to agentic systems if intentionally extended to them.

The problem is that “intentionally extended” is the operative phrase. An MSP that deploys an agentic tool without updating their ISMS documentation to cover the agent as an identity is relying on general controls that were not designed for autonomous systems. When an ISO 27001 audit reviews supplier risk management or access control, the agent may not appear in the relevant documentation at all. That absence is a control gap, even if the underlying processes are sound.

Consider how this plays out in practice: an MSP deploys a third-party agentic tool for security alert triage. The tool is added to the tech stack without a formal supplier assessment or ISMS update. Six months later, during an ISO 27001 surveillance audit, the auditor requests the supplier risk register. The agent vendor is not on it. The auditor notes a nonconformity against Annex A.5.19. The agentic tool was doing exactly what it was configured to do; the gap was that nobody documented it as a supplier accessing information assets.

The compliance framework requirements for SOC 2 and ISO 27001 are compatible with agentic AI deployment. The question is whether the deployment has been documented in terms the frameworks recognize.

HIPAA and the Business Associate Agreement Problem

For MSPs who work with healthcare clients, the Business Associate Agreement (BAA) is the contractual foundation for handling protected health information (PHI) on a client’s behalf. The Health Insurance Portability and Accountability Act (HIPAA) requires covered entities to enter into BAAs with third-party service providers who create, receive, maintain, or transmit PHI.

The HIPAA BAA provisions define a business associate as a person or entity performing functions involving PHI access. The contract must establish permitted uses, require appropriate safeguards, and cover downstream subprocessors. AI agents that access PHI as part of an automated workflow fall into this definition, but only if the MSP has scoped the agent’s access to permitted uses and configured the downstream AI vendor’s own BAA to cover the agent’s actions.

The exposure is that most MSPs have not verified whether their AI vendor has a signed BAA in place, whether the BAA covers AI-assisted processing specifically, or whether the agent’s PHI access has been limited to the permitted uses defined in the contract. Assuming the BAA applies without confirming those conditions is where the exposure sits.

A concrete example: an MSP deploys an AI agent to assist with scheduling and administrative tasks at a dental practice client. The agent has access to the practice management system, which holds patient records. The MSP’s BAA with the dental practice covers its staff and listed vendors. The AI tool vendor is not listed. When the patient management vendor conducts a routine security review, it flags the agent’s access pattern. At that point, the MSP has no BAA coverage for the exposure and no documented scoping of the agent’s PHI access. A Department of Health and Human Services (HHS) audit would treat those as two distinct compliance gaps.

For healthcare MSP work, the technical control layer matters here too. An agent with broad file access in a client environment may be accessing PHI incidentally, outside any permitted use, without anyone having made that decision deliberately. The risk register documentation for audit readiness that supports HIPAA compliance needs to include AI agents as access points, with their permitted scope explicitly defined.

What the Gap Actually Requires to Close

The liability gap is conditional, not binary. MSPs are not universally exposed or universally protected: they are conditionally protected, based on documentation and scoping work most have not yet done. The conditions are documentable and achievable:

E&O coverage starts with a policy review. Check for AI-related exclusions or autonomous-operation language. If they exist, ask your broker about endorsements or supplemental coverage. If you are adding agentic capabilities to your service offering, have that conversation with your carrier before deployment.

SOC 2 requires treating each agentic deployment as a distinct access principal in your control environment. Agent-initiated actions need to be logged with sufficient attribution to satisfy CC6.1 and CC8.1. If you are audited, be prepared to show how agent outputs are validated and how human oversight is structured for high-risk decisions.

ISO 27001 compliance means updating your ISMS documentation to treat AI agents as identities. Define their access scope, log their actions, include them in your supplier risk register if they are third-party systems, and document the authorization chain for their permitted actions.

HIPAA compliance means confirming your AI vendor has a signed BAA before any PHI-touching deployment. Verify that the BAA covers AI-assisted processing specifically. Scope the agent’s PHI access to the minimum necessary for its permitted functions, and include that scoping in your BAA and in your own risk documentation.

The table below maps the gap to the closure requirement:

All of it is documentation and scoping work: the steps that make existing frameworks apply to a deployment type they did not anticipate.

The Evaluation Question Before You Deploy

For MSPs evaluating agentic tools now, the framework gaps above should translate into vendor questions. Before deploying any agentic system in a client environment, the baseline evaluation includes:

• What access does the agent require, and can that access be scoped to the minimum necessary?
• What does the action log look like? Can individual agent actions be attributed and reviewed?
• Does the vendor offer a BAA for healthcare clients?
• What human oversight points exist in the workflow, and how are high-risk decisions escalated?
• If the agent makes an error, what is the correction path, and where does liability sit?

Agentic systems that answer these questions with documented, auditable answers carry a fundamentally different risk profile than those that do not. The distinction matters now, before a client incident surfaces the gap in a context where it is much harder to address.

Cynomi’s agentic Security Growth Platform is built on explainable, bounded AI: every action logged, every recommendation auditable, every client environment scoped separately. Request a demo to see how the architecture addresses the liability considerations before they become your problem.