Skip to content

Functional Risk Assessment: OutlookCalendar Integration#

@RISK:OutlookCalendar

Requirement Reference#

  • URS Reference: @URS:OutlookCalendar
  • Feature File: requirements/features/outlook-calendar.feature
  • System Component: Outlook Calendar MCP Server (connectors/mcps/outlook-calendar/)

Executive Summary#

The OutlookCalendar integration enables AI assistants to retrieve calendar events from Microsoft 365 calendars via Microsoft Graph API. This assessment identifies 6 primary risks spanning security (unauthorized access, token compromise), privacy (meeting details, attendee PII), and availability (service dependencies).

Risk Classification: HIGH
Key Concerns: Calendar events contain sensitive meeting details, attendee information, and location data. OAuth2 token compromise or implementation errors could expose scheduling patterns and confidential business activities. Read-only access reduces impact compared to write-enabled systems.

Risk Inventory#

R1: Unauthorized Calendar Access via Token Compromise#

@RISK_ID:OutlookCalendar-R1

Description:
An attacker obtains a valid OAuth2 access token (through phishing, malware, or token theft) and uses it to read calendar events, meeting details, and attendee information that the legitimate user can access.

Cause: - OAuth2 bearer tokens grant access to anyone presenting them - Tokens transmitted over HTTPS but could be logged, cached, or stolen from client memory - Token lifetime creates a window of opportunity (default: 1 hour)

Impact:
HIGH — Exposure of sensitive meeting details (subject lines like "Performance Review", "Confidential Project X"), attendee lists (PII: names, email addresses), location data, online meeting URLs, and scheduling patterns revealing business activities

Likelihood:
MEDIUM — OAuth2 tokens are targeted by attackers. Mobile/desktop clients increase exposure surface.

Risk Level: HIGH (Impact: HIGH × Likelihood: MEDIUM)

Mitigations: 1. OAuth2 On-Behalf-Of (OBO) Flow (connectors/mcps/outlook-calendar/auth.py) - User identity preserved through token chain - No shared service account credentials - Each assistant session authenticated as the actual user

  1. Scoped Permissions (task-definition.json - GRAPH_SCOPES)
  2. Limited to Calendars.Read only (no create, update, delete, or send capabilities)

  3. Reduces blast radius if token compromised

  4. Token Expiration (Microsoft Entra ID default: 60 minutes)

  5. Limits window of unauthorized access

  6. Requires re-authentication after expiry

  7. TLS Encryption (Microsoft Graph API enforces HTTPS)

  8. Tokens encrypted in transit

  9. Protection against network interception

  10. Azure AD Conditional Access (Microsoft Entra ID policies)

  11. MFA enforcement at authentication time
  12. Device compliance checks
  13. IP-based access restrictions
  14. Risk-based conditional access (Azure AD Identity Protection)

Verification: - TEST-OutlookCalendar-R1-T1: Verify expired tokens rejected by Microsoft Graph API - TEST-OutlookCalendar-R1-T2: Confirm token scopes limited to Calendars.Read (no write operations succeed) - TEST-OutlookCalendar-R1-T3: Test cross-user access denied (User A token cannot access User B calendar) - TEST-OutlookCalendar-R1-T4: Verify shared calendar access respects Microsoft 365 permissions (only accessible if user has permission)

Residual Risk: MEDIUM — Token theft remains possible through endpoint compromise. No additional technical controls within this component (relies on Azure AD conditional access policies, device compliance).

R2: Calendar Data Exposure Through Logging#

@RISK_ID:OutlookCalendar-R2

Description:
Calendar event subject lines, attendee names/emails, location details, or meeting body content logged to CloudWatch Logs, creating a GDPR violation and confidential information leak.

Cause: - Python logging framework in use (connectors/mcps/outlook-calendar/calendar.py, server.py) - Debug-level logging may inadvertently capture sensitive data - CloudWatch logs retained for extended periods (configurable) - Calendar events contain high-density PII (names, emails, locations, meeting notes)

Impact:
HIGH — GDPR Article 5 violation (data minimization, purpose limitation). Confidential meeting details exposed to anyone with CloudWatch access. Regulatory penalties, reputational damage.

Likelihood:
MEDIUM — Common misconfiguration during development. Default Python logging includes function arguments.

Risk Level: HIGH (Impact: HIGH × Likelihood: MEDIUM)

