AI Agent Integration withLegacy Systems in 2026

Most conversations about agents in enterprise operations start in the wrong place. They start with the model — which one, how good, how expensive, how it handles your documents. That is the interesting part and it is almost never the binding part. The binding part is duller and older, and it has not changed in twenty years: the system of record is closed, and somebody else controls the write path into it.

Across the industries in this cluster the same asymmetry shows up every time: the richest data is available to read and the smallest surface is available to write. A machine-telematics platform will stream you everything a tractor did in a field, and the agronomic write path runs through a partner agreement. A rail clearinghouse will sell you equipment movement events by the row, and registering equipment requires a reporting mark issued to a company with a relationship. A plant historian will hand an agent every tag on the line, and writing a setpoint crosses a safety boundary where change is a filing rather than a deploy. A claims core publishes read APIs, and the estimating write path belongs to a different vendor on a different contract.

Agents that only read are close to a solved integration problem everywhere. Agents that write are a contract problem, a certification problem or a safety problem — and only rarely an engineering problem. So the first artefact of any serious agent project is not an architecture diagram. It is a census: every system your workflow touches, and which rung of the ladder it sits on.

The five rungs

The ladder is a decision framework, not a metaphor. Each rung down means less vendor cooperation, more fragility and more contractual exposure. You are on exactly one rung per system, whatever your integration layer claims.

The integration ladder. Each rung has a different cost, fragility and contractual exposure.

Rung 1 is narrower than it looks

A documented public API is the rung everybody hopes for, and it is genuinely the right choice when the vendor has a commercial interest in your integration existing. But two things go wrong at Rung 1 with dispiriting regularity.

The first is that the write surface is narrower than the read surface, often dramatically so. Read-heavy APIs with thin write surfaces are the norm, not the exception. Check the specific endpoint that creates the specific record before you architect anything: a documented API with no write path is a Rung 5 in disguise, and discovering that in week nine turns a fixed price into a change order.

The second is that Rung 1 access is still the vendor's to price and gate. Two verified shapes are worth knowing. Amazon's Selling Partner API is free to the seller but gatekept by role: restricted roles that touch personal data require an architecture review with Amazon's SP-API Solutions Architecture team, including data-flow and data-protection documentation, and Amazon approves or denies. Salesforce takes the commercial route with no bad faith involved: API access is not included in Professional Edition and must be purchased as an add-on, and paid editions carry a 24-hour request allocation that scales with provisioned licenses, with additional calls purchasable in increments.

The cleanest available illustration that Rung 1 terms are unilateral is Amazon's 2025–2026 fee episode. In November 2025 Amazon announced an SP-API fee structure for third-party developers — a $1,400 annual subscription from 31 January 2026 plus monthly usage fees on GET call volume from 30 April 2026. As reported by the trade outlet ppc.land and corroborated by Shopifreaks and Tirnav, Amazon then said it would not move forward with the SP-API usage and annual fees at this time, and the fees were cancelled in May 2026 before any were collected; SP-API remained free throughout for sellers using it for their own business. We could not retrieve Amazon's own announcement page — it returned a 404 to us again on 17 August 2026 — so we attribute the wording to the reporting rather than to Amazon, and we do not print a specific reversal date because secondary sources disagree on the day.

Rungs move — sometimes by law

One reason to date the ladder rather than treat it as permanent: regulation occasionally creates a Rung 1 where a vendor offered none. The strongest live example is the EU Data Act (Regulation 2023/2854), whose core obligations — user access rights, interoperability requirements, fair contractual terms, and cloud switching rights including technical cooperation for data porting — became applicable on 12 September 2025. From 12 September 2026, connected products must be designed with accessible data pathways; from 12 January 2027, switching charges are prohibited outright, with only cost-linked charges permitted during the transition. Those dates come from law-firm summaries rather than our own reading of the regulation text, so treat the detail as directional and verify before you build a compliance-driven business case on it.

The counter-example is at least as instructive. The United States has no enforceable federal open-banking mandate today. The CFPB's Personal Financial Data Rights rule under Dodd-Frank section 1033 was finalized in 2024 with phased compliance from 1 April 2026; on 29 October 2025 the U.S. District Court for the Eastern District of Kentucky enjoined the CFPB from enforcing it pending completion of the Bureau's reconsideration, and the 1 April 2026 date passed without becoming a binding trigger. Be precise about status: the rule is enjoined and under reconsideration — it is not vacated, and the Bureau asking a court for vacatur is not vacatur. A replacement proposal exists on the regulatory agenda and has not yet been published. Anyone building a product on the assumption that US open banking arrives on a schedule is building on a rung that is not there.

Rung 2 deserves more attention than it gets, because it is where the real gatekeeping lives and where the costs are least visible before you commit. A certified partner program looks like a sanctioned path — and it is — but the terms are drafted by the vendor, renewed by the vendor, and priced by the vendor in a conversation you cannot have until you are already invested.

The process is standard for the rung: application, then a data exchange agreement, then build, then a beta with a pilot client, then release. Partners on the Standard Interface track get sandbox access, and partners generally get technical support and listing as an approved vendor. What they do not get is a published price. The fee amount is not disclosed anywhere we could find, and the widely repeated third-party figure of $25,000 per interface per year traces to a consulting-firm blog rather than to Yardi, so we do not treat it as a price. The structure is verifiable and the number is not, and saying so is more useful to you than repeating it.

