Your engineers keep their coding assistants.
Reviewers get a traceable path from prompt to commit. For the agreed population, prompts and tool calls sent through Reign Gateway are checked and recorded. Code context stays within the agreed deployment boundary, and AI-assisted commits follow your existing review and release path.
Available today in infrastructure iTmethods operates or in your own AWS or Azure account. Both configurations are single-tenant. Google Cloud is planned for 2027. Air-gapped and sovereign deployment are supported.
The governed path from prompt to commit.
Published findings on adoption, dependencies and delivery stability.
Each finding retains its source, date and population.
| What is measured | Whose figure, and when | What it shows |
|---|---|---|
| 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. Report page. | Security controls at the point of recommendation address a measured dependency risk. |
| 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. | AI-assisted code is already widespread; deployment and recordkeeping are current operating decisions. |
| 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. | DORA associates AI adoption with higher throughput and continuing delivery-stability pressure. |
DORA reports these relationships directionally and publishes no coefficients, so a precise percentage for AI’s effect on stability is unsupported. These are external findings; they provide no iTmethods measurement or prediction about your estate.
What changes for engineers and reviewers.
Engineers keep the tools they already use. Reign Ops operates the boundary those tools work through.
| Tool | What your team gets |
|---|---|
| Cursor | Engineers keep the tool. Model calls route through Reign Gateway, where policy is checked and the call is recorded. |
| Claude Code | Code context remains within the agreed boundary. Routed through Reign Gateway for governed routing and prompt and tool guardrails, with the record written where the work happened. |
| GitHub Copilot | Activity joins one identity-bound record. Bound to your identity provider, with telemetry captured and feeding that record alongside everything else on this list. |
| Cortex | Reviewers can follow the change. Internal developer portal with governance hooks and identity binding; service catalogs and golden paths become objects to follow. |
| Docker | Production remains isolated. Ephemeral, governed developer sandboxes let engineers work with assistants on real code without touching production. |
| MCP-enabled IDEs | Unauthorized tool calls are refused and recorded. 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 also support autonomous agents. Reign applies different policy and oversight to human-assisted and autonomous action.
AI-assisted work follows your existing delivery path.
Single sign-on connects each action to the person and assistant that performed it.
Reign Gateway checks policy before the model sees code and records whether the call was allowed or refused.
Your existing review, approval and checks apply to every AI-assisted commit.
The record is written as the work happens and is ready when requested.
Framework requirements set out what each asks for. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed.
One record from prompt to tool call to commit.
Coding assistants need code context and tool access. Reign Gateway applies one policy across both paths for each assistant whose calls are routed through it.
You choose which autonomous work may run, and keep every merge and release decision.
Your team keeps code review, branch and release decisions.
The scope is agreed in writing before deployment.
| Actor | Responsibility |
|---|---|
| Reign Ops platform | Operates the governed path as a single-tenant dedicated instance inside your authorization boundary: Reign Gateway, the MCP gateway, developer sandboxes and the record. The assistants run where their vendors host them. Binds each assistant to your identity provider, routes the prompts and tool calls it sends through Reign Gateway, records each request, policy decision and result, and patches and operates those instances. |
| Your team | Selects the sanctioned assistants and teams, authors the gateway policy, and retains code review, branch and release policy. Your repositories, prompts and intellectual property remain yours. |
| iTmethods operating team | Onboards tools in stages, develops the initial gateway policy with your team, connects the record to your existing pipeline and periodically reviews what the assistants can reach. |
FAQ
Do our engineers have to change tools?
Does this slow down review?
Which deployment shapes can we have?
What does it cost?
Tell us which assistants your engineers use today.
We will return with a proposed operating scope and the responsibilities that stay with your team.