The thesis: this is an interface question, and finance is good at interface questions.
Something quietly significant happened to ERP integration architecture over the past eighteen months. The Model Context Protocol, released as an open source project by Anthropic in November 2024, became the ordinary way an AI agent reaches a business system. Microsoft now ships a Dynamics 365 ERP server for it that can create, read, update and delete data, drive application forms, and invoke application code. SAP publishes a reference architecture for third party access to SAP solutions through it. The connection between a language model and the general ledger is no longer a thought experiment. It is a configuration setting, and in at least one product it is on by default.
In May 2026 the NSA’s Artificial Intelligence Security Center published its design considerations for the protocol, produced with the Carnegie Mellon University Software Engineering Institute. It is worth reading in full, and the most useful thing in it is also the plainest. The protocol does not enforce your controls. Authorization is optional. Role permissions are not exchanged between components. Audit logging is left to whoever built the server. The guidance quotes the protocol’s own documentation to the effect that these principles cannot be enforced at the protocol level at all.
NSA is releasing security design considerations for AI-driven automation leveraging MCP which, while simplifying the integration of diverse capabilities into powerful agent workflows, requires caution.
Read quickly, that sounds like a reason to wait. Read properly, it is the opposite. A protocol that declines to enforce access control is not unusual. Neither HTTP nor SFTP decides who may post a journal entry, and no finance team has ever expected them to. The controls live one layer up, in the system that owns the data, and finance has spent thirty years learning how to describe them: a named counterparty, a scoped role, a validation contract, an approval threshold, a log. The interesting finding in the vendor documentation is that this is exactly where Microsoft and SAP have put them, independently and in almost the same shape.
So the practical question is not whether to allow an agent near the ledger. It is whether the connection is described with the same care as the bank connection sitting next to it. That is a tractable piece of work, most of it is documentation rather than engineering, and the artefact it produces stays useful regardless of which agent platform survives the next two years.
What the guidance actually says, and what each point means in a finance system.
The document runs to seventeen pages including its works cited, and its structure is straightforward: observed concerns first, then recommendations, then real world examples of implementations that went wrong. The concerns below are the ones that change something about how a finance team should specify an agent. The left column is what the guidance says. The right column is ours.
| Concern | What the NSA published | What it means for the ledger |
|---|---|---|
| Access control | Associating a session to an identity is not defined by the protocol and is left to the implementer. Many implementations omit authentication entirely, and those that include it often lack role based enforcement such as distinguishing create, read, update and delete permissions. The protocol has no way to exchange role based access control permissions at instantiation. | The question a controller asks first, which is whose authority the agent posted under, has no protocol level answer. It has an excellent ERP level answer, and that is where to ask it. |
| Approval workflows | The NSA quotes the protocol documentation directly: MCP itself cannot enforce these security principles at the protocol level. It adds that a change in capability or data access for an already trusted server can often be made without approval, and that users are frequently not prompted to consent to the change. | Capability drift is the finance risk here. A server approved to read the trial balance in March can be reading and writing something else by September without anything asking a human. |
| Token and session security | Authorization is optional. Servers rely on bearer tokens as defined in OAuth 2.1 without protocol level token lifecycle management, meaning refresh, revocation and reuse control. Expiration and rotation appear as best practice in drafts rather than as a core requirement. Idempotency is not enforced by the protocol and is left to the transport. | Idempotency is the one that lands squarely in accounting. A retried tool call that posts twice is a duplicate journal entry, and the protocol is not the layer that will stop it. |
| Audit logging | The specification includes basic logging guidance and leaves comprehensive audit requirements to the implementer. Many implementations omit logging or record only minimal operational metadata. The NSA asks for a traceable sequence of actions across sessions, source information from the request headers, and detection of repeated or malformed requests, authorization failures and role violations. | This is the sentence to read twice before an audit. Evidence that an agent acted within its authority exists only if someone chose to write it. |
| Trust between components | Output from one component should never be treated as implicitly trusted input by the next, even when it came from a vetted component. In multi component pipelines the NSA asks for the output of each tool to be logged and inspected before it is passed on. | A close pipeline where an agent reads a bank file, summarises it, and hands the summary to a second agent that posts, has two trust boundaries in it and usually no check at either. |
| Data segregation | The guidance asks organisations to align tools and models with data classification zones, and names financial information explicitly among the categories that should be controlled and segregated. It recommends preferring a local server instance when private data is being processed. | A useful prompt for a decision most teams have not made yet, which is whether the ledger tools and the general productivity tools belong on the same surface at all. |
| Inventory and exposure | Maintain a clear inventory of every deployed agent and tool with versioning, patch history and known concerns. Scan the network for unauthenticated, vulnerable, unauthorised or internet exposed servers, noting that servers may change ports dynamically. | An interface register by another name. Finance has kept one of these for bank connections and EDI for years, and the same discipline transfers without modification. |
| Serialisation and parameters | Structured payloads move through serialisation mechanisms that often lack strict validation or schema enforcement. Every tool invocation should validate its inputs against a well defined schema, expected ranges, and the context the data will be processed in, and parameter forwarding should be blocked when the origin of the data is ambiguous. | The ERP equivalent is the interface validation nobody regrets writing. A tool that accepts a posting amount should say what a legal posting amount is. |
Two of those rows deserve to be pulled out, because they are the ones that map onto accounting outcomes rather than onto security outcomes. The first is idempotency. The guidance notes that the ability to execute an operation more than once without changing the result beyond the first application is not directly enforced by the protocol, and is instead left to the underlying transport. Every finance interface built in the last two decades has a duplicate prevention story, because a retried payment file or a re-processed invoice batch is a well understood incident. A tool that posts a journal needs the same story, written down, before it is switched on.
The second is capability drift. The guidance observes that a change in capability or data access for a server that is already trusted and connected can often be made without approval, that end users are frequently unaware, and that a previously benign service can later reach sensitive resources without triggering a review. In an ERP context that is a change to the effective scope of an approved interface, which is precisely the kind of change a controls environment is built to catch. It just needs to be visible as a change, which means the tool list has to be written down somewhere it can be compared against.
The problem is MCP was built for speed, not security. It flips a familiar pattern: instead of your system requesting
Where the protocol stops, in its own words.
It is worth going to the specification directly rather than relying on the summary, because the specification is more precise than its reputation and the precision cuts both ways. The authorization section opens with the sentence that matters most: authorization is optional for MCP implementations. That is a genuine gap and the NSA is right to lead with it.
What is less widely quoted is how much the specification does require once an implementation chooses to authorize. A server must publish protected resource metadata so a client can discover its authorization server. A server must validate that an access token was issued specifically for it, must reject tokens that do not name it, and must not pass a token it received on to a downstream service. A client must implement resource indicators so a token is bound to the server it was requested for, and must use PKCE with the stronger challenge method where it is capable of it. Clients are told to follow least privilege on scopes, and there is a defined path for a server to ask for more scope at runtime rather than being granted everything up front. Those are real requirements, and an ERP connection that meets them is in decent shape.
The protocol is also moving. Its versioning page records 2026-07-28 as the current revision, with every request declaring the protocol version it is using and a mandatory discovery call that returns a server’s supported versions, capabilities and identity in one request. For a finance team the practical consequence is small but real: the interface has a version, versions change, and the register should record which one this connection speaks. That is the same discipline applied to any message standard, and nobody needs a new process for it.
The honest summary is that the protocol handles transport and discovery, offers a solid optional authorization story, and declines to model your business permissions. It has no concept of a posting, a period, a company code or a segregation of duties conflict, and there is no reason it should. Those live in the ERP, which is fortunate, because the ERP is where a controller can actually see them.
What the ERP vendors did about it, and why the convergence matters.
Two published designs, from vendors with no reason to coordinate, arrive at the same answers. That convergence is the most useful evidence available right now about what good looks like, and it is more actionable than any framework, because both are written as product documentation that an implementation team can be held to.
| Question | Microsoft, for Dynamics 365 finance and operations | SAP, for third party access to SAP solutions | What to take from it |
|---|---|---|---|
| Who the agent is | Microsoft binds the agent to an authenticated user context in the finance and operations app. A dedicated System agent role exists purely for licensing and, by design, carries no permissions, duties or privileges at all, so a real security role has to be assigned deliberately for the agent to do anything. | SAP requires that the server never proxies the caller token to a downstream API. It performs a token exchange for a scoped credential that carries the identity of the calling agent so actions can be attributed to that agent rather than only to the end user, while retaining the user context for data access and audit. | Both answer the protocol gap the same way. The agent gets an identity of its own, held by the enterprise identity system rather than by the protocol. |
| What the agent can reach | The server updates the context it returns on every call from the security role. Menu items, entities and actions outside the role never appear in the view model, and explicit calls to objects outside the role are rejected. The documentation puts it plainly: the agent works with the application like a human with the same security access. | The exchanged credential is scoped to the minimum permissions required by the specific tool being invoked, rather than to everything the user could do. | Least privilege expressed in the vocabulary finance already uses for people. A role you can name in a segregation of duties matrix is a role you can explain to an auditor. |
| Which clients may connect | An allowed MCP clients list gates access by registered application identifier. A small default set is permitted, and any other agent platform has to be registered in the directory and added deliberately. | Every inbound request to the server and every outbound call to a SAP API must be authenticated through the identity service, and long lived credentials are not to be stored in the server. | The interface has a named counterparty on both sides. This is exactly the control a treasury team applies to a bank connection. |
| What is off limits by construction | Administration forms are excluded from the server outright, including security configuration, user role assignment, separation of duties configuration, privileged access control, user and user group maintenance, directory application registration and feature management. | The reference architecture treats the server as stateless and versioned, with tool manifests versioned and breaking schema changes coordinated rather than shipped quietly. | An agent that cannot change its own permissions is a much shorter conversation with internal audit than one that merely has not. |
| What gets written down | Tool calls are metered and attributable, and the finance and operations tools are explicit about which are data operations, which drive a form, and which invoke code. | Log every tool invocation with the caller identity, the parameters with personal data redacted, the target API, and the response status and latency. Propagate trace context into the downstream calls so an end to end trace exists. Alert on error spikes, latency degradation and authentication failures. | This is the audit trail the protocol does not require, specified in enough detail to be built. Most of it is ordinary observability, which means the platform team probably has it already. |
The Microsoft documentation contains one sentence that is worth carrying into any steering committee, because it resolves an argument before it starts. Working through the form tools, it says, the agent works with the application like a human with the same security access would perform the actions. That is a design commitment with a clear consequence. If the agent can do it, a person with that role could have done it, and the controls you already wrote for that role are the controls that apply. It also means the reverse is true and equally useful: a role that is too broad for a person is too broad for an agent, and the agent will exercise the breadth far more thoroughly.
The SAP position on tokens is the other one to keep. Forwarding a user token without transformation grants the server and any consuming agent the full permissions of that user and bypasses audit attribution. The prescribed alternative is a token exchange that produces a credential carrying the identity of the calling agent, retaining the original user context for data access and audit, and scoped to the minimum permissions the specific tool needs. Stated in accounting terms, that is the difference between an audit trail which says a person did this and one which says an agent did this, on behalf of a person, within these permissions. Only the second is true, and only the second survives a question.
One date is worth putting in a plan. Microsoft documents that the earlier static Dynamics 365 ERP MCP server, which carried thirteen fixed tools built on the Dataverse connector framework, retires on 1 October 2026, and directs customers to the newer dynamic server. Anyone who built against the static tool set has a migration to schedule, and the shape of the change is worth understanding rather than treating as a version bump: a fixed set of thirteen business functions is being replaced by a general surface of data, form and action tools. The control question changes with it, from which of these thirteen things may the agent do, to which slice of the application does this role expose.
The register this asks for.
The NSA recommendation is to maintain a clear inventory of all deployed agents and tools, with versioning, patch history and known concerns, so that triage is fast when something is disclosed. That is a security artefact. A finance team needs a slightly different one covering the same ground, because the question an auditor asks is not which version of the server is deployed but who authorised this posting and how would we know if the scope had changed.
The unit is the tool, not the agent. This is the single most important design choice in the whole artefact. An agent is a name and a personality. A tool is an interface with a defined effect, and an agent with twelve tools is twelve interfaces of wildly different consequence sharing one approval. Registering at the agent level averages a read tool and a posting tool into a single risk rating, which is how a read only pilot acquires a write path without anyone deciding it should.
tool_id
The tool as the agent sees it, one row per callable tool rather than one row per agent. An agent with twelve tools is twelve different interfaces with twelve different blast radii, and averaging them hides the only ones that matter.
business_effect
What calling this tool does in accounting terms, in a sentence a controller would recognise. Reads a balance, proposes a journal, posts a journal, releases a payment. This is the field only finance can fill in, and it is the field the whole register turns on.
write_scope
Whether the tool reads, proposes, or commits. A read tool and a commit tool should not be governed identically, and lumping them under one agent approval is how a read only pilot quietly grows a write path.
acts_as
The identity the call runs under, named as it appears in the ERP: the agent principal, the security role assigned to it, and the human whose context is retained. If the honest answer is a shared service account, the register has already earned its keep.
role_and_privileges
The specific ERP security role scoping this tool, with the duties and privileges it carries. The point of naming it here is that it can be diffed. A role that gains a privilege in November should show up as a change to this row.
approval_gate
Whether a human approves before the effect lands, at what threshold, and who. Blank is a legitimate answer for a read tool and a finding for a posting tool.
idempotency_key
How a repeated call is made safe, since the protocol does not enforce this. The reference the tool uses to recognise that it has already done this, and what happens when it sees a duplicate.
input_contract
The schema, ranges and required fields the tool validates before acting. Written down so that the validation is a specification rather than whatever the implementation happened to check.
evidence_written
What lands in the log when this tool runs: caller identity, parameters, target, response, and where the trace can be picked up. This is the row an auditor will actually test, so it should describe something that exists.
owner_and_review
The named person in finance who can defend this tool being callable, and the date the scope was last reviewed. Capability drift is the risk the guidance names, and a review date is the cheapest defence against it.
One row of an agent interface register, for a tool that commits
{
"tool_id": "erp.ap.post_supplier_invoice",
"business_effect": "Posts a supplier invoice to the AP subledger against a matched purchase order and goods receipt, within the tolerance already configured for three way matching.",
"write_scope": "commits",
"acts_as": {
"agent_principal": "agent-ap-clerk@example.com",
"erp_security_role": "AP_Invoice_Clerk_Agent",
"human_context_retained": "the requesting AP analyst",
"shared_account": false
},
"role_and_privileges": {
"duties": ["Maintain vendor invoices"],
"excludes": ["Maintain vendors", "Release payments", "Maintain security roles"],
"last_diffed": "2026-08-12"
},
"approval_gate": {
"required": true,
"threshold": "any invoice outside matching tolerance, or above 25000 in any currency",
"approver_role": "AP_Manager"
},
"idempotency_key": "supplier_invoice_number + vendor_id + company_code",
"duplicate_behaviour": "returns the existing document number and posts nothing",
"input_contract": {
"schema": "ap_invoice_v3",
"required": ["vendor_id", "invoice_number", "invoice_date", "currency", "gross_amount", "po_reference"],
"rejects": ["posting dates in a closed period", "negative gross amount", "currency outside the company code set"]
},
"evidence_written": {
"fields": ["caller_identity", "parameters_redacted", "target_api", "response_status", "latency_ms"],
"trace": "W3C TraceContext propagated into the ERP call",
"sink": "the same log store the existing AP interfaces write to"
},
"owner_and_review": {
"owner": "ap.controller@example.com",
"last_reviewed": "2026-08-19",
"review_cadence": "quarterly"
}
}Three fields carry most of the weight. The acts_as field is the one that ends the longest argument, because it forces a specific answer to whose authority the agent used, and a shared service account cannot hide inside it. The write_scope field is what keeps read tools cheap to approve and commit tools properly examined, which is the only way a review process stays proportionate as the tool count grows. And the idempotency_key field addresses the gap the guidance names directly, in the place where the consequence is a duplicate document rather than an abstraction.
The role_and_privileges field earns its place for a quieter reason. It is the field that can be compared against the live system. A register that lists the duties and privileges behind each tool can be diffed against the ERP’s actual role definitions on a schedule, which turns capability drift from something noticed after an incident into something that appears as a changed row. That comparison is a short script against data both systems already hold, and it is the closest thing here to a genuine control rather than a document.
Model Context Protocol has quietly become the backbone of AI agents running across finance, legal, healthcare, and software development.
Implementation checklist.
List the tools before approving the agent. An agent approval is not a unit of control, because the agent is a name and the tools are the interfaces. Ask for the tool list, and expect it to be longer than the demo suggested. A server that exposes generic create, read, update and delete over data entities has exposed the whole entity surface the role permits, not the two entities that were shown.
Give the agent its own identity and its own security role. Both published vendor designs converge here, and the protocol offers nothing that substitutes for it. A role built for the agent can be scoped to the tasks it actually performs, which is the difference between a segregation of duties matrix that still means something and one that has a wildcard in it.
Refuse the shared service account, politely and early. If the agent runs as a human user, every action it takes is attributed to a person who did not take it, and the audit trail becomes actively misleading rather than merely thin. This is the single change with the best ratio of effort to control value.
Split read tools from commit tools and govern them differently. A read tool wants scope minimisation and a log. A commit tool wants an approval threshold, an idempotency key, and an owner. Approving them as one thing is how a pilot turns into a posting path without a decision being made.
Design for the retry now, not after the first duplicate. The guidance is explicit that the protocol does not enforce idempotency and leaves it to the transport. Every tool that commits needs a key that identifies the work, and a defined behaviour when it sees that key again. Returning the existing document number is usually right and is almost never the default.
Write the audit record deliberately, because nothing else will. Caller identity, parameters with personal data redacted, target, response status and latency, with trace context propagated through to the ERP call. That list comes from a published reference architecture rather than from first principles, so it is a reasonable thing to hand a platform team as a requirement.
Put a change gate on capability, not only on access. The NSA names the drift specifically: a trusted server can gain capability or data access without anyone being asked to approve it. Version the tool manifest, diff it on a schedule, and treat a new tool on an approved server as a change that needs the same review the server got.
Validate the inputs at the tool, in a written schema. Ranges, required fields, closed period rules, currency sets. The tool is now an interface into the ledger, and interfaces into the ledger have always had validation specifications. This one deserves the same.
Keep the ledger tools on a surface of their own. The guidance asks for tools and models to be aligned with data classification zones and prefers a local server instance for private data. Whether the finance tools sit beside the general productivity tools is an architecture decision worth making on purpose rather than inheriting from a default.
Register every server you can reach, including the ones nobody approved. The recommendation to scan for unauthenticated, unauthorised and internet exposed servers exists because these are cheap to stand up and easy to forget. Finding one before an assessment does is comfortably the better order.
Order these by which ones get harder to fix later. Identity is first, because every log line written before the agent has its own principal is a log line attributing work to the wrong actor, and that record cannot be corrected afterwards. Idempotency is second, since it is cheap to design in and expensive to retrofit around documents that already exist. Everything else improves whenever it happens, which makes this a good piece of work to start before the platform decision is settled rather than after.
Constructive failure modes to design around.
Reading the guidance as a reason to wait. The NSA describes the protocol as a promising but still maturing foundation, and says its security posture depends on implementation discipline rather than protocol guarantees. That is a description of where the work sits, not an argument against doing it. Discipline at the ERP layer is something a finance function is genuinely good at.
Approving the agent and never looking at the tool list. The demo shows three tools. The server may expose generic data operations across every entity the role allows. Both statements can be true at once, and only one of them was in the approval.
Assuming the protocol supplies the access control. It does not, and it says so. Authorization is optional in the specification, role permissions are not exchanged at instantiation, and the documentation states directly that these principles cannot be enforced at the protocol level. Every published vendor design solves this outside the protocol, which is the useful signal.
Letting the agent inherit a person. Forwarding a user token without transformation grants the server and any consuming agent the full permissions of that user and bypasses attribution. It is also the fastest path to a demo, which is exactly why it needs to be ruled out before the pilot rather than after it.
Treating a read only pilot as permanently read only. Scope grows by ordinary, well intentioned increments. The register makes the growth visible as a change to a row, which is the only reliable way anyone notices.
Trusting an intermediate output because the component that produced it was approved. Each output is untrusted input to the next stage. A chain where one agent summarises and another acts on the summary needs a check between them, and the NSA notes that protocol aware security proxies are still maturing, so the check is unlikely to arrive as a product this year.
Logging the prompt and calling it evidence. The conversation is not the audit trail. The tool call is: which tool, under which identity, with which parameters, against which target, with what result. That is testable in a way a transcript is not.
Building the register as a document. It is a set of rows that should be diffable against what the ERP actually permits today. A register that cannot be compared against the live role definitions describes an intention rather than a system.
The thread running through all of these is a category error, which is treating the agent as a user of the system rather than as an interface into it. Users get onboarded, trained and periodically reviewed. Interfaces get specified, validated, monitored and version controlled. The second set of habits is the one that fits, and the useful part is that finance functions already have them, applied to file transfers and bank connections that nobody finds novel any more.
What to ask your ERP vendor or integrator now.
What is the complete list of tools this agent can call in our environment, and which of them commit rather than read? Ask for it as data rather than as a slide, because the register is built from it.
What identity does the agent act under, and is it distinct from any human user? If the answer involves a shared account, ask what the plan is to change that and when.
Which security role scopes the agent, and what duties and privileges does that role carry today? A role name on its own is not an answer. The privilege list is the answer.
How is a repeated tool call made safe for anything that posts? Ask for the key and the duplicate behaviour specifically, since the protocol leaves this to the implementation.
What exactly is written to the log on every tool call, and can we trace one call from the prompt through to the document number in the ledger? Ask to see a real trace rather than a description of one.
What happens when a new tool is added to a server we have already approved? If the answer is that it becomes available immediately, that is the capability drift the guidance names, and it needs a gate.
Which clients are permitted to connect to this server, and how is that list maintained? An allowed client list is only a control if somebody owns it.
Can the agent reach anything that changes security configuration, role assignment or separation of duties settings? The published designs exclude these deliberately, so a vendor should be able to answer without checking.
These are answerable questions, and a vendor who has thought about the problem will welcome them, because every one of them narrows the scope of what has to be defended later. Both of the published designs referenced here answer most of the list in their own documentation, which is a fair benchmark to hold a smaller vendor to as well.
Practical takeaway.
The agent connection to your ERP is an interface, and the guidance published this year makes it unusually easy to specify one properly. The NSA has written down where the protocol does not help, which is a gift rather than a warning: authorization is optional, role permissions are not exchanged, idempotency is not enforced, and audit logging is whatever the implementer decided. Microsoft and SAP have written down what to do about each of those, and they agree. Give the agent its own identity. Scope it with a real security role that a person could be given. Gate which clients may connect at all. Make every committing tool idempotent. Log the call, not the conversation. Then write the whole thing down one tool at a time, with a finance owner against each row and a date next to it. That register is a week of work, most of it description rather than build, and it answers the two questions that actually get asked: what can this thing do to the ledger, and how would we know if that changed.
Sources.
- NSA Artificial Intelligence Security Center, Cybersecurity Information Sheet: Model Context Protocol (MCP), Security Design Considerations for AI-Driven Automation. Document U/OO/6030316-26, PP-26-1834, May 2026 version 1.0, seventeen pages, produced with the Carnegie Mellon University Software Engineering Institute. Downloaded and read in full rather than summarised, and the source of every NSA point quoted here
- Model Context Protocol specification, Authorization, revision 2025-11-25. The source of the statement that authorization is optional for MCP implementations, and of the resource indicator, audience validation and token passthrough requirements that apply when it is implemented
- Model Context Protocol specification, Versioning. Records 2026-07-28 as the current protocol revision, the per request protocol version declaration, and the mandatory server discovery call
- Microsoft Learn: Use Model Context Protocol for finance and operations apps. The source of the Dynamics 365 ERP MCP server tool categories, the allowed MCP clients gate, the security role scoped view model, the System agent role, the excluded administration forms, and the 1 October 2026 retirement of the earlier static server
- SAP Architecture Center reference architecture: Third-Party MCP Access to SAP Solutions. The source of the token exchange requirement, the agent identity in the exchanged credential, the per tool minimum permission scoping, and the tool invocation logging and tracing guidance
- Model Context Protocol specification, Security Best Practices, revision 2025-11-25. The token passthrough and confused deputy sections the authorization specification points at
- RFC 8707, Resource Indicators for OAuth 2.0. The mechanism the specification requires clients to use so that a token issued for one server cannot be presented at another
- RFC 9728, OAuth 2.0 Protected Resource Metadata. The discovery mechanism an MCP server must implement to tell a client where its authorization server lives
The NSA information sheet is a public PDF and was downloaded and read page by page rather than fetched through a summariser, which matters on a document where the specific wording of each concern is the whole point. Its identifiers, its May 2026 version 1.0 date, its length of seventeen pages including works cited, and its acknowledgement of the Carnegie Mellon University Software Engineering Institute were all read from the file itself. The protocol statements were taken from the specification pages rather than from commentary about them, and the current revision identifier of 2026-07-28 was read from the versioning page. The Microsoft and SAP positions were read from the vendors’ own documentation. The three posts on X quoted above were each verified as public, current and on topic before being cited, with the author, handle and date confirmed against the live post; nothing has been invented and no post has been paraphrased into something it did not say. The register record shown above is a worked example of the shape being described and is not an extract from any customer system, and the supplier invoice tool in it is an example rather than a recommendation about which tools to expose. Vendor pricing and licensing details are mentioned only where they affect how a connection is designed, and are current as of the documentation dates linked above.