Epic is also the rare case where the partner-access question has produced live antitrust litigation, and the status needs stating precisely because it is widely mangled. Particle Health v. Epic (S.D.N.Y., No. 1:24-cv-07174, filed September 2024) alleges Epic used monopoly power over EHRs to foreclose Particle from the payer-platform market. On 5 September 2025, Judge Naomi Reice Buchwald granted in part and denied in partEpic's motion to dismiss, dismissing five of the nine claims. Particle's Sherman Act section 2 monopolization claims and a tortious-interference claim survived. Among the claims dismissed was the allegation that Epic used its influence to obtain an unfavourable ruling from the Carequality exchange — the court observed that Carequality's imposition of a corrective action plan on Particle was reasonable. Trade coverage reports discovery expanded back to 2021 as of May 2026, and the case remains ongoing as of August 2026 with no merits ruling. A partial dismissal is not a denial, and the Carequality theory is not a surviving allegation.

Other Rung 2 programs follow the same pattern with less published detail. ADP's Marketplace is application-only and, on ADP's own developer materials, favours partners with a substantial base of shared clients — the same prior-traction gate as Yardi. Partners track revenue-share payments to ADP, confirming a revenue-share model exists, but the percentage is not published, and the “up to 75%” figure that circulates belongs to ADP's Accountant referral program, which is a different thing entirely. In P&C insurance, Guidewire publicly documents three API surfaces — Cloud API for InsuranceSuite, InsuranceNow API and a REST API Client — on a page that states no fees, no certification requirements and no sandbox-access policy, and directs readers to contact sales. A prospective integrator cannot price the integration before entering a sales conversation. That is the finding.

Rung 3: EDI and batch, which is better for agents than its reputation

EDI is decades old, boring, and extremely durable. It is still the backbone of healthcare claims, retail supply chain, logistics and banking, and for an agent it is frequently the safestwrite path available — precisely because it is batch. The file is the assertion, the acknowledgement is the acceptance, and the difference between them is a reconciliation queue you can work. Real-time API writes have no such artefact unless you build one, and most teams do not.

The costs are real and mostly visible. The standards themselves are licensed rather than free: X12 operates a multi-tier licensing program — Commercial, Internal, Developer, a Glass Premium subscription and a Code List Update Subscription, plus a free registered-user account for non-premium resources — and access to the EDI Standard requires a paid license tier. The tiers are published; the prices are not. Write “licensed, priced on application,” not a number.

Freight rail supplies the most concrete picture of what the transport layer costs, because Railinc publishes a price list. Its 2026 list prices mailboxes at $30 for TRAIN II and $100 for non-TRAIN II, bills switch usage at $80 per megabyte with a $100 monthly minimum, charges $250 for primary account setup and $250 per trading partner added, $250 for a standard configuration change on a five-business-day turnaround and $500 for an expedited two-day change, and $250 to retransmit a week of messages you lost with $50 per additional day. The customer's data licence is internal-use-only, third-party access requires a Letter of Authorization, and the terms of use may be modified without prior notice, effective upon posting. Billing discrepancies must be raised within 90 days or they are waived.

The characteristic Rung 3 failure is version drift on an announced date. Union Pacific upgraded its EDI requirements from version 8030 to version 8050 effective 11 February 2025, across all of its 417, 418, 419, 420 and 421 transaction sets. That is exactly the class of change that silently breaks an agent whose parser was written against last year's implementation guide — and it was announced on a customer web page rather than pushed to a changelog endpoint. Pharmacy has the same structure on a longer fuse: the HIPAA-adopted retail pharmacy standards move from Telecommunication D.0 and Batch 1.2 to F6 and Batch 15, with a dual-use transition window running 14 August 2027 to 14 April 2028 and full compliance required 14 April 2028, while Medicare Part D e-prescribing moves to NCPDP SCRIPT 2023011 after a transition period ending 1 January 2028. Two independently scheduled migrations, neither of which the pharmacy or its vendors control.

Rung 4: screen scraping and RPA, both halves of the truth

The honest posture is: technically possible almost everywhere, contractually exposed almost everywhere, and structurally fragile because you are consuming a presentation layer the vendor is free to change without notice or versioning. Any UI change breaks it. So does an A/B test, a bot-detection rollout, an MFA requirement, or a contract renewal that adds an anti-automation clause. It is the right choice when it is genuinely the only path, the volume is low, the data is low-stakes, and you have read the terms of service you are bound by. The legal half gets its own section below, because it is the part most commentary gets wrong.

The RPA vendors have repositioned around agents, and their own framing is worth reading closely because it is an admission. UiPath describes a three-layer architecture — orchestration, execution, governance — and states the division of labour like this: “Agents reason within governed workflows… Robots act on systems of record. APIs move data. People intervene where judgment matters.” Elsewhere on the same page: “Where AI agents reason, robots act, and people lead, under one governed control plane,” and “Agency is bounded by architecture, not assumed.”

Take the vendor at its word and the conclusion is ours: robots still do the writing.The brittle screen-driving layer does not disappear when you put an LLM planner on top of it, so Rung 4 fragility is unchanged — UI drift still breaks the write path. What changes is that failures become non-deterministic. A scripted bot fails loudly and identically every time; an agent may improvise around a changed screen and write something wrong. The genuinely new capability is handling unstructured input and branching that was previously un-scriptable. The genuinely new risk is that the thing improvising is holding the write credential.

