Christian Posta asked an AI agent to fix a problem on his machine. It fixed the problem. It also signed him up for AWS services he never requested, and he wasn't sure what else it had touched.
Posta is Solo.io's VP and Global Field CTO. He's one of three people at the company whose experience with an ungoverned coding agent became the reason Solo.io built agentdesktop, an open source project the company released on September 3 to give security and platform teams visibility into what AI agents are doing on employee laptops.
The other two incidents came from Solo.io's own leadership. Idit Levine, the company's CEO, watched her husband ask Claude to fix a problem on his computer. It fixed the problem, and changed other settings without telling him. He didn't find out for days. Yuval Kohavi, Solo.io's chief architect, wanted to hand Codex a task and let it run overnight so the work would be done by morning. Before he could do that comfortably, he needed to know the agent wouldn't do anything destructive while he slept.
"The agent did work nobody saw and nobody had agreed to," said Nathan Pearce, Solo.io's principal technical strategist for enterprise AI, describing the pattern across all three. None of the three needed a security breach to make the point. An agent quietly doing more than it was asked, with nobody watching, was enough.
That gap is wider than three anecdotes suggest. In a March 2026 survey Okta commissioned from Apprize360, 52% of employees admitted to using AI tools their employer hadn't approved, while 90% of executives said they were confident they knew what AI tools were running across their organization. Separately, the 2026 CISO AI Risk Report from Saviynt and Cybersecurity Insiders found that among 235 security leaders at large enterprises, 86% don't enforce access policies for AI identities at all.
Mobile device management tools handle the device layer well: enrollment, patching, disk encryption. What they don't do is know which coding harnesses, MCP servers, skills, and models are actually running on a given laptop, or what any of them are allowed to touch. And the options that exist today for that layer are proprietary, according to Pearce, which means every company ends up solving the same discovery problem privately while the tools themselves change weekly.
agentdesktop runs as a daemon on each workstation. It discovers what's installed, and it translates one centralized policy into whatever native configuration format each tool expects: Claude Code, Codex, VS Code, and OpenCode at launch on September 3, with Cursor and Grok Build added in a v0.1.1 release on September 16. A rule like "deny access to ~/.ssh, allow network access to these domains only" gets written into each tool's own settings rather than bolted on beside it. Because the project is open source, Pearce said support for a new harness can land as a pull request rather than wait for a vendor roadmap, two additions in two weeks, with more PRs arriving as this piece was reported.
Credentials work the same way MDM handles device certificates. A developer signs into corporate SSO once, and agentdesktop installs a credential helper that hands authentication over to the harness. Requests route through Solo.io's agentgateway, where a JWT carrying the user's identity, the device ID, and a client label gets validated and exchanged for the actual provider API key, which never touches the laptop. The access token defaults to a five-minute lifespan; a longer-lived refresh token renews it roughly once a minute while the harness is active.
Pearce didn't oversell what's finished. The client label in that JWT, which tool is asking, is asserted today, not cryptographically proven. "That credential is still scoped to that user, that device, and the allowlist, and it still expires," he said, but another process on the same laptop could theoretically claim a different label. Closing that gap means proving the harness binary is what it says it is, likely through SPIFFE-based identity, and Pearce wouldn't commit to a date. MCP servers are inventoried by agentdesktop today but not yet routed through agentgateway automatically; that wiring is on the near-term roadmap, not shipped.
The project is Apache 2.0, and Pearce said Solo.io is in the early planning stages of an enterprise product on top of it, following the pattern it's used elsewhere with agentgateway. Standalone mode works off a local YAML file for one developer who wants visibility into their own machine. Fleet mode adds a central controller for security teams managing an entire org, and Pearce said the slower part of rollout isn't the software, it's deciding policy. Which harnesses get allowed, what a sandbox permits, what budgets apply per team. Starting with discovery first tends to shorten that argument, since everyone ends up looking at the same inventory instead of guessing at it.
Pearce doesn't expect AI tooling sprawl to disappear. New harnesses will keep shipping, and developers will keep installing them faster than any policy committee can review them. What he expects to change is who owns the response. Fleet inventory of AI harnesses, MCP servers, and skills becomes something a security review checks for routinely, the way device inventory already is, pulled out of platform teams improvising a fix and into the standard audit. The pull toward that, he said, is already coming from CISOs telling Solo.io this is live for them today, not a future problem they're budgeting for later.