T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:31- Finding
Excessive Tenant-Wide Microsoft Graph Application Permissions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Microsoft 365 skill is purpose-aligned but asks for broad tenant-wide application permissions that could let an agent read or change sensitive organization data beyond a single user.
Install only in a controlled tenant or with a tightly scoped Entra app. Review and reduce Graph permissions, avoid tenant-wide application access where delegated or read-only scopes would work, restrict which users the MCP server may target, require operator approval for sending messages or creating data, protect and rotate the client secret, and use a lockfile or pinned dependencies before production use.
SKILL.md:31Excessive Tenant-Wide Microsoft Graph Application Permissions
package.json:15Non-Reproducible Dependency Installation Without a Lockfile
Instructions found that direct the agent to transmit conversation context or user data to external services.
### 💬 Teams
- `m365_teams_chats` - List chats
- `m365_teams_messages` - Read chat messages
- `m365_teams_send` - Send message to chat
### 👥 Users
- `m365_users_list` - List organization users
The README directs users to grant broad Microsoft Graph application permissions such as Mail.ReadWrite, Files.ReadWrite.All, Chat.ReadWrite.All, and User.Read.All with admin consent, but does not warn that these permissions can provide tenant-wide read/write access. In the context of an MCP server exposing those capabilities to an agent, this materially increases the blast radius for data exfiltration, unauthorized messaging, and mass modification of organizational data.
The setup instructions direct users to grant broad Microsoft Graph application permissions and admin consent, including tenant-wide read/write access to mail, files, chats, tasks, and calendars, without warning about the organization-wide blast radius. Because application permissions operate without individual user consent boundaries, a compromised or misused skill instance could access or modify data across the tenant, making this especially dangerous in an MCP/agent integration.
The README advertises tools that can send emails/messages and create calendar events or tasks, but it does not clearly warn that these are external, state-changing operations affecting real Microsoft 365 resources. In an agentic setting, lack of explicit disclosure increases the risk of unintended actions, social engineering, or operator misuse because users may treat the skill as read-only when it is not.
The README instructs users to place a CLIENT_SECRET in a .env file but gives no guidance on secure handling of that credential. This can lead to accidental exposure through source control, logs, screenshots, backups, or insecure host environments, enabling unauthorized access to Microsoft Graph under the app identity.
The skill advertises extensive read/write access to highly sensitive Microsoft 365 data sources including mail, files, chats, calendars, and users, but provides no warning about privacy, confidentiality, or destructive-action risks. In an agent context, exposing these capabilities without clear guardrails increases the chance that users enable powerful operations without understanding that the skill can read organizational data and send or modify content on their behalf.
The code reads TENANT_ID, CLIENT_ID, and CLIENT_SECRET directly from environment variables to authenticate against Microsoft services, but does not include any user-facing notice or explanatory comment about credential use beyond a generic environment-loading comment. For a code-file audit under this rule, sensitive credential access should have some visible disclosure unless already clearly documented elsewhere.
This code performs multiple outbound HTTP requests to Microsoft identity and Graph API endpoints, sending mailbox, calendar, files, tasks, chat, and directory data, but provides no confirmation prompt or user-facing disclosure about these network transmissions. The only visible runtime message announces server startup, which does not warn users that their organizational data will be accessed and sent to external services.
The dependency uses a caret range (^1.0.0), which allows automatic installation of newer compatible releases instead of a single fixed version. This increases supply-chain risk and makes builds non-reproducible, especially important here because this package is an MCP server integrating with Microsoft 365 data and permissions.
"author": "Mahmoud Alkhatib",
"license": "MIT",
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0",
"dotenv": "^16.3.1"
},
"devDependencies": {
The manifest depends on @modelcontextprotocol/sdk without pinning an exact version, while known advisories exist for some releases of that package. Because this project is an MCP server connected to Microsoft 365 services, using an affected SDK version could expose sensitive cross-client data, enable denial of service, or weaken network-origin protections, making the uncertainty materially more dangerous than a generic library issue.
The dotenv dependency is specified with a caret range, so different installs may resolve to different package versions over time. While dotenv itself is common and this alone is not an immediate exploit, it still weakens build reproducibility and increases exposure to compromised or vulnerable upstream releases.
"license": "MIT",
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0",
"dotenv": "^16.3.1"
},
"devDependencies": {
"@types/node": "^20.10.0",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"dotenv": "^16.3.1"
},
"devDependencies": {
"@types/node": "^20.10.0",
"tsx": "^4.7.0",
"typescript": "^5.3.0"
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"@types/node": "^20.10.0",
"tsx": "^4.7.0",
"typescript": "^5.3.0"
}
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"devDependencies": {
"@types/node": "^20.10.0",
"tsx": "^4.7.0",
"typescript": "^5.3.0"
}
}
Detected: suspicious.env_credential_access