AI agents for prior authorization: automating the paperwork without automating the denial

A physician orders an MRI on a Tuesday. What happens next is one of the most expensive administrative rituals in American healthcare: someone on the practice staff figures out whether the patient’s plan requires prior authorization, digs the clinical documentation out of the chart, fills a payer-specific form, faxes or portals it in, and then waits — sometimes days — for a decision that might be a denial with a reason nobody can decipher. Multiply that by every imaging order, specialty referral, infusion, and surgery, and you have a workflow that burns clinician time, delays care, and generates appeals volume on both sides.

It is also, on paper, the perfect problem for an AI agent: high-volume, repetitive, rule-bound, and drowning in structured and semi-structured data. Which is exactly why it’s dangerous. The same agent that could assemble and submit a prior authorization request in seconds could, if you let it, decide that the request should be denied — and the moment it does, you’ve pointed a large language model at a regulated medical-necessity determination that carries federal rules, state law, and real patient harm if it’s wrong. Prior auth is the sharpest version of a pattern we’ve written about in claims automation: automatable enough to be worth it, consequential enough that autonomy in the wrong place is a compliance incident. This post is about where that line goes, and how to build the safe side of it on Salesforce.

Why now: the regulatory clock is the forcing function

Prior authorization automation isn’t a 2026 story because the technology suddenly appeared. It’s a 2026 story because CMS put a clock on it. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) imposes staggered obligations on Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the federal exchanges.

The two dates that matter:

• Beginning in 2026, impacted payers must send prior authorization decisions within 72 hours for expedited (urgent) requests and 7 calendar days for standard requests, and must include a specific reason for every denial. They also begin publicly reporting prior authorization metrics.
• By January 1, 2027, those payers must stand up a set of FHIR-based APIs — including a dedicated Prior Authorization API that conveys which items and services require authorization, the documentation required, and supports electronic prior authorization requests and responses, alongside enhanced Patient Access, Provider Access, and Payer-to-Payer APIs.

Read those requirements as an architecture brief. Faster mandated turnarounds mean payers can’t rely on manual queues. A required, machine-readable denial reason means the decision has to be explainable. And a standardized FHIR Prior Authorization API means the submission surface an agent needs to talk to is finally becoming programmatic instead of a fax number. The rule is dragging prior auth from paper toward API — and an agent is only useful on the side of that transition where the data is structured and the surface is callable.

The line: assemble and submit, yes; determine medical necessity, no

Here is the non-negotiable. An AI agent may gather documentation, check whether authorization is required, assemble the request, submit it, and track its status. An AI agent may not be the thing that makes an adverse medical-necessity determination.

This isn’t a matter of taste; it’s law and it’s tightening. CMS rules bar Medicare Advantage organizations from making medical-necessity determinations using an algorithm or software that does not account for an individual patient’s specific circumstances. A coverage denial has to rest on the individual clinical picture reviewed by a qualified person, not a model’s pattern-match. States have layered their own restrictions on top — California’s SB 1120 and comparable statutes in other states restrict AI from being the sole basis for a medical-necessity denial. And the AMA’s position, backed by physician surveys reporting that automated review is driving more and faster denials, is that AI should augment human judgment, not replace it.

So the design rule writes itself, and it maps cleanly onto the two sides of the transaction:

• On the provider side, the agent does the administrative scaffolding: determine whether PA is required for this plan and service, pull the supporting clinical evidence from the record, pre-fill the payer’s form, submit it electronically, and follow up on status. Every one of those is busywork, and none of them is a clinical judgment.
• On the payer side, the agent can intake, validate completeness, check the request against coverage policy, and — critically — auto-approve or route. Approvals and administrative completeness checks are safe to automate. Denials are not: an adverse determination must go to clinician review. The agent’s job on the payer side is to clear the easy yeses fast and hand every potential no to a human with the case assembled.

This is the same human-in-the-loop discipline that governs any consequential agent, with the escalation point fixed by regulation rather than left to product judgment. The agent’s autonomy ends precisely where a patient could be harmed by a wrong call — and you design that checkpoint in from the first sprint, not after an audit.

The Salesforce architecture: grounded on Health Cloud, gated by the Trust Layer

For a provider or payer already on Salesforce, the reason to build this on Agentforce rather than a point solution is that the data the agent must reason over — the member’s coverage, the care request, the prior auth record, the clinical context — already lives in the Health Cloud data model. Salesforce brought this together under Agentforce for Health (the product listings now show Health Cloud itself rebranded as Agentforce Health), with a library of prebuilt healthcare agent skills and, announced in early 2026, a wave of prebuilt health agents spanning referrals, EHR read/write, and claims and coverage.

