Skip to main content

Security

The Ductape MCP server is designed for safe multi-tenant use in AI agent environments where credentials must not leak between users or sessions.

Stateless architecture​

The MCP server process:

  • Loads no SDK locally — all execution happens on the Ductape backend
  • Stores no database or filesystem state
  • Holds a single optional environment variable (DUCTAPE_PUBLISHABLE_KEY) scoped to one workspace

Each tool invocation is independent. Restarting the server loses nothing because there is nothing to lose.

Authentication​

Set DUCTAPE_PUBLISHABLE_KEY in the env block of your MCP client config. The server reads it at startup and uses it for every tool call automatically:

{
  "mcpServers": {
    "ductape": {
      "command": "npx",
      "args": ["-y", "@ductape/mcp"],
      "env": {
        "DUCTAPE_PUBLISHABLE_KEY": "pk_your_workspace_key"
      }
    }
  }
}

Per-call override​

Pass publishable_key as a tool argument to override the env var for that call. This is useful in multi-workspace setups where different calls target different workspaces:

{
  "publishable_key": "pk_other_workspace_key",
  "module": "databases",
  "method": "query",
  "params": [...]
}

If neither the env var nor a per-call key is present, the server returns:

Not authenticated. Set DUCTAPE_PUBLISHABLE_KEY in your MCP server env config, or pass publishable_key on every tool call.

The key is forwarded to the Ductape backend and validated there. The MCP server never caches or logs keys.

Config vs per-call keys​

Use the env config approach (DUCTAPE_PUBLISHABLE_KEY) for personal development — it is the simplest setup and means the AI client never needs to know or pass the key.

Use the per-call publishable_key argument when:

  • A single MCP server instance serves multiple users (each user supplies their own key)
  • You need to target different workspaces in the same session
  • You are building an agent orchestration layer that manages keys dynamically

For project-scoped config that is committed to a shared repo, avoid hardcoding the key. Either leave the env block out and pass keys per call, or reference a shell variable if your MCP client supports it.

Multi-tenant safety​

This architecture supports deployments where a single MCP server instance multiplexes connections (e.g. SSE-based MCP hosts):

User A → MCP Server → ductape_execute(publishable_key: A's key) → Proxy → User A's workspace
User B → MCP Server → ductape_execute(publishable_key: B's key) → Proxy → User B's workspace

Because keys travel with each request, there is no cross-tenant state in the server process.

Proxy allowlist​

Even with a valid publishable key, the backend proxy rejects:

  • Unknown module names
  • Method names not in the allowlist
  • Malformed parameter payloads

This limits blast radius if an agent hallucinates an invalid SDK call. See Modules & methods.

The allowlist is enforced server-side​

Key hygiene​

Treat your Publishable Key as a secret:

  • Do not commit keys to version control (keep project-scoped MCP configs key-free when shared in repos)
  • Rotate keys if exposed
  • Use environment-specific keys where possible (separate keys for dev and production workspaces)

Agent prompt considerations​

When using MCP with AI agents, be aware that:

  1. Agents may include keys in conversation context — the LLM sees tool arguments including publishable_key
  2. Tool results may contain sensitive data — database queries, secret metadata, session tokens
  3. Agents can call any allowed method — an agent with your publishable key can mutate platform state

Mitigations:

  • Use read-only exploration prompts when testing ("list databases" not "delete all records")
  • Scope keys to least-privilege workspaces for agent experimentation
  • Use separate workspaces for production vs development
  • Review agent tool calls in MCP client logs before approving sensitive operations (where your client supports approval gates)

Network security​

All backend communication uses HTTPS to https://api.ductape.app:

EndpointPurpose
/proxy/v1/sdk-proxy/executeSDK execution
/integrations/v1/payloads/generatePayload/snippet generation

The MCP server makes outbound HTTPS requests only. It does not listen on any network port.

Reporting issues​

If you discover a security issue with the MCP server or proxy allowlist, report it through your organization's security channel rather than filing a public issue with credential details.