Anthropic has published it. AWS has built it into Bedrock's architecture. Google has documented it for the Gemini Enterprise Agent Platform. All three have, in their own language and with their own technical designs, drawn a clear boundary around what they are responsible for — and where your responsibility as an agent builder begins.
Most engineering teams building Agentic AI systems today have not read that boundary carefully enough. Not because they are careless. Because they are focused on making the system work. The governance question gets deferred to "later" — which, in enterprise deployments into aviation, healthcare, pharma, or financial services, is precisely the wrong sequence.
I came to this not through a client engagement but through deliberate hands-on research across all three platforms — Claude, AWS Bedrock, and Gemini Enterprise. The starting point was a question that had been nagging at me from thirty years of enterprise architecture work: how do these systems actually handle accountability at the execution layer, when the stakes are genuinely high? I went looking platform by platform, reading not just the technical documentation but the usage policies, the guardrail design, and the contract language that sits underneath the product. What I found was consistent across all three — and more consequential than most builders realise.
Each vendor has deliberately engineered a legal boundary into the architecture itself. The question is whether the teams building on top of these platforms have absorbed what that boundary actually means for their own exposure.
The vendors have not left this ambiguous. They have documented it, built it into their architecture, and structured their contracts around it. The question is whether the teams building enterprise agents have absorbed what that actually means for them.
— Sethunath U N, Chief Consultant & Advisor, Mavis DxThe Architecture Is a Legal Document, Not Just an Engineering Pattern
In every major Agentic AI framework - Claude's tool use, AWS Bedrock's agent actions, Gemini's function calling - the model does not execute actions. It generates a structured request: call this function, with these parameters. Your orchestration layer - your code, your infrastructure, your engineering team's decisions - executes or refuses that request.
This is not an implementation detail. It is a deliberate design choice that carries direct legal consequences. The model generates a recommendation. Your system acts on it. That split in the execution chain is exactly where liability begins to separate.
Anthropic's guidance on agentic systems makes this explicit: the model should be given the minimum necessary permissions and tools. The engineering team controls what is executable - not by trying to constrain the LLM's reasoning, but by controlling what tools exist in the first place. The blast radius of any AI decision is bounded by what your orchestration layer permits. That is an engineering decision. It is also a governance decision. And if something goes wrong in a regulated environment, it will be treated as a legal decision.
What Each Vendor Has Built - and What They Are Saying With It
Reading the three platforms side by side, a coherent pattern emerges. Each vendor has taken deliberate steps to demonstrate that they exercised reasonable care over the model's outputs. And each has structured their architecture so that the deploying organisation - your team - holds accountability for the execution layer.
Anthropic's Constitutional AI framework, and the usage policies that accompany Claude's deployment, exist for reasons beyond product quality. They are a documented record that Anthropic took reasonable steps to prevent malignant use of the model's outputs. In a foreseeability argument - where a court asks whether the vendor knew harm was possible and did nothing - Constitutional AI is Anthropic's answer.
Anthropic's published guidance for agentic deployments goes further. It calls out that agents should request only necessary permissions, prefer reversible over irreversible actions, and confirm with users when uncertain about intended scope. These are not suggestions. They are the design principles that define the boundary of what Anthropic considers appropriate use. If your deployment violates these principles, you are outside the boundary Anthropic has drawn - and outside the protection that boundary provides.
Anthropic's usage policies are not just terms of service. They define the scope of your compliance obligation as a deployer. Building against those principles is not just a policy violation - it is a shift of liability onto your organisation that Anthropic's legal team has deliberately engineered.
AWS's shared responsibility model is the most mature liability framework in enterprise cloud. Most senior technology leaders understand it for infrastructure: AWS owns security of the cloud; you own security in the cloud. Bedrock extends this logic into AI explicitly. AWS is responsible for the model's outputs within the Bedrock platform. You are responsible for what you do with those outputs - what tools you expose to the agent, what systems those tools connect to, and what safeguards you build into the orchestration layer.
Bedrock Guardrails is AWS's equivalent of Constitutional AI in this context. It is a documented, deployable control layer that demonstrates AWS has taken reasonable steps. But Guardrails is a tool you configure. The configuration decisions - what topics to block, what content policies to apply, what thresholds to set - are yours. AWS has provided the mechanism. The choices are the deployer's responsibility.
If your Bedrock-based agent causes harm in a regulated environment and you did not configure Guardrails appropriately for your use case, AWS's position is clear: you owned the configuration. The shared responsibility model is not a safety net - it is a division of accountability that AWS's contracts formalise precisely.
Google's approach through the Gemini Enterprise Agent Platform follows the same structural logic. Model Armor - Google's safety and compliance layer - is the vendor's demonstration of reasonable care. Like Bedrock Guardrails, it is a tool made available to deployers, not a guarantee applied on their behalf.
Google's documentation for Gemini function calling is explicit about a point that applies across all three platforms: the model has no visibility into the systems your functions connect to. When Gemini generates a function call with specific parameters, it is reasoning from the context it has been given - the system prompt, the conversation history, the tool definitions you provided. What happens after that call is issued is entirely within your infrastructure. Google did not design it, cannot see it, and does not control it.
The system prompt and tool definitions you provide to Gemini are the specification the model is executing against. If that specification is poorly designed, incomplete, or does not account for edge cases that could cause harm in your deployment context, the model is not the author of that gap. You are.
The Three Complications That Prevent a Clean Indemnity
It would be convenient to read the above as: the vendors are responsible for the model; you are responsible for the execution; therefore your exposure is bounded to what your code does. That reading is directionally correct but legally incomplete. Three factors complicate it.
Foreseeability
If your deployment allows the agent to take actions in a domain where harm is a foreseeable outcome - financial transactions, clinical data, safety-critical records - your organisation had a duty of care over the design of the execution layer. The architecture gave you the control points. Choosing not to implement adequate controls is a decision courts can scrutinise.
The System Prompt Is Yours
The system prompt is the specification your organisation gave the model. If it instructs the model to behave in ways that enable harm - even by omission, even unintentionally - your organisation authored those instructions. The model executed them. The liability for the instruction sits with the author.
The EU AI Act Creates Two Zones, Not One
The EU AI Act, in force since 2024, places obligations on AI system providers and deployers independently. Anthropic, AWS, and Google each carry obligations as providers. Your organisation carries separate obligations as a deployer. The architecture separates them technically. The regulation formalises them legally. Both zones carry accountability - and neither can outsource its obligations to the other.
Chain of Custody, Not Just Chain of Execution
When the model recommends a function call and your infrastructure executes it against a regulated system, the chain of custody runs through every organisation in that sequence. The vendor drew their boundary. Your organisation's boundary is what your contracts, your runbooks, and your audit logs demonstrate it to be.
What the Precise Legal Effect Actually Is
Stated without softening: the tool-call architecture does not eliminate liability for LLM vendors, and it does not give deploying organisations a clean indemnity. What it does is clearly delineate where each party's accountability begins and ends.
The LLM vendor is accountable for the quality and safety of the model's reasoning and outputs, within the scope of their published usage policies and the reasonable-care steps they have documented. The deploying organisation is accountable for what tools they expose, what systems those tools connect to, what the system prompt instructs the model to do, and what safeguards exist at the execution layer.
This delineation only protects your organisation if you have actually built the governance layer it assumes. An organisation that has given an agent broad tool permissions, written a system prompt that was never reviewed by legal or compliance, and deployed into a regulated environment without documented human-in-the-loop gates for consequential actions - that organisation is not protected by the architecture. It has the structure without the substance.
The architecture is simultaneously an engineering control mechanism and a liability delineation mechanism. If you have only used it as the first, you have not used it as the second.
- Sethunath U N, Chief Consultant & Advisor, Mavis DxWhat "Built the Governance Layer" Actually Means
- Tool permissions scoped to convenience, not minimum necessary access
- System prompt written by engineering, never reviewed by legal or compliance
- No pre-execution audit log of what the agent requested and with what parameters
- Irreversible or high-consequence actions have no documented human approval gate
- Liability boundary defined by the vendor's contract, not by your own documented controls
- EU AI Act deployer obligations unaddressed at go-live
- Tool permission matrix documented, version-controlled, and reviewed against minimum-necessary principle
- System prompt treated as a compliance artefact - reviewed by legal, compliance, and security before deployment
- Full pre-execution audit log: what the agent requested, what parameters, what timestamp, what was approved or refused
- Explicit human-in-the-loop gates defined for actions above a documented consequence threshold
- Deployer obligations under the EU AI Act mapped and addressed before go-live
- Liability boundary documented in your own governance records - not just inherited from the vendor
How to Frame This With Enterprise Buyers
If you are selling a SaaS product that includes Agentic AI capabilities into aviation, healthcare, pharma, or BFSI, the procurement team across the table will eventually get to the governance question. Their legal counsel or CISO will want to understand where your organisation's accountability ends and the model vendor's begins.
The right answer is not a deflection to the vendor's published policies. It is a demonstration that your organisation has read those policies, understood the boundary they draw, and built the execution layer to match. That demonstration consists of artefacts - documented tool permission matrices, system prompt review records, audit log architecture, human-in-the-loop gate definitions, EU AI Act compliance mapping.
The framing that works in that room: the architecture gives our organisation clear control and clear accountability at every layer the model cannot reach. What the model recommends, our orchestration layer validates, approves, or refuses - and every one of those decisions is logged. The vendor has drawn their boundary. We have built ours.
That answer turns a legal concern into a trust signal. In regulated industries, it is the difference between a vendor who has deployed AI and a vendor who has deployed AI responsibly.
Building Agentic AI for enterprise or regulated environments?
The governance gap between what the architecture permits and what your organisation has actually built is exactly where enterprise deals stall - and where legal exposure accumulates quietly. A focused conversation with Mavis Dx will tell you whether your current agentic deployment would hold up in a procurement room with a General Counsel and a CISO at the table.
Outcome-based · No-commit · Monthly engagement
You continue only when you see real value. That is our promise.
Start the Conversation →