mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
dd5637b1db
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne): - R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6 kraevede noegler; keywords haandskrevet pr. fil da de driver worklist-selektionen i INDEX/knowledge-index - R09: manglende Description-sektion - regel-agtige foersteoverskrifter (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat efter titlen hvor intro-tekst fandtes - R10: fenced code blocks konverteret til 4-space indrykkede blokke i alle filer (indhold uaendret) - R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk tab (ai-eval-scores 143->100, git-lifecycle 121->97, permission-sets 113->99, test-feature-scenario-tags 105->91) - R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet til maks 10 Ingen regler er fjernet eller aendret i betydning - kun form. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
46 lines
2.2 KiB
Markdown
46 lines
2.2 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: mcp
|
|
keywords: [api-page, least-privilege, write-access, odata, security]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
# CURABIS MCP: API Pages Must Use Least-Privilege Write Access
|
|
|
|
## Description
|
|
|
|
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.
|
|
|
|
## 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.
|
|
|
|
## Pattern to Avoid
|
|
|
|
// 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
|
|
field(gitHubRepository; Rec."GitHub Repository") { } // the one field we want writable
|
|
field(estimatedHours; Rec."Estimated Hours") { } // should be read-only
|
|
|
|
## Correct Pattern
|
|
|
|
Create a separate, minimal API page:
|
|
|
|
page 6102904 "CUR MCP Project Repository"
|
|
{
|
|
// Only two fields: the key and the one writable field
|
|
field(no; Rec."No.") { Editable = false; }
|
|
field(gitHubRepository; Rec."GitHub Repository") { }
|
|
}
|
|
|
|
## Requirements
|
|
|
|
- Each distinct write concern (e.g., setting a GitHub repo, updating a dev status) should have its own API page or be deliberately grouped only with closely related fields
|
|
- Read-only fields on write-enabled pages must carry `Editable = false`
|
|
- The page description must document which fields are writable and why
|
|
|
|
## Verification
|
|
|
|
For each API page where `ModifyAllowed = true` (or default), list all fields without `Editable = false`. Confirm that every writable field is intentionally writable for the same consumer use case. If unrelated fields are writable on the same page, split the page.
|