TL;DR
Not by borrowing one. Microsoft gives the ERP MCP server no anonymous path, so the confirmation has to be mediated and a known identity does the posting.
Not by borrowing one. Microsoft states that the ERP MCP server offers no anonymous or shared-service path, so a plant supervisor with no ERP account cannot be slipped in behind an agent. The confirmation has to be mediated: a person is asked in a channel they already use, and a recognised identity does the posting.
Can an agent just act on their behalf?
No, and Microsoft closes the door in one sentence:
"Every MCP request requires an authenticated user. The MCP server doesn't provide an anonymous or shared-service path for accessing finance and operations data."
There is no service account loophole either, because the server grants nothing of its own: "It doesn't create a separate security boundary or grant permissions independently from the application."
So the question "how do we give the warehouse team agent access" has no good answer, and that is by design rather than by omission. The right question is different: how does their knowledge reach the ERP without their identity having to?
What identities are actually available?
Two patterns, and Microsoft names both.
| Pattern | Microsoft's description | Whose identity acts |
|---|---|---|
| Chat / delegated agent | "set the agent configuration to run on behalf of the user who is chatting with the agent" | the chatting user's |
| Autonomous agent | "no human user chats with the agent at the time of the request. The autonomous agent has its own identity, and that identity is the authenticated user making the request" | the agent's own |
Microsoft is explicit that permissions follow whichever it is: "In both cases, permissions are applied based on the identity that's used for user authentication."
And neither grows. "The MCP server doesn't elevate privilege", and "The authenticated user can never do more through the MCP server than they're able to do through the finance and operations application."
### The practical reading An autonomous agent is the only pattern that works when the person who knows is not an ERP user — because the delegated pattern needs a chatting user who already has access. The agent holds its own identity, with exactly the roles the job needs, and nothing more.
So who confirms, and who posts?
They are two different actors, and keeping them separate is the whole design.
The person who knows confirms. They answer a question — did these twelve pallets arrive on the fourth? — in a tool they already open. They need no ERP account to answer a question.
A recognised identity posts. The agent, running under its own identity with the minimum roles, writes the product receipt once the answer is yes.
What travels between them is a decision, not a credential. The confirmation is evidence; the posting is an action; and the ERP only ever sees the action, performed by an identity it knows.
This is not a workaround. It is the same shape as a paper goods-received note signed at the gate and keyed in by someone in the office — except the note is a message and the keying-in is the agent.
What carries the question?
An adaptive card is the usual answer, and it has one property that matters more than its looks.
Microsoft's own description of posting one to a person: "This action posts an adaptive card as a flow bot to a specific user… Then, the card shows up in that recipient's chat and activity feeds during the flow run."
And the behaviour that makes it a confirmation rather than a notification:
"the flow run doesn't continue after the post until the recipient responds to inputs that are required within the card. The flow continues after the recipient responds."
That is a blocking wait, in a chat window. The process pauses until a human answers — which is exactly what an approval gate is, implemented without anybody opening the ERP.
⚠️ One documented restriction: "Adaptive cards aren't available within the DoD (Department of Defense) environment." Check your tenant's cloud before designing around them.
What does the ERP end up seeing?
A normal posting, attributable to an identity.
"An action that an agent takes through the MCP server is therefore attributable to the user who initiated the request, similar to an action that the same user takes in the finance and operations client."
And nothing is skipped on the way in: "Business logic, validations, and workflows aren't bypassed."
Which means your auditors see something they recognise. The receipt was posted by a named identity, the validations ran, the workflow ran. The confirmation that justified it lives in the chat thread and in whatever log you chose to keep — and that second part is yours to design, because the ERP has no opinion about it.
What this costs you in design
Three things, stated plainly.
An identity to govern. An autonomous agent is a thing in your directory with roles attached. Somebody owns it, reviews it, and removes it when the process ends.
A channel decision. The confirmation has to reach a person who will actually answer. That is a behavioural question, not a technical one, and getting it wrong produces a queue nobody clears.
A log you build. The ERP records the posting. It does not record the question you asked, who answered, or how long they took. If you need that trail — and for anything financial you probably do — it is your responsibility, not the platform's.
### Where we are with this, honestly We have built two agents on this ground and they run on test data. The Teams confirmation card and the Outlook notice are designed and in build, not shipped. No published results exist for this pattern, ours or anyone's. A read-only look at your own open lines is the honest first step.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
If the person who knows what arrived has no ERP account, that constraint shapes the whole design. Bring the process and the people to a 15-minute call.
Sources
- Security for Dynamics 365 ERP MCP · fetched and read in full 2026-10-21
- Use MCP for finance and operations apps · fetched and read in full 2026-10-21
- Overview of adaptive cards for Teams — Power Automate · fetched and read in full 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "Every MCP request requires an authenticated user. The MCP server doesn't provide an anonymous or shared-service path for accessing finance and operations data" | T1 — verbatim | mcp-security | PASS — the cluster's spine |
| 2 | 1 | "It doesn't create a separate security boundary or grant permissions independently from the application" | T1 — verbatim | Same page | PASS |
| 3 | 2 | Both patterns quoted — delegated "on behalf of the user who is chatting with the agent"; autonomous "has its own identity, and that identity is the authenticated user making the request" | T1 — verbatim ×2 | Same page | PASS |
| 4 | 2 | "In both cases, permissions are applied based on the identity that's used for user authentication" | T1 — verbatim | Same page | PASS |
| 5 | 2 | "The MCP server doesn't elevate privilege"; "The authenticated user can never do more through the MCP server than they're able to do through the finance and operations application" | T1 — verbatim ×2 | Same page | PASS |
| 6 | 2 | Only the autonomous pattern works for a non-ERP user | T2 — ours, deduced from claim 3: the delegated pattern requires a chatting user with access | — | PASS |
| 7 | 3 | Separate the confirmation from the posting; what travels is a decision, not a credential | T2 — ours, the design argument, stated as ours | — | PASS |
| 8 | 4 | "This action posts an adaptive card as a flow bot to a specific user… the card shows up in that recipient's chat and activity feed" | T1 — verbatim | overview-adaptive-cards | PASS |
| 9 | 4 | "the flow run doesn't continue after the post until the recipient responds to inputs that are required within the card. The flow continues after the recipient responds" | T1 — verbatim | Same page | PASS — this is what makes it a gate |
| 10 | 4 | "Adaptive cards aren't available within the DoD (Department of Defense) environment" | T1 — verbatim, a documented restriction, reported not inferred | Same page | PASS |
| 11 | 5 | "attributable to the user who initiated the request, similar to an action that the same user takes in the finance and operations client" | T1 — verbatim | mcp-security | PASS |
| 12 | 5 | "Business logic, validations, and workflows aren't bypassed" | T1 — verbatim | Same page | PASS |
| 13 | 5 | The ERP records the posting, not the question. The trail for the conversation is yours to build | T2 — ours, and BOUNDED: it is a statement about what the MCP security page documents, not a claim that no Dynamics 365 feature anywhere logs an approval. F&O workflow history exists and is a different mechanism | — | PASS — see note |
| 14 | 6 | The three design costs — an identity to govern, a channel decision, a log you build | T2 — ours, method | — | PASS |
| 15 | 6 | Our two agents run on test data; the Teams card and Outlook notice are designed and in build, not shipped | T2 — a REQUIRED disclosure, per the source document's own guardrail table | — | PASS |
Tier summary: 10 × T1 (all verbatim), 5 × T2 — 0 × T4.
### ⚠️ Claim 13 is the one a hostile reader attacks, so it is bounded twice "The ERP records the posting, not the conversation" could be read as Dynamics 365 has no approval audit trail, which would be false — F&O workflow history records approvals, and a workflow triggered by the posting would be recorded normally. The claim is narrower: the MCP security page documents attribution of the action, and says nothing about retaining the out-of-band question that preceded it. The body says "the ERP has no opinion about it" in the context of the chat thread, and §6 frames the log as a design responsibility rather than a platform gap.
### 🔴 Guardrails this article was written against | Rule from the source document | Compliance | |---|---| | Never "least-privilege" or "locked down to a role" | The article says "the minimum roles the job needs" and quotes Microsoft's own "doesn't elevate privilege". The banned phrasing does not appear | | Never "Teams and Outlook are live" | §6 states "designed and in build, not shipped" | | Never "zero middleware" | Not used. The article names Power Automate's flow behaviour explicitly | | Never "autonomous" unqualified | Used only in Microsoft's precise sense — an autonomous agent has its own identity — and always alongside the approval gate | | Never a customer name, saving or percentage | None. §6 states that no published results exist |
🔴 No pricing. No rate, licence cost, credit figure or currency anywhere. The word "licence" appears in the title as an access question, not a commercial one.
No unbounded absence claimed. "No anonymous or shared-service path" is Microsoft's own sentence. The DoD restriction is Microsoft's own. The one inference of ours — that only the autonomous pattern suits a non-ERP user — is deduced from a quoted definition and labelled T2.
No figures of ours. No volume, no accuracy, no time saved, no customer.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