Mitigations: 1. Structured Logging with Field Exclusion - Configure Python logging to exclude event subject, attendees, location, body fields - Log only metadata: event IDs, counts, date ranges, error codes

  1. Log Level Configuration (ECS task: LOG_LEVEL=INFO)
  2. Disable DEBUG logging in production

  3. Review existing log statements in calendar.py for content leakage

  4. CloudWatch Log Encryption (AWS KMS)

  5. Encrypt logs at rest with customer-managed key

  6. Rotate encryption keys annually

  7. Log Retention Policy (AWS CloudWatch retention: 7 days)

  8. Minimize retention window for operational logs

  9. No long-term storage of request/response logs

  10. Code Review Checklist

  11. Review all logger.debug(), logger.info() calls before production deployment
  12. Automated linting rule: flag logging of variables named subject, attendees, location, body

Verification: - TEST-OutlookCalendar-R2-T1: Review CloudWatch logs after test calendar retrieval → expect no subject lines, attendee names, or locations - TEST-OutlookCalendar-R2-T2: Verify CloudWatch log group encryption enabled - TEST-OutlookCalendar-R2-T3: Test error handling → confirm exceptions do not include event content

Residual Risk: LOW — With proper configuration and code review, logging leakage is preventable. Requires ongoing vigilance during development.

R3: Cross-User Calendar Access via Authorization Bypass#

@RISK_ID:OutlookCalendar-R3

Description:
Implementation error in user-scoped calendar queries allows User A to retrieve calendar events belonging to User B, violating confidentiality and privacy.

Cause: - Incorrect Microsoft Graph API query construction (e.g., using users/{user-id}/calendar with hardcoded or manipulated user ID) - Missing user context validation in request routing - Token misuse (service account token used instead of user-delegated token)

Impact:
CRITICAL — Unauthorized access to any user's calendar. Breach of trust, GDPR violation (unauthorized processing of personal data), potential for blackmail or competitive intelligence gathering.

Likelihood:
LOW — OAuth2 OBO flow inherently scopes access to the authenticated user. Would require deliberate implementation error.

Risk Level: MEDIUM (Impact: CRITICAL × Likelihood: LOW)

Mitigations: 1. Microsoft Graph API /me Endpoint (calendar.py) - Use /me/calendar endpoint instead of /users/{user-id}/calendar - Microsoft Graph API enforces token-based user context (no user ID manipulation possible)

  1. No Parameterized User IDs
  2. Never accept user ID from client requests

  3. User identity derived solely from OAuth2 token claims

  4. OAuth2 On-Behalf-Of (OBO) Flow

  5. Token inherently scoped to authenticated user

  6. Microsoft Entra ID validates token-to-user binding

  7. Integration Test Coverage

  8. Multi-user test scenarios: User A requests calendar, verify User B events not returned

Verification: - TEST-OutlookCalendar-R3-T1: User A authenticates, attempts to specify User B's calendar → expect access denied - TEST-OutlookCalendar-R3-T2: Review code for /users/{user-id} patterns → expect only /me usage - TEST-OutlookCalendar-R3-T3: Token from User A used in API call → verify only User A's events returned

Residual Risk: LOW — OAuth2 OBO flow and Microsoft Graph API architecture make cross-user access technically difficult. Requires code review discipline.

R4: Meeting Attendee Privacy Violation#

@RISK_ID:OutlookCalendar-R4

Description:
Calendar event queries expose personal data of meeting attendees (names, email addresses) beyond the authenticated user's legitimate need, creating a GDPR data minimization violation.

Cause: - Microsoft Graph API returns full attendee list by default when retrieving event details - No filtering or redaction of attendee information in MCP server response - Attendee data includes both internal and external contacts (potential exposure of external business relationships)

Impact:
MEDIUM — GDPR Article 5(1)(c) violation (data minimization). Exposure of names and email addresses of individuals who did not consent to AI assistant access. Lower impact than full event content exposure (names/emails less sensitive than meeting content), but still creates compliance risk.

Likelihood:
HIGH — By design, calendar events include attendee lists. No technical control prevents this unless explicitly filtered.

Risk Level: MEDIUM (Impact: MEDIUM × Likelihood: HIGH)

