Why Your AI Agent Deployment Is a Vendor Risk Decision, Not a Software Deployment
Image: Depositphotos
Over the past ten years, every executive who has sanctioned a cybersecurity budget can detail the vendor risk process. A SaaS contract triggers a SOC 2 review, sub-processor reviews, data handling reviews, breach notification clauses, etc. NIST and ISO 27001 codify it. It is a developed field.
Almost none of that discipline is being applied to AI agent deployments.
On April 19, 2026, Vercel disclosed that it suffered a breach of its internal systems via a supply chain attack that implicated a third-party AI tool, Context.ai. A Vercel employee registered the Context.ai AI Office Suite with their enterprise Google account and provided “Allow All” OAuth permissions. The harvested OAuth token was then used to take over this employee’s Google Workspace account and penetrate Vercel’s internal systems. A cybercriminal allegedly attempted to sell the breached data for $2 million on BreachForums. Vercel reported that sensitive encrypted values were not accessed, and notified a limited subset of affected customers.
Every executive who read that story processed it as a vendor breach. This perspective illustrates the mismatch most enterprises have yet to articulate. An AI agent with enterprise-level access is structurally the same as a SaaS vendor. It authenticates on your behalf. It reads your data. It operates within your business systems. Its failure modes cascade into your environment. Almost no enterprise I have reviewed treats agent deployments through the vendor risk lens. They consider agent deployments to be like software deployments: internal security review, engineering manager sign-off, identity workflow provisioning.
I have attended many enterprise vendor reviews, but I have never seen an AI agent deployment go through the same process.
The Agent Vendor Risk Test
I use a simple test. If AI agents are able to access regulated data, authenticate through delegated credentials, function within business systems, depend on sub-processors you have not audited, or retain access after a pilot ends, then those deployments are third-party risk management issues, not SDLC issues.
Testing against a standard deployment showcases the issues clearly. The data ownership problem often comes from a vendor contract that no one with DPA background has reviewed. Alleged security postures are vendor self-attestations; the application-layer audit frameworks are still a work in progress. Breach notification clauses are often vague or even absent. Sub-processor chains are more complex than SaaS: foundation model providers, tool registries, embedding stores, and connected MCP servers. Employees give access via OAuth consent screens by clicking “Allow All” on their own authority. Access termination seldom includes a revocation of tokens, a destruction of the ingested data, or audit trails confirming that the data has been cleaned up.
Five concurrent gaps. That is a vendor risk problem shaped like a software deployment.
Figure 1: The same AI agent deployment evaluated through software vs vendor risk lenses.
The market is already repricing
The strongest evidence that vendor-layer AI security is still immature is what the vendors themselves are doing. On March 9, 2026, OpenAI announced the acquisition of Promptfoo, an AI security testing company that is used by more than 25% of Fortune 500 companies, and stated that it will be integrating Promptfoo into its Frontier enterprise platform. OpenAI stated that businesses need systematic ways to test agent behavior and detect risks prior to deployment. The platform layer is acquiring the control layer because enterprises are demanding it.
Gartner predicts that by 2028, custom-built AI-driven applications will be the focus of 50% of enterprise cybersecurity incident response. A Cloud Security Alliance survey released in April found that 82% of enterprises have identified previously unknown AI agents in their environments, with 41% indicating this has occurred on multiple occasions. 65% have had an incident involving an AI agent over the past year.
Previously unknown agents in 82% of enterprises are not a policy problem. It is a vendor intake problem.
The counterargument
The common executive response is that vendor risk processes are slow and will stall agent adoption. Half of that is true. The other half: the cost of a Vercel outcome is measured in direct loss, brand damage, and regulatory exposure. The “move fast, accept the risk” approach is not a risk calculation. It is a refusal to do one. The top enterprises in the next two years will streamline their vendor risk process for agents, not route around it.
Three board-level shifts
In the third-party risk register, AI agent deployments should be considered engagements with vendors. Agents interacting with sensitive or regulated data, financial systems, or customer data will be assigned a vendor file, risk rating, and annual review.
All major deployments need the sign-off of named executives. This includes one CIO, CTO, or head of a business unit on the risk register. Diffused responsibility is what causes Context.ai-class incidents. An employee who provided OAuth consent did not think they were approving a vendor contractual engagement.
Build a vendor risk process calibrated specifically for agents. Include risk-based tiers and a low-risk category for pre-approved agents. Use risk-adjusted thresholds. Focus on high-risk deployments that require an extensive review. Do not use a generic SaaS template.
An agent-driven data breach headline will be published about a peer company in the next six months. Forrester made that prediction in its 2026 Cybersecurity and Risk report. The Vercel incident is not that breach, but it is a near miss. The question that every board must answer is: will your company be the next one?
The framing determines the outcome.
Nik Kale
Nik Kale is a Principal Engineer at Cisco Systems and an ISSIP Ambassador, working at the intersection of enterprise platforms, AI systems, and service innovation.