---
title: "How does someone confirm a delivery without a Dynamics 365 licence?"
canonical_url: "https://cognilium.ai/blogs/confirm-a-delivery-without-a-dynamics-365-licence"
slug: "confirm-a-delivery-without-a-dynamics-365-licence"
section: "blogs"
date_published: "2026-10-21"
date_modified: "2026-10-21"
word_count: 1187
reading_time_minutes: 5
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related: []
---
# How does someone confirm a delivery without a Dynamics 365 licence?

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.

## Key takeaways

- There is no anonymous or shared-service path into finance and operations through the MCP server. Microsoft states it directly, so a borrowed identity is not an option.
- Two identity patterns exist — delegated, running as the chatting user, and autonomous, holding its own identity. Only the second works when the person who knows is not an ERP user.
- Neither pattern elevates privilege. The authenticated user can never do more through the server than in the application.
- Separate the confirmation from the posting. A person answers a question in their own tool; a recognised identity writes the record.
- An adaptive card can block the process until someone answers, which is an approval gate without an ERP login.
- The ERP records the posting, not the conversation. The audit trail for the question itself is yours to build.

**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.**

**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](/erp-ai).

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](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/mcp/mcp-security) · **fetched and read in full 2026-10-21**
- [Use MCP for finance and operations apps](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp) · **fetched and read in full 2026-10-21**
- [Overview of adaptive cards for Teams — Power Automate](https://learn.microsoft.com/en-us/power-automate/overview-adaptive-cards) · **fetched and read in full 2026-10-21**

## Fact-check

**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.

## Frequently asked questions

### Can an agent just act on their behalf?

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."

### What identities are actually available?

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."

### So who confirms, and who posts?

They are two different actors, and keeping them separate is the whole design.

### What carries the question?

An adaptive card is the usual answer, and it has one property that matters more than its looks.

### What does the ERP end up seeing?

And nothing is skipped on the way in: "Business logic, validations, and workflows aren't bypassed."

---

Canonical HTML: https://cognilium.ai/blogs/confirm-a-delivery-without-a-dynamics-365-licence