Researcher demonstrates cross-tenant hijacking of Vaani AI voice agents via BOLA flaw

What the researcher describes

In a first-person write-up published on dev.to, a developer posting as billasur claims to have hijacked AI voice agents belonging to other customers of Vaani, a platform for building enterprise voice agents that recently topped Product Hunt as Product of the Day. According to the account, the attack needed no stolen passwords, no firewall bypass and no zero-day exploit — just a free account's API key and a single HTTP request.

The demonstration took place at a hackathon hosted by the company, where the author says he bet the founding engineer he could break the platform that day and was invited to try. To prove the flaw without causing damage, he says he did not steal data or push malicious instructions. Instead he overwrote the persona of an enterprise real-estate survey agent named Zoe, replacing a carefully crafted 500-word system prompt with a single line telling the agent to answer every question like a pirate. The write-up says the change appeared immediately in the victim tenant's dashboard, meaning the next outbound call would follow the attacker's script. The author adds that the vendor has since patched the issue and that the API keys shown in the post are long-expired test keys.

The technical flaw

The root cause, according to the author, is broken object-level authorization (BOLA), the API equivalent of an IDOR.

The API authenticated requests with a simple X-API-Key header. The agent-listing endpoint correctly scoped its results to the calling tenant, and the agent-deletion route was also protected, returning 403 Forbidden on cross-tenant attempts. But GET and PATCH on the persona endpoint performed no ownership check at all.

Agent identifiers made exploitation straightforward. Slugs followed a predictable pattern combining the organization name and the agent's role — for example prahaladrealestateagent — rather than random UUIDs, so guessing another tenant's agent identifier was trivial for anyone who knew a company used the platform.

Armed with Tenant B's key, the author says a GET request returned Tenant A's complete persona, including the system prompt, company context and private variables, with a 200 OK. A PATCH replacing the system prompt also returned 200 OK. The author attributes the bug to a database query on the persona endpoint that looked up the agent by slug alone, without binding the row to the authenticated tenant — the ownership condition enforced elsewhere was simply missing on this route.

Why voice AI changes the blast radius

In a conventional web SaaS, this class of bug leaks another user's data or changes a profile setting. Voice agents are different: they connect to telephony trunks and place real outbound calls from the customer's verified caller ID. A hijacked persona means a company's own phone line can be made to read attacker-controlled instructions to real customers, live and with no warning to either side. The persona read access adds a second problem, since competitors or attackers could quietly harvest another company's system prompts and private configuration variables.

Why it matters

The write-up is a single, self-published account that has not been independently verified, and the vendor's own confirmation is not cited. But if accurate, it sketches a genuinely new attack surface: companies deploying voice bots hand an AI a phone trunk and their caller reputation, so an authorization bug in the vendor's API becomes spoken social engineering at scale, delivered under a trusted caller ID.

For platform builders, the lessons are conventional but routinely missed: every endpoint that touches an object must verify that the authenticated caller owns it, not just the obvious routes like list and delete; predictable identifiers are safe only when that check is enforced uniformly; and cross-tenant access tests belong in CI.

For enterprises buying voice AI, vendor security now sits directly in the call path. Useful questions include how agent configuration is isolated between tenants, who can modify prompts, and whether changes are logged and alertable — because in voice, the interface an attacker ends up controlling is a human being on the other end of the line.