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.
15 of 46 findings
Critical1
| Finding | Who acts |
|---|---|
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 |
Warnings4
| 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 |
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 |
Notes10
| Finding | Who acts |
|---|---|
| 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 |