Whatever branding it ships under, the architecture underneath is what matters, and it has three load-bearing pieces.

Grounding on the Health Cloud data model. Prior authorization is not an abstract concept in Health Cloud — it’s modeled. The CareRequest object explicitly covers preauthorizations for drugs and services (alongside admission notifications and concurrent requests), with CarePreauth as the preauthorization record and MemberPlan holding the member’s coverage. There’s a dedicated Benefits Verification data model and a Utilization Management data model to sit the workflow on. That existing schema is what lets an agent ground its answers in real coverage and request state instead of guessing. A read action might be as simple as:

-- Illustrative: exact field API names vary by Health Cloud version,
-- so confirm them against the CarePreauth object reference for your org.
SELECT Id, Name, Status, MemberPlanId, CareRequestId
FROM   CarePreauth
WHERE  MemberPlanId = :memberPlanId
AND    Status IN ('Approved', 'Pending')

The agent grounds on the member’s actual authorizations before it ever composes a new request — so it never invents a coverage state, because it reads one.

A real-time connection to the payer. The record is only half the job; the other half is talking to the payer’s system in the moment. Salesforce’s integration with Availity is the piece that turns this from an internal workflow into an end-to-end one: it lets providers communicate directly with payers in real time to run eligibility checks and, where a service requires prior authorization, submit and receive decisions, positioned to meet CMS interoperability mandates. Salesforce describes decisions coming back in seconds — treat that as a vendor performance claim to verify against your own payer mix, not a guarantee, but the shape is right: the agent’s submit action calls a real payer connectivity layer rather than printing a fax. That’s what keeps it honest. An agent that consumes untrusted input and takes external actions is one you scope tightly — the least-privilege posture is not optional when the action moves protected health information to a payer.

PHI governance through the Einstein Trust Layer. Everything here is protected health information, which means the agent’s reasoning has to run inside guardrails built for it. The Einstein Trust Layer provides the controls that make sending PHI-adjacent context to an LLM defensible — dynamic data masking, an audit trail, and zero data retention with the external model providers, so prompts sent to the model aren’t retained by them. Salesforce will sign a BAA covering the platform, but read that carefully: the BAA covers Salesforce’s platform, not your implementation. Which fields you expose to the agent, how you mask them, what the agent is scoped to do, and how you monitor it are your responsibility, and they’re where a HIPAA problem actually gets made or avoided.

Designing the agent so it can’t step over the line

The architecture makes the safe version possible; the topic and action design makes it enforced. Structure the agent around actions that are individually incapable of rendering an adverse clinical decision:

• CheckAuthorizationRequired — given the plan and the service/procedure code, determine whether prior auth is needed. A lookup against coverage rules and the Utilization Management model, not a judgment.
• AssembleClinicalPacket — retrieve and attach the supporting documentation from the record. Grounded retrieval; the agent gathers evidence, it doesn’t weigh it.
• SubmitPriorAuth — call the payer connectivity layer (Availity/FHIR PA API) to submit. A deterministic action with a real confirmation.
• CheckAuthStatus — poll and surface the decision. Read-only.
• EscalateToClinician — the mandatory path. Any request that would otherwise resolve as a denial, or that the agent can’t complete with confidence, routes to a human with the case fully assembled.

Notice what’s absent: there is no ApproveDenial or DetermineMedicalNecessity action, because the agent must not have one. On the payer side you might add a ValidateCompleteness and an AutoApprove (approvals being the safe direction), but the negative determination has no agent action at all — it only ever exits through EscalateToClinician. When autonomy is dangerous, the cleanest guardrail is that the dangerous action doesn’t exist in the agent’s toolset. A refund agent shouldn’t be able to move money it wasn’t scoped to; a prior-auth agent shouldn’t be able to deny care. Build the constraint into the action list, where it’s auditable, not into a prompt, where it’s advisory.

Keep the actions bulk-safe and grounded, and run the Apex in user mode so the agent’s field access to PHI is enforced by the platform rather than trusted:

public with sharing class SubmitPriorAuthAction {
    @InvocableMethod(label='Submit Prior Authorization'
                     description='Submits an assembled preauth to the payer connectivity layer.')
    public static List<Result> submit(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request req : requests) {
            // Read enforces the Agent User's FLS/CRUD on PHI fields.
            CarePreauth pa = [
                SELECT Id, Status
                FROM   CarePreauth
                WHERE  Id = :req.carePreauthId
                WITH   USER_MODE
                LIMIT  1
            ];
            // Deterministic call to the payer connectivity layer; the agent
            // never decides the outcome — it only transmits and records it.
            Result r = new Result();
            r.confirmationId = PayerGateway.submit(pa);   // e.g. Availity / FHIR PA API
            results.add(r);
        }
        return results;
    }
    // Request/Result inner classes omitted for brevity.
}

