Keep critical operations under your control.

Let services and AI agents work across your systems within clear boundaries. Decide what they can change, when they need approval, and how authorization is verified.

Talk to us Explore attack scenarios

What if…

Can a compromised CI pipeline publish?

An attacker controls a build job and submits a release under your package name.You keep release approval outside CI.Case and policy

Let your pipeline build and request releases. Choose who must approve a package before it can be published under your name.

Require independent approvals for the exact package and artifact you want to release. Keep publishing credentials with a service that verifies your signed command, so taking over a build job isn’t enough to publish.

Decide who can release

policy "release-publishing" {
    allow when {
        request.operation == "publish"
        request.registry == "pypi"
        request.package == "acme-agent"
    }

    require 2 of [operations, security]
}

A service requests its own CA certificate?

An automated enrollment request asks for CA privileges instead of a service certificate.You can keep CA privileges out of service enrollment.Case and policy

Issue service certificates automatically while keeping the right to create new certificate authorities under separate control.

Limit automated issuance to the common names your services need. Keep CA privileges off for that path, with server-auth and digital-signature requirements for every certificate.

Limit certificate issuance

authority "service-certificates" {
    intent = "x509.tbs-certificate"
    version = "1"

    policy "service-certificates" {
        allow when {
            version == 3
            subject.commonName == "billing-api.internal"
            extensions.basicConstraints.present
            not extensions.basicConstraints.cA
            extensions.keyUsage.digitalSignature
            extensions.extKeyUsage.serverAuth
        }
    }
}

One breached signing server exposes your key?

An attacker takes over a signing peer and steals the key material on that host.Losing one peer doesn’t hand over your key.Case and policy

Distribute signing across peers you administer independently. Choose how many must participate before your key can sign.

Keep one compromised host from gaining signing power on its own. Other peers still enforce the permissions and approvals you require.

Protect your signing authority

Compromised peer
The attacker obtains one share. In threshold mode, that share can’t produce a signature by itself.
The attacker requests a signature
Other peers independently check the assigned authority and required approvals.
Not enough peers participate
Without enough participating peers, the protected command has no valid signature.

Security Model

Authorize the exact production change.

Decide which services your pipeline can deploy and who must approve production changes. Each approval covers the release you actually chose.

Read the technical guide

Authority and approvalsproduction-changes.edict

authority "production-changes" {
    intent = "custom"
    version = "1"

    input request {
        operation: Text
        service: Text
        environment: Text
        release: Text
    }

    approver operations {
        type = "public-key"
        id = "operations"
        algorithm = "ED25519"
        publicKey64 = "T9U4X0BiYmULPIhbIU8/Xs/qNOhY516SF35rDUevc+w="
    }

    approver security {
        type = "public-key"
        id = "security"
        algorithm = "ED25519"
        publicKey64 = "OJWc78OkW6qIFUImSlFPd2Ni/idNHZq6GawrqnKiacg="
    }

    policy "production-changes" {
        allow when {
            request.operation == "deploy"
            request.service == "billing-api"
            request.environment in ["staging", "production"]
        }

        require 2 of [operations, security] if (request.environment == "production")
    }
}

Certificate policy examples

See how to constrain automated service certificate issuance.

X.509 CertificatesCertificate subjects, usage, and CA restrictions.

Choose what your services can change.

Let services handle routine work and ask for approval before critical changes. Decide which operations, targets, and parameters each identity may use.

Read the technical guide

Keep critical authority distributed.

Distribute your signing keys across independent peers and choose how many must participate. Keep control of your service identities when one host is compromised.

How MPC works

Explore the details.

Machine authentication and authorization Human approval for critical actions Machine action integration Human approval controls Security assurance Source on GitHub

Have a workflow in mind?

Talk to us about it