Mitigations: 1. User Consent and Transparency (OAuth2 consent screen) - Azure AD OAuth2 consent flow explicitly states "Read your calendars" scope - User aware that calendar access includes attendee information

  1. Purpose Limitation (System design)
  2. MCP server is read-only proxy with no persistence
  3. Attendee data not stored, cached, or logged

  4. Transient access only during active user session

  5. Shared Calendar Permission Inheritance

  6. Microsoft Graph API enforces Microsoft 365 sharing permissions

  7. If user has access to shared calendar, attendee visibility follows Microsoft 365 policy

  8. No Third-Party Disclosure

  9. Attendee data remains within Microsoft 365 and Azure AD security boundaries
  10. No export, backup, or replication to non-Microsoft systems

Verification: - TEST-OutlookCalendar-R4-T1: Review OAuth2 consent screen → confirm "Read your calendars" scope disclosed - TEST-OutlookCalendar-R4-T2: Verify MCP server does not persist attendee data (no database writes, no cache) - TEST-OutlookCalendar-R4-T3: Test shared calendar access → confirm attendee visibility matches Microsoft 365 permissions

Residual Risk: MEDIUM — Attendee data exposure is inherent to calendar functionality. Mitigated by user consent and purpose limitation, but not eliminated. Consider future enhancement: optional attendee redaction if user only needs scheduling availability (not full attendee lists).

R5: Service Dependency on Microsoft Graph API Availability#

@RISK_ID:OutlookCalendar-R5

Description:
Microsoft Graph API downtime, throttling, or regional outage prevents AI assistant from accessing calendar data, blocking time-sensitive queries (e.g., "What meetings do I have in the next hour?").

Cause: - External dependency on Microsoft 365 service availability - Microsoft Graph API rate limits (per-user, per-app throttling) - Regional Azure outages affecting Graph API endpoints - Network connectivity issues between AWS ECS and Microsoft Graph API

Impact:
MEDIUM — User functionality degraded. Calendar queries fail, reducing AI assistant utility. Does not create data loss or security risk (read-only operations). Business impact depends on user reliance on calendar feature.

Likelihood:
MEDIUM — Microsoft Graph API generally reliable (99.9% SLA), but throttling and transient errors occur. Rate limits can be reached with high-frequency queries.

Risk Level: MEDIUM (Impact: MEDIUM × Likelihood: MEDIUM)

Mitigations: 1. Exponential Backoff and Retry Logic (calendar.py) - Implement retry mechanism for transient HTTP errors (429, 503, 504) - Exponential backoff with jitter to avoid thundering herd

  1. Rate Limit Awareness (Microsoft Graph API documentation)
  2. Respect Retry-After header in 429 responses

  3. Avoid high-frequency polling (use event-driven approaches where possible)

  4. User-Facing Error Messages

  5. Graceful degradation: return "Calendar temporarily unavailable" instead of raw API error

  6. No stack traces or internal errors exposed to user

  7. Monitoring and Alerting (CloudWatch metrics)

  8. Track Microsoft Graph API error rates (429, 5xx responses)

  9. Alert on sustained elevated error rates

  10. Microsoft 365 Status Monitoring

  11. Subscribe to Microsoft 365 Service Health API for proactive awareness of outages

Verification: - TEST-OutlookCalendar-R5-T1: Simulate Microsoft Graph API 503 error → expect retry logic activated - TEST-OutlookCalendar-R5-T2: Simulate Microsoft Graph API 429 throttling → expect backoff and Retry-After respected - TEST-OutlookCalendar-R5-T3: Verify user-facing error message (no stack traces)

Residual Risk: MEDIUM — External dependency cannot be eliminated. Availability risk accepted as inherent to cloud service integration.

R6: Timezone and Recurrence Parsing Errors Causing Data Integrity Issues#

@RISK_ID:OutlookCalendar-R6

Description:
Incorrect parsing or handling of timezone-aware event times or recurring event patterns results in wrong event times displayed to users, leading to missed meetings or incorrect scheduling decisions.

Cause: - Microsoft Graph API returns times in ISO 8601 format with timezone information - Python datetime parsing errors (naive vs. aware datetime objects) - Recurring event expansion logic errors (missing or duplicated occurrences) - Daylight Saving Time (DST) transitions handled incorrectly

Impact:
MEDIUM — User sees wrong meeting times, potentially causing missed appointments. Does not create data loss (read-only system), but creates operational risk and user distrust.

Likelihood:
MEDIUM — Timezone and recurrence logic is complex. Common source of bugs in calendar integrations.

