Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Who Approves an AI Agent's Appeal of a Denied Claim?
The billing manager approves it, on the submission, because an appeal commits the provider to a clinical position the organization has to defend. Check what the model received from the denial and the draft before that signature, and whether the approval names the person and the claim.
A provider's billing office starts every appeal from a page the payer wrote: a claim number, a member identifier, a reason code, an allowed amount and a date by which the provider must answer. An agent can open that page, read the clinical note and the coding history, and put a draft appeal in front of a person in minutes. What the draft carries is the whole question. An appeal is the provider's statement that a denial was wrong, and the organization stands behind the clinical position while the dispute runs, so the signature belongs to someone with authority over the claim, not to the model that assembled the letter.
Before the draft exists, the model has read the denial, and in most workflows it read the member identifier, the claim number and the diagnosis code as the portal rendered them. The person who signs is therefore approving a position built from values the model already holds, on a screen the model wrote. Who that person is, what they are shown and what record survives the submission are the three parts of the answer for one record type in a provider's queue: an appeal submitted after review, with the denial page and the draft as the two documents the decision rests on.
Key findings
- For an appeal to be governed rather than merely reviewed, the denial and the draft would have to be rendered with consistent tokens before any model reads the screen, so the agent works from MEMBER_001 and CLAIM_001 while the real identifiers stay outside its context (What Is Supervised Delegation?).
- It would also require a named person approving the submission, with a record that ties that signature to the appeal text and to the screen the model read, because an appeal commits the provider to a position it has to defend (What Is an AI Control Record?).
- None of the pages reviewed describes an approval that names both the appeal and the screen the model read: Coupa's API records an approver and an approved-by value, and neither of them carries the draft the approver was shown (Coupa, Approvals, 2026).
- Guidewire's Qusar release gives insurers agents with "secure, real-time access to policy, claims, and billing data and workflows," and the announcement says nothing about human approval of an agent action (Guidewire, 2026).
- Oracle Health's patient accounting page says the system "tracks payments from patients and health insurance payers" and uses business rules to "identify and assign work," which automates the queue and not the signature on an appeal (Oracle, 2026).
- OWASP describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," which makes the approval page part of the surface (OWASP Foundation, n.d.).
Who signs an appeal once the denial has been read?
The worked record is an appeal submitted after review. A denied professional claim sits in the payer portal with its denial letter, the agent has drafted the appeal in the claims system, and the draft waits at an approval step. The signature there belongs to the billing manager who owns the claim, not to the agent that assembled the letter. Rishov Chatterjee, AI engineer at Curology and former Director of Data Science and AI at Integra Connect, described the evidence problem on a HAL podcast: "So when you have all these situations, a lot of times the best way to solve it is just provide the evidence yourself" (Who Is Responsible When an AI Agent Takes Patient Records? A Healthcare AI Builder on BAAs, Biometrics and Cost).
An appeal is the provider's written position that a denial was wrong on medical necessity, coding or eligibility, and the payer answers it in writing. Horton and co-authors define the class as "autonomous software systems that perceive, reason, and act in digital environments to achieve goals on behalf of human principals," and the principal in that definition is the party an appeal binds (MIT Sloan, 2026).
Insurers have written this down. The NAIC Model Bulletin, adopted by 24 states as of March 2025, requires insurers to maintain a governance accountability structure for AI systems with defined responsibilities, and an agent payment with no named approver fails that requirement on its face (Who Approves an AI Agent's Claim Payment?). The bulletin binds insurers, and a provider's appeal runs under the billing office's authority.
The signature also settles who is disclosing. HHS lists "claims processing or administration" among the business-associate activities that require "satisfactory assurances, in the form of a contract or other written arrangement," so a drafting vendor that reads the denial is a business associate (HHS Office for Civil Rights, 2026). A provider that submits its own claim acts as the covered entity, which keeps a self-submitted appeal inside its authority (HHS Office for Civil Rights, 2026).
What does the agent read when it opens the denial?
The denial page starts the work. A payer portal claim view shows the claim number, the member identifier, the dates of service, the diagnosis and procedure codes, the allowed amount, the remittance and the appeal deadline. The agent reads all of it as the page draws it, and the draft repeats the claim number and the member identifier, because an appeal has to identify the claim. 123.9 million of the 220.0 million people affected by large healthcare breaches in 2025 and 2026, 56.3%, were in breaches that came through a business associate, which is why the denial a vendor renders deserves the same limit (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
That repetition is a privacy question. The minimum necessary standard at 45 CFR 164.502(b) asks the organization to limit protected health information to what the task requires, and an agent that reads the whole chart to check a claim status has not limited anything (Can an AI Agent Work in Epic Without Holding PHI?). The version that page sets out is a model that receives tokens where the identifiers were, which is the only version in which the minimum necessary showing is direct (Can Staff Use AI on Patient Records Without PHI?).
The submission is a second reading. An appeal leaves through a portal form or an attachment, and the confirmation page repeats the claim number and the member identifier. A control that covers the typing step and stops at the confirmation covers half of this record (Can a Browser Agent Fill In a Form Without Seeing the Values?).
What do the vendors themselves say?
Guidewire's Qusar release announces an Agentic Framework that "provides AI agents with secure, real-time access to policy, claims, and billing data and workflows," and it names claim summarization among the agents it ships, but the announcement gives no approval workflow, no authority limits and no statement that a human must approve an agent's action (Guidewire, 2026).
Oracle Health markets Patient Accounting as an EHR-agnostic system that "tracks payments from patients and health insurance payers to drive accurate billing" and promises to "Prioritize and collect on outstanding accounts receivable with embedded business rules to identify and assign work efficiently," and the page names no API or agent, so the automation sits at the workflow level and not at the signature (Oracle, 2026).
Coupa's Approvals API carries an approval object, and its fields describe the item rather than what the approver saw. It exposes approve, hold and reject actions; its elements include approver, approvable-id and approved-by; and "an approval must be Pending (and not already approved or rejected)" before a PUT can act on it (Coupa, Approvals, 2026). The page "does not say who may approve or how approval chains are configured," so it documents the shape of a signature and not the authority behind it (Coupa, Approvals, 2026).
Workato's Coupa Approval Operations MCP server puts the approval in a model's hands with a guardrail, and the page describes tool behavior rather than Coupa's policy. Its approve_approval tool "Approves a pending approval if it hasn't changed since it was last reviewed," and actions run with the approver's own account permissions, because "A request made without the required permission returns a permission-denied outcome" (Workato, 2026).
| Dimension | What the page documents | What a buyer should verify |
|---|---|---|
| Agent reach into claims | Guidewire: agents with "secure, real-time access to policy, claims, and billing data and workflows" | Whether an agent's claim action needs a person's approval, and where it is recorded |
| Work assignment | Oracle: business rules that "identify and assign work" | Whether the draft appeal is a queue item or a document with a signature |
| Approval fields | Coupa: approver, approver-type, approved-by, and a status that must be Pending | Who may approve, and whether the approval is bound to the appeal text |
| Confirmation | Workato: approval "after showing the document summary and obtaining confirmation" | Whether the summary shown is composed by the model or drawn from the page |
Does an approval tool in the workflow answer the question?
An approval tool answers a narrower question than the title asks. It records that a person acted on an item, when, and what the item's status was: a history of the queue rather than evidence of what the approver saw. The record that matters for an appeal has to show the denial page the model read and the draft the person released, and a status field holds neither.
The one vendor page that describes the approver's evidence describes a summary the model composed. Workato's server has the model approve "after showing the document summary and obtaining confirmation," so the confirmation answers a presentation of the item rather than the page the model read (Workato, 2026). Its guardrail holds only while the item has not changed since it was last reviewed, which binds the signature to a version and not to the screen behind it.
OWASP describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," and a dialog fed by a model-written summary is the case that attack describes (OWASP Foundation, n.d.). A person who approves a summary has authorized whatever it left out.
The design-patterns paper puts the constraint where an approval cannot reach it: once an agent ingests untrusted input, "it must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al., 2025). An approval bound to the denial as it rendered for the model, and to the draft as it will be sent, is the version that meets it.
What does a governed environment change?
A governed environment changes both the object of the approval and what the model holds when the approval arrives. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.Policy-chosen values, the member identifier, claim number and diagnosis code among them, are replaced with consistent tokens before any model reads the screen, so the agent works from MEMBER_001, CLAIM_001 and DX_001 on the denial and on the draft. Real values resolve only at the approved destination, at the moment of an approved action, and for an appeal that destination is the payer portal submission a named person releases. The claims portal test puts it the same way: the page shows MEMBER_001 and DX_001 (ChatGPT Atlas, discontinued in August 2026).
That changes what the approver is deciding: the ungoverned screen shows a draft carrying identifiers the model already read, and the governed one shows the tokens, the resolved appeal at the submission, and the name on the signature.
Chan and co-authors propose three visibility measures, "agent identifiers, real-time monitoring, and activity logging," and all three describe what an agent did (Chan et al., 2024). Every screen the model read, every action and approval is written to an evidence set that exports to the organization's monitoring (What Is an AI Control Record?).
No single control produces that record. Columbia's DAPLab writes that "trustworthy agent automation cannot be solved at a single layer of the stack," and an appeal crosses the EHR, the clearinghouse and the payer portal (Columbia University DAPLab, 2026). Mitchell and co-authors argue that fully autonomous AI agents should not be developed, which places the design weight on the supervision layer (Mitchell et al., 2025).
The scope is the rendered page: the payer portal, the EHR screen and the clearinghouse form, not the terminal, a direct API call, or the payer's own systems.
What the record shows
Accountability for a provider's appeal is settled by two artifacts: the screen the model read and the signature on the submission. The billing manager signs because the appeal commits the provider to a position, and the vendor pages reviewed automate the queue and the approval object without describing what the approver saw. The design that closes the gap replaces the identifiers with tokens before any model reads the screen, resolves the real values only at the approved submission, and writes the screen, the action and the approval to one record. Revenue cycle leaders should check it on one denied claim: run the draft with test values, capture the denial page, the draft and the approval, and compare it with the submission; if the capture holds the real member identifier, the signature arrived after the exposure.
Methodology and limitations
This page rests on vendor documentation from Guidewire, Oracle, Coupa and Workato, HHS OCR guidance, the OWASP community attack page, three research preprints, industry analysis from MIT Sloan and Columbia's DAPLab, and RedactSure research pages. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page, and the RedactSure pages cited describe a design rather than a measured result. "Not described in the pages reviewed" means the pages listed in Sources, and vendor features change, so the page carries its date. The example describes a record type, an appeal submitted after review, and not an organization. RedactSure is deploying now with enterprise and government customers. Determinations about whether an appeal or a disclosure meets a contractual or regulatory requirement belong to counsel, assessors and the organization's compliance officers, and a pilot of one workflow replaces none of it.
Frequently asked questions
Who approves an AI agent's appeal of a denied claim?
The billing manager who owns the claim approves it, on the submission, and that person is named before the draft is sent. The agent drafts from the denial and the record; it does not commit the provider to a position the organization has to defend. A queue approval, a payer's confirmation and a vendor's review are different objects. Check that the approval names the claim, the appeal and the person, and that it arrives before the submission rather than after it.
What does the agent see on the denial page?
Whatever the portal renders: the claim number, the member identifier, the dates of service, the diagnosis and procedure codes, the allowed amount and the denial reason. Unless those values are replaced before the model reads the page, they stay in the draft and in the run's context for the rest of the task. The appeal repeats the denial's identifiers, so the reading and the writing carry the same data.
Does the payer's portal confirmation count as the approval?
No. A confirmation shows that the portal accepted a submission, and it arrives after the model has read the denial and written the draft. It names no person at the provider and states no position the organization took. Treat it as evidence the appeal was filed, not as the signature on it, and look for the approval that exists before the submission and names the claim.
What record should exist after the appeal is filed?
It should hold the claim, the appeal text, the screen the model received, the person who approved and the time. It should export to the organization's own monitoring rather than stay in a vendor dashboard. Chan and co-authors propose agent identifiers, real-time monitoring and activity logging; an appeal needs the approver's name beside those. Without the screen, the record shows what was sent and not what the model knew when it wrote the draft.
Can a standing approval or a dollar threshold replace the billing manager?
No. An appeal is not sized like an invoice, so a threshold does not sort it, and one letter commits the provider to a clinical position for as long as the dispute runs. A standing approval for a class of appeals has the same problem, because the position changes with the denial reason and the record. The signature should be per submission, by a person with authority over the claim.
What should a security team ask a vendor in writing?
Ask what the model receives from a rendered screen: the full denial page, consistent tokens such as MEMBER_001, or nothing. Then ask who approves the submission, whether the approval is bound to the appeal text, and where the record of the screen and the signature lives. An answer the documentation does not support is unanswered until a test on one claim, with no real patient data, confirms it.
How RedactSure Keeps an Appeal Behind a Named Signature
An appeal drafted from a denial the model has already read leaves the signature on a position the model wrote. Workato's approval tool "Approves a pending approval if it hasn't changed since it was last reviewed," which checks the item rather than what the approver saw (Workato, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the denial renders the member identifier, claim number and diagnosis code, and the model carries them into the draft. Inside: it renders as MEMBER_001, CLAIM_001 and DX_001, the draft is written on those tokens, and real values resolve only at the submission a billing manager approves.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An appeal is a position the organization defends, and the signature is where it takes one. Bring a denied claim and see, with test values, what the model reads and who approves the submission. Book a demo