Skip to content
SignerSet

Multi-party approvals for exact actions

Never let agents act alone on consequential actions

Specify exact actions and parameters that require approval, and decide which combination of humans, agents, or deterministic software can approve them

No approvals required

Approvals required

delete_database

environment = development

delete_database

environment = production

outlook_move_message

Move to Archive

outlook_delete_message

Permanently delete

Different actions or parameters. Different authorization policy.

Protect Your WorkflowIntegrate SignerSet

The authorization gap

Permission to use a system is not approval for every action inside it.

Identity, permissions, sandboxes, and policy engines establish where an agent may operate. The consequential moment comes later: when a particular request, with particular parameters, is about to execute.

SignerSet adds that second decision point without taking away the agent's ability to handle routine work.

Existing controls ask

Does this identity have permission to use this system?

Consequential actions also require

Is this exact action authorized to execute right now?

How it works

Authorize the request, not just the identity.

A verifier sits before credentialed execution. It independently checks each signature and applies the policy to the exact action being proposed.

PROPOSERCreate the requestAgentSeparate user account/machineAPPROVERSReview and signHumanAgentDeterministic softwareSeparate user account/machineTRUST BOUNDARYVERIFIERSIGNATURES2 of 3the exact actionresultCREDENTIAL ACCOUNTCredentialsTOKENSeparate user account/machine

01

Propose the exact action

The agent submits the operation and its parameters without receiving the protected credential.

02

Collect the required approvals

Policy selects the authorized humans, independent agents, or deterministic checks required for this request.

03

Execute only what was approved

The verifier approves the request only when valid signatures from authorized signers satisfy the policy. The credential adapter then executes that exact request—nothing broader.

Designed against approval fatigueGovern the consequential edges of the workflow, not every step. Routine actions pass through; only selected actions require additional authorization.
COMMANDEXACT PARAMETERSIGNATURES REQUIREDRECORDEDdelete databaseenvironment = test1who, what, which policydelete databaseenvironment = production3who, what, which policyThe command is identical. Only the parameters differ — and the policy responds to the difference.

Choose your path

One control layer. Two ways to use it.

Use SignerSet directly with an autonomous workflow, or embed the same authorization boundary in a product or enterprise security stack.

For autonomous-agent operators

Protect an agent workflow

Require approval before an agent deletes data, exposes secrets, sends a message, spends money, or takes another irreversible action.

Get Started

For product and security teams

Integrate SignerSet

Embed exact-action authorization in your product or add it alongside PAM, IAM, policy engines, gateways, secrets management, and audit systems.

Integrations

Additive by design

Keep the security stack you trust.

PAM, IAM, secrets managers, gateways, sandboxes, policy engines, and monitoring each solve an important part of agent security. SignerSet adds an authorization filter before those systems release a credentialed action.

That makes adoption bounded: start with one consequential action, leave existing controls in place, and expand only after the integration has earned trust.

See the Integration Model
THE EXISTING SECURITY STACKsandboxespermissionspolicy enginesmonitoringWhere an agent may operate, what it may access, how it is observed.CONTINUOUS · AMBIENTSIGNERSET ADDS ONE MORE CONTROLAuthorization for the exact action,before it executes.2 of 3A SINGLE POINT IN TIME · PORTABLE · VERIFIABLESignerSet does not replace your stack. It gives it a common way to implement exact-action multi-party approvals.

The trust model

Clear guarantees. Clear boundaries.

What SignerSet enforces

  • Approval is bound to the exact action and parameters.
  • Policy determines which participants and how many signatures are required.
  • The verifier counts only valid signatures from authorized signers and approves the request only when the policy threshold is met.
  • Cryptographic receipts preserve what was approved, by whom, and under which policy.

What still depends on your design

  • Setting up independent trust domains for proposers, approvers, and credentials.
  • Ensuring your signer keys are securely protected and managed.
  • Giving your approvers access to the action's context to minimize reliance on the proposer.
  • Being deliberate about which approvers are required for each action—human, agent, and/or deterministic software.
This website was deployed through a SignerSet Slack workflow with an agent proposer, an independent agent reviewer, and a human approver.
Screenshot of the Slack conversation between Prosper, Marvin, and Alftom while building the SignerSet website with MPAS

Open protocol

Built for interoperability, not vendor dependency.

SignerSet contributed the core Multi-Party Action Security specification and protocol to OMA3 for incubation.

The goal is to reduce vendor dependency and create an open, interoperable standard across heterogeneous environments.

View MPAS on GitHub

Give agents room to act without letting one agent act alone.

Start with one consequential action that should require independent authorization before it executes.

Get StartedTalk to SignerSet