Agentic AI Red Teaming for Patient Access
The front door was already fragile, and personal and provider-side agents are changing its scale, speed, and operating assumptions.
Patient access was a systems problem long before either a patient or an agent reached us through a web browser. When 14-year-old Charlie Mayo connected his father's medical office to the family farm with Rochester's first telephone line in 1879, people who needed the doctor still had to make their needs known at a local drugstore during the day or find the night watchman after hours, because someone had to operate the line and pass along the request. By 1930, house calls still represented 40 percent of physician-patient encounters, and country doctors often spent much of their day traveling from a small home office to patients on farms or in their homes; the setting was more personal, but timely access still depended on a familiar sequence: receive the request, find the doctor, and decide what happened next.
Our patients still depend on us for timely access, but those of us who work in patient access already know that they are no longer comparing the experience with the small-town doctor who knew every family; they are comparing it with Amazon delivery, where the experience feels simple because a request is visible and the next step seems to happen without another phone call. That expectation is rising just as AI agents begin reaching public scheduling workflows through portals and websites, while healthcare organizations deploy their own voice agents to answer the access-center line.
The Front Door Now Has Software on Both Sides
Where an AI chatbot usually answers a question, an AI agent can carry the work forward: it makes a plan, uses tools to carry it out, and reports what changed. In a sufficiently connected patient-access workflow, one request could leave the patient with an appointment scheduled and transportation arranged before they return to the conversation; the operational difference becomes clear when the agent books, cancels, or reschedules, because that is the moment a helpful conversation becomes a change in the authoritative record.
Readers may have heard this broader category described through Hermes Agent and OpenClaw, both of which can use browsers and carry work across multiple steps; ChatGPT Codex and Claude Cowork bring the same idea of delegated computer work into products many leaders may already recognize. These agents were built for broader work, but their relevance to patient access is straightforward: software that can operate a browser can reach a public scheduling workflow without carrying a healthcare label.
Inside healthcare, the names can become confusing because the agents serve different sides of the front door. Zocdoc's Zo sits on the provider side, answering practice calls and booking directly into the EHR under the organization's scheduling rules; Epic's Emmie gives patients a natural-language text conversation for scheduling or rescheduling without a call or portal login. Amazon One Medical's Health AI is another patient-side example within the One Medical ecosystem, where Amazon says the assistant can book appointments and manage medications. These first-party descriptions establish the capabilities each company offers; architecture, adoption, and safety still require evaluation in the local deployment.
Healthcare management publications are already treating this as a patient-access issue, with a 2025 American Journal of Healthcare Strategy overview naming appointment scheduling as a single-agent use case and an American College of Healthcare Executives program describing both referral calls and phone bots that change appointments. The Healthcare Financial Management Association's consumerism model also places real-time scheduling and AI-supported care prompts among advanced access capabilities; we should therefore expect encounters in which a patient's agent reaches one of our provider-deployed agents before service identities and connectors carry the result into the record.
The Old Access Problem Did Not Disappear
Patient-access leaders have spent years trying to make entry into care accurate, timely, and navigable, so the underlying problem should feel familiar: unreliable information sends patients toward a dead end, while inconsistent scheduling logic can place them with the wrong service even when every person involved is trying to help. A 2025 Delphi study of access leaders identified appointment accuracy, availability, and capacity management as core determinants of access, with contact-center management and good data supporting the work. A 2024 Government Accountability Office review then found an error in most behavioral-health provider listings from the sampled TRICARE directories, including inaccurate locations or phone numbers; the threat was already present in ordinary operations.
Digital self-service carried the same complexity onto the web, where a Delphi panel on automated self-scheduling documented variation across specialties and providers alongside concerns about insurance and referral requirements. The panel also identified triage, incomplete information, and template design as practical problems, which means the agent will inherit the same rules our teams have been working to simplify. A stale directory lets the agent call the wrong number faster, inconsistent routing lets it repeat the wrong path more efficiently, and a schedule that accepts an invalid transaction lets automation reproduce the error without fatigue.
What Changed Is Scale, Speed, and Agency
Leaders will sometimes hear this shift summarized as, "there are more agents on the internet than humans," and the phrase captures the feeling of an internet increasingly shaped by automated activity, although the available evidence leaves that literal head count unresolved. In the 2026 Thales Bad Bot Report, automated systems generated more than 53 percent of the web traffic observed during 2025, compared with 47 percent attributed to humans. The figure measures traffic and cannot be read as a census of personal AI agents because the category includes conventional crawlers, scripts, and malicious bots; the report offers no evidence that autonomous agents outnumber people.
Even within that boundary, machine interaction is already a normal condition of operating an internet service; newer agents add the ability to pursue a goal, choose a route, and adapt after a failure. A patient-access workflow built around human pace may now receive continuous searches or parallel calls, with rapid retries arriving across channels; access policy must preserve legitimate requests while governing capacity, authority, and fairness at machine speed.
Figure 1 · The patient-access scale shift
The access problem remains. Software changes its pace and reach.
Agent-mediated access brings new actors into existing scheduling workflows. They can remain active, change routes, and repeat actions across the same capacity constraints.
A patient, caregiver, or staff member works through one call or portal session.
A patient-side or provider-side agent works through a browser, voice system, or service identity.
The work is usually serial and constrained by attention, hold time, and office hours.
The work can continue in parallel, monitor capacity, and retry without fatigue.
The person follows the phone tree, portal path, or handoff the organization presents.
The agent can move between web, voice, and connected tools when one path fails.
Stale information or a broken referral can send one patient down the wrong path.
The same weakness can be found, retried, and reproduced across more patients or channels.
One caller waits, leaves the queue, or occupies one scheduling position at a time.
Continuous monitoring and parallel requests can change who reaches scarce capacity first.
Leaders need accurate information, usable routing, and a correct appointment.
Leaders also need to verify who acted, what authority they held, and how an error will be recovered.
This creates an equity question alongside the security question because an agent may help a patient work through a confusing portal, manage a long hold, or keep checking for an earlier appointment without asking the patient to spend another afternoon on the task. The same persistence could give people with better tools an advantage when scarce capacity is released, although that remains an inference from existing access-allocation concerns and needs empirical study. Leaders should measure who benefits and who carries additional burden, because assumptions about either side are too weak for an access policy.
A Booking Incident Shows the Control Problem
To see why this matters, consider a reported Australian gym incident, where the reporting and the member's first-person account describe an assistant using an authenticated workflow to book beyond the horizon shown in the ordinary interface. Later, the assistant reportedly treated a question about moving up a waitlist as permission to cancel another member's reservation; the cancellation committed, and attempts to restore the earlier state reportedly failed.
The vendor's root cause remains unconfirmed in the public record, but leaders do not need the source code to see the control problem: an ambiguous request became a live action against someone else's reservation, the application accepted it, and the service could not reliably recover. In patient access, the same sequence could consume scarce capacity or alter a referral, then trigger downstream messages that leave the patient and staff with different versions of what happened.
A control failure can predate the agent; the agent changes how excessive authority is discovered, composed, and exercised. Authentication may prove which account arrived, but authorization must still determine whether that account can act for the represented patient on the specific appointment, while the workflow preserves evidence that the person approved the agent's interpretation.
What Authorized Agentic Red Teaming Adds
Conventional application security tests the components; authorized agentic red teaming tests the configured trajectory across them. Source review, authorization tests, and penetration testing remain necessary because they can find the underlying defect; agentic testing follows goal-directed software as it interprets an ambiguous objective, carries state across channels, and reports a completed result to the patient after the system has already changed.
The National Institute of Standards and Technology defines AI red teaming as structured testing used to find flaws and vulnerabilities, often in a controlled environment with system developers. For patient access, that means beginning with three safeguards: written rules of engagement, nonproduction assets, and synthetic identities, then placing hard limits beside explicit stop and incident procedures. The first scenario should follow one consequential workflow such as booking, cancellation, or rescheduling, with prompt variation added only when it helps test the same operational path.
A useful test pairs an adversarial or ambiguous case with a benign case, asking whether the agent can exceed delegated authority while confirming that the same controls still let a patient or authorized proxy complete the task without avoidable delay. The evidence should let an access leader reconstruct who was allowed to act, what the person authorized, and what the system committed; it should also show what reached the patient and whether the earlier state could be recovered.
Four Questions for the Agentic Front Door
Once the executive team looks past the product names, accountability comes down to four questions that patient-access leaders already know how to ask.
- Who is acting? Determine whether the actor is the patient, an authorized proxy, or a patient-side agent, then identify any provider-deployed agent or connector identity that accepts the work on the organization's behalf.
- What may it do? Define where its authority ends; decide whether it may read and propose, hold capacity, or commit a booking, while giving cancellation and disclosure their own explicit decisions.
- At what pace and scale? Set limits for concurrency, retries, and slot holds, then decide how long the agent may persist across channels or repeat an identity check.
- How will the organization know and recover? Name the authoritative system and preserve evidence linking the person's intent to the committed transaction, including the confirmation sent to the patient and the path for reconciling an incorrect action.
Figure 2 · Executive control model
Local accountability sits between a patient's request and the scheduling record.
Every agent-mediated transaction should leave enough evidence to explain who acted, what changed, and how the organization responded.
Represented patient
Stated intent reaches the workflow through a patient, proxy, or agent.
Accountability boundary
The organization decides what it will accept before access capacity changes.
Record and confirmation
The authoritative record changes, and the patient receives a clear result.
Six questions the local workflow must answer
- IdentityName the actor and the represented patient.
- AuthoritySeparate permission to read, propose, and commit.
- CapacityLimit retries and slot holds.
- AccuracyApply referral and scheduling rules.
- EvidenceLink stated intent to the authoritative record.
- RecoveryReconcile the error and confirm the outcome with the patient.
Four ways the trajectory can fail
Delegated overreach
The agent commits an action beyond the represented patient's instruction.
Existing workflow exploitation
The agent finds weak routing or excess access already present in the workflow.
Instruction or context hijacking
Untrusted content redirects the agent's plan or action.
Agent-scaled interaction abuse
Automated retries or slot holds consume access capacity and create false denials.
represented patient and authorized intent → committed action in the authoritative record → patient confirmation and recovery
These questions apply whether the organization built the agent, bought it from a vendor, or simply receives its work through a public workflow. Responsibility may be shared across several parties, but the organization still owns the local decision to accept a request and commit a change to the patient's record.
Keep the Technical Lesson Simple
The technical point can be reduced to one historical software example. In Easy!Appointments 1.5.2, a customer search could reveal an appointment identifier outside the provider's proper scope, while a separate appointment-management path accepted that identifier as enough authority to change the record; GHSA-4vmm-5qvc-w5p7 / CVE-2026-55651 identifies the affected revision and links the later scope-filtering change.
A broad read could feed a consequential write, which is the access-operations lesson leaders need to carry forward: limit what each search can reveal, then check the actor's authority again at the system that commits the appointment change. A disclosed identifier may help the system find the record, but it cannot serve as permission to alter the authoritative state.
Replaying this known chain can support regression testing, while unassisted discovery remains a separate outcome because reproducing an already documented path answers a different question. The cited code applies only to the specified revisions; no clinic, hosted tenant, or live patient-access service was inspected or tested.
A 90-Day Executive Response
Use the first ninety days to choose one high-consequence workflow, beginning with a local write such as cancellation or rescheduling, and map how a person or agent can reach the authoritative record. Establish the conventional application-security baseline before building synthetic cases with outcomes that the access team can inspect and explain.
Give an executive sponsor and a clinical access owner shared responsibility for the pilot, then pair them with the technical control owners and a leader who can represent patient safety or access equity. Privacy and legal teams should define the operating boundaries, vendors should own named duties, and one evidence owner should integrate the findings into a decision the group can act on.
Figure 3 · Initial 90-day red-team implementation horizon
Start with one local write and test whether the organization can control it.
The pilot needs a clinical access owner and an authoritative record. Vendors may supply product evidence. The organization owns the local decision and recovery.
Days 0-30
Choose and define
- Executive + clinical access + patient safety
Choose one local write
Start with a high-consequence action, such as cancellation or rescheduling. Set the nonproduction boundary and stop conditions. Name the clinical access owner and the evidence owner.
- Application security + IAM + engineering
Build inspectable ground truth
Inventory every route that can complete the write. Create synthetic patients and proxies in isolation. Record whether authority, the committed state, and the patient-facing message agree.
Days 31-60
Test and correct
- Application security + clinical access
Establish the conventional baseline
Inspect source and scheduling configuration. Test authorization, business rules, and identity matching before attributing a finding to agent behavior.
- Red-team lead + patient representative + language access
Run authorized access cases
Exercise legitimate and adversarial goals through the selected channels. Preserve each observable step. Report known-chain reproduction separately from unassisted discovery.
Days 61-90
Recover and retest
- Engineering + IAM + clinical operations
Test the local boundary
Enforce authority at the write. Replay held-out cases and simulate a lost acknowledgement. Confirm that the authoritative record, patient message, and recovery path agree.
- Evidence owner + privacy + vendor risk
Make retesting routine
Trigger retesting when the model, tool, or identity rule changes. Keep versioned results and unresolved exceptions. Set vendor notice, logging, and incident duties in contracts.
- Named clinical access owner
- Versioned action inventory
- Synthetic operational ground truth
- Assigned findings and recovery exercise
- Remediation retest
- Completion, false-denial, and access-burden measures
Pair each adversarial case with a benign one so the pilot can measure unsafe reach and patient burden in the same view; after fixing the earliest enforceable boundary, replay held-out cases to see whether the control works without making legitimate access harder.
Reassess the workflow after a change to the model, tool, or identity rule; use the same trigger when scheduling configuration or a consequential connector changes. Degraded modes need an accountable clinical-operations owner; monitoring should show delay, false denial, and unequal capture of access capacity.
Limits and Research Agenda
This Perspective is grounded in one reported nonclinical incident, published patient-access research, and public security evidence, with first-party product descriptions used only for the capabilities those companies declare. Exact historical source revisions support the technical example, and their limits constrain what this Perspective can conclude.
The traffic measurement describes requests without counting personal agents, while vendor documentation establishes declared channels without verifying local architecture or configuration. Adoption, safety, and effectiveness therefore remain open questions; live healthcare services remained outside the scope of testing.
Future work should measure how often patient-side and provider-side agents complete legitimate access tasks, then examine whether continuous search or retry changes who receives scarce appointments. Controls should be evaluated for false denials and additional burden, while agentic red teams are compared with experienced application-security testers under matched budgets.
The Leadership Decision
For leaders, this belongs in today's access operation because public workflows already receive automated visitors with very different purposes, from a patient's scheduling assistant trying to find care to malicious automation trying to consume capacity. The response has to protect the beneficial request while keeping the local rules for identity, authority, and pace clear enough to enforce.
Health systems are now operating a front door used by patients, agents working on their behalf, and agents deployed by the organization; malicious automation reaches many of the same public routes. At machine speed, a stale directory or an incorrect routing rule can become a capacity problem very quickly, which means someone must own the decision and the organization must be able to recover when the result is wrong.
This Perspective makes a specific recommendation: health systems should add bounded, authorized agentic red teaming to conventional application-security testing of selected, locally configured patient-access workflows, beginning with the transactions and capacity effects that could most disrupt access. Legitimate and adversarial trajectories should be tested together so leaders can see whether a stronger control also creates another barrier for the patient.
The application must enforce authority at the local write, the workflow must preserve a reliable path back, and leadership must keep measuring the result that matters to patients: simple and timely access, handled accurately and fairly.
Author note. This Perspective reflects the author's personal analysis of public sources and does not represent any employer or vendor.
Notes
- Mayo Clinic. “Mayo and the Telephone.” 24 January 2011. The account describes the Mayo family's 1879 telephone link and the daytime and after-hours intermediaries who operated it for patients.
- Dao T, et al. “Characteristics of the modern-day physician house call.” Medicine. 2019;98(8):e14671. The historical introduction reports that house calls represented 40 percent of physician-patient encounters in 1930.
- Country Doctor Museum. “Doctors on the Go!” East Carolina University; 28 January 2022. The museum describes rural physicians working from offices at or near home and spending much of their time making house calls.
- Thales. “AI-driven Bot Attacks Surged 12.5x According to Thales Bad Bot Report.” 29 April 2026. The underlying report analyzes Thales-observed 2025 traffic; its bot category is broader than personal AI agents.
- Nous Research. “Hermes Agent.” Product documentation; retrieved 12 August 2026 UTC.
- OpenClaw Foundation. “OpenClaw: Personal AI Assistant.” Product documentation; retrieved 12 August 2026 UTC.
- OpenAI. “Introducing the Codex app.” Product announcement; retrieved 12 August 2026 UTC.
- Anthropic. “Claude Cowork.” Product documentation; retrieved 12 August 2026 UTC.
- Sharma R. “Agent as a Service (AaaS): The Next Transformation in Healthcare.” American Journal of Healthcare Strategy. 2025;1(3).
- Amazon. “Amazon One Medical introduces agentic Health AI assistant for simpler, personalized, and more actionable health care.” Product announcement; retrieved 12 August 2026 UTC.
- Zocdoc. “Zo, the AI Phone Assistant for healthcare.” Product documentation; retrieved 12 August 2026 UTC.
- Epic. “Emmie for Patients.” Product documentation; retrieved 12 August 2026 UTC.
- American College of Healthcare Executives. “Leveraging Technology and Innovation To Improve the Patient Journey and Access to Care.” 2026 Congress on Healthcare Leadership; 4 March 2026.
- Healthcare Financial Management Association. “Consumerism Maturity Integration Model: Maturity Scale for Appointment Scheduling.” Retrieved 12 August 2026 UTC.
- Woodcock EW, Profeta C. “A framework for patient access management: consensus from a Delphi panel of US health system leaders.” BMC Health Services Research. 2025;25:524.
- U.S. Government Accountability Office. “Defense Health Care: DOD Should Improve Accuracy of Behavioral Health Provider Information in TRICARE Directories.” GAO-24-106588; 8 July 2024.
- Woodcock EW. “Barriers and Facilitators to Automated Self-Scheduling: Consensus from a Delphi Panel of Key Stakeholders.” Perspectives in Health Information Management. 2022;19(1):1m.
- Wilson C, Hobbins R. “AI assistant hacks gym website in first known Australian autonomous cyber attack.” ABC News. 10 August 2026.
- Bird A. “When my AI agent hacked my gym, Mythos stopped feeling theoretical.” 10 April 2026.
- National Institute of Standards and Technology. “Artificial intelligence red-teaming.” CSRC Glossary; sourced to NIST SP 800-218A. Retrieved 12 August 2026 UTC.
- Easy!Appointments. Affected 1.5.2 source, provider-scope search fix, and 1.6.0 source containing the filtering change. Retrieved 12 August 2026 UTC.
- GitHub Advisory Database. GHSA-4vmm-5qvc-w5p7 / CVE-2026-55651. Retrieved 12 August 2026 UTC.