AIOps platform · private beta
The AI proposes. An engineer approves. Your gateway executes.
Vesmona turns the monitoring tickets you already have into evidence-backed remediation proposals. Every change passes a policy gate and a human approval, then runs as an allowlisted job on a gateway you operate — our control plane holds zero standing credentials to your infrastructure.
no agents required on day one · early access — run it against your real incidents
- standing credentials in the control plane — no keys, tokens, or shells to your hosts
- 0
- engineer approval on every change, no exceptions in v1
- 1
- independent enforcement layers: our policy gate, then your gateway's own allowlist
- 2
- of execution happens inside your boundary, on a gateway you operate
- 100%
Why it pays
Cut the cost of incidents — not the team that handles them
Every incident bills you twice: once for the downtime, and once for the senior hours it takes to reach a decision. The platform attacks the second bill. It does the legwork — investigation, correlation, documentation, and the re-solving of already-solved problems — so your engineers' hours go where they earn the most: the decision, and the engineering that was waiting behind the queue.
Investigations arrive pre-assembled
The expensive part of an incident is rarely the fix — it's the hours of evidence-gathering before anyone can decide anything. Here, diagnostics run when the ticket arrives. Your engineer starts at the decision, with the evidence attached.
Repeat incidents stop costing full price
When an approved fix verifies, it can be promoted to a vetted, parameterized runbook keyed to that incident's signature. The next occurrence arrives as a pre-vetted proposal — the unit cost of a repeat incident falls, and reliance on the model shrinks with it.
Absorb growth without growing the on-call rota
More hosts and more alerts don't have to mean proportionally more interruptions. The platform absorbs triage volume; your people absorb decisions. And on-call that doesn't burn people out is a retention line, too — attrition and re-hiring are operating costs.
the dark cells are your engineer's hours — with every promoted runbook, they converge on the decision itself
The pipeline
From ticket to verified fix — one auditable path
Four stages. The model's output is treated as untrusted data at every one of them, and the last stage is the only one that touches your systems.
- 01
A ticket arrives
Your monitoring stack files the incident it already files today. The platform consumes the signal you have — no new agents on day one.
runs · control plane - 02
The AI investigates and proposes
Read-only diagnostics gather evidence through your gateway. The model returns a proposal with confidence and the evidence attached — and it is allowed to say “I don't know.”
runs · control plane - 03
Policy gates, a human approves
Every proposal passes an auditable policy gate, then lands with an engineer. Nothing the model writes can reach execution on its own.
runs · control plane + your engineer - 04
A deterministic workflow executes
The approved action — an allowlisted operation, never a free-form command — runs via your gateway, signed both directions, and reports back with a verification pass.
runs · your boundary
stages 01–03 never touch your hosts · stage 04 crosses the boundary — signed, expiring, re-validated against your allowlist
Where this sits
The third position: execution with structural containment
The category has settled into two patterns — and both leave the hard question open: who holds the keys, and what bounds a mistake?
category pattern · the read-only assistant
Stops at the diagnosis
Investigates, correlates, writes a solid summary — then hands back. The fix itself is still yours to type, at whatever hour the pager went off.
category pattern · the autonomy dial
Trades containment for speed
Executes with its own credentials, governed by a threshold. Safety becomes a setting — and a setting can be misconfigured. The blast radius is whatever those credentials reach.
this platform
Executes — inside limits it cannot exceed
Model output is data, never commands, and the policy gate sits on the only path to execution. What executes runs on a gateway you operate, against an allowlist you publish, with zero standing credentials in our control plane. A signed job from our own control plane is still refused if it isn't on your list.
In production that path defaults to an engineer's approval — in v1, on every change.
The platform
Two lanes. One gateway. Your terms.
Operational incidents and security findings are different problems, and the platform refuses to blur them. Both ride the same credential-less gateway — but only the ops lane is ever eligible for anything beyond a human decision.
Lane 01 · Ops — monitor & remediate
Agentless-first monitoring
- Day one: the platform consumes tickets from the monitoring you already run. Nothing to roll out across the fleet before the first proposal lands.
- Tier 1, the default — bounded sampling: the gateway connects over SSH, runs a short eBPF/perf sample against a learned baseline, and leaves nothing resident on the host.
- Tier 3, opt-in — resident sensor: a Falco/Tetragon-class sensor for continuous fidelity and in-kernel defense-in-depth, on exactly the hosts where you want it.
sensors are an upgrade, not a prerequisite
Lane 02 · Security — scan, prioritize, contain
A security lane that refuses autopilot
- SBOM-based vulnerability scanning across the fleet, matched against public feeds — NVD, OSV, distro advisories.
- Prioritization you can defend: known-exploited and exploit-probability signals (KEV, EPSS) sharpen the queue. Exploit databases are a read-only signal — nothing is ever fetched or run.
- Breach-detection signals feed the same incident engine, tagged security and routed to an evidence-preserving containment lane — where a human drives every step.
risk = criticality × exposure × severity × exploit likelihood
auto-remediation here: refused by design
deployment models
Control plane
Managed by us — or provided in your own datacenter. The same platform, inside your perimeter.
Gateways
One per network segment where your topology demands it. Each dials out, each enforces its own local allowlist — strong segmentation stays strong.
Inference
A hosted frontier model — or vLLM on your own hardware. Chosen per tenant.
both lanes execute the same way — allowlisted, signed jobs on the gateway you operate, inside your boundary
The safety model
Built for the question your CISO will ask
Approval here is architecture, not a setting: no execution path exists around the policy gate, and nothing on our side can widen what your allowlist permits. If a claim in this table ever changes, the architecture changed first.
Security incidents are never auto-remediated
Security findings route to a human-driven, evidence-preserving containment lane. Auto-mutation on attacker-influenceable signals destroys forensics and can be triggered by the attacker — so it's a path we refuse to build, not a toggle we ship turned off.
refused by designFAQ
The questions we'd ask, answered plainly
How is this different from other AI-SRE tools?
Most tools in this category either stop at the diagnosis — investigation and a summary, the fix stays manual — or execute with their own credentials behind a configurable autonomy threshold. This platform takes a third position: it does execute, but only through a gateway you operate, against an allowlist you publish, with zero standing credentials in the control plane and a policy gate plus human approval on the only path to execution. Containment is the architecture, not a setting.
Does the AI run commands on our systems?
No. The model produces proposals — structured data with evidence and a confidence score. Execution is a separate, deterministic system that only runs operations from an allowlist you control, after policy and human approval.
What credentials do you hold to our infrastructure?
None. The control plane has zero standing credentials to client infrastructure. Secrets live only in the gateway that runs inside your boundary, and it dials out — there is no inbound path.
What about prompt injection through log content?
We assume it. Logs and tickets are treated as attacker-influenceable, so model output is quarantined until it passes the policy gate and human approval. Security-lane findings are never auto-remediated at all.
What happens when the AI is wrong?
It says so, or a human catches it. Proposals carry confidence and evidence; the model is allowed to answer “I don't know.” Nothing executes without an engineer's approval, and every step lands in an audit trail.
Will this replace our operations team?
No. The platform takes over the repetitive part of incident work — evidence gathering, correlation, documentation, and re-solving already-solved problems. Decisions stay with your engineers: in v1, nothing executes without their approval. What changes is what their hours are spent on.
Can the whole platform run inside our datacenter?
Yes. The control plane is available managed by us or provided in your own datacenter. Inference is OpenAI-API-compatible, so it runs against your own vLLM deployment on your hardware if you choose. And gateways sit inside your network — one per segment in strongly segmented environments, each dialing out, each enforcing its own local allowlist. Nothing has to leave your perimeter.
Run it against your real incidents — as a design partner
Vesmona is in private beta. We're looking for a small group of teams who'll run the platform on real incidents and tell us where it falls short. You get early access, a direct line to the engineering team, and a real say in the roadmap. We get the operational reality — and, where it's earned, the reference — that makes a platform product-ready.
Become a design partner