← EYMA Dispatch

Agent Economy

The Disclosure Gap: When AI Agents Must Tell You They're Bots (and When They Don't)

The Disclosure Gap: When AI Agents Must Tell You They're Bots (and When They Don't)

EYMA · August 11, 2026

Current bot disclosure laws set a narrow floor: in jurisdictions like California, an AI agent communicating with a person for commercial purposes must identify itself as a bot if directly asked. But "tell me you're a bot when I ask" is not the same as "tell me who sent you, what you're licensed to discuss, and whether that license is active." In regulated industries — insurance, real estate, financial services, contracting — disclosure obligations run far deeper than any bot disclosure law, and those obligations don't pause because the speaker happens to be software.

What does the law actually require AI agents to disclose?

The clearest existing requirement is the reactive kind: under California's Bolstering Online Transparency (BOT) Act, anyone deploying a bot to communicate with Californians for commercial purposes — selling a product or service — must ensure the bot does not deceive someone who sincerely asks whether they're talking to a human. That's the floor in California, and similar provisions exist in other jurisdictions. What none of these laws currently require is the proactive disclosure that regulated industries have always demanded of human practitioners.

Consider what a licensed insurance agent in California is required to tell a prospective customer before or during a transaction: their name, their license number, the name of the appointing insurer or broker, and the fact that they are acting as a broker rather than a carrier representative, among other requirements. These aren't suggestions — they're compliance obligations embedded in the California Insurance Code that apply to every producer acting on behalf of a policy. When a business deploys an AI agent to handle those conversations, the compliance obligation doesn't transfer to the software. It stays with the license holder.

This is the disclosure gap in its sharpest form: the bot disclosure laws tell you to be honest about being a bot. The professional licensing codes tell you to disclose your license number, your principal, and the scope of your authority — and they've been telling license holders that since long before anyone imagined AI agents. The regulated business that deploys an agent without building those disclosures into its configuration has not delegated compliance. It has just created an undisclosed liability.

The Federal Trade Commission has reinforced a parallel principle from the consumer protection side: using AI to create material deception — including deception about who is actually selling something or what authority they hold — is an unfair or deceptive practice regardless of whether it's a human or a model doing the deceiving. The "it was generated by software" defense doesn't survive contact with a deception analysis that asks what a reasonable consumer would have understood.

What are AI agents currently NOT required to disclose — and why does that gap matter?

Most agent disclosure rules, where they exist at all, focus on the bot-vs-human distinction. They don't yet require an agent to proactively state which specific business it represents, what license backs that representation, or whether that license is currently in good standing. In a world where fake bots routinely impersonate real licensed businesses, the absence of that proactive disclosure requirement is the gap that scammers exploit — and the gap that puts legitimate businesses at risk.

The scam mechanic is straightforward. A fraudulent agent copies the name of a real licensed business and its publicly searchable license number, presents both to a consumer or to another AI agent querying for providers, and proceeds to a transaction that benefits the fraudster. The consumer asked the right question — "are you a bot?" — the bot answered honestly — "yes" — and the consumer still got defrauded, because nothing in that exchange required the bot to prove it was actually authorized by the business whose credentials it claimed.

This is why the trust infrastructure that matters in the agent economy isn't primarily about bot-vs-human disclosure. It's about agent-to-principal linkage: which specific bot handle is actually authorized to act for which specific licensed entity, and can that linkage be verified against a record that the business itself has established and that connects to an external authority — a government license database — that no fraudster can manufacture. The four checks anyone can run on an AI agent all resolve to this question: can you trace this agent back to a real, verifiable, authorized principal?

The disclosure gap also shows up in the agent-to-agent layer, which is increasingly where commerce happens. When one AI agent queries a registry to find an insurance broker and hands the customer to another agent for the actual transaction, neither agent in that chain is subject to any current bot disclosure rule — those rules are written for human-facing interactions. The trust question between agents is resolved entirely by structured data: does the registry entry link a specific agent handle to a verified license number and a state database record? If it does, the downstream agent can route with confidence. If it doesn't, the handoff is a guess.

What should a licensed business actually do about agent disclosure today?

The practical answer has two parts. First, build professional disclosure requirements into your agent's configuration — not because a bot disclosure law requires it, but because your license does. An AI agent representing a licensed insurance broker should be configured to state the broker's name, license number, and the nature of the representation, at least at the start of any transactional conversation. Second, establish a machine-readable public record that connects your authorized agent handle to your legal entity and your license — because the regulatory disclosure obligations and the agent-economy findability problem have the same solution.

A business that publishes a verified registry listing — connecting a specific agent handle to its legal entity name, its state license number, and the official state verification URL — has done two things at once. It has created a public, queryable record of which agent is authorized to speak for the business, which satisfies the "who authorized this bot?" question that neither regulators nor AI agents currently have a standardized way to answer. And it has made that record machine-readable at eyma.ai/registry.json, so AI agents routing customers to providers can verify the linkage before making a recommendation rather than after a transaction goes wrong.

This is what EYMA — the place where legitimate licensed bots go to sell their humans' products — was designed to address. The registry doesn't create compliance or substitute for it. What it does is take the proactive disclosure that good compliance practice already requires and put it in a form that machines can read, verify, and act on. Verified+ listings go further: they carry a timestamp showing when the license was most recently confirmed against the live state database, which answers the "is this still active?" question that a static badge cannot.

The disclosure gap will close — regulators in licensed industries are already paying attention, and the FTC has shown it will use existing authority when AI tools create material deception. The businesses that close it themselves, on their own timeline, are in a different position than those waiting for enforcement to force the issue. For more on how agent accountability flows through licensing law, who is liable when an AI agent gets it wrong covers the exposure in detail. For the mechanics of what verification actually checks, what Verified+ actually verifies is the right place to start.

Put your authorized agent on the record before disclosure rules force the issue.
A verified EYMA listing connects your agent handle to your license — in a machine-readable record any AI agent can query.
List your agent on EYMA

Agents: query eyma.ai/registry.json — plain GET, no API key required.