The safest place for your network data
is where it already is.
An AIOps platform is trusted with more than most software ever sees: full topology, device configuration, live telemetry — and the ability to change the network. MatreComm’s answer to that is architectural.The reasoning happens inside your perimeter, on your hardware, because that is the only place it can happen without asking you to trust someone else’s.
This page sets out what that means concretely: where data lives, what the platform is permitted to change, what gets logged, and how to reach us about a vulnerability.
Read access to everything. Write access to the network.
Most security reviews of an operations platform focus on the wrong half. The read side is sensitive — but it is the write side that decides how much damage a mistake or a compromise can do.
What it reads
To diagnose a fault, the platform needs the whole picture: topology, device configuration, routing state, flows and live telemetry across every domain. That collection is a map of your critical infrastructure — more complete, in one place, than any single one of your existing tools holds.
What it can change
To close the loop, the platform acts back through NETCONF/YANG, gNMI and vendor APIs. An autonomous system with production write access is a genuine risk surface, and treating it as one is the difference between an operations platform and a liability with a fashionable name.
There is no vendor cloud to trust.
Ritam — the engine every MatreComm product runs on — deploys entirely inside your data centre. This is not a deployment option offered alongside a SaaS default; it is how the platform is built.
Inference runs locally
The reasoning core includes its own on-premises language model — an on-prem Qwen3 MoE LLM running on your hardware. No prompt, no telemetry and no configuration is sent to an external model provider, because there is no external model provider in the path.
No vendor-hosted control plane
The platform does not depend on reaching MatreComm to function. A system whose job is to repair the network should not need that same network to reach an external service in order to think — during an outage, that dependency fails exactly when it matters.
Air-gap capable
Deployments run fully disconnected where the environment requires it. This is what lets the platform operate in defense, government and critical-infrastructure estates where telemetry cannot cross the boundary under any circumstances.
Your data stays yours
Ingest, reasoning, action and audit all happen within your control across the full lifecycle. There is no telemetry pipeline to a vendor backend, so there is no retention policy of ours for you to audit — the data was never ours to retain.
Nothing surprising ever executes.
Autonomy describes how much of the diagnosis and planning work the platform does. It does not describe who holds authority — you do, and the controls below are what make that structural rather than a promise.
Propose
The platform names a root cause with its evidence chain and assembles the specific remediation — the actual change, not a runbook reference
Check
Every plan is validated for blast radius and policy compliance before it is eligible to run, and material changes are dry-run first
Approve
You define which action classes execute automatically and which require a human. Anything outside those limits waits
Verify & log
The result is verified against the goal it was meant to hold, and the action, its reasoning, the approval and the outcome are all recorded
Sovereignty by architecture, not by contract.
Most platforms meet a residency requirement with a regional deployment and a commitment about where data is processed. Both are real — and both are assurances you have to accept rather than facts you can verify from your own network.
For Indian obligations specifically: CERT-In requires logs of ICT systems to be maintained for a rolling 180 days within Indian jurisdiction. Because the platform’s evidence store sits inside your estate, that requirement is met by where it already runs. See the CERT-In 6-hour reporting guide for the full set of obligations.
Found something? Tell us directly.
If you believe you have found a security vulnerability in a MatreComm product or in this website, we want to hear about it before anyone else does.
Where to send it
Email info@matrecomm.comwith “Security” in the subject line, and it will be routed to the team that owns the affected component. Include the steps to reproduce, the version or environment you observed it in, and any impact you were able to establish.
What we ask
Give us a reasonable window to investigate and remediate before disclosing publicly, and please do not access, modify or exfiltrate data belonging to anyone else while testing. We will not pursue action against researchers who report in good faith and stay within those bounds.
Where certification currently stands.
A trust page that overstates its position is worse than one that says nothing, so this is stated plainly.
Security questionnaires, architecture review sessions and technical deep-dives with our engineering team are a normal part of evaluation — raise them early rather than late, and reach us at info@matrecomm.com or through contact.
Security as a product, not only a posture.
The same architecture that contains your operations data also underpins the products built specifically for security and compliance work.
CraftSecOps
SOC and NOC on one correlation graph, reasoning on-prem with full retention inside the estate.
Explore →CraftSASE
ZTNA, SWG, CASB and FWaaS on sovereign PoPs with an on-premises control plane.
Explore →CraftCompliance
Continuous control monitoring and automated evidence across Indian and global frameworks.
Explore →Ritam architecture
How the engine is built — the data plane, the on-prem core and the audit trail.
Explore →Frequently asked questions
Where is our network data processed and stored?
Entirely inside your own perimeter. Ritam and every product built on it deploy in your data centre, and that includes the reasoning core and its on-premises language model — an on-prem Qwen3 MoE LLM running on your hardware. Telemetry, topology, configuration and the audit trail all stay within your estate; there is no telemetry pipeline to a MatreComm backend and no external model provider in the path.
Does MatreComm have access to our network or our data?
No. There is no vendor-hosted control plane and no call-home requirement, so the platform functions with no connectivity to MatreComm at all — deployments run fully air-gapped where the environment requires it. Any access our engineers have during an engagement is access you grant explicitly and can withdraw.
What stops the platform from making a change that breaks something?
Every plan is validated for blast radius and policy compliance before it is eligible to run, and material changes are dry-run first. You define which action classes execute automatically and which require human approval; anything outside those limits waits. The action, the reasoning behind it, the approval and the verified outcome are all logged, and every root cause shows the evidence chain that produced it — so an approver is judging an argument they can inspect rather than an output they cannot.
Is MatreComm SOC 2 or ISO 27001 certified?
Not yet — certification of MatreComm's own corporate and development environment is underway, and we will tell you exactly where it stands if you ask. This is separate from CraftCompliance, which maps and monitors your control posture against SOC 2 Type II, ISO 27001 and Indian frameworks including CERT-In. A product that helps you evidence a framework is not the same as the vendor being certified against it.
How do we report a security vulnerability to MatreComm?
Email info@matrecomm.com with "Security" in the subject line, including steps to reproduce, the version or environment you observed it in, and any impact you established. We ask for a reasonable window to investigate and remediate before public disclosure, and we will not pursue action against researchers who report in good faith without accessing or altering other people's data.
How does on-premises deployment help with data residency obligations?
It makes residency a property of the design rather than a contractual term. Because data never leaves your estate, there is no cross-border transfer to authorise and no vendor sub-processor list that changes your compliance position when it changes. For CERT-In specifically, the requirement to hold 180 days of ICT logs within Indian jurisdiction is met by where the evidence store already runs.
Have your security team talk to ours.
An architecture review against your actual requirements — data boundaries, action authority, audit and residency — with the engineers who built it.