The AI Vendor's Warning Label

The useful executive question is about delegation: what did the company hand to the vendor, what stayed in-house, and what residual risk did leadership accept before production sign-off? That starts as an operating gap. Later it shows up as a legal, insurance, procurement, or board problem—once nobody can reconstruct the record.

An enterprise agent is not a chatbot with extra context. It holds an identity, reads files, searches externally, pulls private data, invokes tools, writes code, triggers workflows, updates records, and leaves logs across multiple systems. Older software questions asked what an application could reach. The agent version asks what the system can infer, decide, and execute without continuous human oversight.

Vendor documentation therefore deserves a second pass. First comes the technical read: sandboxes, limited egress, tool-input checks, log monitoring, approval thresholds, narrowed credentials. Then comes the strategic read—because the same text sketches responsibility lines before the market has settled how blame will be assigned.

The Cloud Lesson

Cloud computing is the closest parallel. Its shared-responsibility model turned a technical division of labor into a governance vocabulary. Amazon Web Services (AWS) still frames the split as security of the cloud versus security in the cloud: the provider protects the underlying infrastructure, while customers keep responsibility for data, identity, configuration, applications, and workload-specific controls. The same guidance notes that shared responsibility covers IT controls for management, operation, and verification.

Verification is what turns architecture into evidence. Saying you own a configuration is different from showing that you evaluated it, put it in place, monitored it, and documented the result. The 2020 Office of the Comptroller of the Currency (OCC) action against Capital One is a clear case: an $80 million penalty for weak risk-assessment processes ahead of a large public-cloud migration. Capital One is not an agent precedent, but it shows how control splits become board, regulatory, audit, and incident-review topics once a technology underpins critical operations. Agents are likely to push the same pattern into messier territory.

Agents Make Control Points Harder

Cloud control surfaces are still more modular than agent surfaces. Storage, compute, network rules, and identity policies can be hard to run well, but their edges stay comparatively clear. Agents merge those surfaces.

Identity choices show the shift immediately. An agent may operate under a service account, a human credential, a delegated identity, or a workflow token—and each option changes the answer to a basic incident question: who performed the action? Tool use adds more layers. Model text output is not the same thing as an actual tool call. Drafting a refund is not the same as issuing one. Updating the customer record, sending confirmation, and folding the result back into context each carry separate risks.

Data handling blurs the lines further. Retrieval systems, uploaded files, memory stores, SaaS connectors, browser state, email, and customer records can mix trusted and untrusted material in one place. Open Worldwide Application Security Project (OWASP) work on tool poisoning shows how tool responses can inject adversarial instructions into an agent context unless data and instructions are separated and controls sit outside model output. Egress risk is not just about blocked domains either. Models can leak through permitted channels; tools can forward data via an allowed API; browser sessions can blend user intent with hostile content; reports can expose more than intended when the system pulls excess background context.

Human approval gates do not solve this by themselves. Microsoft recommends gates for high-risk tools and treats model-supplied function arguments as untrusted. Anthropic guidance for chief information security officers (CISOs) asks for the untrusted content an agent receives, the actions it can perform, the authority it uses, the impact radius, and the observability in place. Those questions remain useful—and they also show the limit of any design that relies on approval without tracking fatigue or escalation quality.

Logging and revocation close the loop. A serious incident may require prompt logs, tool-call logs, approval logs, SaaS audit logs, code-execution logs, memory records, connector tokens, service-key rotation, and retained outputs. When those records sit in separate systems with separate owners, reconstruction after the fact can prove impossible.

Agent safety is operating a chain of delegated controls. Buying a secure product is the wrong mental model.

The Vendor Document As Control Map

Vendor warnings therefore carry commercial weight. Anthropic’s self-hosted sandbox model now uses explicit shared-responsibility language: Anthropic secures the control plane while customers own sandbox image quality, runtime hardening, network egress, service-key storage and rotation, workload isolation, tool-execution scope, and log retention. Microsoft guidance takes a similar approach. Developers are directed to map trust lines across user input, chat history, context providers, model services, and function tools, with required practices that include validating function inputs, approving high-risk tools, keeping developers in control of system messages, vetting extension providers, sanitizing model output, protecting sensitive logs, securing session data, and implementing resource limits.

This is sound engineering. It also previews the questions an auditor, insurer, board committee, procurement lawyer, or incident reviewer will later raise. Did the buyer restrict egress? Rotate keys? Separate trust lines? Treat tool output as untrusted? Preserve logs? Identify which identity the agent used? Require approvals only where they carried weight? Test revocation before production?

None of this proves vendor innocence after a failure, or customer liability. Documentation alone does not settle legal responsibility. It can make the control split legible—and once it is legible, executives should treat it as potential evidence.

Why This Belongs In The C-Suite

Security teams can identify controls, but commercial autonomy for an agent is still a business decision they cannot own alone. Legal can negotiate contract terms, yet every approval threshold still needs operational design beyond the contract. Finance can request efficiency gains; the risk change from a faster process still needs a separate call. Boards can ask whether AI is governed and still receive usage dashboards instead of evidence of control ownership. The core difficulty is ambiguous accountability.

Agent programs often start with productivity claims—fewer tickets, faster summaries, cheaper research, quicker coding, better support. Those claims can be true and still obscure ownership. Action capability requires an owner for the action limit. Untrusted content needs an owner for the trust rule. Credentials need an owner for the identity model. Learning from outcomes needs an owner for drift and feedback.

At many companies the first serious incident will not arrive as a philosophical debate. It will arrive as a practical question: who allowed the agent to reach that system, trust that input, use that credential, execute that tool, skip that approval, retain that log, or send that output? Refusing every agent is not a workable strategy either. Anthropic guidance notes that outright rejection can drive adoption into shadow channels with weak telemetry and no off switch. Bounded risk with named owners is the stronger posture.

The Responsibility Matrix

Before approving a production agent, the buyer should require a responsibility matrix. It does not need to be elaborate. It does need to be specific enough that the company can later explain what it believed, controlled, delegated, and accepted.

This matrix should stay public in the article. The paid layer, if any, can add the worksheet, contract-control addendum, board template, and insurance questions. Hiding the matrix would weaken the public argument. Publishing it gives the reader the practical payoff and makes the paid layer implementation support rather than a toll on the core idea.

Read It Before The Accident

Reading vendor guidance as pure blame-shifting misses the point. Vendors will protect themselves. The more useful observation is that agent guidance is becoming accountability infrastructure before any settled liability regime exists. Buyers learn how to reduce blast radius. Implementers learn which controls matter. Procurement teams learn what to capture in contract language. Insurers learn which assumptions to test. Boards learn what evidence to request.

Companies that get real value from agents will be able to show the autonomy zone they allowed, the limits they set, the controls they delegated, the controls they retained, and the events that occurred at each control point. Simple trust or distrust of the technology is not the differentiator. Read the documentation as a warning label before the accident. After the accident, someone else may read it as evidence.