ScopeNeatExample Corp, EU region
Menu
Language
Theme

Demo data. Example Corp is fictitious, and nothing you do here is saved.

View as Sofia R.

You are viewing as Sofia R., Resource owner, CRM API. Decides what her API allows. Approves, can't implement.

Example Corp assistant

Start a review

MCP server with 6 tools and 11 API operations. No approved baseline yet.

7
Critical
26
Warnings
13
Notes
17
Scopes

45 of 46 findings

Critical7

FindingWho acts
factures:créerNot a valid scope valueScopeNeat recommendation: Rename the scope with letters, digits and separators such as colon, dot, underscore or hyphen.Next step: The steward picks a valid name, the resource owner confirms it means the same, and IAM engineering creates it before the old one is retired.Sources: RFC 6749 §3.3. Defined by the standard
Accountable, Responsible: Scope stewardConsulted: Resource ownerInformed: IAM engineering
deleteUserA read scope is enough to change dataScopes concerned: user:readScopeNeat recommendation: Require a scope whose action matches the operation, such as a write or delete scope on the same resource.Next step: The resource owner approves the scope this operation should require, and the developer changes the API before release.Sources: RFC 9700 §2.3. Recommended by the standard (SHOULD)
References (3)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.3 Supports evidence

    Information access restriction

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: DeveloperConsulted: Scope steward, SecurityInformed: IAM engineering
lookup_customerA read-only tool holds a scope that can change dataScopes concerned: crm:writeScopeNeat recommendation: Give the tool only read scopes. If it really needs to write, correct its readOnlyHint annotation.Next step: The MCP server owner decides whether the tool really writes, the developer corrects the scopes or the annotation, and the resource owner is consulted on the new mapping.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 4, MCP schema ToolAnnotations, readOnlyHint. Published security guidance
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Resource owner, SecurityInformed: Scope steward
export_monthly_reportA read-only tool holds a scope that can change dataScopes concerned: files:*ScopeNeat recommendation: Give the tool only read scopes. If it really needs to write, correct its readOnlyHint annotation.Next step: The MCP server owner decides whether the tool really writes, the developer corrects the scopes or the annotation, and the resource owner is consulted on the new mapping.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 4, MCP schema ToolAnnotations, readOnlyHint. Published security guidance
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Resource owner, SecurityInformed: Scope steward
export_monthly_reportThe tool relies on a scope that grants everythingScopes concerned: files:*ScopeNeat recommendation: Map the tool to the narrow scopes its calls need, and request the others only when a riskier action is attempted.Next step: The developer maps the tool to the narrow scopes its calls need, and the resource owner approves the new mapping with security consulted.Sources: MCP Security Best Practices Scope Minimization. Published security guidance
References (4)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.15 Supports evidence

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: DeveloperConsulted: MCP server owner, SecurityInformed: Scope steward
cleanup_stale_recordsThe tool relies on a scope that grants everythingScopes concerned: adminScopeNeat recommendation: Map the tool to the narrow scopes its calls need, and request the others only when a riskier action is attempted.Next step: The developer maps the tool to the narrow scopes its calls need, and the resource owner approves the new mapping with security consulted.Sources: MCP Security Best Practices Scope Minimization. Published security guidance
References (4)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.15 Supports evidence

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: DeveloperConsulted: MCP server owner, SecurityInformed: Scope steward
getMonthlyReportThe API accepts tokens from the password flowScopeNeat recommendation: Remove the password flow from the scheme. Clients move to the authorization code flow, or to client credentials when no user is involved.Next step: IAM engineering turns the password flow off at the identity provider, client owners move to the authorization code flow, and the developer removes it from the description.Sources: RFC 9700 §2.4. Defined by the standard
References (3)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(d) Supports evidence

    implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(f)(ii) Supports evidence

    the use of strong authentication methods in accordance with leading practices and techniques for remote access to the financial entity’s network, for privileged access, for access to ICT assets supporting critical or important functions or ICT assets that are publicly accessible

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.5 Supports evidence

    Secure authentication

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable, Responsible: IAM engineeringResponsible: DeveloperConsulted: Security, Client software ownerInformed: Resource owner

