Every tool an agent can reach, and the proof of what it did.
MCP servers, tool registries, third-party integrations and in-house tool servers, operated as one governed supply chain. Policy is evaluated before an agent binds a tool, and every binding is recorded.
Delivered as a single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today. Air-gapped and sovereign are in development.
Every model that can call a tool is a new way into your systems.
MCP is spreading through the enterprise faster than anyone is governing it. Most organizations cannot say which agents are calling which tools, with whose permissions, against which data.
As MCP becomes the default way models act on the world, that operational control is what separates a useful agent from an ungoverned one.
Treating it as a supply chain rather than a feature is what makes signature, provenance and drift detection obvious rather than optional.
Afterwards is a description of what happened. Before is a control.
That is the part Reign Ops takes. Your engineers keep the tools and the agents.
Seven capabilities, one governance contract.
The full tool-operations surface, and the same contract whether the server is one of ours, a third party's, or one your team wrote.
| Capability | What it means in operation |
|---|---|
| MCP server hosting | Managed runtime with policy enforcement applied at the call boundary, operated inside your authorization boundary. |
| Tool inventory and registry | Every tool an agent can bind, with its version, owner, classification and risk tier. The inventory is the thing most estates do not have. |
| Third-party integrations | Vetted and sandboxed onboarding with supply-chain review before anything is bindable. |
| In-house tool servers | First-party tools under the same governance contract as third-party. No private route around it. |
| Supply-chain controls | Software bill of materials, signature and provenance checks, and drift detection across the catalog. |
| Tool-call governance | Policy evaluated before an agent binds. Every binding logged, including the ones that were refused. |
| Lifecycle operations | Deprecation, rotation and incident isolation across the tool surface, so removing a tool is an operation rather than an archaeology project. |
The systems agents actually ask for.
| Category | Servers we operate |
|---|---|
| Engineering | Atlassian GitHub GitLab Jenkins JFrog Artifactory SonarQube |
| Data | PostgreSQL MySQL MongoDB Redis |
| Cloud | AWS Azure GCP |
| Communication | Slack Microsoft Teams |
| Yours | Internal systems Custom MCP servers Proprietary APIs |
Not seeing your system? Custom MCP servers for internal or third-party systems are part of the same contract. Tell us what it is →
Hardened before anything can bind to it.
Applied at deployment rather than negotiated per server, and the same for a server we host as for one you wrote.
Bound to an identity from your provider. There is no anonymous tool call and no shared service account standing in for one.
What a server can reach is set before it is bindable, rather than inferred later from what it reached.
Bill of materials, signature and provenance checked on the way in, and drift detected across the catalog afterwards.
A binding that policy declined is as much a part of the record as one it allowed, and it is usually the more interesting half.
Attestation status and the standard pack for procurement are released on request under non-disclosure rather than asserted here. Security and trust → · Regulatory alignment →
Operating the tool layer is one job. Governing what crosses it is another.
Reign Ops runs the servers, the registry and the supply chain. Reign Gateway is what sits on the call path and applies the policy. The two were designed to meet at the tool boundary, and the record is written once rather than assembled from both.
What we run, what you run.
Written down before anything is deployed, so the boundary is a document rather than a discovery.
| Who | What they hold |
|---|---|
| Reign Ops, automated | Operate the MCP servers, the registry and the supply-chain controls inside your authorization boundary. Authenticate and scope every call. Sandbox at the tool-call boundary. Check signature and provenance on the way in and detect drift after. Record every binding and every refusal. Handle deprecation, rotation and incident isolation. |
| Customer authored | Which tools are sanctioned and which agents may bind them. The classification of the data each tool reaches. Risk tier and owner for each entry in the registry. What a policy exception means and who may grant one. |
| Operating partner engagement | Onboarding servers in scoped waves rather than all at once. Supply-chain review on third-party servers before they are bindable. Authoring the first policy set with your team. The periodic review of the catalog, including what should be removed. |
The questions that arrive every time.
Can you run a server we wrote ourselves?
How long does it take to get a server running?
What happens when a tool has to be pulled?
Which deployment shapes can we have?
What does it cost?
Tell us what your agents are already reaching.
Which tools, which agents, and whether anyone can currently say which is calling which. We will come back with what we would take on first and what we would leave alone.