You also cannot price this migration from public information, which is itself a material fact about the rung. UiPath publishes “Starting at $25 per month” for its Basic tier — a floor, not a price — capped at five Basic, five Plus and one Pro user with two unattended robots, and notes that users and robots may require additional license purchases. Standard and Enterprise are “Contact Sales for pricing.” Automation Anywhere's agent tooling is branded AI Agent Studio and its pricing has gone fully quote-based, with only the free Community edition publicly priced. The widely circulated figure of $8,000 to $15,000 per robot per year comes from third-party pricing aggregators with no disclosed methodology; we treat it as unverifiableand will not print it as fact. Note that unverifiable is not the same as contradicted — a capped entry tier says nothing about enterprise per-robot pricing, because the enterprise tiers are quote-only.

We also found no independent, methodologically-disclosed study of RPA-to-agent migration outcomes, and no major RPA vendor appears to have published migration outcome data. Anyone quoting you a migration success rate is quoting marketing.

Rung 5: no path at all, which is a real answer

Some systems of record have no write path for third parties at any price, and the pillar should say so plainly rather than pretend every problem has an integration. The pattern shows up in three shapes. Sometimes the documented API is explicitly read-only: CivicPlus's own help documentation for SeeClickFix, the volume leader in municipal 311, names exactly two APIs — an Open311 API for pulling public data and a private organizational API for internal dashboards and reporting — and both are described as read or pull. We found no documented public endpoint through which an agent could close a case. Sometimes the standard itself has no write verb: MTConnect, the dominant machine-tool data standard, is built around an agent that publishes device data over HTTP with retrieval verbs — probe, current, sample, asset — and defines no write verb; version 2.5.0 was published on 5 January 2026. And sometimes there is simply no published interface: independent-pharmacy management systems route integrators to a partner page and an inquiry form with no public API documentation, no published certification criteria and no published fees, a pattern visible at Datascan and Keycentrix as independent examples.

At Rung 5 you have three honest options. Change vendors, which is a multi-year decision with switching costs of its own. Wait for a regulatory forcing function, which may or may not arrive on schedule. Or put a human in the loop for the write step and let the agent do everything up to it.

Two cases dominate every conversation about scraping, and both are routinely misstated in ways that would matter in front of a judge. Here is the precise position, from the primary sources.

hiQ Labs v. LinkedIn did not make scraping legal

The Ninth Circuit opinion (No. 17-16783, filed 18 April 2022) was a ruling on a preliminary injunction, not a merits judgment. The standard applied was the circuit's sliding scale: in the panel's words, “So, when the balance of hardships tips sharply in the plaintiff's favor, the plaintiff need demonstrate only ‘serious questions going to the merits.’” The finding, again in the panel's own words:

“HiQ has therefore raised serious questions about whether LinkedIn may invoke the CFAA to preempt hiQ's possibly meritorious tortious interference claim.”

— hiQ Labs v. LinkedIn, No. 17-16783 (9th Cir. 2022), opinion body

A serious question is not a holding that something is lawful. Procedurally, the panel affirmed the injunction, the Supreme Court granted certiorari, vacated and remanded in light of Van Buren, and the panel again affirmed and remanded for further proceedings. On the interaction with Van Buren, the panel wrote that its reasoning reinforces the court's interpretation of the CFAA, although it did not directly address the statute's “without authorization” clause.

What happened after remand is the part that should govern your architecture decisions. In November 2022, on summary judgment, the district court held that hiQ had breached LinkedIn's User Agreement, through automated scraping and through hiring crowdsourced workers to create fake profiles; website terms prohibiting scraping and fake accounts were held enforceable in a breach-of-contract claim, hiQ having expressly agreed to them when it created a corporate account. In December 2022 a stipulated consent judgment entered for $500,000, together with a permanent injunction requiring hiQ to cease all scraping of LinkedIn and to destroy source code, data and algorithms derived from scraped profile data. hiQ stipulated that LinkedIn could establish CFAA and California-equivalent liability, but the CFAA claim was never decided on the merits— a stipulation is not precedent. These post-remand facts come from law-firm summaries rather than our own reading of the docket.

The doctrinal point for your project: terms-of-service breach and CFAA liability are different questions with different answers, and the contract claim is the one that actually bit.hiQ won the CFAA argument far enough to hold an injunction and still lost the case for half a million dollars and a destruction order. “The CFAA probably doesn't reach public scraping in the Ninth Circuit” is a poor foundation for a business, because contract, trespass to chattels and state computer-crime claims are all still live.

Van Buren expressly left the ToS question open

The Supreme Court held that an individual “exceeds authorized access” when he accesses a computer with authorization but then obtains information located in particular areas of the computer — such as files, folders, or databases — that are off limits to him. The much-quoted gates formulation reads, in full: “Under Van Buren's reading, liability under both clauses stems from a gates-up-or-down inquiry—one either can or cannot access a computer system, and one either can or cannot access certain areas within the system.” The opener matters: that sentence is the Court characterising the reading the petitioner urged, which it then adopts. Dropping the opener misrepresents the Court as announcing a test in the abstract, and a legal reader who pulls the cite will find the mismatch.

And then the sentence that most commentary omits entirely:

“For present purposes, we need not address whether this inquiry turns only on technological (or ‘code-based’) limitations on access, or instead also looks to limits contained in contracts or policies.”

