Edge Agent

Many ERPs, databases and line-of-business applications run inside private networks, and they should stay there. Publishing a system to the internet so a cloud service can reach it — a reverse proxy, an inbound firewall rule — adds attack surface just to support an integration. The Edge Agent is designed to avoid that.

How it works#

The Edge Agent is a small agent you run inside your network, next to the systems it serves. 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.

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.

An allowlist, not a tunnel to everything#

The agent reaches only what it is told to reach. An illustrative configuration for an on-prem Priority installation and a warehouse database:

agent: plant-01reach:  - system: priority    endpoint: https://erp.internal/odata/Priority/tabula.ini/acme    allow:      - read CUSTOMERS      - write CUSTOMERS, ORDERS      - read DOCUMENTS_D, AINVOICES  - system: warehouse-db    endpoint: sqlserver://wms.internal:1433    allow: [read]credentials: local              # never leave this hostaudit: local + console

Priority's REST service is part of its application server, so on-prem the agent calls it on your LAN — the same OData API a cloud tenant exposes, with nothing to publish.

Identity and revocation#

Each agent receives its own identity when it is registered, so one site can be revoked without touching another. Which protocols an agent relays at your site — HTTP APIs, database connections, file shares — is settled in the architecture review and named explicitly in its allowlist; anything not named is refused.

What your network team still does#

Outbound-only does not mean no network work at all:

• Allow outbound HTTPS from the agent's host to PartnerMCP, usually by hostname.
• Exempt the agent's connection from TLS inspection if your proxy decrypts traffic — the same exception other outbound connectors need.
• Run the agent on a dedicated, hardened host, and run two for availability.

The honest trade-off#

An outbound connection is still a path into your network. Its safety depends on a tight allowlist, a strong agent identity and the authorization checks on the PartnerMCP side — which is why the agent's scope is explicit and every relayed request is logged. Treat the host as security-critical, the way SAP's guidance treats its own Cloud Connector.

A proven pattern#

Outbound-only connectors are how enterprise platforms already reach private systems. SAP's Cloud Connector, Microsoft's on-premises data gateway and the on-prem agents of integration platforms all open the connection from inside the network and need no inbound ports. Priority's own Gateway reaches Priority Connect services the same way: outbound HTTPS from the server, with no access opened into it. The Edge Agent follows that pattern.