Skip to main content
Polycore integrations are collaborative. We work with your engineering and security teams to choose an initial workflow, define the authority it needs, prepare your runner, and verify the governed path end to end.
Polycore is in early access and is not self-serve. These docs show the technical shape so you can evaluate the system before we start. You will not be expected to assemble the integration alone.

​
What we build together

The first integration is intentionally narrow. It should prove the full operating model without asking you to move an entire internal-tools estate at once.

A useful read

A real question against production data through a constrained capability your policy clears to answer instantly. Examples include a count, an account lookup, or an operational summary.

A governed change

A representative change through a typed action. Polycore holds the request, a human approves or denies it, and the runner executes only after approval.
That pair validates credentials, routing, grounding, policy, approval, failure handling, and audit attribution.

​
Who does what

Your team

You choose the workflow, approve the trust and IAM design, create scoped access in your cloud or datastore, review the integration code, and own the deployed runner.

Polycore

We map the capability design, prepare your runner, provision the control-plane side, pair the runner, configure the initial interfaces, and validate the complete flow with you.
Your production credentials are created and stored on your side. Polycore does not ask you to paste them into our cloud or send them to us.

​
The path to production

1

1. Scope the first workflow

We start from an operation, not a connector checklist. Together we identify:
  • The people or agents that need access.
  • The system and environment they need to reach.
  • One high-value read.
  • One write whose approval behavior is representative.
  • The result shape and audit evidence your team needs.
This keeps the first catalog small enough to review while exercising the important trust boundaries.
2

2. Design least-privilege access

We map each capability to the narrowest authority the downstream system can enforce.
A read-only role or read replica backs generic queries. Actions that change state use separate credentials with only the grants they require.
Read and write authority stay separate whenever the platform supports it.
3

3. Prepare your runner

We create or update runner code in a repository your team controls. Its typical shape is:
polycore-runner
polycore.json
Dockerfile
package.json
Structural configuration and standing actions are reviewed as code. Deploy configuration supplies runtime identity and secret bindings.
4

4. Deploy the runner in your infrastructure

The runner is deployed near the systems it calls. It needs:
  • Outbound network access to the Polycore control plane.
  • Network access to the selected datastore or APIs.
  • Access to the specific secrets or workload identity it will use.
  • An enrollment identity provisioned for one Polycore project and environment.
The runner opens the control-plane connection itself. No inbound route to the runner is required.
5

5. Connect the interfaces

We expose the same governed catalog through the interfaces in scope:
  • Slack for conversational requests and approval cards.
  • MCP for coding agents and other MCP clients.
  • Admin dashboards for purpose-built human workflows.
A capability is governed by the same access policy and recorded with the same audit behavior whichever interface calls it.
6

6. Validate and hand off

We test the production path together:
  1. A permitted read succeeds and returns a bounded result.
  2. A prohibited read or missing permission fails clearly.
  3. A write creates an approval request and does not execute early.
  4. Approval releases the exact pending invocation.
  5. Denial leaves the downstream system unchanged.
  6. The request, invocation, result, and decision appear in the audit trail.
We then document ownership, deployment changes, secret rotation, and the process for adding future capabilities.

​
What we need from your team

You do not need every answer before the first conversation. The following details let us form a concrete design quickly:
Which production system should be connected first? Where does it run? Which environment should the first runner serve? Can an outbound worker reach both the Polycore control plane and that system?
Which cloud identity, database role, or API credential model is available? Which secret manager or workload identity mechanism should the runner use?
Name one real read and one governed change. Include the expected input, output, limits, and who should be able to request or approve them.
Which repository should hold the runner? Who reviews changes? Which CI or infrastructure workflow deploys long-running workers in your environment?

​
How the integration grows

After the first path is stable, expansion is incremental:

Add data sources

Connect another datastore or API with its own least-privilege identity.

Add actions

Review and deploy another typed operation from the same runner repository.

Add interfaces

Reuse the governed catalog in more agent and human workflows.
Ready to discuss a first workflow? Request early access and tell us which system you want to connect.