Skip to content

Functional Risk Assessment: SharePoint Access Integration#

@RISK:SharePointAccess

Requirement Reference#

  • URS Reference: @URS:SharePointAccess
  • Feature File: requirements/features/sharepoint-access.feature
  • System Component: SharePoint MCP Server (connectors/mcps/sharepoint/)

Executive Summary#

The SharePoint Access integration enables AI assistants to search, browse, and read documents from Microsoft SharePoint sites and OneDrive via Microsoft Graph API. This assessment identifies 7 primary risks spanning security (unauthorized access, token compromise), privacy (document content, metadata exposure), data integrity (parsing errors), and availability (service dependencies).

Risk Classification: HIGH Key Concerns: SharePoint documents contain confidential business information, proprietary data, and personal information. OAuth2 token compromise, sensitivity label misconfiguration, or implementation errors could expose restricted documents and violate data protection policies. Read-only access and sensitivity label gating reduce impact compared to write-enabled systems.

Risk Inventory#

R1: Unauthorized Document Access via Token Compromise#

@RISK_ID:SharePointAccess-R1

Description: An attacker obtains a valid OAuth2 access token (through phishing, malware, or token theft) and uses it to search, browse, and read SharePoint documents and OneDrive files that the legitimate user can access, potentially exposing confidential business information and personal data.

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 for access tokens) - Microsoft Graph API scopes (Sites.Read.All, Files.Read.All) grant broad read access to all SharePoint sites and OneDrive files the user can access

Impact: HIGH — Exposure of confidential documents containing: business strategies, financial data, proprietary research, customer information, employee records, internal communications, and personal data. Documents may contain GDPR-protected PII (names, email addresses, phone numbers, health information). Potential for competitive intelligence gathering, insider trading, or reputational damage.

Likelihood: MEDIUM — OAuth2 tokens are actively targeted by attackers. Mobile/desktop clients and browser extensions increase exposure surface. SharePoint contains high-value targets for corporate espionage.

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

Mitigations: 1. OAuth2 On-Behalf-Of (OBO) Flow (connectors/mcps/sharepoint/src/sharepoint_mcp/auth.py) - User identity preserved through token chain - No shared service account credentials - Each assistant session authenticated as the actual user - Token exchange scoped to specific user permissions

  1. Scoped Permissions (task-definition.json - GRAPH_SCOPES)
  2. Limited to Sites.Read.All and Files.Read.All only (no write, delete, or share capabilities)
  3. Reduces blast radius if token compromised

  4. No ability to modify permissions or share documents

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

  6. Limits window of unauthorized access
  7. Requires re-authentication after expiry

  8. Refresh tokens stored in DynamoDB with TTL

  9. TLS Encryption (Microsoft Graph API enforces HTTPS)

  10. Tokens encrypted in transit
  11. Protection against network interception

  12. AWS ALB to ECS communication over TLS

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

  14. MFA enforcement at authentication time
  15. Device compliance checks
  16. IP-based access restrictions

  17. Risk-based conditional access (Azure AD Identity Protection)

  18. Stateless HTTP Mode (server.py: stateless_http=True)

  19. No server-side session state
  20. Token not persisted in application memory beyond request scope
  21. Reduces token exposure window

