Agentic AI Red Teaming for Patient Access
Weak authorization and poor recovery already put patient-access systems at risk. Agentic AI can expose and repeat those failures at greater speed and scale.
Contents
Patient access was a systems problem long before anyone reached a health system through a portal or delegated a request to software. When 14-year-old Charlie Mayo connected his father's medical office to the family farm by telephone in 1879, patients still depended on intermediaries to receive their requests and determine how those requests would reach the physician; decades later, even as house calls remained common, the underlying operational problem had changed little. Today's channels are more complex, and patients increasingly expect the status of a request to remain visible without another phone call, but the health system's responsibility is familiar: understand the request, determine whether it may be acted upon, and communicate a reliable outcome. Agentic AI matters because software can now participate on both sides of that process.
The Front Door Now Has Software on Both Sides
An AI agent becomes operationally significant when it can carry a conversation into action. A patient-delegated system may search for an appointment or attempt to change one, while a provider-deployed system may answer the access-center line and write directly into the organization's scheduling workflow. The important boundary appears when conversational assistance can alter the system of record, because the organization must then determine whose request is being represented, what authority accompanies it, and how an erroneous transaction can be reversed.
Current products already illustrate both directions: some act for patients, while others are deployed by health systems to manage calls or scheduling. Their documentation establishes declared capability, but local configuration still determines how identity, delegated authority, and recovery are handled.
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 long worked around inaccurate directories, inconsistent scheduling rules, and fragmented handoffs, any of which can misroute a legitimate request before malicious intent enters the picture. A 2025 Delphi study identified appointment accuracy, availability, and capacity management as central determinants of access, while a 2024 GAO review found errors in most of the sampled behavioral-health provider listings in TRICARE directories. These conditions are vulnerabilities in the operating environment rather than threats in themselves; automation changes the number of times they can be encountered and the scale of the resulting disruption.
The same distinction between identity and delegated authority appears in patient portals. In a 2018 telephone study of 102 U.S. hospitals, 68% offered proxy accounts, yet personnel at 45% endorsed credential sharing, and only 19% of hospitals with proxy access allowed patients to restrict what a proxy could see. Because the study measured guidance provided by hospital personnel rather than successful account compromise, it should be cited as evidence of insecure delegation practices rather than a demonstrated breach. The authors' warning that "eliminating all caregiver access would be a grave mistake" sharpens the operational point: health systems need proxy pathways that preserve legitimate caregiving while making separate, appropriately scoped access easier to use than password sharing.
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. Inaccurate directories and inconsistent routing already misdirect patients; automation increases the speed and frequency with which the same failure can be repeated.
Automation Changes the Economics of Voice-Based Access
The most consequential change is economic. Voice phishing once required a human operator to conduct each call, which naturally constrained the number of concurrent attempts; contemporary voice systems reduce that labor requirement and make persistent, parallel calling substantially cheaper. In a survey experiment involving 4,100 U.S. adults, Heiding and colleagues found that 16.5% of participants said they would or might comply across five scam scenarios, with the highest rate (36.1%) occurring in the relative-in-distress condition. Those figures measure stated susceptibility rather than observed fraud, but they provide more relevant evidence for the patient-access threat model than general web-bot traffic because they examine how people respond to persuasive AI-generated voice interactions.
The authors therefore locate the near-term risk in the "economics of automation rather than novel or 'superhuman' persuasive techniques." For access-center leaders, that framing shifts attention away from perfect voice cloning and toward the possibility that a low-cost system can repeatedly exercise the same verification process until one attempt succeeds.
Persuasiveness was the strongest independent predictor of compliance, whereas perceived human-likeness was not independently predictive after the other measures were considered. Representative performance should therefore be evaluated through adherence to the approved verification and authorization process; judgments about whether the caller sounds synthetic are too unreliable to serve as a control. Familiarity with AI offered no measurable detection advantage in the study, which further weakens any policy that depends on frontline intuition.
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. Any access policy should therefore measure both the reduction in patient effort and the distribution of scarce capacity, rather than assuming that agentic assistance will be uniformly beneficial or uniformly harmful.
The Access Center Is an Authentication Boundary
The financial sector offers a useful, although nonbinding, control analogue. FFIEC guidance describes threat actors deceiving call-center and help-desk personnel into resetting credentials, and it states that reliable verification methods "generally do not depend solely on knowledge-based questions." Applied to patient access, the implication is that portal recovery and other high-consequence requests should use an additional control tied to a pre-established device or communication channel, while unusual attempt patterns and the final decision remain visible in the audit record. The guidance does not create a healthcare compliance requirement, but it provides a mature model for a problem that health systems increasingly share.
The same guidance distinguishes third-party access that depends on retained customer credentials from access using institution-issued API or token credentials. The healthcare parallel is direct: caregivers and patient-delegated software should use distinct, scoped credentials wherever the local system supports them, because possession of a patient's password does not establish authority to act as that patient's proxy.
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 can establish which account initiated a request, while authorization determines whether that account may act for the represented patient in the specific transaction; the workflow must also preserve enough evidence to show what the patient or proxy actually approved.
What Authorized Agentic Red Teaming Adds
Conventional application-security testing and agentic red teaming answer complementary questions. Source review, authorization testing, and penetration testing can identify the underlying defect, while a supervised software agent can show how that defect behaves when a goal is pursued across the configured workflow and carried through to a patient-facing result. NIST defines AI red teaming as a structured effort to identify flaws and vulnerabilities in an AI system; this article extends that logic to the broader patient-access workflow, where technical controls and operational procedures interact. This broader healthcare application is my proposed extension; NIST has not defined it as a patient-access method.
Testing should begin only after the organization has approved the scope and isolated the environment, with stop conditions and incident ownership established before execution. Each adversarial case should be paired with a legitimate case, allowing leaders to see whether the control prevents unauthorized action without creating an avoidable barrier for the patient or proxy. The evidence package should allow the full path, from the original request and authority decision through the committed transaction and any subsequent recovery, to be reconstructed.
User acceptance testing establishes whether an approved user can complete the intended workflow, while application-security testing examines the technical controls that protect it. Agentic workflow red teaming adds a third question: how does the end-to-end process behave when goal-directed software introduces ambiguity, persistence, or adaptation across channels? The three methods should share findings, but their results should remain separately reported because they answer different assurance questions.
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, and for whom? The workflow should identify the requester and the patient being represented, while distinguishing a patient or authorized proxy from software acting on either side of the transaction.
- What authority accompanies the request? Permission should be defined at the level of the transaction, since a system may be allowed to search for or propose an appointment without being allowed to cancel or commit a change.
- How much persistence will the workflow accept? Limits should reflect both the risk of the action and the capacity of the channel, especially when repeated verification failures or concurrent requests begin to resemble abuse.
- Can the organization explain and reverse the result? The audit trail should connect the expressed request to the system decision and patient-facing confirmation, while the recovery process should restore the correct state when the transaction is wrong.
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
The first 90 days should focus on a single workflow in which a call can produce a consequential change, such as portal credential recovery or appointment cancellation. The team should map the entire path from the incoming request and authority decision to the system change and patient confirmation. Establishing that end-to-end path before testing helps separate weaknesses in the underlying workflow from behavior introduced by the voice agent.
During the first month, the organization should define the authorized test boundary and create approved patient and proxy accounts that cannot affect live records. In the second month, human reviewers should establish the expected result for each case while software agents introduce controlled variation in wording, urgency, and retry behavior. The final month should be used to correct the earliest control that allowed unauthorized progress, retest the workflow with new cases, and conduct a recovery exercise in which the system record and patient communication initially disagree.
For an access-center leader, the pilot should end with evidence that answers three practical questions: did any unauthorized request complete, could legitimate patients and proxies still finish the task, and could staff reconstruct and correct an erroneous result? Handle time, transfers, and repeat contacts should be reported alongside the security findings so that a stronger control is not accepted at the cost of an unusable access process.
Recovery is incomplete when the system record has been corrected but the patient continues to receive messages that describe a different outcome. Waddell and Mehta describe the point at which communication volume begins to reduce engagement as "message saturation" and recommend centralized tracking so that new protocols "complement, not duplicate" existing outreach. A red-team case should therefore capture every message generated by the tested workflow and verify that the final communication reflects the system-of-record outcome; time-sensitive security or cancellation notices should remain separate when bundling could delay or obscure the action required.
Give an executive sponsor and a patient-access operations 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 record-changing transaction and test whether the organization can control it.
The pilot needs a patient-access operations 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 record-changing transaction
Start with a high-consequence action, such as cancellation or rescheduling. Set the nonproduction boundary and stop conditions. Name the patient-access operations owner and the evidence owner.
- Application security + IAM + engineering
Build predefined expected result
Inventory every route that can complete the write. Create approved test patient accounts 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 new cases not used during remediation and simulate a record changed without a confirmation. 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 patient-access operations owner
- Versioned action inventory
- Synthetic operational ground truth
- Assigned findings and recovery exercise
- Remediation retest
- Completion, legitimate request incorrectly blocked, and access-burden measures
Pair each adversarial case with a legitimate one so the pilot can measure unsafe reach and patient burden in the same view; after fixing the earliest enforceable boundary, replay new cases not used during remediation 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. Manual fallback during an outage needs an accountable clinical-operations owner; monitoring should show delay, legitimate request incorrectly blocked, and unequal capture of access capacity.
Limits and Research Agenda
This Perspective combines empirical studies of portal delegation and AI-enabled vishing with financial-sector authentication guidance and public technical disclosures. The sources support different parts of the argument, but none directly evaluates an AI voice agent against a live healthcare access center. The portal study measured guidance provided by hospital personnel and was not nationally representative overall, while the vishing experiment measured stated willingness to comply after exposure to recordings rather than behavior during a live call. The FFIEC guidance is used as a control analogue rather than a healthcare compliance standard, and no live patient account or production access workflow was tested.
Future research should evaluate whether supervised agentic testing identifies workflow failures that conventional application-security testing or manual UAT does not, while also measuring the burden introduced for legitimate patients and proxies. Studies should distinguish the discovery of a previously unknown weakness from the automated reproduction of a known one, since those outcomes support different claims about the value of the method.
The Leadership Decision
Health systems do not need to wait for a documented AI-driven breach before examining the workflows that already govern identity, delegated authority, and recovery. The practical recommendation is deliberately narrow: select one high-consequence patient-access transaction, establish a controlled environment with approved test accounts, and use supervised software agents to execute paired legitimate and adversarial cases alongside conventional application-security testing. Expansion should depend on evidence that the workflow prevents unauthorized action without creating unacceptable delay or false denial for legitimate patients and proxies.
The leadership decision is whether the local access process can remain safe, auditable, and recoverable as software begins to act through it. That decision belongs within patient-access operations because the relevant failures appear at the same points leaders already manage: when a request is interpreted; when authority is accepted; when the record changes; and when the patient is told what happened.
The application must enforce authority when the record changes, while the surrounding workflow preserves a reliable path for explanation and recovery. Leadership can then judge the control against the outcome that matters to patients: timely access that remains accurate, usable, and fair.
Author note. This Perspective reflects the author's personal analysis of public sources and does not represent any employer or vendor.
Applying this to your workflow
For specialist work on agent-workflow assurance, visit Access Red Team to explore how a bounded assessment could apply to your patient-access workflow.
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.
- Nous Research. “Hermes Agent.” Product documentation; retrieved 12 August 2026 UTC. Declared capabilities only; cited as a patient-side browser-capable agent example rather than as evidence of local patient-access deployment.
- OpenClaw Foundation. “OpenClaw: Personal AI Assistant.” Product documentation; retrieved 12 August 2026 UTC. Declared capabilities only.
- OpenAI. “Introducing the Codex app.” Product announcement; retrieved 12 August 2026 UTC. Cited as ChatGPT Codex delegated computer-work documentation.
- Anthropic. “Claude Cowork.” Product documentation; retrieved 12 August 2026 UTC.
- Zocdoc. “Zo, the AI Phone Assistant for healthcare.” Product documentation; retrieved 12 August 2026 UTC. Zocdoc's Zo is cited for provider-side declared scheduling capability.
- Epic. “Emmie for Patients.” Product documentation; retrieved 12 August 2026 UTC. Patient-side declared scheduling capability.
- Amazon. “Amazon One Medical introduces agentic Health AI assistant for simpler, personalized, and more actionable health care.” Product announcement; retrieved 12 August 2026 UTC. Amazon One Medical's Health AI is cited as a patient-side example within the One Medical ecosystem.
- Sharma R. “Agent as a Service (AaaS): The Next Transformation in Healthcare.” American Journal of Healthcare Strategy. 2025;1(3).
- 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.
- Latulipe C, Mazumder SF, Wilson RKW, et al. “Security and Privacy Risks Associated With Adult Patient Portal Accounts in US Hospitals.” JAMA Internal Medicine. 2020;180(6):845-849. Telephone survey conducted May-December 2018; authors caution that the stratified sample is not nationally representative overall and that responses reflect personnel guidance rather than verified hospital policy or successful compromise.
- 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.
- Heiding F, Mayrink Verdun C, Lermen S, et al. “Evaluating AI Models’ Capability to Automate Voice Phishing Attacks.” arXiv:2607.09970; 2026. Survey experiment (N=4,100) measuring stated willingness to comply after exposure to scam recordings or transcripts; figures are not observed live-call fraud rates.
- Federal Financial Institutions Examination Council. “Authentication and Access to Financial Institution Services and Systems; Interagency Guidance.” August 2021. Cited as a nonbinding financial-sector control analogue for call-center verification and credentialed third-party access.
- Waddell KJ, Mehta SJ. “Texting in Health Care - Preserving Impact and Managing Influx.” JAMA Internal Medicine. 29 June 2026. Viewpoint on message volume, centralized tracking, and complementary rather than duplicative outreach; exact quoted phrases should be verified against the publisher PDF if page proofs differ.
- 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. Defines AI-system red teaming; this Perspective extends the logic to patient-access workflows without claiming NIST has defined that broader healthcare method.
- 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.
About the illustration
