Skip to main content

MCP security & access model

LinkMe treats MCP as a strict adapter over the Edge REST API, not as a privileged backend.

Security invariant​

For any caller principal (session or app key):

Allowed(MCP) ⊆ Allowed(REST)

If a request would be forbidden over REST, it must also be forbidden via MCP.

What MCP is allowed to do​

  • Call only explicitly allowlisted public /api/* endpoints.
  • Use the same authentication context as the caller:
    • session/cookie context for portal users
    • app API key context for app-scoped automation
  • Enforce app scope and capability checks before forwarding requests.

What MCP is not allowed to do​

  • Access /internal/* endpoints.
  • Bypass auth, ownership, or tenant boundaries.
  • Use elevated service credentials to impersonate broader access.
  • Call undocumented/unallowlisted tools.

Access controls​

  • Tool allowlist: each MCP tool is pinned to one REST method and path template.
  • Auth mode restrictions: tools define whether session and/or app-key calls are accepted.
  • Capability checks:
    • read tools require read capability for app keys
    • write tools require write capability for app keys
  • App scope checks: app-key tools that target /api/apps/:id/* must match the key’s app_id.
  • Write gate: write tools are disabled by default and require MCP_WRITE_ENABLED=1.

Validation and parity testing​

LinkMe includes security tests that simulate natural-language asks and protocol calls, then verifies policy and REST parity:

  • question-to-tool security scenarios (deny escalation attempts)
  • MCP protocol tests (initialize, tools/list, tools/call)
  • MCP-vs-REST status parity for the same principal and target resources

These checks run locally in the E2E harness and are intended to be required in CI.

  1. Start in read-only MCP mode.
  2. Validate parity and tenant-isolation tests in CI.
  3. Enable write tools only after passing the full security suite.
  4. Keep audit logging and alerting on denied/suspicious calls.