AI Agent Contracts: Liability, Logging, Kill Switch Terms

When a vendor's AI agent acts inside your systems with your credentials, a standard SaaS or AI contract rarely says who can stop it, what record it must leave, who holds its keys, or who pays when it does something nobody asked for. Those gaps surface during an incident, when the customer finds it cannot halt the agent itself, cannot get the action logs in time, or discovers the vendor holds long-lived tokens to its production estate. This guide covers only the contract terms specific to agents: action logging, the kill switch, credential handling, liability for autonomous actions and the service levels that make them enforceable. Data use, model change, intellectual property and exit terms for AI products in general are in the AI Contract Clauses Guide, which this page builds on. It is written for security, procurement and legal teams negotiating with agent platform vendors and with suppliers whose products include agents. The examples are points to raise with your lawyers, not finished drafting.

Source note: EU AI Act article wording is summarised from the article text on artificialintelligenceact.eu and OWASP and NIST references from their own publications, as checked in November 2026. The term sets, tiers and example points are NHI Mgmt Group recommendations, not legal requirements. Confirm against the official text before relying on it.

Key takeaways

Contract for the action, not just the model. Agent terms must cover what the agent does in your systems: which actions it may take, under which identity, with what record, and how it is stopped.
The customer must be able to stop the agent alone. A kill switch that needs a vendor support ticket is not a kill switch. Agree a customer-operated stop, a maximum time to halt and what happens to in-flight actions.
Logs must outlive the vendor relationship. Require per-action records in a stated schema, delivered to your own storage in near real time, so evidence does not depend on the vendor's retention or goodwill.
Keep credentials on your side. Prefer customer-issued, scoped, short-lived credentials that you can revoke, and require the vendor to disclose where any credential it holds is stored and who can reach it.
Allocate liability by cause. Separate out actions outside the agreed scope, failures of vendor-side guardrails, and customer misconfiguration, and give out-of-scope autonomous actions their own cap or carve-out.

What makes an agent contract different

A model API returns text; a person decides what to do with it. An agent decides and acts: it sends the email, changes the record, runs the deployment, moves the money. That shifts four questions into the contract that ordinary AI terms leave open.

Question	Model or AI feature	Agent	Contract area
What can it change?	Usually nothing directly	Anything its tools and credentials reach	Authorised action scope
What evidence exists?	Prompts and outputs	A chain of decisions, tool calls and side effects in other systems	Action logging
How is it stopped?	Stop using the feature	In-flight work may continue across systems	Kill switch and suspension
Whose keys does it hold?	An API key to the model	OAuth grants, API keys and service accounts into your estate	Credential handling
Who pays for a wrong action?	Output quality warranties	Losses from actions taken without a human decision	Liability for autonomous actions

OWASP LLM06:2025 Excessive Agency names the root causes as excessive functionality, excessive permissions and excessive autonomy, and its mitigations include limiting extension permissions, executing in the user's context and requiring human approval for high-impact actions. Each of those becomes a contract question when someone else builds and runs the agent. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.

Defining the authorised action scope

Every other agent term depends on a schedule that says what the agent is allowed to do. Without it, "the agent acted outside its scope" cannot be proved or priced.

Action schedule: a list of permitted actions by system (for example: read tickets, update ticket status, draft but not send customer emails), with actions that require human approval marked, and a statement that anything not listed is out of scope.
Autonomy level: which actions run unattended, which need approval, and who approves. See the AI Agent Autonomy Levels Framework.
Value and volume limits: per-action and per-day limits on records changed, messages sent and money moved, enforced in the platform rather than in prompts. See the AI Agent Action Approvals and Spending Limits Guide.
Environment boundary: which environments the agent may touch. Production access should be a named, separately approved line in the schedule.
Change of scope: new tools, connectors or permissions need written customer approval before activation, including when the vendor adds them by default in a product update.

The AI Agent Permission Matrix Template works well as the schedule itself.

Action logging terms

When an agent does something unexpected, the first questions are what it did, why and on whose instruction. The answers live in the vendor's platform unless the contract moves them to you.

Term	Example point to negotiate	Why it matters for agents
Record content	Each action logged with timestamp, agent identity, acting-on-behalf-of user, tool, target system and object, parameters, result, and the approval reference where one applied	Lets you reconstruct a chain of actions across systems and attribute it
Decision context	Prompts, retrieved content and tool outputs that led to an action kept and linked to the action record, subject to data protection limits	Distinguishes a prompt injection from a vendor logic fault, which drives liability
Schema	A documented, versioned schema with notice before changes	Detection rules and evidence processes break silently when fields change
Delivery	Streaming or near real-time export to [Organisation]'s SIEM or storage, with a maximum delivery delay of [minutes]	Evidence stays available if the vendor account is suspended or the contract ends
Integrity	Records protected against alteration, with a stated mechanism (append-only storage, signing or hash chaining)	Logs used to allocate fault must be trustworthy to both parties
Retention	Vendor-side retention of [period], plus [Organisation]'s copy, whichever is longer, and preservation on request during an incident or dispute	Regulatory and dispute timelines often exceed default platform retention
Incident access	Full logs for a named agent within [hours] of request during an incident, at no extra charge	Log access sold as a premium tier is a common gap at incident time

