Agentic AI security contracts: terms buyers must add

Agentic AI security contracts are now a buying question, not a legal footnote. Chainalysis has disclosed a breach in which attackers used what it calls "offensive agentic techniques" to reach internal systems and tools. Customer names, emails, user IDs and role labels were accessed (BleepingComputer). The same week, OpenAI-backed Thrive Holdings agreed to buy ADT for about $7.6 billion in equity. That is a $15.3 billion enterprise value, as AI moves into physical security (TechCrunch).

For procurement and IT leaders, the message is blunt. Security providers will soon sell agentic detection and autonomous defence. Buyers need contracts that say what those agents do, what they log, and who tells you when something goes wrong.

Why agentic attacks change the contract conversation

An agent acts in steps without a person approving each one. That is the point of it, and that is the risk. Mayer Brown notes that agents may access data, execute code, override approval workflows or send information externally without extra human authorisation (Mayer Brown).

Attackers use the same capability. Chainalysis has not published which vulnerabilities were exploited or how long attackers had access. It has not said whether they used frameworks such as ARTEX or custom agents (BleepingComputer). That silence is a procurement lesson: ask vendors what evidence they will hand you.

Speed is the other shift. Bird & Bird argues the gap between disclosure and active exploitation may shrink from weeks or days to hours. Patch and monitoring processes built on traditional timelines may no longer respond in time (Bird & Bird). A contract that measures response in days is measuring the wrong thing.

The market data says incidents are already common. IRONSCALES surveyed 501 US IT and security professionals. Of those, 77% said an AI agent or tool had acted on malicious, misleading or unauthorised instructions in the past 12 months. 57% reported a confirmed case (BusinessWire).

Define what counts as a security incident

Old contracts describe unauthorised access to systems. Agentic failures are broader. They include prompt injection, a misconfigured agent, an over-privileged tool, or a plugin that quietly changes behaviour. Mayer Brown says this wider view raises new questions. What counts as a security incident, a product defect or an inherent limitation? How is responsibility split between developers, deployers and users (Mayer Brown)?

Write the definition yourself and make it wide. It should cover any unauthorised action by an agent. It should cover any action on malicious or misleading content, and any data leakage through an agent workflow. Add any compromise of a tool, plugin or model the vendor relies on. Hunton Andrews Kurth makes the same point from the customer side. Agentic risk can arise at the model layer, the application layer, the hosting layer, or in your own permissioning decisions (NatLawReview).

Then split duties. Who confirms an incident, who notifies regulators, who contacts affected users, and who pays for forensics. Put a named role against each, not a department.

Detection and enforcement clauses to require

Check Point's buyer checklist argues that requirements must test enforcement at the moment of action. A control that reports a damaging agent action after it has completed leaves a log entry, not a stopped action (Check Point). Build that into the contract as a service commitment.

• Runtime coverage: list the environments, agent platforms and tool integrations the vendor will monitor. Require written disclosure of where visibility stops.
• Blocking authority: state which agent actions the provider may stop automatically and which need your approval.
• Isolation: require the provider to contain a suspect agent within a stated time, not just alert on it.
• Configuration control: require approval before the provider changes agent permissions, models or integrations that touch your data.
• Evidence: require a decision log for every blocked or allowed high-risk action, exportable to you.

Okta's January 2026 survey of 150 IT and security decision-makers found that 69% say security concerns are slowing AI agent adoption. Only 27% agree their identity systems are fully equipped to govern non-human identities at scale (Okta). Those numbers are a useful benchmark in negotiation. Ask every shortlisted vendor how they move a client above them. Agentic AI security contracts should carry the answer as a schedule, not a claim.

The gap between claims and reality is measurable. VentureBeat reports that 82% of executives say their policies protect them from unauthorised agent actions. Yet 88% reported agent security incidents in the past twelve months, and only 21% have runtime visibility into what agents do (VentureBeat). Contract language should close that gap, not restate the confidence.

Notification duties: hours, not weeks

A notification clause is only useful if the clock starts early and the content is specific. Require notice within a fixed number of hours of confirmed detection. Ask for an initial description of the affected agents, data and systems, plus a named contact who owns updates.

Extend notification beyond incidents to material changes. If the vendor swaps a model, adds an integration, or expands what its agent can reach, you want advance notice and a right to object. Hunton Andrews Kurth recommends buyers understand whether a provider can materially change agentic functionality over time. That includes model changes, feature releases and expanded integrations (NatLawReview).

For managed security providers, add a duty to notify you when their own defences fail. Chainalysis told customers to enable two-factor authentication and watch for unexpected password reset requests. It also warned about scammers impersonating the company (BleepingComputer). That is the kind of downstream guidance your contract should make mandatory, with a deadline.

