Security Policy & Architecture

1. Security Architecture & Threat Model

DynamicsSuite is engineered from the ground up to operate safely in regulated enterprise and government environments. Unlike traditional desktop toolboxes that require administrator rights, installation of machine-wide DLLs, or external cloud proxies, DynamicsSuite maintains a strict Zero Trust, Local-First architecture:

2. Identity & Token Lifecycle Management

Authentication in DynamicsSuite is strictly centralized and decoupled from individual plugins:

• Microsoft Authentication Library (MSAL): Authentication is handled natively using Microsoft's official MSAL library via interactive browser login or device code flow.
• In-Memory Token Cache: Bearer access tokens reside exclusively in volatile application memory (RAM) within the active Python session. Tokens are never written to disk, SQLite databases, or unencrypted local caches.
• Plugin Isolation: Individual plugins are passed an encapsulated AppContext. Plugins never have access to raw refresh tokens, sign-in credentials, or user passwords. They can only request an in-memory bearer token scoped to the target Dataverse environment URL.
• Automatic Session Invalidation: When you stop the local application or restart the browser, session tokens are immediately purged from memory.

3. Local-Only Execution & Data Privacy

DynamicsSuite operates solely as a local application bound to your local network loopback interface:

The web portal (bigscene.uk/DynamicsSuite) serves only as a static catalog and documentation site. The software executable itself runs purely on your workstation.

4. AI-Directed Development & Open Source Collaboration

In the spirit of complete transparency, DynamicsSuite is developed collaboratively using state-of-the-art Generative AI:

• Human-Directed Vision & Rigorous Testing: The creator and lead architect (Mo) defines every architectural boundary, data contract, user experience workflow, and conducts thorough end-to-end testing against real-world Microsoft Dynamics 365 and Dataverse instances.
• AI-Accelerated Code Synthesis: AI tools accelerate rapid iteration, boilerplate generation, and AST-based linting.
• Community & Peer Review: Because of this hybrid approach, we embrace open source peer review. All code is published publicly at github.com/BigSceneUK/DynamcisSuite under the BSD 3-Clause License. We warmly welcome consultants, developers, and security researchers to inspect, audit, test, and contribute improvements.

5. Recommended Best Practices for Enterprise Production

When deploying DynamicsSuite within enterprise environments or customer tenants, we strongly advise following these security best practices:

1. Register Your Own Microsoft Entra ID App Registration

For production workloads, avoid using default or shared client IDs. Set up your organization's own App Registration in Microsoft Entra ID:

1. Navigate to Microsoft Entra admin center (https://entra.microsoft.com)
2. Go to Identity > Applications > App registrations > + New registration
3. Set Supported account types: "Accounts in this organizational directory only" (Single Tenant)
4. Set Redirect URI: Platform = "Mobile and desktop applications", Redirect URI = "http://localhost"
5. Under API permissions, grant:
   - Dynamics CRM > user_impersonation (Delegated)
   - (Optional) Microsoft Graph > User.Read (Delegated)
6. Configure the Client ID in DynamicsSuite's config.py or environment variable MSAL_CLIENT_ID

2. Enforce Least Privilege & Conditional Access

DynamicsSuite operates under the identity of the signed-in user. It inherits whatever Dataverse security roles (System Customizer, System Administrator, or custom business roles) the user holds. We recommend:

• Applying Conditional Access policies (e.g. Compliant Device, MFA) to your Entra ID tenant.
• Granting users only the minimum required Dataverse security roles needed to perform their administrative tasks.

6. Plugin Integrity & Checksum Verification

To protect against tampering or unverified code injection:

• Cryptographic Hashes (SHA-256): Every plugin published in the official catalog feed includes a deterministic SHA-256 hash. You can verify archive integrity before installation.
• AI Code Review Prior to Installation: We encourage security teams to review the pure Python source files inside any plugins/<plugin_id>/ directory using automated static analysis or LLM security reviewers before enabling in production environments.
• No Compiled Binaries: All plugins are written in clean, human-readable Python. There are no opaque C++ DLLs or compiled machine executables.

7. Responsible Vulnerability Disclosure

If you discover any security vulnerability, improper credential handling, token persistence bug, or data integrity issue in DynamicsSuite, please report it responsibly:

Please include steps to reproduce, sample proof of concept, and environment details. We are committed to patching validated security vulnerabilities swiftly and providing credit to responsible reporters.