— Van Buren v. United States (2021)

The technological-versus-contractual question is open. Anyone who tells you Van Buren settled whether a terms-of-service violation can create CFAA liability is overstating it.

The rules we give clients

• Say Ninth Circuit, not US law: Other circuits are not bound by hiQ. We did not survey post-2022 circuit splits and neither should you assume national uniformity. Nothing here is legal advice; get counsel before you scrape anything commercially significant.
• Do not say scraping is legal or illegal: Say instead: CFAA exposure for public, unauthenticated data is weak in the Ninth Circuit; contract exposure is strong and proven; and other claims — trespass to chattels, state computer-crime statutes, misappropriation — are still live.
• Scraping behind a login you agreed to terms for is a materially worse position: That is the whole difference between a hard CFAA argument and an easy contract loss. hiQ's fake-profile conduct is what made its contract loss straightforward.
• The credential is the tell: If your agent needed an account to see the data, you are bound by whatever that account agreed to. Read it before you automate against it, and read it again at renewal.
• Assume fragility regardless of legality: Even a legally comfortable scrape is a presentation-layer integration. Budget permanent maintenance, alerting on selector failure, and a fallback that degrades to human work rather than to silence.

Below are ten enterprise systems of record from across this cluster's industries, ranked by how open the write path actually is on public evidence. This is the highest-risk table in the article, so read the methodology first — and read the refusal, which is the part that makes the rest of it worth anything.

Ten enterprise systems of record ranked by write-path openness on public evidence, checked 2026-08-17. Tiers, not scores.

Three observations from building it. First, the top of the table is not the biggest vendor — it is the vendor whose customers are its distribution. Bullhorn documents its REST API publicly and issues OAuth keys to customers on a support ticket, with no partner agreement or client sponsorship stated as a prerequisite. It sits directly opposite the dealership DMS market, where sanctioned access runs through gated, contract-based programs with no published criteria or fees. Same year, same country, opposite ends of the ladder.

Second, published prices and open access are different axes. Railinc prices its plumbing to the dollar and still gates access behind a reporting mark and a letter of authorization; its modern visibility products are all quote-only. Jack Henry publishes an unusually open policy and no prices at all. Published price signals commodity utility; quote-only signals negotiation, and your leverage is your volume.

Third, the systems that did not make the table are the ones to watch. We deliberately excluded any vendor whose posture we could not verify from a primary source, which is why the largest credit-union core, several municipal ERP and CIS platforms, and the entire independent-pharmacy management category are absent rather than ranked low. Absence here means unverified, not bad. Do not read it as a recommendation in either direction.

Once you know your rung, the next question is who the agent is to the system it writes into. Get this wrong and you will pass a functional test and fail a compliance review, because the log will say a person did something a machine did.

The clearest shipping articulation is Microsoft's. Entra Agent ID describes agent identities as identity accounts within Microsoft Entra ID that provide unique identification and authentication capabilities for AI agents, with a stated rationale that is vendor-neutral in substance: the need to distinguish operations performed by AI agents from operations performed by workforce, customer, or workload identities; right-sized access; preventing agents from reaching the most critical roles; and scaling identity management to large numbers of AI agents that might be quickly created and destroyed.

On why a service principal is the wrong primitive, Microsoft's own documentation is the best available statement of the problem. Application identities carry the expectation of long-term stability, known ownership, and managed lifecycle, whereas an agent might exist for minutes during a specific task, or might be created and destroyed thousands of times per day; the identity model is designed for scale and ephemerality rather than permanence. If your design begins with a shared service account called something like svc-automation, you have already lost the audit argument.

The two access modes, and why the distinction is load-bearing

• Autonomous access: Agents act autonomously, using access rights given directly to the agent identity. This is the right model for background work — reconciliation, monitoring, batch preparation — where there is no specific human on whose behalf the agent is acting.
• Delegated access: Agents act on behalf of human users, using access rights given to the user, with the user controlling which rights are delegated. This is the right model for anything a person requested, and it is the model that keeps accountability legible.
• The compatibility shim, and its cost: Agents can also be paired with an agent user account — a special user account in a one-to-one relationship with the agent identity — for systems that only understand human users. Be honest about what that does: it is a shim, and it is exactly where audit trails get muddy. If you use one, document why, and make sure your own logs record the real actor even when the downstream system cannot.

One commercial detail that is often glossed and shouldn't be: Microsoft states that Agent ID is available for all Microsoft Entra customers, but that extending Microsoft Entra security features to agents requires Microsoft Agent 365, which is included with Microsoft 365 E7 and available as an add-on to E5, A5 and Business Premium. The identity is free; the security controls are the upsell.On general availability, prefer “generally available as of mid-2026” to a specific GA date — the secondary blogs that assert April 2026 are not supported by the primary documentation page.

The standards status, stated precisely

Most of this layer is draft, and vendors describe drafts as standards. OAuth 2.1 is the base for MCP remote authorization and is still an Internet-Draft, referenced as draft-ietf-oauth-v2-1-13 in the MCP specification. The Identity Assertion JWT Authorization Grant — ID-JAG, the leading cross-application-access building block, which lets an application obtain a token for a third-party API by coordinating through the enterprise identity provider both parties already trust for SSO — is at revision -04, dated 21 May 2026, with IESG state “I-D Exists.” It is not an RFC.Agent-specific OAuth extensions, including an on-behalf-of-user draft introducing a requested-agent parameter and an agent authorization-code grant type, exist as individual drafts rather than working-group items. Call them early drafts, never “the standard.”