Warnings26

FindingWho acts
User.Read, user.readTwo scopes that differ only by caseScopeNeat recommendation: Keep one spelling, move its users to it, then delete the other.Next step: The steward keeps one spelling, client owners move to it, and IAM engineering deletes the other after the migration window.Sources: RFC 6749 §3.3. Defined by the standard
Accountable, Responsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Resource owner
adminA scope that grants everythingScopeNeat recommendation: Split it into scopes that each name a resource and an action, and give clients and tools only those they need.Next step: The steward proposes narrower scopes, the resource owner approves them with security consulted, and clients and tools move to them.Sources: MCP Security Best Practices Scope Minimization, RFC 9700 §2.3. Published security guidance
References (4)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.15 Supports evidence

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardConsulted: MCP server owner, Client software owner, SecurityInformed: IAM engineering
files:*A scope that grants everythingScopeNeat recommendation: Split it into scopes that each name a resource and an action, and give clients and tools only those they need.Next step: The steward proposes narrower scopes, the resource owner approves them with security consulted, and clients and tools move to them.Sources: MCP Security Best Practices Scope Minimization, RFC 9700 §2.3. Published security guidance
References (4)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.2 Supports evidence

    Privileged access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.15 Supports evidence

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardConsulted: MCP server owner, Client software owner, SecurityInformed: IAM engineering
refund:under_500An action without a resourceScopeNeat recommendation: Name the resource in the scope, one scope per resource that needs this action.Next step: The steward names the resource in the scope, and the resource owner approves the new name.Sources: RFC 9700 §2.3. Recommended by the standard (SHOULD)
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Related

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.5.15 Related

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardConsulted: DeveloperInformed: IAM engineering
api:writeAn action without a resourceScopeNeat recommendation: Name the resource in the scope, one scope per resource that needs this action.Next step: The steward names the resource in the scope, and the resource owner approves the new name.Sources: RFC 9700 §2.3. Recommended by the standard (SHOULD)
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Related

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.5.15 Related

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardConsulted: DeveloperInformed: IAM engineering
refund:under_500A value written into the scope nameScopeNeat recommendation: Keep the scope for the resource and the action, and carry the value in the request with Rich Authorization Requests (authorization_details) or in an access policy.Next step: The resource owner decides where the value belongs, in the request or in an access policy, and the steward removes it from the name.Sources: RFC 9396 §1. Published security guidance
Accountable: Resource ownerResponsible: Scope stewardResponsible: DeveloperConsulted: SecurityInformed: IAM engineering
deals:emeaA value written into the scope nameScopeNeat recommendation: Keep the scope for the resource and the action, and carry the value in the request with Rich Authorization Requests (authorization_details) or in an access policy.Next step: The resource owner decides where the value belongs, in the request or in an access policy, and the steward removes it from the name.Sources: RFC 9396 §1. Published security guidance
Accountable: Resource ownerResponsible: Scope stewardResponsible: DeveloperConsulted: SecurityInformed: IAM engineering
read_users, user:read, getUsers, User.Read, user.readSeveral names for the same permissionScopeNeat recommendation: Choose one name, written in the convention most used here, list its owner, and retire the others.Next step: The steward proposes a merge, the resource owner approves it, and IAM engineering implements it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.9 Related

    Inventory of information and other associated assets

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: MCP server owner
createRefundRequires a scope the API does not declareScopes concerned: refund:under_500ScopeNeat recommendation: Declare the scope in the security scheme with a short description, or fix its spelling in the operation.Next step: The developer declares the scope or fixes its spelling, and the steward checks it against the dictionary.Sources: OpenAPI 3.1.1 OAuth Flow Object, OpenAPI 3.1.1 Security Requirement Object. Defined by the standard
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.15 Related

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Scope stewardResponsible: DeveloperConsulted: Resource owner
approveRefundRequires a scope the API does not declareScopes concerned: refund:under_500ScopeNeat recommendation: Declare the scope in the security scheme with a short description, or fix its spelling in the operation.Next step: The developer declares the scope or fixes its spelling, and the steward checks it against the dictionary.Sources: OpenAPI 3.1.1 OAuth Flow Object, OpenAPI 3.1.1 Security Requirement Object. Defined by the standard
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.15 Related

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Scope stewardResponsible: DeveloperConsulted: Resource owner
refund_angry_customerToo many scopes for one toolScopes concerned: user:read, crm:write, refund:under_500, payments:transfer, billing:invoices:readScopeNeat recommendation: Ask first for the read scopes, and the others only when the tool attempts the action that needs them (step-up). Check whether some scopes are near-duplicates.Next step: The MCP server owner decides which scopes are asked first and which only at step-up, and the developer changes the mapping.Sources: MCP Security Best Practices Scope Minimization, MCP Security Best Practices Scope Minimization. Published security guidance
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Related

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Scope stewardInformed: Resource owner
cleanup_stale_recordsThe tool uses a scope missing from the inventoryScopes concerned: records:deleteScopeNeat recommendation: Add the scope to the inventory with its owner, or fix its name in the mapping.Next step: The steward adds the scope to the dictionary with its owner, or the developer fixes its name in the mapping.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.9 Related

    Inventory of information and other associated assets

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Scope stewardResponsible: DeveloperConsulted: Resource owner
summarize_ticketNo scope mapped to this toolScopeNeat recommendation: List the scopes this tool's calls require in the mapping.Next step: The developer lists the scopes the tool's calls require, and the MCP server owner confirms the mapping.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 4. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(d) Related

    a provision on restrictions of access to ICT assets, setting out controls and tools to prevent unauthorised access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.5.15 Related

    Access control

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Scope stewardInformed: Resource owner
refund_angry_customerHigh-impact tool, plan a human approvalScopeNeat recommendation: Ask a human to approve each call, with the details of the action, before it runs.Next step: The resource owner approves the tool and its human approval mode, with security consulted because the tool changes state.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 6, MCP Tools Security Considerations. Published security guidance
Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: IAM engineering
export_monthly_reportHigh-impact tool, plan a human approvalScopeNeat recommendation: Ask a human to approve each call, with the details of the action, before it runs.Next step: The resource owner approves the tool and its human approval mode, with security consulted because the tool changes state.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 6, MCP Tools Security Considerations. Published security guidance
Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: IAM engineering
cleanup_stale_recordsHigh-impact tool, plan a human approvalScopeNeat recommendation: Ask a human to approve each call, with the details of the action, before it runs.Next step: The resource owner approves the tool and its human approval mode, with security consulted because the tool changes state.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 6, MCP Tools Security Considerations. Published security guidance
Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: IAM engineering
process_refundHigh-impact tool, plan a human approvalScopeNeat recommendation: Ask a human to approve each call, with the details of the action, before it runs.Next step: The resource owner approves the tool and its human approval mode, with security consulted because the tool changes state.Sources: OWASP Top 10 for LLM 2026 LLM03:2026, mitigation 6, MCP Tools Security Considerations. Published security guidance
Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: IAM engineering
export_monthly_reportReading sensitive data is not low riskScopeNeat recommendation: Narrow its scopes to the data the task needs, show the user what it will read, and log each call.Next step: The resource owner decides what the tool may read, with the DPO consulted when personal data is reached.Sources: MCP Tools Security Considerations. Published security guidance
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • GDPR Art. 25(2) Supports evidence

    The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.

    Applies as: legal requirement. Applies whenever personal data is processed, so only to scopes that reach personal data.

  • ISO/IEC 27001 A.8.3 Supports evidence

    Information access restriction

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: MCP server ownerConsulted: DPO, Security
lookup_customerThe tool holds a scope none of its calls needsScopes concerned: crm:writeScopeNeat recommendation: Remove the scope from the tool's mapping, or add to its calls the operation that really needs it.Next step: The developer removes the scope from the tool's mapping, and the resource owner approves the narrower mapping.Sources: RFC 9700 §2.3. Recommended by the standard (SHOULD)
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: DeveloperConsulted: MCP server owner, Scope stewardInformed: IAM engineering
summarize_ticketThe tool calls an operation the API description doesn't listOperations: GET /tickets/{id}ScopeNeat recommendation: Add the operation to the API description with its security requirement, or fix its name in the tool's calls.Next step: The developer documents the operation or fixes the call, and the MCP server owner confirms the tool's calls.Sources: OpenAPI 3.1.1 Security Requirement Object. YogaSec practice
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.9 Related

    Inventory of information and other associated assets

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Resource ownerInformed: Scope steward
crm:writeThe server advertises a powerful scope by defaultScopeNeat recommendation: Keep only the scopes needed for basic use in scopes_supported, and have the server ask for the others with a scope challenge when a tool first needs them (step-up).Next step: The MCP server owner keeps only the scopes needed for basic use in scopes_supported, and the developer has the server ask for the others by step-up when a tool first needs them.Sources: MCP Authorization Scope Selection Strategy, MCP Authorization Scope Selection Strategy, RFC 9728 §7.2. Recommended by the standard (SHOULD)
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Resource owner, SecurityInformed: Scope steward
payments:transferThe server advertises a powerful scope by defaultScopeNeat recommendation: Keep only the scopes needed for basic use in scopes_supported, and have the server ask for the others with a scope challenge when a tool first needs them (step-up).Next step: The MCP server owner keeps only the scopes needed for basic use in scopes_supported, and the developer has the server ask for the others by step-up when a tool first needs them.Sources: MCP Authorization Scope Selection Strategy, MCP Authorization Scope Selection Strategy, RFC 9728 §7.2. Recommended by the standard (SHOULD)
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(a) Supports evidence

    the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: MCP server ownerResponsible: DeveloperConsulted: Resource owner, SecurityInformed: Scope steward
