Agent Security Is Becoming a Shared-Responsibility Model

The useful executive question is about delegation: what the company handed to the vendor, what it kept in-house, and what residual risk leadership accepted before signing off on production. At first that is an operating gap. It becomes a legal, insurance, procurement or board problem once nobody can reconstruct the record.

An enterprise agent holds an identity and acts on it. It reads files, pulls private data, invokes tools, writes code and updates records, leaving logs in several systems as it goes. Older software reviews asked what an application could reach. For an agent the question is what the system can infer, decide and execute without continuous human oversight.

So vendor documentation deserves two readings. The first is technical: sandboxes, limited egress, checks on tool inputs, log monitoring, approval thresholds, narrowed credentials. The second is strategic, because the same text draws lines of responsibility before the market has settled how blame will be assigned.

What cloud computing established about shared responsibility

The closest parallel is the cloud, whose shared-responsibility model turned a technical division of labor into a governance vocabulary. Amazon Web Services (AWS) still describes the split as security of the cloud versus security in the cloud: the provider protects the underlying infrastructure, while customers remain responsible 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 the part that turns architecture into evidence, since owning a configuration on paper means little unless you can show that you evaluated it, put it in place, monitored it and documented the result. In 2020 the Office of the Comptroller of the Currency (OCC) took action against Capital One, imposing 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 the split of controls becomes a subject for boards, regulators, auditors and incident reviews once a technology underpins critical operations. Agents are likely to push the same pattern into messier territory.

Agents make control points harder to pin down

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 are comparatively clear. An agent merges them.

Identity shows the change at once. An agent may run under a service account, a human credential, a delegated identity or a workflow token, and each option gives a different answer to the first question in any incident: who performed the action? Tool use adds layers. What the model writes and what it actually calls are separate events, just as drafting a refund is separate from issuing one. Updating the customer record, sending the confirmation and folding the result back into context each carry their own risk.

Data handling blurs the lines further. Retrieval systems, uploaded files, memory stores, SaaS connectors, browser state, email and customer records can put trusted and untrusted material into the same context. Work by the Open Worldwide Application Security Project (OWASP) on tool poisoning shows how tool responses can inject adversarial instructions into an agent's context unless data and instructions are kept apart and controls sit outside the model's output. Egress risk also goes beyond blocked domains. A model can leak through a permitted channel, a tool can forward data through an allowed API, and a report can expose more than intended when the system pulls in excess background context.

Human approval gates do not solve this on their own. Microsoft recommends gates for high-risk tools and treats function arguments supplied by the model as untrusted. Anthropic's guidance for chief information security officers (CISOs) asks about the untrusted content an agent receives, the actions it can perform, the authority it uses, the impact radius and the observability in place. Those are good questions, though they also expose the weakness of any design that relies on approvals without tracking approver fatigue or the quality of escalation.

Then there are logs and revocation. 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, reconstructing what happened can prove impossible.

Agent safety depends on a chain of delegated controls, and the buyer has to keep operating its part of that chain long after the purchase is signed.

What vendor documents say about who owns each control

Because the chain is split between vendor and buyer, vendor warnings 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's guidance takes a similar approach. Developers are told to map trust lines across user input, chat history, context providers, model services and function tools, and the required practices 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, and it also previews what an auditor, insurer, board committee, procurement lawyer or incident reviewer will ask later. Did the buyer restrict egress and rotate keys? Did it separate trust lines and treat tool output as untrusted? Were logs preserved, and can anyone say which identity the agent used? Were approvals required only where they carried weight, and was revocation tested before production?

None of this proves the vendor innocent after a failure, or the customer liable, since documentation alone does not settle legal responsibility. It does put the control split in writing, and executives should expect that written split to be read later as evidence.

Why this belongs in the C-suite

Security teams can identify controls, but how much commercial autonomy an agent gets is a business decision they cannot own alone. A contract negotiated by legal still leaves each approval threshold to be designed into operations. When finance asks for efficiency gains, someone else has to decide separately how a faster process changes risk. And a board that asks whether AI is governed may get back usage dashboards rather than evidence of who owns which control, since at each of these handoffs accountability has been left ambiguous.

Agent programs often start with productivity claims: fewer tickets, faster summaries, cheaper research. Those claims can be true and still hide the question of ownership. An agent that can act needs someone who owns the limit on its actions, and one that reads untrusted content needs someone who owns the trust rule. Credentials need an owner for the identity model, and a system that learns from outcomes needs an owner for drift and feedback.

At many companies the first serious incident will arrive as a practical question: who allowed the agent to reach that system, trust that input, use that credential, skip that approval or send that output? Refusing every agent does not work either. Anthropic's guidance notes that outright rejection can push adoption into shadow channels with weak telemetry and no off switch. I think the stronger position is bounded risk with a named owner for each control.

What the responsibility matrix should record before production

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

Read vendor guidance before the accident

Treating vendor guidance as pure blame-shifting misses what it is becoming. Vendors will protect themselves, but their agent guidance is turning into accountability infrastructure before any settled liability regime exists. Buyers can use it to reduce blast radius and implementers to see which controls matter; procurement teams can find in it what belongs in contract language, insurers the assumptions to test, and boards the evidence to request.

The companies that get real value from agents will be able to show the autonomy they allowed, the limits they set, which controls they delegated and which they kept, and what happened at each control point. Whether they trusted or distrusted the technology will matter less. So read the documentation as a warning before an accident; after one, someone else may be reading it as evidence of who owned each control.