SPIFFE and SPIRE are the mature exception — short-lived cryptographic credentials issued on verified workload properties rather than stored secrets, graduated in August 2022 (SPIRE on 22 August, SPIFFE on 23 August, with CNCF announcing on 20 September). They are excellent, and they answer a different question. SPIFFE tells you which service this is. It does not tell you whether this agent is acting for Alice, scoped to these operations, revocably, for the next thirty minutes.

And a negative fact worth stating plainly because it gets asserted the other way: NIST has not published agentic control overlays. The COSAiS project (SP 800-53 Control Overlays for Securing AI Systems) includes single-agent and multi-agent use cases, but as of 2026 these remain in development and unpublished. Do not cite NIST agent controls as existing guidance.

What is genuinely unsolved

• Delegation chains that survive multiple hops: Agent to sub-agent to tool to a second system. No deployed standard carries “acting for Alice, scoped, revocable” across trust domains end to end today. ID-JAG is the leading attempt and it is a draft.
• Revocation and provable cleanup: Creating thousands of ephemeral identities a day is solved. Proving to an auditor that all of them were cleaned up is not.
• Audit attribution: If the agent acts through a user-account shim, the log says a user did it. The MCP specification independently flags this class of accountability risk in its token-passthrough rules.
• Cross-vendor identity: Entra governs Microsoft's estate. There is no neutral, deployed agent-identity layer spanning SaaS vendors, which means a multi-system agent has a different identity story per system.

Meanwhile, in the industries this cluster covers, identity often is not a token at all. In freight rail it is a registered reporting mark or a Railinc-assigned company ID plus a relationship review; BNSF requires certificate-based authentication with an x509 certificate from a well-known certificate authority and rejects self-signed, private, Let's Encrypt, webCARES and CloudFlare certificates, with the certificate common name matching the company on the account, and it conditions shipment-data access on the requesting company appearing on the waybill. Union Pacific requires an active Letter of Authority for third-party providers. That is not a token scope. It is a party-role on a transportation document and a piece of paper, and no amount of OAuth sophistication substitutes for it.

Here is the sentence we say in every discovery call, and it never gets easier to say: prompt injection is not solved, and the people closest to it say so. The entire practical discipline is blast-radius reduction. Anyone selling you prevention is selling you a detection rate.

The most useful framing device is Simon Willison's lethal trifecta, which names three elements: access to your private data; exposure to untrusted content; and the ability to externally communicate in a way that could be used to steal data. On whether it is fixable, his own words: “we still don't know how to 100% reliably prevent this from happening.” On the vendor products that claim otherwise:

Such tools “almost always carry confident claims that they capture ‘95% of attacks’ or similar… but in web application security 95% is very much a failing grade.”

— Simon Willison — The lethal trifecta for AI agents

The integration version of the trifecta is specific and easy to check against your own design. An agent that (1) holds a write credential into a system of record, (2) reads untrusted content — inbound email, a supplier PDF, a customer message, a payer portal, a fax, a web page — and (3) can act without a human seeing it first. Remove any one leg and the blast radius collapses. That is an architectural decision, not a filter, and it is available to you today at no licence cost.

What the MCP specification actually mandates

The 2026-07-28 MCP specification's security document contains real normative requirements — MUSTs in a published spec, not marketing. The important ones for an integration boundary:

1. 1.No token passthrough: MCP servers must not accept any tokens that were not explicitly issued for the MCP server, with audience validation per RFC 9068. This is the rule that stops an agent laundering a credential from one system into another.
2. 2.Confused-deputy controls on proxies: Proxy servers must implement per-client consent, checked before forwarding to a third-party authorization server; redirect URIs must be validated by exact string matching rather than pattern matching or wildcards; state must be single-use with short expiry; consent cookies must be __Host- prefixed and Secure, HttpOnly and SameSite.
3. 3.State handles are not authentication: New in the stateless model: servers must not treat possession of a state handle as authentication, and should bind handles server-side to the authenticated user — for example keying state as user_id:handle where the user ID is derived from the verified token rather than supplied by the client.
4. 4.Server-side request forgery: Clients must consider SSRF when fetching OAuth metadata URLs and should block private and link-local ranges including 169.254.0.0/16, the cloud metadata range. The spec advises against implementing IP validation manually, because encoding tricks defeat custom parsers.
5. 5.Local server compromise: One-click local server configuration must show the exact command without truncation and require explicit approval, because such servers run with the same privileges as the client.
6. 6.Scope minimization: Named risks include expanded blast radius from a stolen broad token enabling unrelated tool and resource access, privilege chaining, and audit noise where a single omnibus scope masks user intent per operation. Named anti-patterns: wildcard or omnibus scopes, publishing all scopes in scopes_supported, and bundling unrelated privileges.

The research direction, and where it actually is

The convergent approach across 2024–2026 research is to enforce security outsidethe model with a deterministic policy engine mediating actions, rather than training the model to refuse. The model proposes; a non-LLM reference monitor disposes. CaMeL (“Defeating Prompt Injections by Design,” arXiv 2503.18813) is the clearest instance: a privileged LLM builds a plan from the trusted user query, a quarantined LLM processes untrusted data with no tool access, and a custom interpreter tracks data provenance and enforces policy before each tool call. Named siblings include FIDES, Progent, RTBAS and FORGE, alongside “Design Patterns for Securing LLM Agents against Prompt Injections” (arXiv 2506.08837). We have read the abstracts, not the papers end to end.

