Security model

An integration engineer with access to your ERP, CRM and payment systems has to be held to a higher standard than a script. PartnerMCP's security model rests on four ideas: least privilege everywhere, determinism at runtime, people approving what matters, and a record of everything.

Identity and access#

• People sign in through your identity provider, and roles decide who can view, build, approve or administer integrations.
• Connections use a dedicated service account per system, with only the permissions the integration needs.
• Scope is enforced, not assumed. Some APIs are broader than their user interfaces. Priority's REST API applies field-level permissions but not the row-level data privileges that restrict users in the UI, so PartnerMCP limits each integration to the forms and operations in its spec and expects a dedicated, least-privilege API user.

scope:                            # what this integration may touch — nothing else  priority:    user: api-salesforce-sync       # dedicated, least-privilege API user    forms: [CUSTOMERS, ORDERS, DOCUMENTS_D, AINVOICES]    operations: [read, create, update]   # no delete  salesforce:    objects: [Account, Opportunity, OpportunityLineItem]mcp:  tools: pinned                     # definition hash recorded at approval  writes: require-approval

Secrets#

Credentials live in a secrets vault — or, for systems behind your firewall, on the Edge Agent's host — and are never written into specs, prompts or logs. Prefer revocable, per-integration tokens: Priority's personal access tokens, for example, are issued per user and can be revoked one at a time.

Intelligence at design time, determinism at runtime#

The reasoning that plans and repairs integrations is not the thing that runs them. Production executes approved specs. PartnerMCP's proposals — a new mapping, a validation step — are tested in a sandbox and wait for the approvals your policy requires. Only the change classes you pre-approve are applied automatically, and those are reported. See Change management.

Protections specific to MCP#

Connecting to MCP servers brings its own risks: tool descriptions that carry hidden instructions (tool poisoning), servers that change a tool after it was approved (a “rug pull”), and tools whose descriptions change how other tools are used (shadowing). PartnerMCP is designed to:

• pin and hash approved tool definitions, and alert on any change;
• allow tools per integration, never a whole server by default;
• require human approval for writes and destructive operations, whatever a tool's annotations claim;
• never pass a token through to a server it wasn't issued for;
• log every tool call; and
• connect only to servers in your private registry of approved servers.

Data handling#

Encryption in transit and at rest is a baseline of the design. PartnerMCP keeps what operating an integration requires — run history, record identifiers, error details — and minimises the payloads it stores. Where data is processed is a configurable control; residency requirements are part of the architecture review.

Traceability#

Every request, plan, mapping decision, test run, approval, deployment and production run is recorded with who or what initiated it. When something happens to a record, the history shows which version of which integration did it, and why.

Reporting a vulnerability#

If you believe you've found a security issue, tell us through the contact form. Include enough detail to reproduce it, and give us reasonable time to fix it before disclosing it publicly.