GitHub Copilot

GitHub and Copilot already provide important controls over access: which users, agents, repositories, plugins, MCP servers, credentials, and tools are available. Ratify is complementary. It gives the system that owns the consequence evidence of the narrower mandate behind one action.

The practical distinction is simple:

This matters when:

• a coding agent holds credentials broader than the current task;
• production actions need stronger evidence than a prompt or approval click;
• an MCP or SaaS provider receives calls from agents it did not issue;
• customer, vendor, or partner agents cross an organizational boundary; or
• security and audit teams need to answer who authorized what, for which agent, resource, operation, and time window.

The outcome is not “more cryptography.” The outcome is that enterprises can permit more agent automation while the receiver retains a precise, auditable, fail-closed decision boundary.

The included principal delegates only:

scope       custom:github:deploy
repository  identities-ai/copilot-authority-demo
path        /services/payments/environments/staging

Copilot sees one ordinary MCP tool named deploy_service. The model never receives the signing key and never constructs the Ratify proof.

The receiver—not the prompt, skill, model, or adapter—is the enforcement boundary. A caller cannot reach the protected handler by skipping Ratify proof presentation.

Four roles, and only two of them write anything. GitHub implements nothing. The plugin uses the existing plugin manifest and MCP mechanisms, so no change to Copilot, GitHub, or any Microsoft surface is required for this to work.

The receiver number is worth being precise about, because the verification call on its own is not an integration. The surrounding work is where a receiver operator spends their effort, and most of it is deciding what this deployment trusts rather than writing protocol code.

The asymmetry is the point. The party that carries the risk is the party that gets to check, and they can check without trusting the agent, the model, the prompt, or the platform that routed the call.

Seven deterministic tests pass with zero failures and zero skips. The plugin was also installed directly from this public GitHub repository and exercised through Copilot CLI against the independent receiver.

Open source

Use the open reference and SDK when you want inspectable protocol semantics, local evaluation, customization, or full operational ownership. The proof format and receiver decision remain portable. This repository is the immediate starting point.

Do not deploy the reference unchanged to production. Its keys are public test material, its state is in memory, its receiver uses local HTTP, and its handler is intentionally a counter.

Ratify Verify

Ratify Verify is the managed commercial path under development. It is intended for organizations that want Ratify to operate the verification control plane:

• tenant-specific trust roots and organization connections;
• durable atomic challenges and replay protection;
• fresh revocation and policy decisions;
• signed verification receipts and audit retention; and
• production availability, observability, and support.

If that matches your deployment, contact partners@ratifyprotocol.com with “Ratify Verify design partner” in the subject. Useful context includes the agent runtime, protected action, receiving system, organizational boundary, and compliance or audit requirement. This is the current lead and design-partner path; Ratify Verify is not yet offered here as a generally available service.