Integrations That Don't Leak Authority

Ask a security team what worries them about an automation platform and the answer is rarely the automation. It is the integrations. Every connector is a doorway between your governed estate and a system outside it. In most platforms those doorways are propped open: an API token with broad scope in a config file, a webhook endpoint that accepts whatever arrives, a service account whose password has not rotated since the integration was built.

The industry calls this "integrating with everything" and sells it as breadth. We call it authority leakage. An integration surface should be judged by what happens to authority at every crossing. The number of logos it carries is a poor measure.

The two directions of leakage

Authority leaks in both directions, and each direction has its own failure mode.

Inbound, the question is who is really knocking. A webhook endpoint that executes whatever arrives has delegated production authority to anyone who can reach the URL or replay a captured request. The integration works until the day it becomes the attack surface.

Outbound, the question is what the connector holds. A standing credential with write access to your source control or your cloud account is waiting to be exfiltrated from a config file, a log line, an environment variable or a backup. The breach reports of the last decade are full of pivots that started there.

How OpsChain governs the crossing

OpsChain treats the integration boundary as a governance boundary. It gets the same treatment as every other one.

• Inbound events are signed and replay-protected. An event that cannot prove its origin, or that has been seen before, is refused before anything runs.
• Inbound events execute as named service accounts. An external system does not act as an ambient administrator. It acts as a specific, inspectable identity with path-based permissions, and everything it starts passes the approval policies bound to the paths it touches.
• Outbound credentials are just-in-time and scoped. When a run needs to act on an external system, the credential is issued for that run, scoped to what the run needs, masked in every log and never persisted. There is no standing token to steal.
• Connection secrets are write-only. The secret you store to establish a connection can be replaced but never read back, whether through the API, the UI or an administrator's session.
• Every crossing is audited. Inbound or outbound, each crossing lands in the same tamper-evident audit lane as every human action. When OpsChain writes a resolution back to an external system, it carries an evidence link to the governed record behind it, so the ticket and the proof cannot drift apart.

A deploy with no standing credential

This is what the model looks like on an ordinary Tuesday.

A platform team at a payments company deploys through GitHub. Their pipeline does not hold an OpsChain API key. There is nothing in the repository secrets to rotate, leak or audit. The workflow authenticates with its OIDC identity instead. GitHub attests cryptographically that this run is from this repository and this branch, and OpsChain federates that identity in. The deploy becomes a governed change on the production path, where the approval policy holds it, with a quorum of two and the submitter excluded, before a single step executes.

When OpsChain needs to act back on GitHub to post the deployment's attestation, it mints a just-in-time token scoped to that repository, uses it and lets it expire. The deployment ships with both sides of the crossing governed and neither side holding a long-lived secret. We run our own releases this way. Every release attests back into GitHub through the same connector we ship.

That evening, a monitoring alert fires on the same estate: disk pressure on a database node. The monitoring system is not integrated in the heavyweight sense. It posts to OpsChain's signed inbound webhook. The signature verifies, the replay check passes, and the event opens a governed remediation run as a named service account whose permissions cover that remediation and nothing else. The production path's policy decides whether a human must approve before the run proceeds. Any system the team runs could start a governed run the same way. Any system can come in, and no authority goes out.

What the platform does not claim

Integration pages are where vendors overclaim most freely, so two boundaries need stating.

• The surface is shipped. What OpsChain connects to today is listed on the platform page because it exists: ITSM, GitHub in both directions, SIEM streaming, secrets vaults, identity providers, notifications, brokered AI model providers, clouds and infrastructure, and the generic signed webhook. Every item on that list is delivered.
• Governed is not frictionless. An inbound event that cannot verify is refused. A run that reaches a governed path waits for its approvals. That friction is the control working. A platform that never says no at the boundary is not governing the boundary.

---

Key takeaway

Judge an integration surface by what happens to authority at each crossing. Inbound events are signed, replay-protected and executed as named service accounts. Outbound credentials are just-in-time, scoped, masked and never persisted. Every crossing is audited.

See the full shipped surface on the platform page, or book a demo and watch a signed event open a governed run live.