Our assessment of adoption, stated as our own argument rather than borrowed testimony:we could find no production-grade CaMeL implementation, and architectural patterns of this class do not appear to be shipping in any mainstream agent harness. We flag it as our reading because the only source we located for that claim in circulation is a sponsored article on a security trade site — paid placement, not research or neutral reporting — which is precisely why we will not quote it or call it the state of the field. Treat the research as the direction of travel and build the boring controls today.

Real versus marketing

For the security review, cite the current list: the OWASP GenAI LLM Top 10, 2026 edition, published 4 August 2026, carries LLM01:2026 Prompt Injection, LLM03:2026 Excessive Agency and LLM10:2026 Improper Output Handling. For agents with tool access to production systems, LLM03 and LLM10 are the priority pair, and the mitigations cited for Excessive Agency are exactly the boring ones: least privilege, confirmation for high-impact actions, and tool-usage logging.

This is the engineering that stops a retry becoming a duplicate invoice, and it is the section most agent write-ups skip. It should not be skipped, because agents write over unreliable networks, get interrupted mid-plan, and are frequently restarted by an orchestrator that has no memory of what already succeeded.

Start with the fact that surprises people: there is no standard. The IETF HTTPAPI working group's draft-ietf-httpapi-idempotency-key-header, intended for the standards track, reached revision -07 on 15 October 2025 and its IESG state is Expired. It is not an RFC. What exists instead is a de-facto convention set by Stripe, which is why every vendor's semantics differ slightly and why integrating with two systems means reading two different idempotency contracts.

The reference implementation is worth understanding precisely. Stripe's documentation states that its idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeds or fails, and that subsequent requests with the same key return the same result, including 500 errors. The clientgenerates the key — V4 UUIDs are recommended, or another random string with enough entropy to avoid collisions, up to 255 characters — and the docs explicitly warn against using sensitive data such as email addresses or personal identifiers as keys. Parameter mismatch is an error: the idempotency layer compares incoming parameters to those of the original request and errors if they are not the same, to prevent accidental misuse. Idempotency keys belong on POST requests; the docs say not to send them on GET and DELETE, which are idempotent by definition.

There is one more edge worth knowing: results are only saved once endpoint execution begins, so if parameters fail validation, or the request conflicts with another request executing concurrently, no idempotent result is saved and those requests remain retryable. Two agent workers racing on the same business event will not be deduplicated by the downstream key alone.

The seven rules we build to

1. 1.Derive the key from business intent, not from the attempt: Key on (tenant, invoice number, amount) or (patient, provider, slot) — not a fresh UUID per retry, which defeats the mechanism entirely. This is the single most common implementation error we see.
2. 2.Persist the key before the call, not after: A key that exists only in the agent's context window is lost on crash, and a crashed agent that restarts is precisely the scenario idempotency exists for.
3. 3.Respect the retention window: If the downstream prunes at 24 hours, your own dedupe table must outlive it. Your retry policy and their retention policy are one system, and only you are looking at both.
4. 4.Never let the model choose the key: Non-determinism in key generation is indistinguishable from having no idempotency at all. Keys are computed by deterministic code from structured fields, not generated in a completion.
5. 5.Reconcile, do not trust: Read back and compare against the system of record on a schedule. Treat the system of record as truth and the agent's belief as a hypothesis — because after an interrupted plan, the agent's belief is exactly that.
6. 6.Prefer reversible writes: A draft invoice beats a posted invoice. A held slot beats a confirmed booking. A work order beats a setpoint. Reversibility is the cheapest blast-radius control available and it composes with everything in the prompt-injection section.
7. 7.Remember that batch rungs give you reconciliation free: On Rung 3 the file is the checkpoint and the acknowledgement is the receipt. Real-time API writes have neither unless you build them, so budget the reconciliation job into the first workflow rather than the third.

The interoperability layer matured fast in 2026, and it is genuinely useful. It is also routinely oversold in exactly one way, which this section exists to correct.

MCP. The current specification is 2026-07-28, published on 28 July 2026; the prior stable version was 2025-11-25. The headline architectural change is that MCP went stateless — in the project's own words, “MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol.” That is a real breaking-change story for anyone who built against the previous stable spec: session state becomes explicit server-minted handles passed as ordinary tool arguments, with the state-handle rules described in the security section above. Other changes include multi round-trip requests, header-based routing via Mcp-Method and Mcp-Name, cacheable list results with ttlMs and cacheScope, and a formal extensions framework that moved Tasks out of core alongside MCP Apps and Enterprise Managed Authorization. Authorization hardened too: authorization servers should return iss per RFC 9207 and clients must validate it, client credentials are bound to the issuer that minted them with no reuse across authorization servers, and Dynamic Client Registration is migrating to Client ID Metadata Documents. Governance moved to the Linux Foundation, with the project describing itself as a Series of LF Projects, LLC. SDKs exist for TypeScript, Python, Go and C#, with a beta Rust SDK.

