IBM's Third-Party Agent Governance Guide Sets an Enterprise Control Baseline
What happened
IBM's guidance document, How to effectively govern third-party AI agents across the enterprise, sets out a full operating model for organizations that deploy or procure AI agents built and maintained by outside vendors. The guidance recommends that enterprises inventory every agent and assign a named accountable owner. Each agent should be classified by how autonomously it can act and how much harm it could cause if it behaved unexpectedly. It then calls for applying least privilege, meaning agents should receive only the access they need for a specific task. It also calls for least agency, meaning agents should take the minimum set of actions needed to complete their work. Importantly, IBM requires that governance assessments be repeated, not just completed at initial deployment, whenever an agent's underlying model, toolset, granted permissions, provider, or stated business purpose changes. This reflects the same accountability gap that 55% of organizations running system-changing AI agents without identity controls have exposed. The FTC's industry-wide probe into rogue AI agent risks has made the same gap visible.
Why it matters
- ·Third-party agents are a named enforcement target. The FTC Enforcement on AI (Section 5 of the FTC Act) covers harms caused by agents enterprises deploy, regardless of who built them. IBM's guidance gives compliance teams a documented, defensible standard to point to when regulators ask how third-party agents were evaluated and controlled.
- ·Change events are the blind spot most programs miss. IBM requires reassessment when an agent's model, tools, permissions, provider, or purpose changes. This directly addresses the pattern seen in incidents documented in OpenAI's nine rogue AI incidents, where agents behaved unexpectedly after a vendor update. Without a formal reassessment trigger, enterprises carry unknown risk between reviews.
- ·Behavioral evidence retention is becoming an audit expectation. Regulators and examiners increasingly want proof of what an agent did and why, not just that controls existed at deployment. IBM's call to retain behavioral records aligns with banking examiners now asking banks to prove AI agents can be audited. The same expectation is spreading beyond financial services.
Governance controls affected
What to do now
- ☐Build or update your agent inventory to include every third-party AI agent currently running in production, noting the vendor, the business purpose, and the level of access each agent holds.
- ☐Assign a named internal owner to each third-party agent who is responsible for approving changes, triggering reassessments, and escalating incidents.
- ☐Define the change events that require a fresh governance review, at minimum: model version updates by the vendor, new tools or integrations added to the agent, changes to the permissions the agent holds, provider switches, and any shift in the agent's stated business purpose.
- ☐Verify that your contracts with third-party agent vendors require them to notify you before making changes that would trigger a reassessment, and check whether existing agreements already cover this.
- ☐Confirm that your audit logs capture what each agent did, what data it accessed, and what decisions or actions it took, and that those records are retained long enough to satisfy any applicable regulatory review window.
What to watch next
The convergence of regulatory enforcement and practitioner guidance is accelerating. The FTC's open probe into rogue agent risks, the ECB's October 31 deadline for bank AI cyber action plans, and examiner pressure on agent auditability all point in the same direction. Formal third-party agent governance requirements are becoming enforceable expectations rather than voluntary best practice. Compliance teams should watch for the Five Eyes Guidance on the Careful Adoption of Agentic AI Services to be cited in enforcement actions. Teams should also monitor whether the EU AI Act (Regulation (EU) 2024/1689) obligations for high-risk AI systems are interpreted to cover agents procured from third-party vendors, not just those developed in-house.
Stay ahead of stories like this
Get every Global AI governance development like this one, plus the rest of the week's developments. Every Thursday.
Recent issues
- Three separate incidents this week reveal that AI vendors cannot be trusted to self-police, and that harm from deployed agents can run unchecked for months before anyone inside the organization notices.15 Oct
- AI systems built to extend your reach are now extending attackers' reach too, and regulators in California and South Korea are making clear that containment failures belong to deployers, not just vendors.8 Oct
Free every Thursday. Unsubscribe anytime.