Is this a sales call?
It is a working session about your situation. Where we are not the right people we say so, and say who might be.
Book a briefing · Reign Gateway
Discuss one AI traffic path.
One traffic path to start. We will look at how your agents and applications reach models today, what one boundary would change, and what the record would let a reviewer follow afterwards. iTmethods operates the boundary as a single-tenant instance, on Reign Dedicated or in your own AWS or Azure account, to your change control.
- A plain answer on fit, including when we are not the right people.
- What we would look at first: your AI traffic.
- A working session on your situation, not a product demo.
The first engagement is scoped together rather than handed over.
- Two decades operating regulated & SDLC platforms
- SOC 2 Type II on Reign Ops
- Dedicated and single-tenant
- FINOS member
After you send it
Three steps, and the first is a person.
A person reads it
Not a rule that files it under a topic. A question about how a platform is operated is answered by the people who operate it.
We reply within one business day
To propose a time, or to say we are not the right people and who might be. You can decline.
A 30-minute working session
One AI traffic path and the policy around it. Nothing is booked, bought or committed until you decide.
What to bring
One traffic path, and the person who owns the policy.
One path that already carries model calls, and the constraints that would have to hold around it.
Why one path rather than all of them
A boundary is stood up on one traffic path before it is widened, and coverage grows as you point more traffic at it.
Starting narrow is not caution, it is how the policy gets written by people who have seen what it has to allow. A boundary designed against every path at once is designed against none of them.
01Calls you cannot reconstruct
An application or an agent reaches a model, and afterwards nobody can say what was asked, what came back, or which rules applied.
This is the most common shape and the easiest to scope, because the gap is already known to somebody.
AskWho would have to answer if a regulator asked what an agent did last quarter?
02Agents somebody else built
Your own engineers have built agents, or a vendor has, and each one reaches models its own way.
The boundary is useful whoever built the agent, and one set of rules covers all of them.
AskHow many different ways does model traffic leave your environment today?
03A policy that exists only in a document
There is a written rule about what may be sent to a model, and nothing enforces it at the point the call is made.
Bring the document. The gap between what it says and what the boundary can hold is the whole first conversation.
AskWhich rule would you most want enforced rather than asserted?
Readiness
What has to be true before we start.
Four conditions, and the fourth is the one most often missing. If an item cannot be met, we would rather find out now than design around a gap.
1
One traffic path we can start with
An application or an agent that already reaches a model, and that somebody would notice if it stopped. Real traffic, not a test harness.
2
Your identity provider, key service and storage target
The boundary wires into what you already run. We do not ask you to adopt ours, and the records land in storage you own.
3
Someone who owns the policy
One person who can say what may be sent, what may not, and who decides when that changes. The policy is written with them, not handed to them.
4
A change-control path we can work to
iTmethods operates the boundary, which only works if we are told how change is approved on your side. That path is agreed before anything carries traffic.
What stays as it is. Your applications, your platform and the way they are written stay as they are. The boundary sits on the path the calls already take.
What you get back
A boundary standing on one path, and the record it produces.
A policy and a record on one path, and a written view of whether to widen it.
At the end
What exists that did not before
On one path, in your environment
A policy that is enforced rather than written down. Agreed with the person who owns it, applied at the point the call is made.
A record a reviewer can follow. For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time it happened.
A written view of what widening would take. Which paths would come next, what each would need, and which ones we would leave alone.
Stated up front
The boundaries of this engagement
The limits, in the same voice as the offer
Coverage is what you point at it. Calls that do not take the path are outside the record, and the record says so rather than implying completeness.
The first engagement. It is designed as a partnership: the scope, the measures and the escalation path are written down together.
SOC 2 Type II. Reign Ops holds a SOC 2 Type II attestation, and the report is available under non-disclosure. Reign Gateway runs on the same infrastructure, team and processes, and the SOC 2 Type II scope is being updated to include it.
Next step
Start with one path.
Tell us which application or agent reaches a model, who owns the policy behind it, and what you would want a reviewer to be able to follow afterwards.
Before you write
Questions people have first.
What should I bring?
One traffic path that already carries model calls, and the person who owns the policy behind it.
Who will I speak to?
The people who operate and build Reign, not a booking queue.