Where an agent is part of a high-risk AI system under the EU AI Act, Article 26(6) requires the deployer to keep the automatically generated logs under its control for at least six months, unless other Union or national law sets a different period. If the vendor controls the logs, the contract is how the deployer meets that duty.

An agent's own account of what it did is not evidence. In the Replit AI agent database deletion, the agent deleted a production database during a declared code freeze and then wrongly reported that rollback was impossible; the customer-side lesson was to keep independent logs and backups. Use the AI Agent Audit Log Schema Template as the schedule, and see the AI Agent Audit Trails for Regulators Guide for the regulatory duties behind the retention period.

Kill switch and suspension terms

The EU AI Act sets a useful public benchmark. For high-risk AI systems, Article 14(4)(e) requires that the people overseeing the system can intervene in its operation or interrupt it through a "stop" button or a similar procedure that allows the system to come to a halt in a safe state. Article 26(5) adds that a deployer with reason to believe a high-risk system presents a risk must promptly inform the provider and suspend use, which is impossible without a stop the deployer controls. Most enterprise agents are not high-risk systems, but the principle translates directly into contract terms.

Customer-operated stop: [Organisation] can suspend a named agent, a group of agents, or all agents in its tenant, through the console and an API, without vendor involvement.
Time to halt: the vendor commits that a stop takes effect within [seconds or minutes], including for scheduled and queued actions.
In-flight actions: what happens to actions already started: completed, rolled back or left in a recorded intermediate state, with a report of each.
Containment levels: pause (state kept, resumable), revoke tools, and full disable, each available to the customer. See the AI Agent Kill Switch and Containment Guide.
Vendor-side suspension: the vendor may suspend an agent it believes is acting outside scope or is compromised, must notify [Organisation] within [time], and must not delete state or logs when doing so.
No penalty: suspension by [Organisation] for security reasons does not breach minimum usage commitments or trigger fees.
Testing right: [Organisation] may test the stop in a non-production tenant at least [quarterly] and the vendor supports the test.
Restart: a suspended agent resumes only on [Organisation]'s instruction, never automatically after a timeout or update.

For the policy and legal context, see the AI Shutdown and Kill Switch Laws Map.

Credential handling terms

Agent vendors usually need credentials into your estate: OAuth grants to SaaS tenants, API keys, cloud roles or database accounts. Those non-human identities are often the most powerful thing in the relationship, and the PocketOS database deletion shows why scope matters: a coding agent found an account-scoped token that had been created only to manage custom domains, and used it to delete a production database and its volume-level backups in a single API call.

Term	Example point to negotiate
Who issues	Credentials are issued by [Organisation] to a distinct identity per agent or agent group, not created by the vendor under a human administrator's account
Scope	Each credential is limited to the systems, environments and permissions in the action schedule; account-wide or administrator-level grants need separate written approval
Lifetime	Short-lived or federated credentials preferred; any long-lived secret has a maximum lifetime of [days] and is rotated on that schedule
Storage	The vendor stores [Organisation] credentials in a secrets manager or hardware-backed store, encrypted, never in prompts, model context, agent memory or logs
Isolation	Credentials are not reachable by other customers' agents, by model providers or by sub-processors, and are not shared between agents
Revocation	[Organisation] can revoke any credential at any time without breaching the contract; the vendor revokes on request within [hours] and confirms in writing
Disclosure	An inventory of every credential the vendor holds for [Organisation], with scope and last use, available on request
Compromise notice	Notice within [hours] of any suspected exposure of [Organisation] credentials, with the information needed to revoke them
Exit	All tokens and keys revoked and deleted at termination, with a deletion certificate

See the Vendor contract clauses for credential revocation and breach notice for revocation and notice terms in depth, and the AI Agent Credential Lifecycle and Rotation Guide for the operational side.

Liability for autonomous actions

Standard caps were written for outages and data breaches, not for an agent that deletes records, sends messages or makes payments on its own. The useful move is to allocate by cause, which is only possible if the logging terms above give both parties the evidence.

Cause of the harmful action	Position to seek	Evidence that decides it
Agent acted outside the authorised action schedule	Vendor responsibility, with a separate or uncapped liability line	Action record compared with the schedule
Vendor-side guardrail, approval gate or limit failed	Vendor responsibility, within a raised cap	Approval references, limit configuration, platform logs
Prompt injection through content the agent processed	Shared; vendor responsible where its documented defences were not applied	Decision context showing the injected content and which controls ran
Customer granted excessive permissions or misconfigured limits	Customer responsibility	Credential scope and configuration history
Customer instruction, followed correctly	Customer responsibility	Instruction and action records

Super-cap or carve-out: a higher cap for out-of-scope actions and for breaches of the credential handling and logging terms, distinct from the general cap.
Recovery costs: include restoration of data and systems, regulatory response and third-party claims caused by an agent action within recoverable losses, rather than letting them fall into an indirect-loss exclusion.
Cooperation: the vendor supports root cause analysis and provides the logs needed to determine cause, whatever the outcome on liability.
Insurance: confirm the vendor's cyber and professional liability cover responds to losses caused by its agents' actions, and ask for evidence.

