Most AI vendor contracts were written for software that waits to be asked. You send a request, the software answers, and a person decides what to do with the answer. That is the SaaS model, and the standard master service agreement (MSA) is built around it: uptime, feature availability, data handling, support response times.
An agent does not wait to be asked. It reads data, calls tools, sends messages, updates records, and triggers workflows, often making hundreds of decisions before anyone sees the first one.
That changes where oversight lives. In the SaaS model, oversight is the human reviewing the output. With an agent moving at machine speed, no human can sit in the loop on every action. The controls that keep the agent inside its lane have to run inside the vendor's platform. So the vendor's infrastructure is now part of your control environment, whether the contract says so or not.
That gives the MSA a new job. It has to convert the governance controls you rely on internally into obligations the vendor is bound to support.
Here is what it looks like when that conversion never happens:
- If the vendor runs every agent under one shared service account, your per-agent identity control is a line in a policy with nothing behind it.
- If the vendor's monitoring is a once-a-day batch report, you are not watching the agent act, you are reconstructing what it already did.
- If the vendor's stop command takes 90 seconds to propagate, your stop authority exists on paper and nowhere in production.
None of those gaps show up in a demo. All of them show up when something goes wrong.
The EU AI Act timing may shift under the Digital Omnibus on AI provisional agreement, the AI strand of the broader Digital Omnibus simplification package, which would move certain AI Act application dates if adopted. The contract sequence does not. Vendor support has to be negotiated before production, not after the agent is already acting. Once an agent is live, renegotiating is slow and your leverage is gone. Procurement and renewal are where this gets fixed.
What Changed
Three developments in 2026 moved agent governance from a model-quality conversation to an infrastructure-and-contract one.
Five Eyes agentic AI guidance, dated April 30, 2026. Six intelligence and cybersecurity agencies (CISA, NSA, ASD ACSC, CCCS, NZ NCSC, and UK NCSC) issued joint guidance on the careful adoption of agentic AI services. The shift is the point. It moved the conversation off model quality and onto agent infrastructure: identity, access scope, monitoring, logging, stop mechanisms, and procurement diligence. Those are not model properties. They are platform properties, which makes them vendor properties.
EU AI Act Article 26. Article 26 of Regulation (EU) 2024/1689, the EU's binding rules on artificial intelligence, puts obligations on deployers of high-risk AI systems: the companies using the agent rather than the providers that built it. The regulation entered into force on August 1, 2024, but its obligations apply in phases, and Article 26's deployer duties were not among those applicable at entry into force. They apply from August 2, 2026 under the regulation as published, or from December 2, 2027 for Annex III systems if the Omnibus agreement is adopted; current law remains the published regulation until then. Those obligations include human oversight, monitoring, logging, and cooperation with regulators. The logging language is worth quoting, because it is where most vendor contracts come up short. Article 26 requires deployers of high-risk AI systems to retain automatically generated logs, to the extent those logs are under their control, for at least six months unless another applicable law provides otherwise. Read the qualifier: to the extent those logs are under their control. When the agent runs on a vendor platform, the logs are usually under the vendor's control, not yours. The contract has to create the access, retention, and export rights that turn "the vendor has the logs" into "I can produce the logs."
G7/CISA AI SBOM minimum elements (May 12, 2026). The G7 and CISA published minimum elements for an AI software bill of materials (AI SBOM: a structured inventory of the models, datasets, infrastructure, and security properties inside an AI system). This is procurement documentation guidance, not a binding legal mandate, and that is exactly what makes it useful. It gives a buyer a structured way to ask a vendor what sits inside the system you are about to let act on your behalf. A vendor who can answer is signaling maturity. A vendor who cannot is signaling risk.
That is the regulatory picture. The rest of this article is about what you do with it at the contract table.
The Contract Architecture: Five Controls, Five Vendor Obligations
The Five Eyes build list gives you five internal controls. Each one works only if the vendor's platform supports it, and each support requirement is something you can write into the contract, test before production, and fall back on if the vendor is not there yet. The pattern repeats for all five: the internal control, the vendor dependency it rests on, the contract obligation that secures it, the evidence you ask for, and the fallback if the vendor cannot deliver today.
1. Stop authority
Internal control. You need to halt the agent before it keeps acting.
Vendor infrastructure dependency. The halt command has to propagate through the vendor's infrastructure fast enough to matter for an agent running at machine speed.
Contract obligation. A written time-to-halt, measured in seconds, with the right to test it and defined consequences if the vendor misses it.
Evidence to request. Pre-production stop-test results, incident logs, a propagation report, the support escalation path, and a plain explanation of how the stop command reaches the running agent.
Fallback / roadmap. If the vendor cannot meet the time-to-halt target today, require interim limits on what the agent is allowed to do, plus a committed roadmap date for the SLA.
2. Per-agent identity
Internal control. Each agent has to be separately identifiable.
Vendor infrastructure dependency. The platform has to issue unique credentials per agent, not run a fleet of agents under one shared service account.
Contract obligation. Per-agent cryptographic identity, or an equivalent unique credential, with every log entry tagged to the specific agent.
Evidence to request. Sample logs, the credential architecture, authentication documentation, and the workflow the vendor uses to attribute an action to an agent after an incident.
Fallback / roadmap. If per-agent credentials are not available, require account segmentation, narrowed permissions, enhanced logging, and a committed migration date.
3. Scope enforcement
Internal control. The agent should reach only approved tools, data, and workflows.
Vendor infrastructure dependency. The vendor has to enforce scope before execution, not just report violations after the action runs.
Contract obligation. Default-deny, pre-execution policy enforcement at the vendor's policy decision point.
Evidence to request. Configuration documentation, failed-action logs, policy-enforcement test results, and the change-control process for scope changes.
Fallback / roadmap. If pre-execution enforcement is not available, limit production use, require human approval for high-risk tools, and set a roadmap date for vendor-side enforcement.
4. Drift detection and monitoring
Internal control. You have to catch unusual behavior, performance degradation, or shifts in the agent's action patterns.
Vendor infrastructure dependency. The vendor has to expose telemetry quickly enough for monitoring to change an outcome rather than explain one.
Contract obligation. Real-time or near-real-time observability through API access or vendor-neutral telemetry, with defined alert thresholds and response obligations.
Evidence to request. The telemetry schema, alert latency, monitoring dashboard access, OpenTelemetry or equivalent export capability, and sample anomaly reports.
Fallback / roadmap. If real-time telemetry is not available, require a narrower deployment scope, shorter review intervals, a batch-export timing commitment, and a transition deadline.
5. Concurrent action logging
Internal control. You need a record of what the agent did, when, under what authority, and with what result.
Vendor infrastructure dependency. The platform has to create action-level logs and make them available in a form you can actually use.
Contract obligation. Per-action logs carrying agent identity, timestamp, the tool called, the user or workflow context, the policy decision, and the outcome, plus retention and export rights and timely access through a live API.
Evidence to request. A sample log export, the retention policy, API documentation, timestamp precision, the data dictionary, and a regulator-ready export format.
Fallback / roadmap. If live API access is not available, require short batch-export windows, interim manual report rights, and a roadmap to API-based access.
Run your own agents through these five and you usually find the same thing. The controls exist on your side of the line. The contract is silent on the vendor's side. That silence is the gap.
Decision Framework
Take these into the next renewal or procurement conversation. They are the short version of the architecture above, framed as questions you can ask out loud.
1. Can the vendor show how the stop command reaches the agent, and how long it takes? Why it matters: an agent at machine speed outruns a slow halt. What creates risk: "there is a stop button in the dashboard," with no propagation time attached. What to ask for: a stop-authority SLA in seconds and pre-production test results.
2. Does every agent have its own identity in the logs? Why it matters: you cannot investigate what you cannot attribute. What creates risk: a shared service account, where the log reads "service-account-x performed 47 actions." What to ask for: sample logs showing per-agent credentials and clean attribution.
3. Are unauthorized actions blocked before execution, or only reported afterward? Why it matters: a log of a bad action is a record, not a control. What creates risk: post-execution auditing described as enforcement. What to ask for: confirmation of default-deny, pre-execution enforcement, and the test results that prove it.
4. Can the vendor expose monitoring data fast enough for oversight to matter? Why it matters: a weekly export cannot catch drift while it is happening. What creates risk: telemetry available only in batch, or locked to the vendor's own dashboard. What to ask for: API or vendor-neutral telemetry access with a stated alert latency.
5. Can the vendor produce action-level logs in a regulator-usable format? Why it matters: Article 26's six-month retention is your obligation, but the logs may be under the vendor's control. What creates risk: summary-only logs, batch-only access, or a multi-day fulfillment window. What to ask for: per-action logs, retention terms, and a live export in a standard format.
Who Should Use This Framework
Founders. Use it before renewal or procurement. The question is whether the vendor contract supports the governance program you are already relying on.
Operators. Use it before production. The question is whether the control actually works inside the vendor's architecture, not just inside your internal policy.
Boards and investors. Use it during diligence. The question is not only whether the company has an AI governance program, but whether its vendor contracts require the infrastructure that program assumes. A governance posture the vendor is not contractually bound to support is a slide, not a control.
Practical Takeaways
- Map the Five Eyes build list to your master service agreement, control by control, before the next renewal. These agent controls sit on top of the 12 clauses every AI vendor contract should already cover; agents add a layer, they do not replace the baseline. This converts the Five Eyes guidance from a reading exercise into a contract gap analysis with a clear next step.
- Require per-agent identity, with every log entry tagged to a specific agent. Shared service accounts are a single attribution failure away from an incident you cannot investigate.
- Require pre-execution scope enforcement: default-deny, at the vendor's policy decision point. Post-execution auditing is a record of what happened, not a control over what happens.
- Require a stop-authority latency in seconds, with testing rights and consequences for failure. A stop button you have never tested in production is not a stop mechanism.
- Require live logs, monitoring access, and at least six-month retention with export rights, to satisfy Article 26's retention obligation even when the logs sit on vendor infrastructure.
- Require AI SBOM-aligned governance documentation in the procurement RFP. A vendor who cannot answer the G7/CISA minimum elements question is signaling a maturity gap before the contract is signed.
Two Additional Clauses Worth Adding
Two clauses sit outside the five-control architecture but belong in the same agreement.
Substantial-modification notice and confirmation. Retraining the vendor's agent on your data, expanding its scope, or wiring in tools the vendor did not anticipate can change your role under the EU AI Act, potentially moving you from deployer to provider, with the heavier obligations that follow. The contract should require you to give notice and get the vendor's confirmation before that kind of change, and it should allocate who carries the added responsibility if the line gets crossed.
Model or system replacement cooperation. FTC enforcement history shows that AI-related remediation can reach the model or system itself, not just the marketing claim or the data practice. If a vendor-caused compliance problem forces a model to be rebuilt or replaced, you do not want to learn the cost and timeline in the middle of the emergency. The contract should allocate cooperation, a replacement timeline, and cost responsibility in advance.
Renewal Diligence Checklist
Use this at every renewal or new procurement where the vendor's system includes an agentic component. Each item maps to one of the five controls above.
- Stop authority: written time-to-halt SLA in seconds, testing rights documented, consequences for missed SLA defined
- Per-agent identity: credential architecture reviewed, sample logs confirm per-agent attribution, not shared-account attribution
- Scope enforcement: default-deny confirmed, pre-execution enforcement verified by test results, scope-change process documented
- Drift detection: telemetry API or export access confirmed, alert latency stated, anomaly-report format reviewed
- Action logging: per-action log format reviewed, six-month retention confirmed, regulator-ready export format available
- AI SBOM: vendor has provided or committed to G7/CISA minimum elements documentation
- Substantial-modification notice clause: present and allocates provider/deployer role shift
- Model or system replacement cooperation clause: present and allocates cost and timeline responsibility
Closing Perspective
The build list tells you what governance needs to exist.
The vendor contract determines whether that governance can operate.
For agentic AI, procurement is no longer just a commercial workflow. It is part of the control environment.
The companies that find the gap at renewal will have options. The companies that find it after deployment will have explanations.
This article is general educational analysis. It does not provide individualized legal advice, client-specific recommendations, outcome guarantees, or jurisdiction-specific directives without factual context.
This article is for informational purposes only and does not constitute legal advice. Every company's situation is different, and you should consult with qualified legal counsel before making compliance decisions based on the developments discussed here.
Primary materials referenced
- Australian Signals Directorate, U.S. Cybersecurity and Infrastructure Security Agency, U.S. National Security Agency, Canadian Centre for Cyber Security, New Zealand National Cyber Security Centre, and U.K. National Cyber Security Centre, "Careful adoption of agentic AI services," April 2026.
- Regulation (EU) 2024/1689 (EU AI Act), Articles 25 and 26; Article 113 phased application, June 2024.
- G7 Cybersecurity Working Group and Cybersecurity and Infrastructure Security Agency, "Software Bill of Materials (SBOM) for Artificial Intelligence: Minimum Elements," May 2026.
- Federal Trade Commission, enforcement actions reaching model or algorithm remediation: In the Matter of Everalbum, Inc. (2021); In the Matter of Weight Watchers International, Inc. / Kurbo (2022); In the Matter of Rite Aid Corporation (2023).
- National Institute of Standards and Technology, Special Publication 800-207, "Zero Trust Architecture," August 2020.
- National Institute of Standards and Technology, "AI Risk Management Framework (AI RMF 1.0)," January 2023.