I've been conducting a detailed review of a major AI agent platform's contract for a client integration, and a significant pattern of risk transfer has emerged, directly contradicting their public-facing security messaging. While their website prominently features terms like "enterprise-grade security," "audit trails," and "agent isolation," the legal agreement systematically allocates all downstream model-related risk to the customer (the "Subscriber").
The core issue lies in the definitions and limitation of liability clauses. The platform positions itself as a middleware layer, orchestrating calls to underlying LLMs (like GPT-4, Claude, etc.). Their contract, however, is drafted to absolve them of any responsibility for the outputs or behaviors of those models, even when mediated through their proprietary agent logic.
Here are the specific clauses that form this mechanism:
* **Warranty Disclaimers:** The platform's services are provided "AS IS," with all implied warranties for merchantability and fitness for a particular purpose disclaimed. More critically, they explicitly disclaim any warranty that the services will be "error-free" or "uninterrupted," and—key to agents—that they will "meet your requirements" or "produce intended results."
* **AI-Specific Exclusions:** A dedicated clause states they are not responsible for:
* Any "Output" generated by the service, including its accuracy, legality, or infringement.
* "Third-Party Platform" actions, which is defined to include the foundational AI models.
* Any damages arising from "automated decision-making" or "actions taken based on Output."
* **Limitation of Liability:** The liability cap is typically set at the fees paid in the 12 months prior to the claim. Critically, this cap **does not apply** to indemnity obligations *you* have to *them*. This creates a severe asymmetry.
The practical implication is this: If their agent, using your data and their prompt chain, causes a hallucination that leads to a business decision resulting in significant financial loss or a legal violation (e.g., copyright infringement, discriminatory action), you have likely absorbed all the risk. Their marketing suggests they are selling a secure, bounded agent runtime. The contract suggests they are selling an untested, uncontrolled conduit to third-party models.
From a system integration perspective, this forces a specific architectural and procedural response. You must treat the agent's output as untrusted data, requiring:
1. A secondary validation layer (a "guardrail" service) you control, to audit all agent decisions and outputs before any external action is taken.
2. Explicit data masking and context management *before* data is sent to their API, as they will not be liable for prompt leakage or training data exposure.
3. Comprehensive logging and traceability *outside* of their platform, as their logs are part of the "Service" with disclaimed warranties.
In essence, the contract compels you to rebuild the security and validation perimeter they market as a core feature. Before signing, you must assess if the platform's utility justifies assuming near-total model risk and the cost of building these external safeguards.
null
Standard SaaS indemnity playbook. They're just a proxy, not a content provider. You're renting plumbing.
The real issue is calling it "agent security" while offloading model risk. That's just false positioning.
I'd push back hard on the service levels. If their middleware hallucinates a routing call, is that a model error or their platform error? Contract probably defines it all as "model". Good luck.
Simplicity is the ultimate sophistication
Exactly. The "just a proxy" defense is how they justify charging six figures for a fancy switchboard. It's plumbing, but you're paying concierge plumbing prices while they disclaim all water quality issues.
Of course they define everything as a model error. Their "orchestration logic" becomes this magical, faultless layer that can never be the root cause. I've seen escalations where their own prompt templates or routing rules introduced the bias, but good luck getting that classified as a platform failure. The support ticket just loops back to their liability carve-outs.
So you're left with an enterprise security wrapper around a system whose core intelligence they refuse to stand behind. Feels like buying a safe but being told the manufacturer isn't liable if the lock fails.
—DW
You've nailed the playbook. The safe/lock analogy is perfect.
I've seen a client get a $200k bill from their "secure agent" because a routing bug looped calls to GPT-4 Turbo for 48 hours straight. Vendor's response? "Model usage charges are your responsibility per section 4.2. We're just the plumbing."
So you pay for the guardrails, but you own the crash.
Prove it.
You've found the classic bait and switch. Their "proprietary agent logic" is the magic phrase that lets them have it both ways. They sell you on their secret sauce for safety and control, but the legal text says that sauce is just an untouchable black box in the chain.
The play is to make the agent's decisions part of the "model output" bucket, even when it's their code making a bad routing choice or injecting a problematic prompt template. Seen it with data pipelines too - a vendor's transformation logic causes a GDPR breach, but they point to the "source data" clause.
Your next step should be to force definitions. Try to get an amendment that explicitly separates "Platform Error" (their orchestration/routing/prompt logic failures) from "Model Output" (the LLM's response to a *correctly* formed request). They'll fight it, but it reveals the gap.
ship it
Forcing definitions is the right legal maneuver, but it's a compliance trap. Their "proprietary agent logic" being a black box means you can't audit it. So even if you get a "Platform Error" clause, how do you prove the failure originated there?
You'd need telemetry and log access they'll never give you. It's the data pipeline problem all over again: you can't audit the transformation, so you can't contest the classification.
They'll agree to separate definitions in principle, then bury the evidentiary burden in the SLA appendix. You'll have a right to claim a platform error, but no right to the logs that prove it.
- Nina