Liability law for agents is moving. Two US proposals published in October 2026 would make AI agent operators and developers answer for agent harms, though neither is law; see the AI Agent Liability Bills Guide.

Service levels that make the terms enforceable

Availability alone says little about an agent. Add measures for the controls above, with service credits or termination rights when they are missed.

Service level	Example measure
Kill switch response	Stop effective within [time] in 99.9 percent of tests and real uses
Log delivery	Action records delivered to [Organisation] within [minutes] of the action, with completeness above [percentage]
Incident notification	Notice of a suspected out-of-scope action or credential compromise within [hours]
Revocation	Vendor-held credentials revoked within [hours] of request
Scope change notice	[Days] notice before new tools, connectors or default permissions

Negotiating by risk

Not every agent deserves the full set. Tier the terms by what the agent can change.

Tier	Example agent	Terms to insist on
Low	Read-only research or drafting assistant	Action schedule, basic logs, credential storage and revocation
Medium	Updates records or sends internal messages	Add log export, customer-operated stop, scope change approval, raised cap for out-of-scope actions
High	Production changes, payments, customer communications, regulated decisions	Full set: integrity-protected logs, time-to-halt service level, customer-issued short-lived credentials, cause-based liability with a super-cap, testing rights

Our recommendation: smaller organisations with little negotiating leverage should prioritise three things: the ability to stop the agent themselves, a copy of the action logs, and credentials they issue and can revoke. Those can often be achieved through configuration and the vendor's standard features even when the paper cannot be changed. Large buyers should push for the cause-based liability table and time-to-halt service levels, and flow them down where the vendor relies on another provider's agent platform.

How to put the terms in place

Inventory agent suppliers. Include products with embedded agents, not only agent platforms, and record each agent's tools, credentials and environments.
Tier each agent using the table above and agree the term set per tier with legal and procurement.
Write the action schedule first. It underpins logging, liability and service levels.
Raise the terms at due diligence, asking the vendor to demonstrate the stop, the log export and its credential storage before signature.
Negotiate, using the low-leverage minimum where the paper cannot move and compensating with configuration.
Test after signature. Run a stop test and a log export test in a non-production tenant before production access is granted.
Keep a fallback. Document how to revoke the vendor's credentials yourself and run the process without the agent, so you can roll back to manual operation if the vendor cannot stop the agent.

Monitoring contract compliance

Terms that are never checked drift. Track:

Stop test results: measured time to halt against the committed level, per test.
Log completeness: sample actions seen in target systems and confirm each has a matching vendor record.
Credential inventory accuracy: compare the vendor's disclosed credentials with what your identity provider and SaaS tenants show.
Unapproved scope changes: new connectors or permissions found that were not approved. Target zero.
Coverage: share of high-tier agent suppliers with the full term set signed.

Framework mapping

Framework	Reference	How the agent terms apply
NIST CSF 2.0	GV.SC-05, GV.SC-06, GV.SC-07, GV.SC-10	Requirements in contracts, due diligence before signature, monitoring during the relationship, and provisions after it ends
NIST SP 800-53 Rev. 5	SA-4 Acquisition Process; SA-9 External System Services; SR-6 Supplier Assessments and Reviews; SR-8 Notification Agreements; AU-10 Non-repudiation; IR-4 Incident Handling	Contracted requirements, oversight of the vendor service, notification, attributable action records and incident support
OWASP Top 10 for LLM Applications 2025	LLM06 Excessive Agency	Action scope, permissions and human approval written into the contract
EU AI Act	Article 14 Human oversight; Article 26 deployer obligations	Stop button as the model for kill switch terms; deployer suspension and six-month log retention for high-risk systems

Common failure patterns

No action schedule. Without a list of permitted actions, an out-of-scope action cannot be shown, so the liability terms never bite.
Stop through support only. The contract promises suspension "on request", which in practice means a ticket queue during an incident.
Logs behind a premium tier. Action logs exist but cannot be exported without an upgrade, or are retained for days.
Vendor-created broad credentials. A vendor engineer connects the agent with an administrator's grant or an account-wide token, as in the PocketOS database deletion.
Instructions treated as controls. A code freeze or "do not touch production" written in a chat or prompt rather than enforced by permissions, as in the Replit AI agent database deletion.

Practitioner checklist

Every agent supplier contract has an action schedule listing permitted actions, approvals and environments.
[Organisation] can stop any agent itself, through console and API, with a committed time to halt.
Action records in a documented schema reach [Organisation]'s own storage in near real time.
Credentials are customer-issued, scoped to the schedule, short-lived where possible and revocable at any time.
The vendor discloses every credential it holds and notifies suspected exposure within agreed hours.
Liability is allocated by cause, with a separate cap for out-of-scope actions and credential breaches.
New tools, connectors or default permissions need written approval before activation.
Stop and log export are tested before production access and at least quarterly after.

AI Agent Contracts: Liability, Logging and Kill Switch Terms to Agree