Files
sbroenne__mcp-server-excel/docs/SECURITY.md
T
Stefan Broenner c320a3fc76 Feature: Data Model and DAX Management Support (Phase 1) (#18)
* docs: Add Data Model and DAX feature specification

- Complete research on Excel COM Model object and TOM API
- Design dual-API architecture (Excel COM + TOM)
- Define 15 commands for basic and advanced operations
- Plan MCP Server integration with 2 tools
- Document 4 implementation phases with estimates
- Add development use cases and security considerations

Relates to #17

* Phase 1: Implement Data Model core commands

- Add Data Model result types to ResultTypes.cs
- Create IDataModelCommands interface
- Add Data Model helper methods to ExcelHelper
- Implement DataModelCommands with 6 methods:
  * ListTables - List all Data Model tables
  * ListMeasures - List all DAX measures
  * ViewMeasure - View measure DAX formula
  * ExportMeasure - Export measure to file
  * ListRelationships - List table relationships
  * Refresh - Refresh Data Model

All commands follow established patterns from PowerQuery/Connections.
Includes proper COM cleanup and error handling.

* Add Data Model integration tests

- Create CoreDataModelCommandsTests with 7 comprehensive tests
- Tests validate all basic Data Model operations:
  * ListTables
  * ListMeasures
  * ViewMeasure
  * ExportMeasure
  * ListRelationships
  * Refresh
- Tests handle both success and 'no Data Model' scenarios
- All 7 tests passing

Note: Tests currently use empty workbooks. Future enhancement:
Create helper to populate workbooks with actual Data Model for
more comprehensive testing.

* style: Remove unnecessary blank lines in DataModelCommands and related tests

* feat: Add realistic Data Model test data and centralized Excel busy retry logic

- Create DataModelTestHelper with realistic sample data (Sales, Customers, Products tables)
- Add 6 new positive test scenarios validating actual Data Model operations
- Implement centralized retry logic in ExcelHelper.WithExcel() for RPC_E_SERVERCALL_RETRYLATER errors
- Use exponential backoff (500ms, 1s, 1.5s) with max 3 retries for transient Excel busy states
- All 13 Data Model integration tests now pass with realistic Excel data (100%)

This ensures tests validate actual Excel operations, not just error scenarios,
per copilot instructions requirement for realistic test data and robust error handling.

* style: Remove trailing whitespace for code consistency

* feat(cli): Add Data Model CLI commands (Phase 2)

- Add IDataModelCommands interface for CLI layer
- Implement DataModelCommands with Spectre.Console formatting:
  * dm-list-tables - List Data Model tables with record counts
  * dm-list-measures - List DAX measures with formulas
  * dm-view-measure - View full DAX formula in panel
  * dm-export-measure - Export DAX to file
  * dm-list-relationships - List relationships with active status
  * dm-refresh - Refresh Data Model with spinner
- Register commands in Program.cs with help text
- Add 14 CLI integration tests validating:
  * Argument validation (missing parameters)
  * File validation (non-existent files)
  * Success paths with realistic Data Model
  * Exit codes (0=success, 1=error)
- All tests passing (14/14)

Phase 2 complete: CLI integration for Data Model operations

* feat(datamodel): Complete CRUD with DELETE operations

- Core: Added DeleteMeasure() and DeleteRelationship() methods
  * Uses measure.Delete() and relationship.Delete() COM API
  * Saves workbook after deletion (save: true)
  * Provides workflow hints and suggested actions

- CLI: Added dm-delete-measure and dm-delete-relationship commands
  * Follows existing pattern with Spectre.Console formatting
  * Includes argument validation and error handling
  * Updated Program.cs routing and help text

- MCP Server: Added delete-measure and delete-relationship actions
  * Parameter validation with helpful error messages
  * Enhanced workflow hints for AI assistants
  * Consistent error handling with McpException

This completes Phase 1 CRUD operations for Data Model:
✅ CREATE (Phase 4 - TOM API, future)
✅ READ (list, view, export)
✅ UPDATE (Phase 4 - TOM API, future)
✅ DELETE (measure.Delete, relationship.Delete - NOW COMPLETE)

All builds successful (Core, CLI, MCP Server)

* test(datamodel): Add integration tests for DELETE operations

- Core Tests: 6 new tests for DeleteMeasure and DeleteRelationship
  * Tests validation, error handling, and success paths
  * Includes resilient Data Model creation with graceful fallback
  * All 6 tests passing

- CLI Tests: 7 new tests for dm-delete-measure and dm-delete-relationship
  * Tests argument validation, file existence, error handling
  * Validates CLI exit codes (0 for success, 1 for error)
  * All 7 tests passing

- Test Helper: Added CreateTestMeasure() to DataModelTestHelper
  * Creates individual test measures for delete operation testing
  * Throws InvalidOperationException if Data Model unavailable
  * Tests handle exception gracefully (skip test if needed)

Total: 13 new integration tests (6 Core + 7 CLI)
All 40 Data Model tests passing (100% pass rate)

* docs: Add Data Model feature documentation

- COMMANDS.md: Added complete Data Model commands section
  * 8 commands documented: list-tables, list-measures, view-measure,
    export-measure, list-relationships, refresh, delete-measure,
    delete-relationship
  * Included usage examples and CRUD status table
  * Explained Phase 4 (TOM API) for CREATE/UPDATE operations

- README.md: Added Data Model to Excel Development Use Cases
  * Measure Management - View, export, delete DAX measures
  * Relationship Analysis - List and manage table relationships
  * Data Model Inspection - Explore tables and structure
  * Code Review - Analyze DAX formulas
  * Version Control - Export DAX to files

- MCP Server README: Updated resource-based tools section
  * Changed from 7 to 8 tools (added excel_datamodel)
  * Documented 8 actions: list-tables, list-measures, view-measure,
    export-measure, list-relationships, refresh, delete-measure,
    delete-relationship
  * Added comprehensive AI interaction examples
  * Explained LLM optimization and TOM API future plans

Complete documentation for Phase 1 Data Model support!

* docs: Add Data Model implementation learnings to copilot instructions

- Document Data Model COM API patterns and object model access
- Add CRUD operation capabilities (Read/Delete via COM, Create/Update requires TOM)
- Include test strategy for Excel version compatibility
- Document test helper pattern for dynamic Data Model object creation
- Add CLI naming convention (dm- prefix) and MCP Server tool design
- Include key insights about 1-based indexing, DAX formulas, relationships
- Add prevention strategies for future Data Model feature work

* feat: Add TOM API research and prototypes for Phase 4 (CREATE/UPDATE operations)

Phase 4.0 Research & Prototyping:
- Add Microsoft.AnalysisServices.NetCore.retail.amd64 (v19.84.1) - .NET 9 compatible
- Create TomPrototype class with connection, measure creation, relationship creation methods
- Create TomPrototypeTest program for validation testing
- Create comprehensive DATA-MODEL-TOM-API-SPEC.md specification
- Document TOM API architecture, implementation phases, and open questions

Key Discoveries:
- Modern .NET Core compatible package: Microsoft.AnalysisServices.NetCore.retail.amd64
- Original package (Microsoft.AnalysisServices.Tabular) only supports .NET Framework
- TOM API compiles successfully with .NET 9.0
- Supports full CRUD: Create/Update measures and relationships

Next Steps:
- Runtime testing with actual Excel file containing Data Model
- Document any Excel-specific TOM limitations
- Proceed to Phase 4.1 (Core Implementation) after validation

* Implement TOM API for Data Model CRUD Operations (Phase 4) + Complete CRUD Review for All Commands (#22)

* feat(datamodel): Complete CRUD with DELETE operations

- Core: Added DeleteMeasure() and DeleteRelationship() methods
  * Uses measure.Delete() and relationship.Delete() COM API
  * Saves workbook after deletion (save: true)
  * Provides workflow hints and suggested actions

- CLI: Added dm-delete-measure and dm-delete-relationship commands
  * Follows existing pattern with Spectre.Console formatting
  * Includes argument validation and error handling
  * Updated Program.cs routing and help text

- MCP Server: Added delete-measure and delete-relationship actions
  * Parameter validation with helpful error messages
  * Enhanced workflow hints for AI assistants
  * Consistent error handling with McpException

This completes Phase 1 CRUD operations for Data Model:
✅ CREATE (Phase 4 - TOM API, future)
✅ READ (list, view, export)
✅ UPDATE (Phase 4 - TOM API, future)
✅ DELETE (measure.Delete, relationship.Delete - NOW COMPLETE)

All builds successful (Core, CLI, MCP Server)

* test(datamodel): Add integration tests for DELETE operations

- Core Tests: 6 new tests for DeleteMeasure and DeleteRelationship
  * Tests validation, error handling, and success paths
  * Includes resilient Data Model creation with graceful fallback
  * All 6 tests passing

- CLI Tests: 7 new tests for dm-delete-measure and dm-delete-relationship
  * Tests argument validation, file existence, error handling
  * Validates CLI exit codes (0 for success, 1 for error)
  * All 7 tests passing

- Test Helper: Added CreateTestMeasure() to DataModelTestHelper
  * Creates individual test measures for delete operation testing
  * Throws InvalidOperationException if Data Model unavailable
  * Tests handle exception gracefully (skip test if needed)

Total: 13 new integration tests (6 Core + 7 CLI)
All 40 Data Model tests passing (100% pass rate)

* docs: Add Data Model feature documentation

- COMMANDS.md: Added complete Data Model commands section
  * 8 commands documented: list-tables, list-measures, view-measure,
    export-measure, list-relationships, refresh, delete-measure,
    delete-relationship
  * Included usage examples and CRUD status table
  * Explained Phase 4 (TOM API) for CREATE/UPDATE operations

- README.md: Added Data Model to Excel Development Use Cases
  * Measure Management - View, export, delete DAX measures
  * Relationship Analysis - List and manage table relationships
  * Data Model Inspection - Explore tables and structure
  * Code Review - Analyze DAX formulas
  * Version Control - Export DAX to files

- MCP Server README: Updated resource-based tools section
  * Changed from 7 to 8 tools (added excel_datamodel)
  * Documented 8 actions: list-tables, list-measures, view-measure,
    export-measure, list-relationships, refresh, delete-measure,
    delete-relationship
  * Added comprehensive AI interaction examples
  * Explained LLM optimization and TOM API future plans

Complete documentation for Phase 1 Data Model support!

* docs: Add Data Model implementation learnings to copilot instructions

- Document Data Model COM API patterns and object model access
- Add CRUD operation capabilities (Read/Delete via COM, Create/Update requires TOM)
- Include test strategy for Excel version compatibility
- Document test helper pattern for dynamic Data Model object creation
- Add CLI naming convention (dm- prefix) and MCP Server tool design
- Include key insights about 1-based indexing, DAX formulas, relationships
- Add prevention strategies for future Data Model feature work

* feat: Add TOM API research and prototypes for Phase 4 (CREATE/UPDATE operations)

Phase 4.0 Research & Prototyping:
- Add Microsoft.AnalysisServices.NetCore.retail.amd64 (v19.84.1) - .NET 9 compatible
- Create TomPrototype class with connection, measure creation, relationship creation methods
- Create TomPrototypeTest program for validation testing
- Create comprehensive DATA-MODEL-TOM-API-SPEC.md specification
- Document TOM API architecture, implementation phases, and open questions

Key Discoveries:
- Modern .NET Core compatible package: Microsoft.AnalysisServices.NetCore.retail.amd64
- Original package (Microsoft.AnalysisServices.Tabular) only supports .NET Framework
- TOM API compiles successfully with .NET 9.0
- Supports full CRUD: Create/Update measures and relationships

Next Steps:
- Runtime testing with actual Excel file containing Data Model
- Document any Excel-specific TOM limitations
- Proceed to Phase 4.1 (Core Implementation) after validation

* Checkpoint from VS Code for coding agent session

* Implement Phase 4.1: Core TOM commands with integration tests

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Implement Phase 4.2: CLI Integration for TOM commands

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Implement Phase 4.3: MCP Server integration for TOM commands

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Complete Phase 4.4: Documentation and implementation summary

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Add full CRUD support for DAX calculated columns

- Add ListCalculatedColumns, ViewCalculatedColumn, UpdateCalculatedColumn, DeleteCalculatedColumn methods
- Extend Core, CLI, and MCP Server layers with calculated column CRUD operations
- Add 4 new CLI commands: dm-list-columns, dm-view-column, dm-update-column, dm-delete-column
- Add 4 new MCP Server actions: list-columns, view-column, update-column, delete-column
- Add result types: DataModelCalculatedColumnListResult, DataModelCalculatedColumnViewResult
- Update help text and documentation

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Add missing CRUD operations: VBA View and Parameter Update

- Add ScriptCommands.View() to view VBA code without exporting
- Add ParameterCommands.Update() to change named range reference
- Add ScriptViewResult to ResultTypes.cs
- Core layer implementation complete

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Add CLI commands for VBA View and Parameter Update

- Add script-view CLI command to view VBA code
- Add param-update CLI command to update named range reference
- Update Program.cs command routing and help text
- All CLI layers now support complete CRUD

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Add MCP Server actions for VBA View and Parameter Update

- Add 'view' action to excel_vba tool
- Add 'update' action to excel_parameter tool
- Update tool descriptions and regex patterns
- All MCP Server layers now support complete CRUD

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Update documentation with new CRUD operations

- Document script-view command in COMMANDS.md
- Document param-update command in COMMANDS.md
- Add usage examples for both new commands
- All documentation now reflects complete CRUD capabilities

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Fix CSV import bug in MCP Server worksheet operations

The MCP Server write and append actions were passing the CSV file path directly
to Core commands instead of reading the file content first. This caused the path
string to be written to Excel instead of the actual CSV data.

Fixed by:
- Reading CSV file content in WriteWorksheet() before calling Core command
- Reading CSV file content in AppendWorksheet() before calling Core command
- Adding file existence validation and error handling
- Matching the pattern used in CLI layer (SheetCommands.Write/Append)

This aligns MCP Server behavior with CLI layer, which already correctly reads
file content before passing to Core commands.

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

---------

Co-authored-by: Stefan Broenner <stefan.broenner@microsoft.comm>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Add NuGet version checking with automatic startup warnings and MCP tool (#23)

* feat: Implement Excel instance pooling with capacity management and actionable guidance for LLMs

* Checkpoint from VS Code for coding agent session

* Add NuGet version checking functionality

- Create VersionChecker service in Core project to query NuGet.org API
- Add ExcelVersionTool for MCP server with 'check' action
- Implement automatic version check on MCP server startup
- Add comprehensive unit and integration tests (11 tests, all passing)
- Add NuGet.Protocol and NuGet.Versioning dependencies
- Display warning to stderr on startup if outdated version detected

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Update documentation for version checking feature

- Add excel_version tool to README.md (8 -> 9 tools)
- Add excel_version documentation to MCP Server README
- Include version check example in AI interaction scenarios
- Update tool count from 7 to 8 in main README
- All 11 version checking tests passing

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* Fix update instructions for dnx installation method

- Replace 'dotnet tool update -g' with correct dnx update instructions
- Update VersionChecker.GetMessage() to explain dnx auto-downloads latest
- Update ExcelVersionTool JSON response with updateInstructions field
- Update Program.cs startup warning with dnx information
- Update documentation example in MCP Server README
- Fix unit and integration tests to match new message format
- All 11 tests passing

Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

---------

Co-authored-by: Stefan Broenner <stefan.broenner@microsoft.comm>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>

* refactor: Migrate ExcelInstancePool to Microsoft.Extensions.ObjectPool

- Replace custom semaphore-based pooling with battle-tested Microsoft.Extensions.ObjectPool
- Eliminates all semaphore bugs (acquire/release mismatches, capacity issues)
- Create ExcelInstancePoolPolicy to manage Excel COM instance lifecycle
- Extract PooledExcelInstance as internal class for reuse
- Simplify code: 344 lines vs 424 lines (80 lines removed)

Benefits:
- No more custom concurrency code - uses standard .NET pooling infrastructure
- Better UX: Immediate capacity exceptions vs 5-second timeouts
- Correct hit tracking: Distinguishes cache hits from cache misses
- Proper Excel process cleanup on eviction and disposal
- Thread-safe with proven production patterns

Tests:
- All 6 pooling integration tests passing (100%)
- Validates metrics, reuse, process counts, eviction, disposal, capacity limits
- Fixed test expectations for hit tracking (first operation is miss, not hit)
- Increased wait times for Excel COM cleanup (2-3 seconds)

* fix: Add missing Microsoft.Extensions.ObjectPool package reference

The package reference was lost during rebase merge conflict resolution.
This fixes the build errors for IPooledObjectPolicy interface.

* fix: Remove dangerous KillExcelProcesses() from pooling tests

CRITICAL SAFETY FIX: Integration tests were killing ALL Excel processes on the system,
including user's personal work files. This is unacceptable for production testing.

Changes:
- Removed KillExcelProcesses() helper method that called Process.Kill() indiscriminately
- Removed all 3 calls to KillExcelProcesses from integration tests
- Marked 3 unreliable process-counting tests as Skip (they test Windows behavior, not our code)
- Tests now rely on baseline Excel process counting instead of forcing zero
- Pool disposal properly cleans up test instances

Why process-counting tests are unreliable:
- Excel process lifecycle is managed by Windows/Excel COM server, not our pool
- Excel may reuse processes internally for performance
- COM cleanup timing is unpredictable (2-5 seconds)
- Process counts don't correlate 1:1 with pool instances

Tests that matter (PoolMetrics):
- ✅ PoolMetrics_MultipleOperations_ShouldShowReuse - PASSING
- ✅ PoolMetrics_MultipleFiles_ShouldCreateMultipleInstances - PASSING

These validate actual pool behavior (reuse, hit tracking, instance management)
without making assumptions about Windows process management.

Prevention: Never kill ALL processes of any application in tests - this destroys user data.

* fix: Prevent ObjectDisposedException during pool disposal and cleanup Excel processes

CRITICAL FIX: Pool disposal was causing ObjectDisposedException when tests were still running.

Changes:
1. **ExcelInstancePool.cs**: Added disposed check in semaphore release finally block
   - Check _disposed flag before releasing semaphore
   - Wrap semaphore.Release() in try-catch for ObjectDisposedException
   - Prevents crash when pool is disposed during active operation

2. **ExcelPooledTestFixture.cs**: Proper disposal sequence
   - Set InstancePool = null first (prevents new operations)
   - Wait 100ms for in-flight operations to complete
   - Then dispose pool to clean up Excel instances

Root Cause:
- Global static InstancePool is used by ALL tests (not just pooled collection)
- Fixture disposal happened while non-pooled tests were still using the pool
- Semaphore.Release() in finally block threw ObjectDisposedException

Why This Works:
- Disabling pool first prevents new operations from starting
- 100ms delay allows current operations to finish
- Disposed check prevents semaphore release errors during cleanup
- Pool disposal now happens safely after operations complete

Test Results:
- ✅ ObjectDisposedException errors resolved
- ✅ Excel processes properly cleaned up (11 vs hundreds)
- ✅ PoolMetrics tests passing (2/2, 100%)

* fix: Add proper wait times for Excel COM process cleanup

Improved pool and fixture disposal to ensure Excel processes fully terminate.

Changes:
1. **ExcelInstancePool.Dispose()**: Added 500ms sleep after disposal
   - Excel COM processes take 2-5 seconds to fully terminate after Quit()
   - Wait ensures processes are cleaned up before test run completes

2. **ExcelPooledTestFixture.Dispose()**: Increased wait from 100ms to 500ms
   - Gives in-flight Excel operations more time to complete
   - Prevents premature pool disposal during active COM operations

Test Results:
- ✅ Before test: 0 Excel processes
- ✅ After test: 0 Excel processes
- ✅ No lingering Excel.exe instances

Prevention: Always include cleanup wait times when disposing Excel COM pools.

* Add comprehensive documentation and testing for Excel COM Interop and MCP Server

- Introduced `excel-com-interop.md` with essential patterns for Excel COM automation, including resource management, critical issues, and common mistakes.
- Added `mcp-server-guide.md` detailing the MCP server architecture, development use cases, tool implementation patterns, and best practices for AI-assisted Excel development.
- Created `testing-strategy.md` outlining a three-tier testing approach, including unit, integration, and round-trip tests, along with a strategy for on-demand tests.
- Implemented `ExcelPoolCleanupTests.cs` to verify proper cleanup of Excel processes after pool disposal, including tests for multiple instances, eviction, and stress scenarios.

* Refactor documentation and testing strategy for ExcelMcp

- Removed outdated testing strategy document.
- Added comprehensive architecture patterns guide for ExcelMcp development.
- Introduced critical rules for development to ensure quality and consistency.
- Established a detailed development workflow with branch protection and CI/CD guidelines.
- Created guidelines for Excel COM interop patterns to enhance reliability.
- Developed a thorough MCP server development guide for AI-assisted Excel workflows.
- Updated testing strategy to clarify test architecture, traits, and execution processes.

* fix: Improve CLI help command verification and error handling in build workflow

* Implement Excel COM instance pooling and management

- Added ExcelInstancePool class to manage a pool of Excel COM instances for efficient reuse.
- Introduced ExcelInstancePoolPolicy for defining object lifecycle management for pooled instances.
- Created ExcelPoolCapacityException to handle scenarios when the pool reaches maximum capacity.
- Developed ExcelSession static class to provide a simplified interface for executing actions with Excel workbooks using the pool.
- Implemented PooledExcelInstance class to encapsulate details of each pooled instance.
- Added unit tests for ConnectionHelpers and PowerQueryHelpers to ensure functionality and maintainability.

* refactor: Remove unused Excel pooling test fixtures and improve file cleanup logic in integration tests

* refactor: Update CodeQL configuration and improve Excel COM instance cleanup logic

* fix: Escape square brackets in CLI help text to prevent Spectre.Console parsing errors

* chore: Downgrade .NET version from 9.0 to 8.0 across all workflows, projects, and documentation

---------

Co-authored-by: Stefan Broenner <stefan.broenner@microsoft.comm>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sbroenne <3026464+sbroenne@users.noreply.github.com>
2025-10-24 16:51:41 +02:00

5.3 KiB

Security Policy

Supported Versions

We currently support the following versions of ExcelMcp with security updates:

Version Supported
1.x.x ✅

Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability in Sbroenne.ExcelMcp, please report it responsibly.

How to Report

  1. Do NOT create a public GitHub issue for security vulnerabilities
  2. Send an email to: stefan_broenner@yahoo.com
  3. Include the following information:
    • Description of the vulnerability
    • Steps to reproduce the issue
    • Potential impact
    • Suggested fix (if you have one)

What to Expect

  • We will acknowledge receipt of your vulnerability report within 48 hours
  • We will provide an estimated timeline for addressing the vulnerability within 1 week
  • We will notify you when the vulnerability has been fixed
  • We will credit you in the security advisory (if you wish)

Security Considerations

Enhanced Security Features (Latest Version)

ExcelMcp implements comprehensive security measures:

  • Input Validation: All file paths validated with length limits (32767 chars) and extension restrictions
  • File Size Limits: 1GB maximum file size to prevent DoS attacks
  • Path Security: Path.GetFullPath() prevents path traversal attacks
  • Resource Protection: Protection against memory exhaustion and process hanging
  • Code Analysis: Enhanced security rules enforced (CA2100, CA3003, CA3006, etc.)
  • Quality Enforcement: All warnings treated as errors for robust code

Excel COM Automation

ExcelMcp uses Excel COM automation with security safeguards:

  • Macro Execution: ExcelMcp can execute VBA macros when using script-run command
  • VBA Trust: VBA operations require "Trust access to the VBA project object model" to be manually enabled in Excel settings (one-time setup)
  • File Validation: Strict file extension validation (.xlsx, .xlsm, .xls only)
  • File Access: ExcelMcp requires read/write access to Excel files with size validation
  • Process Isolation: Each command runs in a separate process that terminates after completion
  • Excel Instance: Creates temporary Excel instances that are properly cleaned up
  • Input Sanitization: All arguments validated for length and content

Power Query Privacy Levels

ExcelMcp implements security-first privacy level handling:

  • Explicit Consent: Privacy levels must be specified explicitly via --privacy-level parameter or EXCEL_DEFAULT_PRIVACY_LEVEL environment variable
  • No Auto-Application: Privacy levels are never applied automatically without user consent
  • Privacy Detection: Analyzes existing queries to recommend appropriate privacy levels
  • Clear Guidance: Provides detailed explanations of privacy level implications
  • Security Options: Supports None, Private (most secure), Organizational, and Public levels

VBA Security Considerations

  • Macro Content: VBA scripts imported via script-import will be executed when called
  • Manual Trust Setup: VBA trust must be enabled manually through Excel's Trust Center settings (never modified automatically by ExcelMcp)
  • File Format: Only .xlsm files can contain and execute VBA code
  • Code Injection: Always validate VBA source files before importing
  • User Control: ExcelMcp never modifies registry settings or security configurations automatically

Best Practices for Users

  1. File Validation: Only run ExcelMcp on trusted Excel files
  2. VBA Source Control: Validate VBA code files before importing with script-import
  3. Network Files: Be cautious when processing files from network locations
  4. Permissions: Run ExcelMcp with minimal necessary permissions
  5. Backup: Always backup important Excel files before processing
  6. VBA Trust: Only enable VBA trust in Excel settings on systems where it's needed (manual one-time setup)
  7. Code Review: Review VBA scripts before execution, especially from external sources
  8. Privacy Levels: Choose appropriate Power Query privacy levels based on data sensitivity (Private for sensitive data, Organizational for internal data, Public for public APIs)
  9. Environment Variables: Use EXCEL_DEFAULT_PRIVACY_LEVEL environment variable for consistent automation security

Known Limitations

  • Windows Only: ExcelMcp only works on Windows with Excel installed
  • COM Dependencies: Relies on Excel COM objects which may have their own security considerations
  • File System Access: Requires appropriate file system permissions for Excel file access

Dependency Security

ExcelMcp has minimal dependencies to reduce attack surface:

  • .NET 8: Microsoft-maintained runtime with regular security updates
  • Spectre.Console: Well-maintained library for console output
  • No External APIs: No network connections or external service dependencies

Version Updates

  • Security patches will be released as soon as possible
  • Users are encouraged to keep ExcelMcp updated to the latest version
  • Breaking changes will be clearly documented in release notes

Contact

For security-related questions or concerns, please contact Stefan Broenner through GitHub issues (for non-sensitive matters) or the security reporting method outlined above.