getMonthlyReportThe API accepts tokens from the implicit flowScopeNeat recommendation: Remove the implicit flow from the scheme. Browser apps move to the authorization code flow with PKCE.Next step: IAM engineering turns the implicit flow off at the identity provider, client owners move to the authorization code flow with PKCE, and the developer removes it from the description.Sources: RFC 9700 §2.1.2. Recommended by the standard (SHOULD)
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.8.5 Related

    Secure authentication

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable, Responsible: IAM engineeringResponsible: DeveloperConsulted: Security, Client software ownerInformed: Resource owner
purgeCacheAnyone may change data through this operationScopeNeat recommendation: Add the security requirement and the scope this operation needs. If it must stay public, say why in the review.Next step: The developer adds the security requirement, the steward proposes its scope, and the resource owner approves it. Security is consulted if the operation must stay public.Sources: OpenAPI 3.1.1 §4.8.10. YogaSec practice
References (3)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Supports evidence

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(d) Supports evidence

    a provision on restrictions of access to ICT assets, setting out controls and tools to prevent unauthorised access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.3 Supports evidence

    Information access restriction

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: DeveloperResponsible: Scope stewardConsulted: SecurityInformed: IAM engineering
reportsThe scope has no real descriptionScopeNeat recommendation: Write one plain sentence saying what the scope allows, and on which data.Next step: The steward writes what the scope allows, and the resource owner confirms it before approving the scope.Sources: OpenAPI 3.1.1 §4.8.29.1. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.9 Related

    Inventory of information and other associated assets

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: Scope stewardInformed: Internal audit
process_refundThe tool can both start an action and approve itOperations: createRefund, approveRefundScopeNeat recommendation: Split the tool in two, and leave approving to another client or to a person. Or give approving the human approval mode.Next step: The MCP server owner splits the tool, security is consulted on who approves, and the resource owner approves the new mapping.Sources: NIST SP 800-53 AC-5. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • RTS 2024/1774 Art. 21(b) Supports evidence

    the segregation of duties designed to prevent unjustified access to critical data or to prevent the allocation of combinations of access rights that may be used to circumvent controls

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.5.3 Supports evidence

    Segregation of duties

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: Internal audit

