Security Overview
Last updated 2026-09-01
This overview is written for the people who have to sign off on deploying agent automation inside a studio or engineering organization. It describes the security model, the defaults, and what happens when something goes wrong.
1. Deployment model
The default architecture is local. The MCP server runs as a process on your machine next to the host application, and the agent connects over stdio. Nothing binds to a network interface unless you configure the HTTP transport.
When HTTP transport is enabled it binds to loopback by default, requires a bearer token, and can be restricted to a set of allowed client origins. Enterprise deployments can run entirely inside your network with no outbound connectivity.
2. Least privilege by default
A fresh install is read-only. Write and execute tools are denied until a policy grants them, and policies can be scoped by project path, tool name and file pattern. Deny rules always take precedence over allow rules.
- Read tools inspect state and never modify a file.
- Write tools run inside a checkpointed transaction.
- Execute tools run long jobs and return artifacts, with resource limits.
3. Reversibility
Destructive operations create a checkpoint before they run. Restores can be scoped to a single object or a full file, and the host application's own undo history is preserved so a human can intervene manually.
4. Credentials and secrets
Integration credentials are stored in the operating system keychain where available. Server tokens are hashed at rest, support rotation, and are never written to audit logs. We do not require you to share host application credentials with DCCMCP.
5. Audit logging
Every tool call is recorded with the tool name, arguments, actor, timestamp, host application version, result status and a file fingerprint. Entries are append-only locally and can be streamed to a webhook or SIEM under Enterprise.
6. Supply chain
Release artifacts are built from tagged sources in a controlled pipeline, signed, and published with checksums. Enterprise customers can receive a software bill of materials and mirrored, offline-installable packages.
7. Vulnerability handling
We triage reported vulnerabilities within two business days. Confirmed issues in a supported release receive a fix on a timeline matched to severity, and we credit reporters who wish to be named once a fix is available.
Report security issues to support@dccmcp.com. Please include reproduction steps and avoid accessing data that is not yours.
8. What we do not claim
We are not SOC 2 certified today. We are documenting controls against SOC 2 criteria and will publish the report when a completed audit exists. Any organization requiring current certification before a pilot should treat that as a blocker rather than assume a timeline.
This document is a plain-language baseline written for technical review and is not legal advice. Enterprise order forms, a DPA and negotiated terms take precedence where they apply. Questions: support@dccmcp.com.