Agents Unchecked
WIRED has a new, ugly data point on what happens when “anyone can ship software now.”
Security researcher Dor Zvi and the team at RedAccess looked at AI-generated, “vibe-coded” web apps built with tools like Lovable, Replit, Base44, and Netlify. They identified more than 5,000 apps left on the open web with little to no real security.
The headline number: RedAccess says roughly 40 percent exposed sensitive information, including medical data, financial data, corporate presentations, strategy documents, and logs of customer chatbot conversations. WIRED notes that some platforms emphasized that privacy controls exist, but configuration is ultimately the creator’s responsibility. The exposure is not theoretical. It is happening at scale because deployment is frictionless.
Now add what is showing up inside normal business meetings. The New York Times’ DealBook team reports that AI note-takers are now common on calls, capturing far more than formal minutes: offhand comments, jokes, corrections, and conversational debris humans usually do not preserve. Corporate lawyers are already changing behavior, with some removing the bot before the meeting starts. The New York City Bar Association has warned attorneys to think carefully about AI recording and transcription because of potential discoverability in litigation and unresolved questions around attorney-client privilege.
Then there is Rubrik Zero Labs survey data from more than 1,600 IT and security leaders. Rubrik reports that 86 percent expect AI agents to outpace their organization’s security guardrails within the next year. Only 23 percent say they have full visibility into agents operating in their environments. More than 80 percent say agents require more manual oversight than they save, and 88 percent lack the ability to roll back agent actions without disrupting systems.
Those are three different surfaces: apps, meetings, and autonomous agents. They point to the same reality. AI systems are already inside operations, already generating artifacts, and already outpacing assumed controls.
The failure mode is simple. A tool enters the workflow without inventory. It receives access through a user, connector, mailbox, browser session, or API token. It creates or exposes records the organization did not classify. Then, when there is a leak, discovery request, audit, or disputed action, nobody can prove what the AI touched or whether it stayed inside policy.
That is the observable failure: AI activity is already present, already consequential, and often not provable after the fact.
Control the Bot
AI is moving from “answers” to “actions.” Once it starts taking action inside real workflows, organizations need to standardize who or what is allowed to act, what tools it can touch, what gets reused, and what gets tracked. Without that, every department builds its own version of “how we use agents.”
You can hear that logic in Google’s Cloud Next keynote, as covered by TechRepublic. Google introduced Gemini Enterprise as “mission control” for an agentic enterprise, with an agent registry, skills and tools catalog, and agent gateway enforcing identity and policy. That is a system trying to turn scattered bots into enterprise assets with lifecycle and control.
Microsoft is moving in the same direction through daily workflow. Thurrott reports that Copilot Cowork is expanding onto mobile, adding reusable skills, and plugging into third-party services including HubSpot, Moody’s, and Notion. This is not just chat on a phone. It is a multi-step executor using saved instructions, shared libraries, and standardized connectors.
ServiceNow is anchoring the same idea in enterprise operations. Its Autonomous Workforce push includes role-scoped “AI specialist” agents across IT ops, HR, finance, and legal, framed around enterprise context, permissions, and audit trails. The promise is not just that the agent is smart. It is that the agent can be deployed consistently inside how work already flows.
That is the mechanism: as automation becomes normal work, control moves from “who has the app” to “what can the app or agent do on behalf of the business.” Platform vendors are trying to make that governable inside their ecosystems. MSPs must decide whether they are reselling those controls, stitching them together across vendors, or excluding unmanaged AI activity from scope.
AI Audit Risk
For MSPs, the consequence is not just that clients will want “AI governance.” It is that clients will demand evidence when something goes wrong: who approved the tool, what identity it used, what data it accessed, what records it created, whether logs exist, whether retention rules applied, and whether the activity was inside policy.
Legal exposure may sit with the client. Product exposure may sit with the vendor. Privacy exposure may sit with the data owner. But operational exposure often lands with the provider managing the environment. If the MSP manages Microsoft 365, Google Workspace, endpoint controls, SaaS access, backup, or security monitoring, the client will expect answers when an AI participant is invisible or its actions cannot be reconstructed.
Regulation is also getting more explicit about outcomes and accountability. Silicon Republic reports that the EU and member states reached a provisional deal to simplify the AI Act, including a clear ban on AI-generated non-consensual sexual imagery, and a delay of high-risk AI rules to December 2027 to give standards and tooling time to catch up. The takeaway is not that MSPs must become EU law experts overnight. It is that regulators are drawing sharper lines around what AI systems are allowed to produce, regardless of whether the bad output was intentional, accidental, or “just the tool.”
Risk expectations are also becoming more connected. Black Kite and Sayari announced an integration combining cyber risk intelligence with corporate ownership and supply-chain network data. Their release says, “risk doesn’t exist in silos—but most tools still do.” That is exactly the problem MSPs inherit. The automation layer touches vendors, plugins, identities, and data sources across the stack.
Native platform controls are necessary but not sufficient. Google, Microsoft, and ServiceNow can provide registries, gateways, audit trails, skills libraries, and permissions inside their platforms. But most clients also have browser-based AI tools, meeting bots, third-party connectors, shadow apps, unmanaged automations, and data moving between systems.
That creates the MSP opening, if the service is defined precisely. The offer is not “we govern AI.” The offer is inventory of AI participants, classification of the records they create, review of identities and connectors, retention and transcript policy, rollback planning for agent actions, and evidence packages for auditors, insurers, attorneys, or boards.
That is the strategic fork. Either the MSP governs the automation layer as an explicit service, or it becomes the default absorber of complexity under agreements priced for support, not provable control.
Why Do We Care?
Because AI is becoming a non-human participant inside managed environments. It can access systems, create records, trigger workflows, and generate evidence clients may later need for audits, litigation, incidents, insurers, or boards.
The MSP risk is implied responsibility. If an AI tool touches identities, connectors, mailboxes, SaaS permissions, endpoints, backups, or logs the MSP manages, the client will expect answers and proof.
The bad decision is treating AI governance as informal support. Existing agreements were not priced for unmanaged agents, note-takers, AI-built apps, transcript retention, connector review, rollback planning, or cross-platform evidence reconstruction.
The mistake is assuming vendor controls settle the MSP boundary. They do not. The client still needs one operational answer across the environment: what AI participants exist, what they can access, what they created, and what evidence exists if something goes wrong.
What to Consider
– Start with scope, not tooling. Define which AI activity the MSP governs and which remains the client’s responsibility. Tie that boundary to managed systems: identity, SaaS administration, endpoint controls, backup, logging, security monitoring, and incident response.
– Run an AI participant inventory. Identify note-takers, copilots, agents, AI browser tools, third-party connectors, and AI-built apps. Document the owner, identity used, data touched, records created, retention location, and log availability. This is a billable discovery engagement, not a free assessment.
– Classify AI-generated artifacts. Meeting transcripts, summaries, chatbot logs, generated documents, agent histories, and app outputs should be mapped to sensitivity and discoverability.
– Add AI artifact and non-human participant language to renewals. Define what the MSP governs, what the client must disclose, what vendors own, and what counts as unmanaged AI activity outside scope.
– Build a vendor-agnostic evidence position. Platform controls will help, but clients need one operational view: what AI tools exist, what they can access, what they created, what policy applies, and what evidence exists if something goes wrong.
If this trend continues, MSP contracts will add explicit exclusions for unmanaged AI participants within two years, and clients will pay separately for AI participant inventory, policy enforcement, transcript governance, agent rollback planning, and audit evidence packages.