The grounding data comes from Health Cloud and, for the unified longitudinal view, Data 360 — which can normalize FHIR and clinical sources into a governed profile the agent reasons over without necessarily storing the raw clinical data in the CRM. The point is consistent with everything we tell teams building consequential agents: the agent’s every factual claim about coverage, benefits, or authorization state must come from a live, governed source, because a hallucinated benefit or a misstated authorization isn’t an awkward sentence — it’s a care delay or a compliance exposure.

The honest limitations

Three things temper the pitch, and any healthcare team should hear them before the demo convinces them otherwise.

First, the payer surface is still uneven. The FHIR Prior Authorization API is a 2027 obligation, not a 2026 reality across the board. Until payers finish standing those APIs up, a chunk of the “submission” layer still runs through portals and connectivity intermediaries with payer-by-payer quirks. An agent helps most where the electronic surface already exists and degrades toward “assemble the packet, hand it to a human to submit” where it doesn’t.

Second, the denial side is a regulatory minefield you should stay out of. It is tempting, on the payer side, to let the agent clear the whole queue. Don’t. The rules and the reputational risk both point the same way: automate approvals and completeness, route anything trending toward denial to a clinician. The AMA’s warning about AI driving batch denials is exactly the failure mode regulators are now watching for.

Third, grounding quality is destiny. Prior auth reasoning over incomplete or dirty clinical data produces confident, wrong requests — the data-quality problem that sinks agents everywhere is acute here, because the cost of a wrong answer is measured in denied care and audit findings. The data foundation isn’t a prerequisite you can defer; it’s the product.

What to do this quarter

If you’re a provider organization, start on the provider side, where the value is real and the regulatory exposure is low: an agent that determines whether authorization is required, assembles the clinical packet from the record, submits through your existing payer connectivity, and tracks status. That alone reclaims a large amount of staff time and speeds care, and it builds the muscle for more.

If you’re a payer, automate the safe direction — intake, completeness validation, and auto-approval of the clean requests — and design the escalation to clinician review as a hard architectural boundary, not a configurable option. In both cases, ground the agent on the Health Cloud data model, govern PHI through the Trust Layer, and structure the action set so the agent is structurally incapable of making the decision the law reserves for a human.

The winning prior-auth agents won’t be the ones that automate the most. They’ll be the ones that automate the paperwork completely and the judgment not at all — because in prior authorization, the paperwork is a cost, but the judgment is a patient. For teams building this on Salesforce, that’s an architecture problem, and it’s the kind we do; see how we approach healthcare and life sciences.

Understanding the basics

Can AI agents handle prior authorization?

Yes, for the administrative parts. An AI agent can determine whether a service requires prior authorization, gather and attach the supporting clinical documentation, pre-fill and submit the request through electronic payer connectivity, and track its status. What an agent must not do is make the medical-necessity determination itself — federal Medicare Advantage rules and state laws like California’s SB 1120 restrict AI from being the basis of an adverse coverage decision, which has to go to qualified human review.

What does CMS-0057-F require for prior authorization?

The CMS Interoperability and Prior Authorization Final Rule requires impacted payers (Medicare Advantage, Medicaid and CHIP programs, and federal-exchange QHP issuers) to return prior authorization decisions within 72 hours for urgent and 7 calendar days for standard requests, to provide a specific denial reason, and to report prior authorization metrics — with these turnaround obligations beginning in 2026. By January 1, 2027, those payers must implement FHIR-based APIs including a dedicated Prior Authorization API that supports electronic requests and responses.

How does Salesforce Agentforce fit into prior authorization?

Agentforce (within Agentforce for Health / Health Cloud) grounds an agent on the Health Cloud data model — objects like CareRequest, CarePreauth, and MemberPlan — so it reasons over real coverage and authorization state. Salesforce’s Availity integration lets the agent run eligibility checks and submit prior authorizations to payers in real time, and the Einstein Trust Layer provides the PHI governance (masking, audit trail, zero data retention with external models). The platform hosts the reasoning and actions; the payer systems remain the source of truth for coverage decisions.

---

Building a prior-authorization agent and trying to keep it on the right side of the medical-necessity line? Talk to us. Grounding healthcare agents in Health Cloud, governing PHI, and designing the human checkpoint where regulation requires it is the architecture we do.