On adoption, the number in circulation comes from the project's own blog and should be attributed and understood: MCP reports that “Across our Tier 1 SDKs, we're seeing close to half-a-billion downloads a month,” with “both TypeScript and Python SDKs crossing the 1 billion total downloads threshold.” That is the promoter's figure and it measures package downloads, not production deployments. CI pipelines download packages too.

A2A.Agent2Agent reached v1.0 in April 2026 under Linux Foundation governance, having been donated by Google Cloud. The Foundation's press release of 9 April 2026 claims more than 150 organizations (up from more than 50 a year earlier), more than 22,000 GitHub stars, and SDKs in five production languages, naming AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP and ServiceNow among adopters, with platform integration cited in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime. Attribute all of that: it is a press release from the foundation that hosts the project, and “150 organizations supporting the standard” is a support or membership count, not a count of production deployments. GitHub stars are not adoption.

What they do not solve

• They are transport and discovery, not permission: MCP standardises how a tool is described and called. It does not decide whether this agent may issue this write.
• No system of record gains a write path because MCP exists: If a vendor's contract requires an interface-partner licence, an MCP server does not change that. An MCP server is a wrapper around whatever rung you were already on. That is the punchline of this entire article.
• They do not solve prompt injection: The specification's own security document is about confused deputies, token scope, SSRF and consent — blast radius, not injection.
• They do not solve identity delegation across trust domains: That is ID-JAG's job, and ID-JAG is a draft at revision -04 with IESG state I-D Exists.
• They do not solve idempotency or reconciliation: Nothing in MCP prevents a retried tool call from creating a second invoice. That remains yours to build.
• Version churn is real and must be budgeted: MCP shipped a stateless rewrite roughly eight months after the previous stable specification. Building on it means accepting that cadence and staffing it.

Integrations do not degrade gracefully; they work until a specific event, then stop. These are the events, in rough order of frequency, with the detection signal and the rollback for each.

This table is the single most useful artefact you can put in front of a sponsor, a security reviewer and a regulator, because it converts “we have humans in the loop” from a reassurance into a specification. Adapt the wording to your industry; do not move the last four rows.

The human-in-the-loop boundary for agents writing into enterprise systems of record.

Two principles hold the table together. The first is reversibility: the further a write can be undone without a person noticing, the more autonomy it can safely carry. The second is accountability transfer: where a statute, a licence or a professional duty attaches to a named human, the agent may prepare everything and decide nothing. Those two tests will classify almost any action you bring to them, including ones this table does not name.

This is the reason the article exists. Phases, week ranges, an owner per phase, an explicit entry and exit criterion, and what to do when the phase fails — because phases do fail, and the failure mode is nearly always “we discovered the write path in week nine.”

A sequenced integration path for an agent writing into a closed system of record.

The five questions to put to your vendor rep, in writing

Phase 1 lives or dies on these. Send them as an email, get a named reply, and file it with the contract. If the answers are vague, that is an answer.

1. 1.Is there a documented endpoint that creates this specific record?: Not “do you have an API.” Name the record — the appointment, the invoice, the claim, the work order, the permit — and ask for the endpoint and its documentation URL. A yes without a URL is a no.
2. 2.What does third-party access cost, and is the fee flat or per-transaction?: Ask for the fee schedule in writing. Ask whether it is per interface, whether it renews annually, and whether the model can change at renewal. Yardi's published wording — annual, per interface, sometimes per-transactional — is the shape to expect.
3. 3.What is the certification or approval process, and how long does it take?: Application, data-exchange agreement, build, beta with a pilot client, release is a normal sequence. Ask who can revoke, on what notice, and what happens to live customers when they do.
4. 4.What are the rate limits, and where are they published?: If they are not published, ask for them in writing anyway. An unpublished limit is still a limit, and you would rather learn it in a sales conversation than at month-end close.
5. 5.How and where do you announce breaking changes, and what notice do we get?: A changelog endpoint is best, an announcement page is normal, and “we email your admin” is a risk you must staff around. Get the notice period, and subscribe whatever the answer is.

What It Costs to Build

These are the bands Frenchy Digital uses to scope agent integration work in 2026. They assume the write-path census sits inside the project rather than being discovered inside it — because that discovery is exactly what turns a fixed price into a change order.

Frenchy Digital cost bands for agent integration engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month, covering model and dependency upgrades, integration monitoring as your vendors ship releases, schema-drift watch against announced version dates, evaluation expansion, incident response and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call. Book that call at calendly.com/frenchydigital/discovery-call or call +1 (424) 272-5601, and bring your system list, your vendor contracts, and the name of the record you actually need to create.

One budgeting note that applies across the cluster. The integration substrate is largely a fixed cost paid once: the first workflow carries the connections, the identity model, the audit pipeline, the idempotency layer and the reconciliation job. The fourth workflow inherits all of it and costs a fraction of the first. Operators who sequence their automation get materially better economics than operators who run four disconnected vendor pilots in parallel — and the second group also ends up with four different data models describing the same business.

Whether you are choosing an agent platform, an integration middleware vendor, or a consultancy, these are the signals that predict trouble. Every one of them is checkable in a first meeting.

