Vesmona
Join the private beta

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.

Become a design partner Read the safety model

no agents required on day one · early access · run it against your real incidents

What it does on your stack

One safe path, whatever the environment. A ticket comes in, read-only diagnostics gather evidence through your gateway, and a single allowlisted fix runs only after your engineer approves it.

Your environment via your gateway · read-only
web-01app-02db-03

read-only signals

  • systemctl status
  • journalctl -p err
  • df · ss
  • deploy log

scenario 01 / 04 Application across hosts

One app, several hosts, one root cause

Incident
Monitoring files a latency spike on the checkout path. The app spans web-01, app-02 and db-03.
Evidence
Through your gateway, read-only diagnostics pull service status, recent errors, resource pressure and the last deploy from each host, then correlate them onto one timeline.
Proposal & approved fix
You get a single proposal: a worker left stuck on app-02 by the 14:02 rollout, evidence attached and confidence scored. You approve, an allowlisted restart runs on app-02, and a verification pass confirms the path recovered.
Your environment via your gateway · read-only
Deploymentpod apipod worker

read-only signals

  • kubectl get pods
  • kubectl describe
  • rollout history
  • resource limits

scenario 02 / 04 Kubernetes workload

A rollout that will not go ready

Incident
A Deployment is crash-looping after a rollout. Your gateway runs in-cluster, installed from the Helm chart.
Evidence
Read-only cluster reads gather pod status, events, the rollout history and resource limits, checked against the last healthy state.
Proposal & approved fix
The proposal is a rollback to the last healthy revision, expressed as a declarative change, with the failing readiness probe as evidence. On approval the allowlisted rollback applies and verification watches the pods reach ready.
Your environment via your gateway · read-only
webapicache

read-only signals

  • docker ps
  • container logs
  • image digest
  • df -h

scenario 03 / 04 Docker services on a host

A bad tag and a disk filling up

Incident
A container is unhealthy and restarting on a Compose host, and the disk is filling.
Evidence
The gateway reads container health, logs, the running image digest and host disk usage, all read-only, and lines them up.
Proposal & approved fix
The proposal: the latest image tag regressed, so roll that one service back to the pinned good tag and rotate the oversized log. You approve each step, allowlisted actions run, and verification confirms the container healthy again.
Your environment via your gateway · read-only
primaryreplica

read-only signals

  • pg_stat_activity
  • long-running SQL
  • replication lag
  • disk usage

scenario 04 / 04 Database under pressure

Connections saturating, a replica lagging

Incident
Connections are saturating on the primary and a replica has started to lag behind.
Evidence
Read-only queries collect connection counts, the longest-running statements and replication status, with nothing written back.
Proposal & approved fix
The proposal names one runaway query holding connections open and proposes terminating just that session, a reversible, allowlisted step. Your engineer approves, it runs through the gateway, and verification confirms connections recovered.
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.

fig. 02 · where the hours gostructure, not measurement
Today an engineer carries every stage of an incident. With the platform, the engineer's share converges on the decision; on repeat incidents, a promoted runbook makes it smaller still. TODAY every hour is your engineer's triage investigate correlate remediate write-up FIRST OCCURRENCE the platform carries the legwork evidence & triage decide & approve execute verify & write-up a fix that verifies ⤷ promoted to a vetted runbook, keyed to the incident signature EVERY REPEAT the same class of incident, cheaper each time vetted runbook match approve execute verify your engineer's hours the platform your gateway

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, from alert to root-cause analysis to a verified fix. 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.

  1. 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
  2. 02

    The AI investigates the root cause 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
  3. 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
  4. 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, across bare metal, VMs and Kubernetes. 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 & delivery

The same platform, packaged for where you run it and shaped to fit a segmented network.

Control plane

Run it managed by us, or self-hosted in your own datacenter. Same platform, inside your perimeter.

Ships as

A Kubernetes install via Helm, a production Docker Compose stack, or native OS packages with hardened systemd services. Images are multi-arch, each with an SBOM and a signature attached.

  • Kubernetes · Helm
  • Docker Compose
  • rpm · deb · systemd

Gateways

One per network segment where your topology needs it. Each dials out, each enforces its own local allowlist, so a strongly segmented network stays segmented.

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: the control plane holds zero standing credentials, 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.

fig. 01 · the credential-less boundaryas shipped
How the AI-SRE platform executes remediation with zero standing credentials: a control plane with zero credentials, a trust boundary, and a customer-operated gateway that dials out and re-validates every job against its own local allowlist. CONTROL PLANE 0 credentials Ingress tickets in AI reasoning proposes only Policy gate OPA · every proposal Approval · engineer nothing ships without it Audit every step JobSpec signed ↓ expiring · idempotent outbound-only · the gateway dials out ↓ JobSpec · signed, expiring ↑ JobResult · evidence, redacted TRUST BOUNDARY mTLS · signed both directions YOUR INFRASTRUCTURE credentials live here, only here Gateway · you deploy and operate it Credential store sealed here Local allowlist yours to publish Executor deterministic re-validates every job against the local allowlist: a valid control-plane signature is not authority to run off-list web-01 db-02 k8s-node-7 allowlisted actions only
What the control plane does
What it can never do
Orchestrates incidents, reasons over evidence, signs job specs.
Hold a credential, key, or shell to any host you run.
Produces remediation proposals with evidence and a confidence score.
Execute anything itself; model output is data, quarantined until gated.
Evaluates every proposal against your policy before an engineer sees it.
Skip the engineer; in v1, every change is human-approved.
Sends signed, expiring, idempotent jobs to your gateway.
Run an action your local allowlist doesn't contain; even a signed job from our own control plane is refused if it isn't on your list.
Reports “I don't know” when the evidence doesn't support a fix.
Dress up a low-confidence guess as an answer.

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 design

FAQ

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.

Does this reduce our MTTR?

It attacks the part of MTTR you actually pay for: the hours before a decision. Investigations arrive pre-assembled, so your engineer starts at the decision with the evidence attached, and repeat incidents can be promoted to vetted runbooks that arrive as pre-vetted proposals. We don't publish a headline percentage; the mechanism is what changes, not a number we invented.

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