Demo data. Example Corp is fictitious, and nothing you do here is saved.
Example Corp assistant
Start a reviewMCP server with 6 tools and 11 API operations. No approved baseline yet.
45 of 46 findings
Critical7
| Finding | Who 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.
| 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 guidanceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (4)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (4)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 standardReferences (3)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| Accountable, Responsible: IAM engineeringResponsible: DeveloperConsulted: Security, Client software ownerInformed: Resource owner |
Warnings26
| Finding | Who 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 guidanceReferences (4)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (4)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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.
| 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.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 standardReferences (1)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 standardReferences (1)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (1)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 guidanceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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.
| 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 practiceReferences (1)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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.
| 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.
| 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.
| 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 practiceReferences (3)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| Accountable: Resource ownerResponsible: MCP server ownerConsulted: SecurityInformed: Internal audit |
Notes12
| Finding | Who 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 practiceReferences (1)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 practiceReferences (2)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| 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 standardReferences (3)A finding supports evidence for these requirements. On its own it does not make an organization compliant.
| Accountable: Resource ownerResponsible: DeveloperConsulted: SecurityInformed: Scope steward |