Verification: - TEST-SharePointAccess-R1-T1: Verify expired tokens rejected by Microsoft Graph API - TEST-SharePointAccess-R1-T2: Confirm token scopes limited to Sites.Read.All and Files.Read.All (no write operations succeed) - TEST-SharePointAccess-R1-T3: Test cross-user access denied (User A token cannot access User B's private OneDrive files) - TEST-SharePointAccess-R1-T4: Verify site permissions respected (documents from inaccessible sites do not appear in search results)

Residual Risk: MEDIUM — Token theft remains possible through endpoint compromise, phishing, or malware. No additional technical controls within this component (relies on Azure AD conditional access policies, device compliance). Broad Sites.Read.All scope cannot be further narrowed without losing functionality.

R2: Document Content Exposure Through Logging#

@RISK_ID:SharePointAccess-R2

Description: Document filenames, content snippets, metadata (authors, titles, folder paths), or full document text logged to CloudWatch Logs, creating a GDPR violation and confidential information leak visible to anyone with CloudWatch access.

Cause: - Python logging framework in use (connectors/mcps/sharepoint/src/sharepoint_mcp/) - Debug-level logging may inadvertently capture document content, search queries, or filenames - CloudWatch logs retained for extended periods (configurable) - Documents contain high-density confidential information (business plans, financial projections, proprietary research) - Parsing errors could trigger exception logs containing document content fragments

Impact: HIGH — GDPR Article 5 violation (data minimization, purpose limitation). Confidential document content exposed to anyone with CloudWatch access (potentially including support personnel, AWS administrators, or via unauthorized access). Regulatory penalties, reputational damage, intellectual property theft.

Likelihood: MEDIUM — Common misconfiguration during development. Default Python logging includes function arguments. Document parsing errors likely to generate exception logs.

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

Mitigations: 1. Structured Logging with Field Exclusion - Configure Python logging to exclude document content, filenames, titles, author names, folder paths - Log only metadata: document IDs, search query IDs (hashed), operation counts, error codes - Use structured logging library (e.g., structlog) with explicit field allow-lists

  1. Log Level Configuration (ECS task: LOG_LEVEL=INFO)
  2. Disable DEBUG logging in production
  3. Review existing log statements in server.py, graph/, tools/ for content leakage

  4. Add code review checklist item: "No document content in log statements"

  5. CloudWatch Log Encryption (AWS KMS)

  6. Encrypt logs at rest with customer-managed key
  7. Rotate encryption keys annually

  8. Restrict KMS key access to operations team only

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

  10. Minimize retention window for operational logs
  11. No long-term storage of request/response logs

  12. Automatic deletion after retention period

  13. Code Review Checklist

  14. Review all logger.debug(), logger.info(), logger.error() calls before production deployment
  15. Automated linting rule: flag logging of variables named content, text, filename, title, author, body

  16. Exception handlers must sanitize messages before logging

  17. Parsing Error Handling (document readers)

  18. Catch exceptions during DOCX/PDF/XLSX parsing
  19. Log only: file extension, size, error code (never document content or binary data)
  20. Return generic error to user: "Document format not supported"

Verification: - TEST-SharePointAccess-R2-T1: Review CloudWatch logs after test document retrieval → expect no filenames, content snippets, or author names - TEST-SharePointAccess-R2-T2: Verify CloudWatch log group encryption enabled with KMS key - TEST-SharePointAccess-R2-T3: Test error handling with corrupted DOCX → confirm exceptions do not include document content - TEST-SharePointAccess-R2-T4: Test search query logging → confirm query text not logged (only query ID or hash)

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

R3: Sensitivity Label Bypass via Misconfiguration#

@RISK_ID:SharePointAccess-R3

Description: Misconfiguration of the sensitivity label gate (incorrect label ordering, missing label checks, or disabled filtering) allows AI assistant access to documents marked as Restricted, Confidential, or Highly Confidential that should be blocked, violating data protection policies.

Cause: - Sensitivity label configuration stored in config.yaml (file-based, not validated at runtime) - Label hierarchy defined manually (e.g., "Public < Internal < Confidential < Restricted") - Human error in YAML syntax or label GUID mappings - Configuration changes not subject to change control or peer review - Default configuration may not enforce any label restrictions (fail-open instead of fail-closed)

Impact: CRITICAL — Unauthorized access to highly confidential documents (executive communications, M&A documents, clinical trial data, employee performance reviews, salary information). GDPR Article 32 violation (failure to ensure appropriate security). Potential for regulatory penalties, competitive harm, or reputational damage.

Likelihood: MEDIUM — Configuration files are prone to human error. Label GUIDs are non-intuitive (easy to copy-paste incorrectly). No runtime validation of label hierarchy.

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

Mitigations: 1. Sensitivity Label Gate Implementation (config.yaml + filter logic in tools/) - Documents above configured maximum sensitivity label have _redacted: true flag set - Content replaced with redaction notice: "Content withheld due to sensitivity label" - Metadata still returned (document exists) but content blocked

  1. Configuration Validation (startup checks)
  2. Validate config.yaml schema at application startup
  3. Fail-closed: if configuration invalid, block all document access

  4. Log configuration errors to CloudWatch with alerting

  5. Fail-Closed Default (code design)

  6. If no sensitivity label configuration present, assume all documents restricted (block by default)

  7. Explicit allow-list approach: only labels in configuration are accessible

  8. Configuration Version Control (Git)

  9. config.yaml stored in version control
  10. Changes require peer review via pull request

  11. Deployment workflow validates configuration before apply

  12. Regular Configuration Audits (quarterly)

  13. Review label GUIDs against Microsoft Purview settings
  14. Verify label hierarchy matches organizational policy

  15. Test sample documents at each sensitivity level

  16. Integration Test Coverage

  17. Automated tests for each sensitivity label level
  18. Verify redaction logic for documents above threshold
  19. Test missing label scenario (unlabeled documents)

Verification: - TEST-SharePointAccess-R3-T1: Upload test document with "Highly Confidential" label → verify content redacted, _redacted: true - TEST-SharePointAccess-R3-T2: Upload test document with "Internal" label → verify content accessible - TEST-SharePointAccess-R3-T3: Test invalid config.yaml (syntax error) → expect application startup failure - TEST-SharePointAccess-R3-T4: Test missing sensitivity label on document → verify fail-closed behavior - TEST-SharePointAccess-R3-T5: Test label GUID mismatch → verify documents blocked until configuration corrected

Residual Risk: MEDIUM — Configuration complexity creates ongoing risk. Mitigated by validation, testing, and change control, but human error in configuration changes remains possible. Consider future enhancement: centralize label configuration in AWS Systems Manager Parameter Store with schema validation.

R4: Site Whitelist Misconfiguration Allowing Overly Broad Access#

@RISK_ID:SharePointAccess-R4

Description: Overly permissive site whitelist configuration (e.g., wildcard patterns, missing restrictions) allows AI assistant access to SharePoint sites beyond intended scope, potentially exposing HR sites, executive sites, or legal document repositories.

Cause: - Site whitelist configured in config.yaml as URL patterns or site IDs - Wildcards or regex patterns may match unintended sites - Human error in pattern design (e.g., *.novonordisk.com matches all sites) - No runtime validation of site whitelist effectiveness - Default configuration may not enforce any site restrictions (all sites accessible)

Impact: HIGH — Access to out-of-scope SharePoint sites containing sensitive information (HR employee files, executive communications, legal holds, M&A documents). Violates principle of least privilege. May expose documents not intended for general workforce access.

Likelihood: MEDIUM — Configuration errors common. Site URL patterns complex (tenant URLs, site slugs, subsite structures). Difficult to test exhaustively.

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

Mitigations: 1. Site Whitelist Enforcement (config.yaml + tools/browse.py) - Only sites matching whitelist patterns returned by list_sites - Search results from non-whitelisted sites excluded - Explicit allow-list approach: no access unless site explicitly configured

  1. Whitelist Configuration Format (explicit site IDs preferred over wildcards)
  2. Use SharePoint site IDs (GUIDs) instead of URL patterns where possible
  3. Document each entry with business justification

  4. Avoid overly broad wildcards

  5. Configuration Validation (startup checks)

  6. Parse whitelist patterns at startup
  7. Log effective whitelist to CloudWatch for audit

  8. Fail-closed: if whitelist empty or invalid, block all site access

  9. Regular Whitelist Audits (quarterly)

  10. Review configured sites against business requirements
  11. Remove sites no longer in scope

  12. Verify no unintended sites matched by patterns

  13. Integration Test Coverage

  14. Test access to whitelisted sites (expect success)
  15. Test access to non-whitelisted sites (expect filtered out)
  16. Test wildcard patterns match only intended sites

Verification: - TEST-SharePointAccess-R4-T1: Configure whitelist with specific site ID → verify only that site accessible - TEST-SharePointAccess-R4-T2: Search across all sites → verify results only from whitelisted sites - TEST-SharePointAccess-R4-T3: Test with empty whitelist → expect all site access blocked - TEST-SharePointAccess-R4-T4: Test wildcard pattern → verify matches only intended sites, not HR or executive sites

Residual Risk: MEDIUM — Configuration complexity creates risk of overly broad patterns. Mitigated by explicit site IDs, validation, and auditing, but ongoing review required. No technical control prevents misconfiguration (relies on correct configuration management).

R5: Document Parsing Errors Exposing Partial Content or Binary Data#

@RISK_ID:SharePointAccess-R5

Description: Errors during document parsing (DOCX, PDF, XLSX, PPTX) result in partial content extraction, binary data fragments, or metadata leakage returned to user, potentially exposing sensitive information that would otherwise be inaccessible.

Cause: - Document parsing libraries (e.g., python-docx, PyPDF2, openpyxl) may fail on corrupted or complex documents - Malformed documents may cause parser to return binary data instead of text - Partial parsing may expose document metadata (author names, revision history, hidden text, comments) - Exception handling may return raw document bytes or parser stack traces - PDF documents with embedded images, forms, or encryption may parse incorrectly

Impact: MEDIUM — Exposure of partial document content that user may not understand is sensitive (e.g., revision history, hidden text, metadata). Binary data leakage not human-readable but could be decoded. Lower impact than full content exposure, but still creates compliance and security risk.

Likelihood: MEDIUM — Document parsing is complex. Real-world documents contain diverse formatting, embedded objects, and legacy formats. Parsing errors inevitable at scale.

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

Mitigations: 1. Robust Error Handling in Parsers (tools/read.py) - Wrap all document parsing in try-except blocks - On parsing failure, return generic error: "Document format not supported or corrupted" - Never return raw binary data or partial parsing results to user - Log parsing errors with document ID and file extension (not content) for debugging

  1. Metadata Sanitization (document parsing)
  2. Strip revision history, hidden text, comments, and tracked changes from parsed output
  3. Only return visible document text

  4. Redact author metadata if not essential to user query

  5. Parser Library Selection (use well-maintained libraries)

  6. Use actively maintained parsing libraries with security patches
  7. Regularly update dependencies to fix parsing vulnerabilities

  8. Consider sandboxing parsers in isolated processes for complex formats

  9. Content Type Validation (before parsing)

  10. Verify MIME type matches file extension
  11. Reject mismatched or unknown file types

  12. Limit supported formats to well-tested types (DOCX, PDF, XLSX, PPTX, TXT)

  13. Integration Test Coverage

  14. Test parsing of corrupted documents (truncated files, missing headers)
  15. Test complex documents (embedded images, macros, forms)
  16. Test legacy formats (DOC, XLS, PPT) if supported
  17. Verify error messages do not leak content

Verification: - TEST-SharePointAccess-R5-T1: Upload corrupted DOCX → expect graceful error, no binary data returned - TEST-SharePointAccess-R5-T2: Upload PDF with embedded images → verify only text extracted (no image data) - TEST-SharePointAccess-R5-T3: Upload document with tracked changes → verify revision history not returned - TEST-SharePointAccess-R5-T4: Upload XLSX with hidden sheets → verify hidden content not exposed - TEST-SharePointAccess-R5-T5: Upload file with mismatched extension (PDF renamed to DOCX) → expect rejection

Residual Risk: LOW — Robust error handling and parser library selection mitigate most risks. Residual risk of unknown parser bugs in complex documents. Requires ongoing dependency updates and monitoring for parsing library CVEs.

R6: Service Dependency on Microsoft Graph API Availability#

@RISK_ID:SharePointAccess-R6

Description: Microsoft Graph API downtime, throttling, or regional outage prevents AI assistant from searching, browsing, or reading SharePoint documents, blocking time-sensitive queries (e.g., "Find the Q4 budget proposal") and degrading user experience.

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 - Search API complexity increases throttling likelihood (KQL queries, large result sets)

Impact: MEDIUM — User functionality degraded. Document search, browse, and read operations fail, reducing AI assistant utility. Does not create data loss or security risk (read-only operations). Business impact depends on user reliance on SharePoint feature and availability of alternative document access methods.

Likelihood: MEDIUM — Microsoft Graph API generally reliable (99.9% SLA), but throttling and transient errors occur. Search API more prone to rate limiting than simple CRUD operations. High-volume usage increases throttling risk.

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

Mitigations: 1. Exponential Backoff and Retry Logic (graph/client.py) - Implement retry mechanism for transient HTTP errors (429, 503, 504) - Exponential backoff with jitter to avoid thundering herd - Respect Retry-After header in 429 responses - Maximum 3 retries before returning error to user

  1. Rate Limit Awareness (Microsoft Graph API documentation)
  2. Monitor for 429 responses and adjust query patterns
  3. Avoid high-frequency polling (batch requests where possible)

  4. Implement client-side rate limiting if needed

  5. User-Facing Error Messages (tool responses)

  6. Graceful degradation: return "SharePoint temporarily unavailable" instead of raw API error
  7. No stack traces or internal errors exposed to user

  8. Include retry guidance: "Please try again in a few moments"

  9. Monitoring and Alerting (CloudWatch metrics)

  10. Track Microsoft Graph API error rates (429, 5xx responses) by operation type
  11. Alert on sustained elevated error rates (>5% over 5 minutes)

  12. Dashboard showing Graph API latency and availability

  13. Microsoft 365 Status Monitoring (proactive awareness)

  14. Subscribe to Microsoft 365 Service Health API for outage notifications

  15. Post-incident review for extended outages

  16. Circuit Breaker Pattern (optional future enhancement)

  17. Temporarily disable search functionality after repeated failures
  18. Prevents cascading failures and resource exhaustion
  19. Automatic recovery after cooldown period

Verification: - TEST-SharePointAccess-R6-T1: Simulate Microsoft Graph API 503 error → expect retry logic activated, eventual failure with user-friendly message - TEST-SharePointAccess-R6-T2: Simulate Microsoft Graph API 429 throttling → expect backoff and Retry-After respected - TEST-SharePointAccess-R6-T3: Verify user-facing error message (no stack traces or raw JSON errors) - TEST-SharePointAccess-R6-T4: Test sustained outage → verify graceful degradation, no cascading failures

Residual Risk: MEDIUM — External dependency cannot be eliminated. Availability risk accepted as inherent to cloud service integration. No local caching or redundancy possible for search operations (must query live SharePoint data).

R7: Search Query Privacy Violation via Logging or Inference#

@RISK_ID:SharePointAccess-R7

Description: User search queries (e.g., "layoff plan", "merger documents", "performance review for John Doe") logged to CloudWatch or transmitted to Microsoft without user awareness, exposing sensitive intent and potentially identifying confidential investigations or business activities.

Cause: - Search queries passed directly to Microsoft Graph Search API (Microsoft may log queries server-side) - Application logging may capture query text for debugging - CloudWatch logs accessible to operations team - Search queries reveal user intent and business context (more sensitive than passive document access)

Impact: MEDIUM — Exposure of user intent and business activities. Search queries may reveal confidential investigations (e.g., "fraud investigation documents"), sensitive topics (e.g., "employee termination procedures"), or business strategy (e.g., "acquisition target research"). Lower impact than full document content exposure, but still creates privacy and confidentiality concerns.

Likelihood: HIGH — By design, search queries transmitted to Microsoft Graph API (required for functionality). Logging of query text for debugging common practice.

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

Mitigations: 1. User Awareness and Transparency (OAuth2 consent screen + documentation) - Azure AD OAuth2 consent flow discloses "Search SharePoint content" capability - User aware that search queries processed by Microsoft Graph API - Documentation states: "Search queries are transmitted to Microsoft for processing"

  1. Query Logging Prohibition (code review + structured logging)
  2. Never log full query text to CloudWatch
  3. Log only: query ID (generated), result count, latency, error codes

  4. Structured logging with explicit field exclusion for query parameter

  5. Microsoft Graph API Privacy Policy (external dependency)

  6. Microsoft processes queries for search functionality only
  7. No third-party disclosure of query data

  8. Query data subject to Microsoft 365 data governance policies

  9. Encryption in Transit (TLS)

  10. All queries transmitted over HTTPS to Microsoft Graph API

  11. Protection against network eavesdropping

  12. No Query Caching (stateless design)

  13. Queries not stored in DynamoDB or other persistent storage
  14. No query history feature
  15. Each search is independent transaction

Verification: - TEST-SharePointAccess-R7-T1: Review CloudWatch logs after test search → expect no query text logged (only query ID or result count) - TEST-SharePointAccess-R7-T2: Verify OAuth2 consent screen discloses search capability - TEST-SharePointAccess-R7-T3: Verify no query caching or history storage (check DynamoDB tables) - TEST-SharePointAccess-R7-T4: Code review for logging statements → confirm no query parameter logged

Residual Risk: MEDIUM — Query transmission to Microsoft Graph API inherent to functionality. Microsoft may log queries server-side (outside this component's control). Mitigated by user consent, transparency, and Microsoft's privacy policies, but not eliminated. Consider future enhancement: query anonymization or hashing before logging (while preserving debugging capability).

Risk Summary#

Risk ID Description Impact Likelihood Risk Level Residual Risk
R1 Unauthorized document access via token compromise HIGH MEDIUM HIGH MEDIUM
R2 Document content exposure through logging HIGH MEDIUM HIGH LOW
R3 Sensitivity label bypass via misconfiguration CRITICAL MEDIUM CRITICAL MEDIUM
R4 Site whitelist misconfiguration allowing overly broad access HIGH MEDIUM HIGH MEDIUM
R5 Document parsing errors exposing partial content or binary data MEDIUM MEDIUM MEDIUM LOW
R6 Service dependency on Microsoft Graph API availability MEDIUM MEDIUM MEDIUM MEDIUM
R7 Search query privacy violation via logging or inference MEDIUM HIGH MEDIUM MEDIUM

Testing Strategy#

Security Testing#

  • Expired token rejection (R1)
  • Cross-user access prevention (R1)
  • Token scope enforcement (R1)
  • Site whitelist enforcement (R4)
  • Sensitivity label gate validation (R3)

Privacy Testing#

  • Log content inspection for documents and queries (R2, R7)
  • Query text non-logging verification (R7)
  • User consent flow validation (R1, R7)
  • Metadata sanitization (R5)

Data Integrity Testing#

  • Document parsing error handling (R5)
  • Corrupted document handling (R5)
  • Metadata stripping (R5)
  • Content type validation (R5)

Reliability Testing#

  • Microsoft Graph API error simulation (R6)
  • Rate limiting handling (R6)
  • Circuit breaker testing (R6)
  • Graceful degradation validation (R6)

Configuration Testing#

  • Sensitivity label hierarchy validation (R3)
  • Site whitelist pattern matching (R4)
  • Invalid configuration handling (R3, R4)
  • Default fail-closed behavior (R3, R4)

Compliance Mapping#

Regulation Requirement Risk Coverage
GDPR Article 5(1)(a) Lawfulness, fairness, transparency R1, R7 (user consent via OAuth2, query transparency)
GDPR Article 5(1)(c) Data minimization R2, R7 (no logging, no query storage)
GDPR Article 5(1)(f) Integrity and confidentiality R1, R2, R3, R4 (access controls, encryption, sensitivity labels)
GDPR Article 32 Security of processing R1, R2, R3 (TLS, token expiration, log encryption, label enforcement)
GDPR Article 25 Data protection by design and by default R3, R4 (fail-closed configuration, explicit whitelists)
21 CFR Part 11.10 Controls for closed systems (if applicable) R1 (user authentication), R2 (audit trails), R3 (sensitivity controls)

Risk Acceptance Statement#

The SharePoint Access integration operates as a read-only proxy to Microsoft Graph API with sensitivity label gating and site whitelist filtering, significantly reducing risk compared to unfiltered or write-enabled systems. All identified risks have mitigations in place. Residual risks (token compromise, configuration errors, external service availability) 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 (Sites.Read.All, Files.Read.All only — no write operations)
  3. No data persistence (stateless proxy, no document caching)
  4. User consent and transparency (OAuth2 consent flow)
  5. Sensitivity label enforcement (content redaction for restricted documents)
  6. Site whitelist enforcement (access limited to approved sites)

Risk Owner: Product Owner / Engineering Lead Review Date: 2026-04-22 Next Review: 2026-10-22 (6 months)

References#

  • URS: requirements/features/sharepoint-access.feature
  • OAuth Design: docs/design-oauth-authentication.md
  • Related Risk Assessment: docs/risks/risk-assessment-oauth-authentication.md
  • Microsoft Graph API: https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview
  • Microsoft Graph API (Sites): https://learn.microsoft.com/en-us/graph/api/resources/site
  • Microsoft Graph API (DriveItem): https://learn.microsoft.com/en-us/graph/api/resources/driveitem
  • GDPR Compliance: https://gdpr.eu/
  • Microsoft Purview Sensitivity Labels: https://learn.microsoft.com/en-us/purview/sensitivity-labels

Document Version: 1.0 Last Updated: 2026-04-22 Author: AI Connectors Security Team