Virtual Signer

The io.sign Virtual Signer is a server-side signer for automated workflows. It holds a share for each vault it joins, evaluates operation requests with your policy engine, and participates in Multi-Party Computation (MPC) when the policy approves.

Like a Mobile Signer, a Virtual Signer never needs the complete private key. It collaborates with an eligible set of signers to create a signature once their combined weight meets or exceeds the vault threshold.

When to use a Virtual Signer

Use a Virtual Signer when signing participation must be continuously available or governed by machine-evaluated rules, for example:

• Restricting requests by vault, operation type, destination, asset, or amount.
• Integrating approvals with an existing risk, compliance, or transaction-policy service.
• Automating a signing path while retaining Mobile Signers for human-controlled alternatives.
• Distributing signing power across separate infrastructure or operational boundaries.

The policy decision controls whether this signer participates. The vault threshold still controls whether the complete signing set has enough combined weight.

Components

A Virtual Signer deployment contains two services:

• The Broker connects to io.sign, receives operation requests, invokes the configured policy engine, and persists the signer's encrypted state.
• MPC Core performs key generation, resharing, and signing operations. Keep its service endpoint private to the Broker and protect it with the deployment's confidential-computing controls.

Separate the services at the network boundary even when they run on the same host. The Broker needs only the connectivity required for io.sign, signer messaging, storage, and policy evaluation; MPC Core should not be exposed to application clients.

Policy engines

Virtual Signers directly support two production policy integrations:

• Open Policy Agent (OPA): evaluate version-controlled Rego policies with the supported OPA integration.
• Custom policy server: send the operation context to a customer-operated service and apply its decision.

Development environments can use a permissive mode to prove connectivity. Do not use an always-approve configuration for production signing power.

See Approval policies, Custom policy server, and Open Policy Agent for configuration, request formats, and failure behaviour.

Operation flow

1. io.sign makes a key-generation, resharing, or signing request available to the Virtual Signer.
2. The Broker sends the policy-relevant request context to OPA or the configured custom policy server.
3. If the policy approves, the Virtual Signer records its decision and makes its weight available to the operation.
4. When an eligible set of participating signers reaches the vault threshold, MPC Core joins the MPC operation.
5. The participating signers jointly produce the requested result without reconstructing the complete private key.

A rejection, abstention, policy timeout, or policy-system failure must not become an approval. Confirm exact retry and failure behavior for your release before assigning production weight.

Deployment choices

Virtual Signers can run in customer-controlled cloud or self-hosted infrastructure. Production requirements depend on the release and target platform, including supported confidential-computing hardware and encryption-at-rest configuration.

Start with these guides:

• Prerequisites for compute, network, credentials, and policy dependencies.
• AWS Architecture for the AWS confidential-computing topology.
• Self-Hosting for customer-operated infrastructure.
• Deployment for installation paths.
• Configuration for the current environment-variable reference.

Security boundary

The Virtual Signer's security depends on more than its container image. Treat all of these as one recovery and trust boundary:

• Persistent signer state and its backups.
• The keys or confidential-computing service used to encrypt that state.
• Broker and MPC Core runtime integrity.
• Network access to internal service endpoints.
• The policy engine, policy source, and policy deployment process.

Losing required state or encryption material can make the signer unrecoverable. Compromising the policy engine can cause the signer to participate in requests your organisation did not intend to approve.

Next steps

1. Review Prerequisites.
2. Choose an architecture and storage/encryption approach before first registration.
3. Deploy the services using the relevant Deployment guide.
4. Configure and test the policy engine before adding production signing weight.