Risk Level: MEDIUM (Impact: MEDIUM × Likelihood: MEDIUM)

Mitigations: 1. Use Microsoft Graph API Timezone Fields (calendar.py) - Preserve start.dateTime, start.timeZone, end.dateTime, end.timeZone from API response - Do not attempt timezone conversion (pass through original values)

  1. ISO 8601 Parsing Library (python-dateutil or datetime)
  2. Use battle-tested parsing libraries instead of custom regex

  3. Handle UTC, offset, and named timezone formats

  4. Recurring Event Expansion by Microsoft Graph API

  5. Use $expand=instances query parameter to let Microsoft Graph API expand recurrences

  6. Avoid client-side recurrence logic (complex and error-prone)

  7. Integration Test Coverage

  8. Test events across DST boundaries
  9. Test recurring events (daily, weekly, monthly patterns)
  10. Test multi-timezone events (organizer in CET, attendee in EST)

Verification: - TEST-OutlookCalendar-R6-T1: Create test event in CET timezone → verify times displayed correctly - TEST-OutlookCalendar-R6-T2: Create recurring weekly event spanning DST transition → verify all occurrences correct - TEST-OutlookCalendar-R6-T3: Create all-day event → verify isAllDay flag preserved (no incorrect time shown)

Residual Risk: LOW — Using Microsoft Graph API native timezone handling and recurrence expansion eliminates most complexity. Requires thorough testing.

Risk Summary#

Risk ID Description Impact Likelihood Risk Level Residual Risk
R1 Unauthorized calendar access via token compromise HIGH MEDIUM HIGH MEDIUM
R2 Calendar data exposure through logging HIGH MEDIUM HIGH LOW
R3 Cross-user calendar access via authorization bypass CRITICAL LOW MEDIUM LOW
R4 Meeting attendee privacy violation MEDIUM HIGH MEDIUM MEDIUM
R5 Service dependency on Microsoft Graph API availability MEDIUM MEDIUM MEDIUM MEDIUM
R6 Timezone and recurrence parsing errors MEDIUM MEDIUM MEDIUM LOW

Testing Strategy#

Security Testing#

  • Expired token rejection (R1)
  • Cross-user access prevention (R1, R3)
  • Token scope enforcement (R1)
  • Shared calendar permission inheritance (R3, R4)

Privacy Testing#

  • Log content inspection (R2)
  • Attendee data non-persistence verification (R4)
  • User consent flow validation (R4)

Reliability Testing#

  • Microsoft Graph API error simulation (R5)
  • Rate limiting handling (R5)
  • Timezone and recurrence edge cases (R6)

Integration Testing#

  • Multi-user scenarios (R3)
  • Shared calendar access (R1, R3)
  • Online meeting details retrieval (R4)

Compliance Mapping#

Regulation Requirement Risk Coverage
GDPR Article 5(1)(a) Lawfulness, fairness, transparency R4 (user consent via OAuth2)
GDPR Article 5(1)(c) Data minimization R2, R4 (no logging, no persistence)
GDPR Article 5(1)(f) Integrity and confidentiality R1, R2, R3 (access controls, encryption)
GDPR Article 32 Security of processing R1, R2 (TLS, token expiration, log encryption)
21 CFR Part 11.10 Controls for closed systems (if applicable) R1 (user authentication), R2 (audit trails)

Risk Acceptance Statement#

The OutlookCalendar integration operates as a read-only proxy to Microsoft Graph API, significantly reducing risk compared to write-enabled calendar systems. All identified risks have mitigations in place. Residual risks (token compromise, attendee privacy) are accepted as inherent to OAuth2-based cloud API integrations and are balanced by:

  1. Microsoft Entra ID security controls (MFA, conditional access)
  2. Scoped permissions (Calendars.Read only)
  3. No data persistence (transient proxy)
  4. User consent and transparency (OAuth2 consent flow)

Risk Owner: Product Owner / Engineering Lead
Review Date: [To be completed after design review]

References#

  • URS: requirements/features/outlook-calendar.feature
  • OAuth Design: docs/design-oauth-authentication.md
  • Related Risk Assessment: docs/risks/risk-assessment-outlook-mail.md
  • Related Risk Assessment: docs/risks/risk-assessment-oauth-authentication.md
  • Microsoft Graph API: https://learn.microsoft.com/en-us/graph/api/calendar-get
  • GDPR Compliance: https://gdpr.eu/