The coding assistants your developers already use, with the prompts staying inside.
Each tool operated as a single-tenant dedicated instance, bound to your identity provider, with every prompt and tool call routed through the governed gateway and recorded — and every AI-assisted commit entering the same pipeline as every other commit.
Delivered as a single-tenant dedicated instance, never as a shared-tenancy service, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today. Google Cloud is planned for 2027. Air-gapped and sovereign are in development.
The productivity case is settled. The governance case is not.
AI coding assistants went from individual experiments to default tooling faster than anyone put controls around them. Four things are true of the SaaS versions, and each is a separate problem.
That is not a configuration mistake. It is how the SaaS form works, and it is the reason the deployment shape is the decision.
By the time it is committed, the provenance question has become an archaeology question.
The check has to happen at the call, which is why this page and the tool layer are the same argument. MCP and tool operations →
Reconstructing it is expensive and produces an answer nobody fully trusts. The alternative is capturing it at the time.
The adoption is not a forecast. It already happened.
Three findings, each somebody else’s, named with its date and its population. The first is the governance gap with a number under it. The third is the one that cuts both ways, and it is on the page for that reason.
| What is measured | Whose figure, and when | Why it is on this page |
|---|---|---|
| 80% of AI-suggested dependencies carry risk — only one in five is clean. Between 44% and 49% of the dependencies imported by coding agents contained known vulnerabilities. Security tooling in the loop lifts safe recommendations from around 20% to 57%. | Endor Labs, State of Dependency Management 2025, 4 November 2025. More than 10,000 GitHub repositories. | This is the governance gap, measured. It is also the argument for governing at the call layer rather than per vendor: the last clause says a check in the path changes the outcome. |
| More than half of all code is now AI-generated, up from 34% one quarter earlier. Median pull request sizes nearly doubled over the same period. | DX, The State of AI Impact in Engineering, Q2 2026, 22 July 2026. More than 500 organizations. | Nobody is deciding whether to adopt this. The decision in front of you is what the deployment shape is, and how much of it is recorded. |
| 90% of respondents use AI at work. In 2025 the relationship between AI adoption and software delivery throughput turned positive — and the negative relationship with delivery stability persisted. | Google / DORA, 2025 State of AI-assisted Software Development, 23 September 2025. Around 5,000 technology professionals. | The productivity case really is settled, and this page says so in its own heading. What did not follow is measurable, and DORA measured it. |
DORA publishes those relationships directionally rather than as coefficients, so the row above describes the finding rather than quantifying it. Any source quoting a precise percentage for AI’s effect on stability from the 2025 report is inventing it. None of the three figures is an iTmethods measurement, and none of them is a prediction about your estate.
The same tools. A different deployment shape.
Nothing here asks your engineers to change tools. Each one is deployed and operated as a single-tenant dedicated instance, never as a shared-tenancy service.
| Tool | How Reign Ops operates it |
|---|---|
| Cursor | Deployed as a single-tenant dedicated instance with model routing through the governed gateway. Prompts and repository context do not leave it. |
| Claude Code | Operated with governed routing and prompt and tool guardrails, with the record written where the work happened. |
| GitHub Copilot | Operated with identity binding and telemetry capture, feeding the same record as everything else on this list. |
| Cortex | Internal developer portal with governance hooks and identity binding. Service catalogs and golden paths become objects a reviewer can follow. |
| Docker | The substrate for ephemeral, governed developer sandboxes, so engineers can iterate with assistants on real code without exposing production systems. |
| MCP-enabled IDEs | Governed at the MCP gateway with registration, allow-listing and per-call policy. An IDE that can call tools is governed like anything else that can. |
The same tools appear in agent runtime operations when an autonomous agent is at the keyboard rather than a person. The boundary between the two pages is human-in-the-loop versus autonomous action.
AI-assisted work gets no separate path.
That sentence is the whole design. Everything below follows from refusing to build a second route for commits an assistant helped write.
Single sign-on at the editor, so the person and the assistant are both identifiable rather than sharing a license key.
Policy-checked at the boundary before the model sees the code, and recorded whether it was allowed or refused.
The same review, the same approval, the same checks as every other commit. There is no route around it for AI-assisted work.
Written where the work happened rather than reconstructed later, which is the only version of this that survives being asked about.
What each framework asks for, and the limits on what any supplier can tell you about your own position, is set out on regulatory alignment. iTmethods makes no compliance, certification or accreditation claim under any of them.
Reign Ops operates the tools. Reign governs what crosses the boundary.
An assistant is useful because it can see the code and call tools. Those are the same two reasons it needs a boundary. Reign Gateway sits on both paths, which is why one policy covers every assistant on the list rather than one policy per vendor.
Same governance. A different thing at the keyboard.
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 each tool as a single-tenant dedicated instance inside your authorization boundary. Bind the IDE to your identity provider. Route every prompt and tool call through the governed gateway. Record what was asked, what applied and what came back. Patch and operate the instances. |
| Customer authored | Which assistants are sanctioned and for which teams. What the policy at the boundary says. Code review, branch and release policy, unchanged. Your repositories, your prompts, your intellectual property. |
| Operating partner engagement | Onboarding tool by tool rather than all at once. Standing up the initial gateway policy with your team. Wiring the record into the pipeline you already run. The periodic review of what the assistants are actually reaching. |
The questions that arrive every time.
Do our engineers have to change tools?
Does this slow down review?
What is the difference between this and agent runtime operations?
Which deployment shapes can we have?
What does it cost?
Tell us which assistants your engineers already run.
Which tools, roughly how many engineers, and whether anyone can currently say what leaves the envelope. We will come back with what we would operate and what we would leave alone.