ProductsReign Gateway

Every model call passes one boundary.

Reign Gateway sits between your agents and the models they call. Policy decides what is allowed. Routing decides which model answers. A record says what was authorized, and why. iTmethods operates the boundary inside your environment, to your change control.

Available today Talk about the call layer Deployment options → Regulatory alignment →

In production at iTmethods, on the deployment we run ourselves. Own-cloud is available today, in your own AWS or Azure account; Google Cloud is planned for 2027. Air-gapped and sovereign are in development.

The boundary every call

The endpoint, the policy and the record all sit inside your environment. What leaves is the call you permitted.

From a call to a record

One endpoint in front. One record underneath.

Your applications and agents call one endpoint. What comes back is the answer; what stays behind is the evidence.

Reign Gateway · one endpoint, operated for you

Upstream and your estate · unchanged

One endpoint

Applications and agents call the boundary rather than a model directly.

Identity

Who is calling, and on whose behalf.

Budget and guard rails

Your limits, your content rules, applied before the provider call.

Translation

To whatever format the provider expects.

Model providers and MCP tool servers

The upstream your policy permits, and nothing else.

The answer

Back to the agent that asked.

Your observability

A copy of the telemetry to the platform you already run.

Refused, and recorded with its reason Outside policy · over budget · the boundary cannot establish that the call is permitted

The call does not proceed. Nothing passes on the assumption that it was probably fine.

Policy changes take effect without a restart. A change of routing is a change of policy and goes through the same review as any other.

Every call on this path becomes a record inside your own deployment — permitted and refused alike.

Revoking a key takes effect across the fleet rather than expiring.

Policy and authorization

What is allowed at the boundary, and who decides.

The policy is yours. We operate the boundary that applies it. We do not hold an opinion about what your organization permits.

01Your policy, not ours

iTmethods carries no default position on what your data may touch.

Rules are written by your security and engineering functions and held in your instance. You can also bring your own policy service rather than being made to use ours.

02A decision at every call

Permitted calls proceed. Calls outside policy are refused, and the refusal is recorded with its reason.

Each call is checked before it reaches a model. The refusal is as much a record as the answer.

03Scope you can name

A rule applies where it is meant to and nowhere else.

Policy can be set by team, by repository, by environment and by class of data.

04Change control

The instance records which version of policy was in force when a call was decided.

Changes are requested, reviewed, versioned and dated, and take effect without a restart.

Model routing

Which model answers, and on what basis.

Routing is a policy decision rather than a preference. You set the basis, and you can change it.

A basis you set

Route by task, by sensitivity of the data, by environment, or by a ceiling you have agreed internally. The rule is explicit and readable.

What should never leave a named environment?

The choice stays with you

Model selection is yours to change.

Who approves a change of model today?

One place to change it

Agents call the boundary rather than a model directly. Changing which model answers does not mean editing every agent that asks.

How many places would you edit today?

Monitoring and records

A record of what was authorized, and why.

For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time it happened. Records read in sequence and are written for people who were not in the room. Following one does not require access to the agent that made the call.

What holds the record together

Records are hash-linked into a Merkle tree as they are written, and exported to write-once storage in your own account. The chain is ours to write. The storage is yours, under your retention and your Object Lock, which is the part that means you are not asked to take our word for it. We do not claim more than that: nothing is signed with your key today, and checking that each stored record still holds its original content is a separate mechanism that is not in the product.

Documented cryptographic check on the audit log

Of 27 AI gateway products reviewed against vendor documentation, 19–20 August 2026.

Any check at all

1 of 27 — administrative events only

Covers the request and response payloads

0 of 27

Checks the stored content itself

0 of 27 — 4 not examined

Audit integrity was checked across almost the full set, so these zeros mean something. The one product that documents a check uses a shared secret, which anyone able to verify can also use to sign, and its archived copy cannot be checked through the product.

Who operates the gateway

Every product surveyed puts the customer in one of two positions. There is no third.

You run it yourself

16 of 27 — open source or licensed, on your staff and your pager

Traffic leaves for a vendor service

6 of 27 — prompts and responses leave your environment

Operated for you, inside your environment

0 of 27 — all 27 examined

Which is the opportunity. No surveyed product operates the gateway inside the customer’s environment, which is why the first engagement is designed as a partnership rather than a handover. What that means in practice →

Read the denominator. Counts are from a review of 27 AI gateway products across 21 capabilities, taken from vendor documentation retrieved 19 and 20 August 2026. Every number is out of the same 27, and a capability was counted whether the vendor documented it fully or partly. Where the number of products not examined for a capability is high, a low count reflects incomplete research rather than a rare capability, so the counts above are limited to rows checked across almost the whole set. Reign's own status is from an engineering reading of the repository, and built means implemented, tested and deployed in our own environment.

Failure mode and change control

What happens when it cannot decide.

This is the unglamorous part, and it is the part that matters. Behavior under failure is defined in advance and written down — including where the behavior is that there is none yet.

One call, decided every call

A call is permitted, refused, or unanswered. There is no fourth outcome, and all three are written down.

When policy cannot resolve, the call does not proceed.

If the boundary cannot establish that a call is permitted, it is refused and the refusal is recorded with its reason.

When a model does not answer, the call fails.

It is recorded as failed. It does not fall back to a model your policy has not permitted, because it does not fall back at all. Automatic failover across permitted models is not built. It is one of the three named below.

Budgets refuse before the provider call, one request late.

Minute, hour and day limits are enforced in the data plane. The request that crosses a limit is priced after it returns, so the next one is the one refused. Weekly and monthly budgets can be configured but are not enforced there.

Policy changes are versioned, and the record says which applied.

Changes are requested, reviewed, versioned and dated. The instance records which version of policy was in force when a call was decided.

A refusal is a reportable outcome, not a failure to be hidden. The same is true of the gaps. Where something is not built, this page says so in the present tense rather than describing it as though it were.

Where it sits

The boundary is useful whoever built the agent.

Reign Factory runs through this boundary. So can the agents your own engineers have already built.

Reign Factory, the build motion, is in beta and being productized. The model calls it makes pass the same boundary and are recorded the same way.
Agents your teams wrote point at the boundary instead of at a model. Policy, routing and records then apply without rewriting how those agents work.
Reign Ops operates the toolchain underneath. The boundary is one more thing run inside your environment, to your change control.

One set of rules covers both. A reviewer does not have to learn two stories to follow what happened.

How it would be delivered

Set up with you. Run for you.

Every product in this category asks you to choose between running the gateway yourself and sending your traffic somewhere else. We think there is a third option, and we would like to build it with you.

1

First, with your team

A named engineer sets the policy with your team and wires the boundary into your identity provider, your key service and your storage target. One traffic path to start.

2

Then, run for you

iTmethods operates your environment and keeps it tuned as traffic changes. Attestation status for the managed service is released on request under non-disclosure rather than asserted here.

3

As your estate changes

Policy changes take effect without a restart. Revoking a key takes effect across the fleet. Coverage widens as you point more traffic at it, and records age on the retention you set.

4

And as the product ships

Reign ships on a regular release train. Because iTmethods operates your environment, taking a release is our work rather than a project on your roadmap.

The first engagement is a design partnership, not a handover. iTmethods has operated commercial and open-source software inside customer environments for twenty-one years. This operating model is new to the category — no product surveyed offers it — so the scope, the measures and the escalation path are written down together before anything carries traffic, and the boundary is stood up on one traffic path before it is widened.

Which applications route through it, what the policies say, and which systems it uses stay yours. Designing those decisions with you is the engagement, not an afterthought to it.