Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Skaerp (Edison): udvid scope forbi MCP, ny anti-pattern for aldrig-begraenset

Browse source
This commit is contained in:
Michael Dieringer 2026-08-13 21:51:58 +02:00
parent 2de05cc65a
commit 87bd8f518c
1 changed files with 79 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

37
custom/knowledge/mcp/api-page-least-privilege-write-access.md
View file

@ -1,7 +1,7 @@
---
bc-version: [all]
domain: mcp
keywords: [api-page, least-privilege, write-access, odata, security]
keywords: [api-page, least-privilege, write-access, odata, security, external-api, identity-fields]
technologies: [al]
countries: [w1]
application-area: [all]
@ -12,12 +12,45 @@ application-area: [all]
A general-purpose API page that exposes many fields should not be widened to allow writes on a single additional field. Instead, create a dedicated minimal API page that exposes only the fields the consumer needs to read and write. This limits the blast radius of any agent or integration mistake.
This applies beyond CURABIS's own MCP tooling — it's a general AL API-page design concern. Any `PageType = API` page consumed by an external integration, a Power BI dataset, or a partner system carries the same risk: a write-enabled page with no per-field restriction is a wide-open surface regardless of who or what is calling it.
## Why This Matters
An MCP agent operates with the permissions of its service identity, not an individual user. A page that allows writing to many fields gives the agent broad power that is hard to audit and easy to misuse. A dedicated page with one writable field makes the intent explicit and the surface area auditable.
An MCP agent operates with the permissions of its service identity, not an individual user — but the same argument holds for any external consumer of an API page. A page that allows writing to many fields gives the caller broad power that is hard to audit and easy to misuse, whether the caller is CURABIS's own agent, a customer's integration, or a Power Platform flow. A dedicated page with one writable field (or explicit `Editable = false` on everything else) makes the intent explicit and the surface area auditable.
## Pattern to Avoid
The most common real-world shape of this violation isn't a page that started narrow and got widened — it's a page that was **never restricted at all**. A `PageType = API` page with `InsertAllowed`/`ModifyAllowed`/`DeleteAllowed` left at their defaults, and no `Editable = false` on any field, exposes every field on the source table — including identity fields (`No.`, `Document Type`) and financially significant ones (`VAT Bus. Posting Group`, `Amount Including VAT`) — as fully writable, with nothing marking that as deliberate:
// WRONG: no restriction declared anywhere on a write-capable API page —
// ~90 fields, including VAT/posting fields and the record's own key,
// are all fully writable by default, with nothing marking that as intentional.
page 50100 "Some Document Header API"
{
PageType = API;
APIPublisher = 'contoso';
APIGroup = 'docs';
APIVersion = 'v1.0';
SourceTable = "Some Document Header";
// no InsertAllowed/ModifyAllowed/DeleteAllowed override, no Editable = false anywhere
layout
{
area(content)
{
repeater(GroupName)
{
field(no; Rec."No.") { }
field(documentType; Rec."Document Type") { }
field(amountIncludingVAT; Rec."Amount Including VAT") { }
field(vatBusPostingGroup; Rec."VAT Bus. Posting Group") { }
// ... ~85 more fields, none marked Editable = false
}
}
}
}
The narrower "widened by one field" shape below is also real, just less common in practice than the above:
// WRONG: General page widened with write access to one field
// Now the agent can accidentally (or intentionally) write to all other fields too
field(status; Rec.Status) { } // should be read-only