Public-Facing AI Agents: What They Can (and Can't) Do With Patient Data

Put a chat bubble on your website and anyone who visits can talk to it — no login, no appointment, no relationship with your practice yet. That's different from handing a trained staff member a tool. Before turning on a public AI agent, it's fair to ask what a total stranger could reach through it. This isn't about connecting an outside AI client like Claude.ai or ChatGPT via MCP (a different topic) or your own staff's internal tools — it's specifically about the chat widget on your public website, open to anyone with a link.

ClinikEHR's Agent Studio — our built-in, no-code AI agent builder — was built with this question in mind, which is why a "Public UI" agent operates under tighter rules than an internal one:

• Only agents that never see real patient data in the first place can be published publicly — no exceptions
• That check isn't a one-time setting — it's re-verified before every single message in a conversation
• The action list a public agent can use is a small, vetted allowlist of self-service tasks, not the full toolkit an internal agent has
• Every action that would touch an existing patient's record is permanently excluded by design, not left as a setting to configure carefully
• Rate limits, an optional email requirement, and usage caps sit on top, to curb abuse from anonymous traffic

Quick Answer

A public, no-login AI agent on a ClinikEHR-powered website can only do two kinds of things: look up information that's already public (hours, location, providers, services, membership plans, store products, booking policies), and create brand-new information tied only to the visitor (book an appointment, join a waitlist, leave contact details). It can never look up, change, reschedule, cancel, or confirm anything tied to an existing patient record — permanently excluded, not a setting a clinic could accidentally leave open. This is enforced twice over: only fully de-identified agents can be published, and that's re-checked before every single reply, not just when the feature is turned on. Underneath sits ordinary anti-abuse tooling — rate limits, an optional email requirement, and usage caps — but candidly, there's no CAPTCHA anywhere in this flow. Anti-abuse relies on limits and caps, not a bot challenge.

Why This Deserves a Careful Look Before You Turn It On

Giving staff access to an internal tool and giving the entire internet access to a chat widget are not the same trust decision, even if the underlying technology looks similar. A staff member is trained, identifiable, and accountable to your practice. A visitor typing into a public widget could be a prospective patient, a curious stranger, or someone probing for a weak spot — and you have no way to tell which. Any practice handling patient data has a responsibility to know exactly what that visitor could reach before flipping the switch.

This is worth asking regardless of vendor: not "is your AI safe" as a marketing line, but "what, specifically, can a stranger with no login do through this." A vague answer is itself useful information — the same instinct behind HHS's guidance on Business Associate Agreements: a vendor's commitments matter, and specifics beat a slogan.

What a Public Agent Is Actually Allowed to Do

The permission model for a public agent is narrower than an internal, staff-facing agent's, on purpose. It splits into two categories: things it can look up, and things it can create.

A public agent can:

• Answer general questions with read-only lookups — hours, location, providers, services, membership plans, store products, booking policies. None of this touches an individual patient's data; it's the same information you'd put on a public page.
• Book a brand-new appointment, add the visitor to a waitlist, or take down the visitor's own contact information (name, phone, email) for follow-up

A public agent can never:

• Reschedule, cancel, or confirm an existing appointment — the visitor's own or, especially, anyone else's. A stranger could otherwise fish for someone else's booking, so this is excluded entirely rather than gated behind a setting.
• Look up or edit another patient's record in the practice's CRM (customer relationship management system — where patient and lead information lives)
• Send documents, send or read patient messages, or connect out to any external MCP tool

Notice the pattern: everything permitted is either public information or new information about the visitor. Nothing permitted involves reaching into a record that already exists for someone else. An agent that could confirm "yes, there's an appointment under that name at 2pm Thursday" would hand a stranger a way to probe for another patient's information one guess at a time — so that capability simply isn't on the table.

How This Is Enforced — Not Just Promised

A policy is only as good as its enforcement, so here's the mechanism, not just the intent.

Only de-identified agents can be published at all. ClinikEHR checks that an agent is fully de-identified — built to never see real patient data, not one instructed to behave carefully around it — before a clinic can turn on the Public UI. No configuration path exists for an agent touching real records. (Our companion post on AI agents and HIPAA covers de-identification generally; this post focuses on the public-access model built on top of it.)

That check runs again before every single message, not just once at setup. It would be easy to check eligibility once and never again. ClinikEHR re-verifies it before every conversation turn — no agent gets a pass on a stale approval.

The allowlist is enforced at the tool level, not the prompt level. The actions above aren't a suggestion a clever visitor could talk the agent out of — they're the actual tools available to it. Rescheduling isn't a tool a public agent has, the same way a public web form has no hidden delete-database button.

Abuse controls sit on top. Per-visitor rate limits (per minute and per day, clinic-configurable) stop any one visitor from hammering the widget. A clinic can optionally require an email before chatting, which blocks disposable domains, plus set a monthly message cap. If the credit balance a clinic uses to pay for AI usage runs into a problem, the system fails safely with a generic "temporarily unavailable" message, not an internal error.

The Honest Limits — What This Doesn't Guarantee

There's no CAPTCHA anywhere in this flow. If you're picturing a puzzle test between a bot and your chat widget, that's not part of this system. Anti-abuse is entirely a function of rate limits, the optional email gate, and usage caps — not a bot-detection challenge. We'd rather state this plainly than let "rate limits" imply something stronger.

The optional email gate isn't identity verification. Requiring an email filters out casual abuse and blocks disposable, temporary domains — it does not confirm the person typing is who they claim to be, or a real patient at all. Treat it as friction against low-effort abuse, not proof of identity.

A clinic still has to think about what it tells the agent to say. The permission model draws a hard line around what's possible, but the welcome message and prompts a clinic configures still shape what visitors ask. A public agent restricted to safe actions can still make an awkward first impression if the prompts weren't thought through — that's on the clinic, not something the platform enforces for you.

When to Think This Through Carefully

Do this homework before your first public agent goes live: understand precisely which actions are possible and which are permanently off the table, and don't assume "public" and "internal" agents behave the same way just because they share a builder. Set your rate limits and consider the optional email gate deliberately, based on expected traffic, rather than leaving defaults unexamined. If you notice unusual traffic — a spike in messages, near-identical conversations, or an unexpected jump in monthly agent-credit usage — that's the moment to revisit those settings, not after a bigger problem surfaces. HealthIT.gov's overview of what an EHR is is a useful refresher on why practices are cautious about any new access point into that ecosystem, public-facing or not.

Product Insight: How ClinikEHR Secures Public Agents

• Only fully de-identified agents are eligible to be published as a Public UI — no configuration path exists for an agent that touches real records
• Eligibility is re-checked before every single conversation turn, not just once when the feature is enabled
• The allowlist is enforced at the tool level: read-only lookups (hours, location, providers, services, plans, products, policies) plus create-only actions limited to the visitor's own new information
• Rescheduling, canceling, or confirming an existing appointment; touching another patient's CRM record; sending documents; patient messaging; and external MCP connections are all permanently excluded
• Per-visitor rate limits, an optional pre-chat email requirement that blocks disposable domains, and an optional monthly message cap are all clinic-configurable
• A credit-balance check fails safely with a generic "temporarily unavailable" message rather than exposing an internal error

Explore the Agent Studio feature page, check pricing — Public UI is available starting on the Starter plan — and read our AI agents and HIPAA companion post for the underlying de-identification mechanism.

Frequently Asked Questions (FAQs)

Can a visitor see another patient's appointment through the widget?

No, never. Confirming, looking up, rescheduling, or canceling an existing appointment is permanently excluded, because a stranger could otherwise use that capability to probe for someone else's booking.

Is there a CAPTCHA to stop bots?

No. Anti-abuse relies on per-visitor rate limits, an optional email requirement, and usage caps — not a bot challenge. We'd rather say this plainly than let "rate limits" imply stronger bot-protection than actually exists.

Can I require an email before someone can chat?

Yes, and it's optional — it also blocks known disposable or temporary domains. It's worth knowing this isn't identity verification; it confirms someone provided an email address, not who they are.

What can a public agent actually book or change?

It can book a brand-new appointment, add someone to a waitlist, or take down the visitor's own contact information. It cannot touch anything that already exists.

Does every agent qualify to be published publicly?

No. Only agents that are fully de-identified — built to never see real patient data — are eligible. This is checked at publish time, and re-checked before every single message afterward.

What happens if the widget can't process a request due to a system issue?

It fails safely. If a credit-balance check runs into a problem, the visitor sees a generic "temporarily unavailable" message, not an internal error.

Conclusion

A public, no-login AI agent doesn't need to be a leap of faith. What it can do is narrow by design — public lookups and brand-new information about the visitor — and what it can never do is excluded permanently. That distinction is enforced at the tool level and re-checked before every message, with rate limits and an optional email gate handling abuse underneath. The one place we won't oversell it: there's no CAPTCHA here, and the email gate isn't identity verification.

Key takeaways:

• A public agent can only look up public information (hours, providers, services, plans, policies) and create new information tied to the visitor (bookings, waitlist, contact details)
• Rescheduling, canceling, or confirming an existing appointment, editing another patient's record, sending documents, and patient messaging are permanently excluded
• Only fully de-identified agents can be published, and that check runs again before every single message
• Abuse controls are per-visitor rate limits, an optional pre-chat email requirement, and usage caps
• There's no CAPTCHA anywhere in this flow — say so plainly rather than implying stronger bot-protection
• The Public UI is available starting on the Starter plan, on the same de-identification covered in our HIPAA companion post

See AI in action first with our Free Clinical Notes AI Generator — professional notes instantly, no signup, no credit card.

Ready to see it for yourself? Try ClinikEHR free, compare pricing plans, or book a demo to walk through Agent Studio's Public UI safeguards with our team.

Disclaimer: This article describes the technical safeguards built into ClinikEHR's Public UI feature for AI agents. Overall compliance and safety also depend on your own practice's configuration choices — the welcome message and prompts you set, the rate limits and email-gate settings you choose, and your broader policies around patient data. This article is educational content, not legal or compliance advice. Consult a qualified compliance professional for guidance specific to your practice. ClinikEHR and the authors of this article are not liable for decisions made based on it.

Related Articles

• How to Add an AI Chat Widget to Your Clinic Website
• AI Front Desk: Let Patients Book From Your Website Without Logging In
• AI Agents and HIPAA: What Every Practice Should Know Before Automating
• What Does 'Exposing an AI Agent as MCP' Mean — and Is It Safe for Patient Data?
• How to Choose an AI Agent Platform for Your Medical Practice
• HIPAA Compliance for Shared Office Spaces in 2026
• What Is MCP (Model Context Protocol) for Healthcare AI Agents?
• How AI Voice Agents Reduce Front-Desk Workload