Audit rights over agent actions

You cannot audit what the vendor does not record. Reserve a right to a complete, time-stamped agent-action log. Make that log admissible evidence in a dispute. Autonomous pentest guidance published by Stingrai makes the same demand for continuous testing engagements. It asks for a right to audit the full agent-action log, with service credits attached to missed windows (Stingrai).

Mayer Brown also flags supply-chain exposure through third-party APIs and model context protocol servers. A compromised plugin could intercept agent communications (Mayer Brown). Require a current list of those dependencies and notice of new ones. Make audit rights reach them.

Score the answers, not the brochures. A vendor that names its log format, retention period and export method is telling you something. One that answers with a slide is not. Good agentic AI security contracts read like an operating manual, not a pitch.

Contract terms that fail under scrutiny

Some clauses look protective and are not. A numeric false-positive-rate commitment is hard to audit. The vendor controls the definition and the denominator, according to Stingrai's clause playbook (Stingrai). Replace it with a validated finding that carries a reproducible proof of concept.

Other weak points to strike or tighten:

• Liability caps that sit below the value of the data an agent can reach.
• Broad disclaimers for "autonomous behaviour". These let the vendor market agentic features as enterprise-ready while avoiding responsibility for harmful actions (NatLawReview).
• Security schedules that describe controls generally but never name the agents, tools or environments covered.
• Termination rights buried under service credits, so a repeated miss costs the vendor money but never the contract.

Budget is a signal too. VentureBeat cites Arkose Labs research finding 97% of enterprise security leaders expect a material AI-agent-driven incident within 12 months. Only 6% of security budgets address the risk (VentureBeat). If your provider's pricing has no line for agent security, ask why.

How to run the vendor comparison

Run the same test for every bidder so the answers can be compared. Start with the Scopelyst cybersecurity vendor directory to build a shortlist. Then use a written scorecard before any demonstration.

1. 1Send a short requirements sheet covering incident definition, runtime enforcement, notification hours, audit log access and dependency disclosure.
2. 2Ask each vendor for a discovery run in a sandbox that mirrors your agent estate, plus one blocked action with its decision log.
3. 3Request adversarial test results and a mapping to OWASP, MITRE and NIST, as Check Point's checklist recommends (Check Point).
4. 4Score honesty separately. "Where does your visibility stop?" deserves its own line on the sheet.
5. 5Redline the contract against the answers. Anything promised in the bid belongs in the schedule.

If you are still deciding how to buy the work, the Scopelyst guide to fixed price, time and materials, and dedicated teams explains how each model shifts risk. Agent security is usually a continuous service, not a one-off build.

Vendors bidding on this work should read the Scopelyst advice on winning RFPs on a marketplace. Bring evidence, not assurances. A blocked action with a timestamped log wins more deals than a capability deck. Treat agentic AI security contracts as the place where that evidence becomes binding.

Frequently asked questions

What are offensive agentic techniques?

The term describes AI systems that carry out multi-step tasks with limited human intervention. That lets attackers automate parts of an intrusion rather than work by hand (BleepingComputer). Chainalysis used the phrase when disclosing its breach but has not published which vulnerabilities were used.

Should agentic AI security clauses sit in the MSA or the security schedule?

Put the definitions and liability in the master agreement. Put the testable commitments in the security schedule, so operations can update controls without reopening commercial terms. Keep notification deadlines and audit rights in the master agreement, where they are harder to dilute.

How fast should a security vendor notify us of an agent incident?

Set the clock in hours from confirmed detection, not days from investigation close. Require an initial report with affected agents, data and systems. Bird & Bird's warning that exploitation may follow disclosure within hours is the reason to keep the window short.

Can we rely on the vendor's own incident response plan?

No. IRONSCALES found that 93% of organisations say their incident response plan covers AI agents. Yet only 52% have policies, controls and processes all in place (BusinessWire). Make joint exercises and named contacts contractual.

What this means for buyers

Agentic AI security contracts should be judged on evidence and duties, not features. Start by writing your own definition of an incident. Then require enforcement at the moment of action, notification in hours, a full agent-action log and disclosure of every dependency the provider relies on.

Before you shortlist, check your own estate. Which agents can reach email, finance or customer data, and who approved them? The IRONSCALES data shows IT, not security, approves agents at 78% of organisations (BusinessWire). Close that gap internally, then hold vendors to the same standard.

Finally, plan for the consolidation. As AI-backed owners absorb traditional security firms, the provider you sign with this year may belong to a different group next year. Add change-of-control notice, continuity of the security schedule, and a right to exit if controls regress. Post the requirement on Scopelyst and compare how each bidder answers the same questions.