Why AI agents that prepare returns still need an IRS provider

Last reviewed 2026-11-05. IRS sources read on 2026-11-05. General information only, not tax, legal or accounting advice. We do not say whether anyone should file anything.

Short answer

An AI agent connected through the Model Context Protocol (MCP) can gather figures, fill a form and check it against rules. It cannot, by itself, deliver a return to the IRS. Electronic transmission to the IRS goes through Modernized e-File (MeF), and MeF is open to firms that the IRS has accepted as e-file providers, that have passed testing, and that sign in with a registered certificate. An agent is a piece of software acting for a person. It is not a firm, and it cannot hold those things. That is the gap, and it is why we think the next wave of agent-assisted filing needs a provider behind it.

What an agent can and cannot do

Agents are good at the preparation side: reading documents the user supplies, asking for missing values, recomputing totals and calling a validator until errors clear. Our own mock server does this for illustration; see the quickstart.

The transmission side is different, for four reasons.

1. The identifiers belong to firms and people, not to models

IRS e-file participation starts with an application in which a firm, with named Principals and Responsible Officials who must pass a suitability check, chooses provider options. Principals and Responsible Officials must be fingerprinted unless they provide professional credentials. ^[S1] Acceptance brings provider identifiers that identify an accountable organization. ^{[S1, S2]} A language model cannot apply for them, cannot be fingerprinted, and cannot sign an agreement. If an agent frontend does not have its own accepted provider behind it, some other firm’s identifiers must be doing the work, and you should ask whose.

2. The credential cannot sit in the model’s context

The IRS Application-to-Application (A2A) channel uses certificate-based strong authentication. Publication 4164 says A2A transmitters must use X.509 digital certificates after enrolling and registering the certificate, and says the signing key should be kept in a standard encrypted key store, not as an unencrypted copy. ^[S3] It also says each system must be registered with the IRS to get an Application System ID, and that without registration the software cannot access MeF. ^[S2] A private key that appears in a prompt, a tool argument or a transcript is a private key that has been disclosed. The credential belongs in a service the model never talks to, with the model only able to request an action.

3. The IRS requires testing and a signed-login channel

Publication 5078 says each Software Developer must pass Assurance Testing System (ATS) testing for each form type and each tax year it supports, and that transmitters must complete a communications test in their first year before transmitting production returns. ^[S2] Publication 4164 describes the A2A channel as web services: a login request signed with the certificate, a login response containing a Security Assertion Markup Language assertion, and later requests to retrieve status records and acknowledgements. ^[S3] None of that is something a general-purpose agent does by being clever. It is an integration that someone builds, tests against the IRS’s scenarios and maintains each processing year. For the detail, see how software can e-file Form 941.

4. Sensitive values should not pass through the assistant

Taxpayer identification numbers, signature PINs and bank details are the things you least want in a model’s context window, a chat log or an upstream provider’s retention. A design where a person completes those steps on a page the service controls, and the assistant only ever sees a reference, is much safer. It is a design, and we do not claim it is built.

Browser automation is not MeF transmission

One alternative is for an MCP server to drive a third-party filing website in a browser. That is not the same thing as transmission through MeF:

• The filing is performed by the website’s own provider. The MCP server is a remote control for someone else’s product. Whether that is acceptable to the site and to the user is a question for them.
• It inherits the site’s limits on forms and users, and it breaks when the page changes.
• It still puts whatever the user types into an automated session, which is a sensitive-data question, not a solved one.
• It does not give the developer a provider relationship or an audit trail of their own.

We are not saying this is bad. We are saying it is a different thing, and a buyer or an agent should be able to tell which one they are using. Some products say they “file” a form without saying which firm is the transmitter of record, so we suggest asking exactly that.

Why a provider, specifically

Think of the provider as the part that the agent cannot be:

The agent is the front door. The provider is the building behind it.

Where we are

We are building this layer. The IRS has accepted Terragroupe, LLC as an e-file provider (Electronic Return Originator, Transmitter and Software Developer). We are preparing for IRS testing and have not been approved to transmit returns, so we cannot file returns for anyone yet. Acceptance as a provider is not IRS approval or endorsement of our software. We are not affiliated with, endorsed by, or acting on behalf of the IRS. Today you can try the mock docs to see the tool shapes, but its output is never sent anywhere. Honest answer to “can an agent file my return with you today?”: no. For the engineering side, see the checklist for IRS-facing MCP tools.

What to ask any agent-based filing product

1. Which firm is the transmitter of record, and has the IRS accepted that firm as a provider?
2. Has the software completed ATS testing, for which forms, for which year?
3. Where does the signing key live, and can the model ever read it?
4. Which values does the assistant see, and which are handled outside it?
5. What does the audit trail show after the fact?
6. What does it say when it does not know the outcome?

Sources

All sources are IRS publications, read on 2026-11-05. The “revision” column is the revision shown on the publication.

IRS pages change. If a link has moved, search irs.gov for the title. The sections on agents, browser automation and the provider table are our own reading and engineering opinion, not IRS guidance.

Related guides

• How software can e-file Form 941: what the IRS requires: The IRS process, step by step, from IRS sources.
• What an IRS-facing MCP tool has to get right: a checklist: Six checks for MCP tools that send filings to a tax authority.
• Docs for the mock MCP server: the mock does not file with the IRS.

Where efile.technology stands

efile.technology plans to offer employment-tax forms first, if and when the IRS approves production transmission. Access will be by application. What is efile.technology? · Apply for early access