Notes12

FindingWho acts
reportsNo action in the nameScopeNeat recommendation: Add the action to the name, or split the scope into one per action.Next step: The steward adds the action to the name, or splits the scope, and the resource owner confirms the meaning.Sources: RFC 9700 §2.3. YogaSec practice
References (1)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable, Responsible: Scope stewardConsulted: Resource owner
read_usersNot written like the other scopesScopeNeat recommendation: Rename it in the dominant convention when its users can follow, or record the exception in the dictionary.Next step: The steward renames it in the dominant convention, or records the exception in the dictionary.Sources: RFC 6749 §3.3. YogaSec practice
Accountable, Responsible: Scope stewardConsulted: Client software ownerInformed: Resource owner
getUsersNot written like the other scopesScopeNeat recommendation: Rename it in the dominant convention when its users can follow, or record the exception in the dictionary.Next step: The steward renames it in the dominant convention, or records the exception in the dictionary.Sources: RFC 6749 §3.3. YogaSec practice
Accountable, Responsible: Scope stewardConsulted: Client software ownerInformed: Resource owner
User.ReadNot written like the other scopesScopeNeat recommendation: Rename it in the dominant convention when its users can follow, or record the exception in the dictionary.Next step: The steward renames it in the dominant convention, or records the exception in the dictionary.Sources: RFC 6749 §3.3. YogaSec practice
Accountable, Responsible: Scope stewardConsulted: Client software ownerInformed: Resource owner
user.readNot written like the other scopesScopeNeat recommendation: Rename it in the dominant convention when its users can follow, or record the exception in the dictionary.Next step: The steward renames it in the dominant convention, or records the exception in the dictionary.Sources: RFC 6749 §3.3. YogaSec practice
Accountable, Responsible: Scope stewardConsulted: Client software ownerInformed: Resource owner
read_usersDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
getUsersDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
User.ReadDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
user.readDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
api:writeDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
factures:créerDeclared but used by nothing hereScopeNeat recommendation: Find who still requests it. If nobody does, remove it from the authorization server and from the API description.Next step: The resource owner confirms retirement, and IAM engineering removes it after checking that no client still requests it.Sources: RFC 6749 §3.3. YogaSec practice
References (2)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • ISO/IEC 27001 A.5.18 Related

    Access rights

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

  • RTS 2024/1774 Art. 21(e)(iii) Related

    withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

