§00Enterprise
AI speed.
Enterprise control.
PartnerMCP proposes. Your policies decide. Every change is classified, proven in a sandbox, approved by the people you choose and recorded, and nothing reaches production outside a versioned release.
PartnerMCP · auto-fix
Retry 6 orders that hit HTTP 429
class: retry
Policypre-approvedSandboxnot neededApprovalautoProductionappliedApplied on its own
logged
PartnerMCP · proposed fix
Map the field Salesforce just made required
class: mapping
Policyneeds approvalSandbox13 / 13Approvalowner approvedProductionv1.5Live as v1.5
logged
Asked in chat
“Just give it access to everything in Priority.”
class: scope
Policynever automaticSandboxApprovalProductionRefused
only an admin changes scopes
Same gates, three answers. Every request, decision and refusal lands in the audit log, including the ones that never reached production.
On this page
PartnerMCP proposes. Your policies decide.
Every change, whether PartnerMCP proposes it or someone asks for it, is classified before anything happens. The class decides what it takes: nothing, a sandbox proof and an approval, two approvers, or a refusal.
Operational
Retries on HTTP 429 and 5xx · backoff · holding a record · resuming a batch
Applies on its ownInside the limits you set. Every action is logged and reported.
Logic
A new mapping · a transformation · a validation step · a condition
Sandbox proof + ownerThe integration owner approves the exact diff that was tested.
Reach
A new system, object or write operation
Sandbox proof + owner + securityTwo people, because what the integration can touch is changing.
Out of bounds
Wider credentials or scopes · deleting records · anything outside a versioned release
Never automaticNo policy can pre-approve these. Scopes change only when an admin changes the system's API user.
Defaults shown. Admins can make any class stricter; nothing in “Out of bounds” can be made automatic.
- Approvals bind to a diff
- An approval covers the exact change that was tested. If the diff changes, it needs approving again.
- Separation of duties
- The person who asks for a production change isn't the one who approves it. Your policy can require more.
- Every decision is recorded
- Requests, classifications, approvals, refusals, deployments and rollbacks, with who or what initiated each.
Sandbox first. Production on approval.
Each integration runs in separate environments against separate systems. A version reaches production only through the promotion gate, and the previous one stays a step away.
Sandbox
- Salesforce
- sandbox org
- Priority
- test company
- Credentials
- sandbox API users
v1.5 candidate
Promotion gate
- 13 / 13 sandbox tests
- Diff reviewed: 1 mapping added
- Approved by the integration owner
promoted · change #231
Production live
- Salesforce
- production org
- Priority
- production company
- Credentials
- production API users
- Separate credentials
- Sandbox and production use different API users, so a sandbox run can't write to production.
- Promotion is reviewed
- Passing tests, a reviewed diff and an approval, for every version that reaches production.
- Rollback is recorded too
- The previous version is kept. Switching back is one step, and it's logged like any change.
Systems behind your firewall stay there.
The Edge Agent is a small agent you run inside your network, next to the ERP. It connects out to PartnerMCP over standard HTTPS, so your ERP never needs a public endpoint or an inbound firewall rule. You choose exactly which systems and operations it can reach; the credentials for those systems stay in your network. Every request it relays is logged.
Architecture concept · illustrative
Design goals
- Outbound-only connections on port 443
- A per-agent identity, with mutual TLS
- An explicit allowlist of systems and operations
- Local, encrypted storage for system credentials
- A local audit log of every relayed request
- Two agents per site, for availability
- Support for corporate HTTP proxies
- Revocation from the PartnerMCP console
Know where every kind of data lives.
Residency is a set of controls, not a line on a slide: what stays in your systems, what passes through PartnerMCP, what it keeps, and for how long.
Stays in your systems
systems of record
- Your records
- Salesforce, Priority and the rest remain the systems of record.
- Unmapped fields
- Fields the spec doesn't map are never requested.
- On-prem credentials
- With the Edge Agent, they stay on its host in your network.
Passes through PartnerMCP
in flight, then gone
- Records in flight
- Only the fields the spec maps, for as long as delivery takes.
- Held records
- Kept until a person releases or fixes them.
- Retries
- Kept until they succeed or land in the review queue.
Kept by PartnerMCP
what operating it requires
- Specs and versions
- Every version, diff, test result and approval.
- Audit log
- Who or what changed what, and when.
- Run traces
- Identifiers, status and timings. Record contents only if you turn capture on.
How PartnerMCP is designed. What runs for your workspace, and where, is confirmed with you before anything connects.
- Processing location
- Set per workspace. Your residency requirements are part of the architecture review, before anything connects.
- Retention windows
- Configurable per kind of data: traces, held records, audit history.
- Field minimisation
- The spec is the boundary. PartnerMCP reads and moves the fields it maps, and nothing else.
- Encryption
- In transit and at rest, as a baseline of the design rather than an option.
Three ways to reach a system.
For each system, PartnerMCP and your team choose the safest path that works with your network. One integration can use all three.
Cloud systems
Direct, over the vendor's API
- Fits
- Salesforce, HubSpot, NetSuite, Priority Cloud and other cloud applications.
- Trade-off
- Each vendor's own authentication, limits and API policy apply. PartnerMCP works inside them.
Architecture concept
Through the Edge Agent
- Fits
- Systems on your network that shouldn't get a public endpoint, such as an on-prem Priority installation.
- Trade-off
- No inbound rule. Outbound allow-listing is still needed, and a TLS-inspecting proxy may need an exception.
What you already run
Through your own gateway
- Fits
- When your network team already publishes APIs through a gateway, reverse proxy, VPN or private link.
- Trade-off
- You keep the controls you already operate. PartnerMCP authenticates like any other client.
How a security review with PartnerMCP works.
Bring your security team. We go through the architecture, the data flows and the controls against your requirements, item by item.
- 01
Architecture
Control plane, data plane, Edge Agent: what runs where, and what talks to what.
- 02
Data flows
For each integration, the systems, objects and fields it touches, and what is kept, where and for how long.
- 03
Identity and access
Single sign-on, roles, separation of duties and who can approve which change.
- 04
Credentials
The least-privilege users you create in each system, where secrets live, how they rotate and how they're revoked.
- 05
Change control
Change classes, environments, approvals and rollback, set against your own policy.
- 06
Network
Outbound-only connectivity, the allowlist, egress rules and TLS inspection.
- 07
AI boundaries
What PartnerMCP's reasoning can see, and what it can never do on its own.
- 08
Logging and audit
What is recorded for every change and every production run, and who can see it.
- 09
Incidents and disclosure
How an issue reaches us, and how we would tell you about one that affects you.
Built to work with your integrator.
Integrators can build with PartnerMCP too. It drafts the mappings, the tests and the monitoring; their experts make the decisions — and hand over integrations their clients can read and change.
Integrator · with PartnerMCP
Discovers, plans, maps and tests in the client's workspace.
Client · approver
Reviews the diff and the tests, and approves what reaches production.
Client · owner
Keeps the specs, versions and audit trail after the engagement ends.
- Less plumbing per project
- Discovery, mapping, tests and deployment run in PartnerMCP. The integrator reviews and decides.
- Expertise where it matters
- Process design, data ownership and edge cases, rather than another round of plumbing.
- The client stays in control
- Approvals, environments and the audit trail live in the client's workspace.
§08Next step
Talk to an engineer.
Bring your systems, your constraints and your security questions. We'll go through the architecture with you.