Trust & Security

Trust Is Architectural

Opscotch is designed to execute inside customer-controlled infrastructure without introducing hidden control planes, implicit permissions, or opaque dependencies.

Trust is enforced through explicit execution boundaries, cryptographic verification, deterministic runtime behavior, and locally validated commercial enforcement.

This page outlines the architectural guarantees that make distributed automation safe, verifiable, and governable.

Core Trust Guarantees

Explicit Execution Boundaries

Workflows operate strictly within customer-defined runtime policy.

• Outbound HTTP hosts must be explicitly declared.
• Runtime resources must be explicitly granted.
• No ambient network access exists.
• No implicit filesystem access exists.
• No undeclared cross-deployment access is permitted.

If a host or resource is not declared in bootstrap configuration, it cannot be accessed.

There are no hidden backchannels.

No Mandatory Control Plane

Opscotch does not require a vendor-hosted SaaS control layer.

The runtime performs:

• Artifact validation locally.
• License validation locally.
• Trust chain verification locally.

Opscotch can operate:

• On-prem
• In private cloud
• In restricted networks
• In air-gapped environments

Connectivity requirements are defined by the customer.

Cryptographic Artifact Verification

Workflow artifacts are signed and verified before execution.

• Artifact signatures are validated locally.
• Trusted signing keys are explicitly configured.
• Invalid or untrusted artifacts are rejected.
• Artifacts are immutable once signed.

Integrity is enforced before activation.

Scoped Trust Domains

Trust can be segmented and version-scoped.

• Signing authority can be restricted to version ranges.
• Separate keys can publish separate release streams.
• Unauthorized version streams are rejected at load time.
• Trust anchors are configurable per deployment.
• Trust domains can be isolated per environment.

This enables controlled upgrade paths and blast-radius containment in case of key compromise.

Runtime-Enforced Licensing

Commercial enforcement is inseparable from execution.

• Licenses are cryptographically validated locally.
• Signature integrity is verified.
• Expiry and validity are evaluated deterministically.
• No mandatory outbound validation is required.

Commercial context travels with the artifact.

Note: Certain licensing categories may require connectivity. This is explicitly communicated before use.

Deterministic and Bounded Execution

Workflows cannot escalate their own privileges.

Execution is constrained by:

• Explicit customer-side configuration
• Declared host access
• Controlled runtime capability surface

Workflows cannot:

• Discover new network hosts implicitly
• Access undeclared resources
• Modify trust anchors
• Extend runtime capabilities dynamically

There are no external runtime dependencies (no dynamic package resolution, no hidden extensions).

Runtime behavior is deterministic and bounded.

Data Stays Inside Customer Infrastructure

Opscotch executes within customer-defined boundaries.

• No data passes through vendor infrastructure.
• No mandatory telemetry is transmitted externally.
• No automatic data relay to vendor systems occurs.

Any outbound communication must be explicitly declared.

Frequently Asked Questions

What happens if a signing key is compromised?

Deployments are recommended to maintain multiple signing keys.

Signing authority can be scoped to version ranges.

Keys can be rotated without invalidating unrelated release streams.

Trust domains are not global by default, limiting blast radius.

Who ultimately controls execution?

The customer.

Execution boundaries, trust anchors, and deployment targets are defined customer-side.

Opscotch does not assume authority.
It enforces what is configured.