Polycore control plane
Stores governance and product state: organizations, projects, environments,
runner registrations, capability metadata, requests, approvals, audit
records, and dashboard pages. It does not hold runner execution credentials
or direct provider tokens.
Hosted integration executor
A separate private service stores supported shared SaaS grants encrypted
with KMS-backed envelope encryption. It has fixed provider hosts, typed
operations, bounded results, least-privilege service IAM, and no public
ingress.
Your infrastructure
Runs the Polycore runner with network access to your selected systems. The
runner resolves execution credentials locally, exposes a reviewed capability
catalog, and performs signed work dispatched by the control plane.
System topology
“Outbound-only” describes the runner’s control and execution path. A hosting
platform can probe a credential-free health endpoint that accepts no
dispatches; the GCP preset restricts it to Google Cloud health probes. The
Polycore control plane remains public because Slack, browsers, MCP clients,
and runners must reach it. The important boundaries are that the public
control plane does not hold runner credentials or direct provider tokens, and
the private executor is isolated from the public web and runner listener.
Hosted integrations are limited to the providers and operations Polycore
explicitly implements.
The four architectural roles
1. Front doors
Slack, MCP clients, and admin dashboards initiate requests. They never
receive the datastore credential. Each interface carries caller and project
context into the same control-plane path.
2. Control plane
Authenticates the caller, resolves the project and environment, selects a
connected runner, evaluates the capability hazard, creates approvals, and
records the request lifecycle.
3. Hosted integration executor
Runs typed, read-only provider adapters for project-wide shared SaaS
connections. It decrypts credentials only inside the isolated executor and
returns bounded results through the control plane gateway.
4. Runner
Advertises the capabilities available for one project and environment,
verifies signed dispatches, resolves local credentials, executes the
selected capability, and returns a structured result.
5. Downstream systems
Your database, API, or service enforces its own IAM and network boundary.
Polycore adds a governed invocation path; it does not replace the downstream
system’s access controls.
Request lifecycle
1
Identify and route
The control plane resolves the organization, project, caller, and requested
capability. Runner capabilities resolve to an exact environment.
Project-wide direct capabilities bypass environment routing and resolve to
their bound hosted connection.
2
Apply the policy gate
Your access policy decides the path: invocations it clears may dispatch
immediately, while invocations it holds require an approval record. Direct
web actions from an authenticated owner or admin may record that decision
inline, while other interfaces wait. Delegated code has
unknown hazard and
always remains pending for review.3
Sign or invoke privately
Runner capabilities use a signed envelope over the runner’s existing
WebSocket. Hosted direct capabilities use an authenticated private RPC to
the isolated executor. Neither path exposes the credential to the caller.
4
Verify and execute
The runner verifies the signature, validates the input schema, resolves only
the secrets declared for the capability, and performs the operation.
5
Return and record
The result returns over the same connection. The control plane records the
user-facing request, governed invocation, timing, outcome, and any approval
decision.
Runner connection and enrollment
The runner is a long-running outbound worker, not an inbound API server.Outbound network
The runner opens and maintains a WebSocket to the control plane. Your
firewall does not need to expose a public runner port.
Enrollment identity
Polycore provisions a runner id, join token, and signing secret for one
project and environment. They authenticate enrollment and dispatches, not
access to your downstream systems.
Self-healing connection
Heartbeats detect a dead connection. The runner reconnects with bounded
backoff and advertises its current catalog again.
Deployment topology
A runner belongs to exactly one Polycore project and one environment. Separate production and staging runners keep credentials, network reach, and failure domains isolated. The control plane routes an invocation to the runner enrolled for the selected environment. The runner does not accept an arbitrary environment argument and switch credentials at runtime.What crosses the boundary
From the runner to the control plane
From the runner to the control plane
Enrollment identity, project slug, capability names and JSON schemas, hazard
metadata, optional agent context, connection health, structured results, and
execution errors.
From the control plane to the runner
From the control plane to the runner
Signed invocation envelopes containing the capability name and validated
arguments, plus connection heartbeat messages.
What stays in your infrastructure
What stays in your infrastructure
Database passwords, service-account authority, API keys, local secret
values, and direct network access to private systems.
What stays in the hosted executor
What stays in the hosted executor
Shared direct-integration grants remain encrypted in the private executor’s
secret store. The public control plane stores only safe grant metadata and
an opaque credential id. Provider tokens never reach callers, prompts,
schemas, audit records, or dashboard responses.
Continue reading
The runner
See how configuration, runtime identity, capabilities, and secrets fit
together.
Security
Review credential custody, least privilege, trust boundaries, and failure
assumptions.
Capabilities
Understand query and action kinds, hazard classes, and the catalog.