ScopeNeatExample Corp, EU region
Menu
Language
Theme

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

View as Tom B.

You are viewing as Tom B., IAM engineering. Implements what was approved, nothing else.

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

24 of 46 findings

Critical3

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

Warnings15

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

Notes6

FindingWho acts
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