Accountable: Resource ownerResponsible: Scope stewardResponsible: IAM engineeringConsulted: Client software ownerInformed: Internal audit
healthNo scope requiredScopeNeat recommendation: If it is not meant to be public, require the scope that matches its resource and action.Next step: The resource owner confirms whether the operation is meant to be public. If not, the developer requires the matching scope.Sources: OpenAPI 3.1.1 Security Requirement Object. Defined by the standard
References (3)

A finding supports evidence for these requirements. On its own it does not make an organization compliant.

  • DORA Art. 9(4)(c) Related

    implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only, and establish to that end a set of policies, procedures and controls that address access rights and ensure a sound administration thereof

    Applies as: legal requirement. Binds EU financial entities such as banks, payment and e-money institutions, investment firms and insurers.

  • RTS 2024/1774 Art. 21(d) Related

    a provision on restrictions of access to ICT assets, setting out controls and tools to prevent unauthorised access

    Applies as: legal requirement. Binds the EU financial entities under DORA. Entities under the simplified framework follow Article 33 instead of Article 21.

  • ISO/IEC 27001 A.8.3 Related

    Information access restriction

    Applies as: certifiable standard. Binding only for a certified organization, on the scope of its certificate.

Accountable: Resource ownerResponsible: DeveloperConsulted: SecurityInformed: Scope steward