• They will not name your rung: Ask which of the five rungs you are on for each of your systems, and ask for the artefact. A vendor who answers “we integrate with everything” has not looked, and you will pay for that later as a change order.
• They quote a detection rate for prompt injection: Any confident percentage on injection capture is a marketing number with no published method. The correct answer to “how do you handle prompt injection” is an architecture — no untrusted content in a session that holds write credentials — not a filter.
• They present vendor-published accuracy, deflection, containment or ROI figures as neutral fact: If the only source for a number is the company that benefits from it, it is a claim, not a finding. Ask for the methodology, the sample and the date. The absence of all three is your answer.
• They cite a per-robot, per-interface or per-seat price for a quote-only product: The major RPA platforms' agentic tiers are quote-only. Yardi, Epic Vendor Services, X12 and the core banking vendors do not publish fees. A specific number for any of these traces to an aggregator blog, not the vendor.
• They say a standard exists when it is a draft: ID-JAG is at -04 with IESG state I-D Exists. OAuth 2.1 is an Internet-Draft. The idempotency-key header draft is expired. NIST's agentic overlays are unpublished. A vendor that calls any of these “the standard” either has not checked or is hoping you will not.
• They tell you hiQ made scraping legal: It did not, and the case ended in a reported $500,000 stipulated consent judgment and a destruction order. A vendor whose compliance story rests on that misreading has a compliance story you cannot use.
• They propose a shared service account: One identity per agent, or the audit trail is fiction. If the proposal is svc-something with broad scopes because “the system only understands users,” make them document the shim and what it costs you in attribution.
• There is no idempotency or reconciliation design in the proposal: Ask how the key is derived, when it is persisted, and what the reconciliation job compares. If the answer involves the model generating a UUID, the proposal has no idempotency at all.
• The pilot has no defined write boundary: “We'll start read-only and expand” is fine if the expansion criteria are written down now. If nobody can tell you what evidence would justify granting a write credential, nobody will be able to tell you later either.
• They will not put schema-drift monitoring in the scope: Version bumps arrive on the vendor's calendar, not yours. If drift watch is not in the retainer, it is not happening, and the first outage will be blamed on the model.
• The proposal has no exit: Insist on source-code and IP ownership transfer, exportable data, and documented interfaces. If leaving costs you the integration, the renewal conversation is not a negotiation.

The honest list. Everything below is a gap in the public record, not a gap in effort, and each one is a place where you should verify before you commit capital.

• No independent measurement of agent integration outcomes exists: We found no methodologically-disclosed study of how often agent integration projects succeed or fail. Anyone quoting you a rate is quoting a vendor survey or an unsourced statistic. We will not imply such a study exists.
• Fee amounts are unpublished across the board: Yardi interface fees, Epic Vendor Services fees, X12 license prices, the ADP Marketplace revenue share, UiPath's Standard and Enterprise tiers, Automation Anywhere's pricing, Guidewire's partner terms, core banking API pricing and independent-pharmacy PMS integration fees are all quote-only or unpublished. That absence is itself a finding, and it is why this article prints structures rather than numbers.
• Scraping law outside the Ninth Circuit: We did not survey post-2022 CFAA circuit splits, did not verify Meta v. Bright Data, and did not establish any EU or UK scraping position. Do not assume national or international uniformity from the cases discussed here, and get counsel.
• The hiQ district-court record: The Ninth Circuit opinion is primary; the November and December 2022 district-court orders reached us through law-firm summaries rather than the docket. If you need to quote the district court, pull the orders first.
• Amazon's own words on the SP-API fee reversal: Amazon's announcement page returned a 404 to us again on 17 August 2026, so the wording is attributed to trade reporting rather than to Amazon, and secondary sources disagree on the exact day in May 2026. We print the month only.
• The Particle Health v. Epic docket: The 5 September 2025 ruling reached us through law-firm and trade summaries rather than the docket itself. A separate August 2026 report of FTC interest in Epic's contracting practices was headline-only and we did not verify it, so we have not used it.
• Healthcare information-blocking rule citations: We did not verify current ONC/ASTP information-blocking or HTI rule citations in this pass. The reason Epic publishes FHIR APIs at all is regulatory, but we refer to that generically rather than naming a rule we have not checked.
• RPA migration outcome data: We found no published migration outcome data from any major RPA vendor and no independent study. The vendor architecture claims quoted here are quoted as claims.
• OWASP verification is harder than it should be: The OWASP GenAI LLM Top 10 landing page still serves the 2025 list, and at least one widely-syndicated security outlet publishes a materially wrong 2026 ordering that aggregators have copied. We verified against the project's own repository, and you should too rather than trusting secondary coverage.
• Vendor corporate status is perishable: Ownership in several of these markets is in motion, and private-equity processes are frequently reported before they close. Where we name an owner we name it as history with a date. Re-check ownership on the day you sign, not the day you research.
• Our cost bands are ours: The Frenchy Digital figures in this article are our scoping bands, not an industry benchmark. They reflect senior-led delivery on integration-heavy work in 2026 and should be read as one firm's pricing, which is exactly how you should read every other number a vendor gives you.

None of this argues against building. It argues for building the census first, the identity model second, the read agent third and the write path fourth — and for pricing the whole thing against the rung you are actually on rather than the one on the slide. The teams that get value from this work are the ones who found out what they were permitted to do before they found out what the model could do.

And the boundary holds throughout. An agent reads, assembles, drafts, checks and proposes. A person commits anything that moves money, changes a clinical or credit or coverage outcome, touches a safety system, or carries a signature. That is not caution for its own sake — it is the only architecture that survives both a prompt injection and a compliance review, and it happens to be the one that actually ships. An agent can only be as autonomous as its write path allows.