Skip to content
Infraware.dev

AI takes on infrastructure operations. Your engineers sign every change.

Infraware’s agent handles alerts, questions, runbooks and changes across your Kubernetes estate. Nothing runs until a named engineer approves it, and every action goes on a permanent record inside your own cluster.

Overview

What is waiting on you, what this install knows about, and what has run recently.

Tasks3 waiting
  1. Review kubectl rollout restart deployment/payments-gateway -n payments
    mutative action, requires your approval payments-gateway 5xx spike after the 14:02 rollout
    4m
  2. Review kubectl -n ledger scale deployment/ledger-worker --replicas=6
    mutative action, requires your approval ledger consumer lag growing, 42k messages behind
    11m
  3. Answer Which replica should I take the heap dump from, the leader or a follower?
    fraud-scoring memory growth
    27m
Your Stack8
  • payments-gateway17 components · 8 checks
  • checkout-api14 components · 9 checks
  • ledger-core11 components · 12 checks
  • fraud-scoring8 components · 6 checks
  • notification-hubSTALE6 components · 5 checks
  • customer-portal9 components · 4 checks
  • settlement-batch7 components · no health panel
  • kyc-serviceFROM DESCRIPTION5 components · 3 checks
Recent Activityall runs
  • reportPaymentsGateway5xxcompleted
  • runLedgerConsumerLag firedalert run
  • reportLedgerConsumerLaganalyzing
  • runRestart payments-gatewaywrite runbook
  • reportFraudScoringMemorycompleted
Alertsall rules

14 active rulesof 17

PaymentsGateway5xxlast fired

Example: the console overview, three tasks waiting on an engineer.

What it is

Delegate the work. Keep the final word.

Infraware is a governed delegation platform for infrastructure operations. Virgil, its agent, works every alert the way an AI SRE does, answers questions about your estate and follows your runbooks, read-only. Every change it proposes waits for a named engineer, and every action is recorded. Built for complex Kubernetes environments in regulated industries.

  • Runs in your cluster

    One Helm install. No Infraware control plane, no channel back to us.

  • A named engineer signs every change

    Nothing writes to production without an approval that carries a person’s name.

  • One record per change

    Who approved what, on what evidence, and what ran, kept in your own log storage.

The problem

Agents can act on production. Someone still answers for every change.

AI agents that diagnose incidents are everywhere, and some already change production on their own. The review that follows always asks the same thing: who approved this change, and on what evidence?

Most tools stop at the diagnosis, or act without asking. Infraware does the work and keeps every decision, and the record of it, with your team.

Who approved the restart at 14:13, and on what evidence?

The question every change review ends with. The record answers it in one entry.

How it works

Four steps, the same every time.

Autonomous up to the approval. Nothing crosses it without a person.

  1. Step 1

    Propose

    Virgil works the alert, the question or the runbook on its own, read-only, and writes a brief with one proposed change.

  2. Step 2

    Sign

    A named engineer reads the brief and approves the change, or refuses it. Nothing runs before that.

  3. Step 3

    Run

    The approved command runs once, as a scoped Kubernetes job under your RBAC. The agent never holds the write credentials.

  4. Step 4

    Record

    One entry lands in your logs: who approved what, on what evidence, and what ran.

Command approval

Write Approved
Why
payments-gateway 5xx after the 14:02 rollout, a restart clears the wedged workers.
Command
kubectl rollout restart deployment/payments-gateway -n payments
Executes as
Kubernetes Job · serviceaccount svc-frontend-rwmutative action, requires your approval
Approved by
Alex Riverajob disp-4c21 · Succeeded

Audit entry

cmd-dispatch 14:13:20
Approver
alex.rivera@example.com · via console
Resolved principal
payments / svc-frontend-rw
Command
kubectl rollout restart deployment/payments-gateway -n payments
Outcome
Succeeded · job disp-4c21 · exit 0
Example run: a restart approved after a failed rollout, and the entry it leaves.

Each step in detail

Autonomy, earned

Human-signed today. Autonomous when the record says so.

Approve the same fix often enough and Virgil proposes the standing version: one signature, scoped to that exact context, revocable in one click. Autonomy is delegated by evidence, never by a toggle.

Standing signature · proposal

routine-cand-004 evidence 12×09:41:07
Command
kubectl rollout restart deployment/payments-gateway -n payments
Evidence
approved identically 12 times · 2026-06-14 to 2026-08-02 · zero rejections
Virgil proposes

Sign it once, as policy.

Same command, same namespace, every time. A standing signature runs this fix on sight, under the same identity binding, with the same audit line per run.

Pattern
rollout restart deployment/payments-gateway · exact argv
Scope
payments · this deployment only
Revoke
one click, the pause returns
Signed as policy
a.rivera2026-08-05 · routine #4 · standing signature
Example: a restart approved twelve times, proposed as policy.

How autonomy is earned

Why you can trust it

Everything runs inside your boundary.

The agent holds no write credentials. Approved changes run once, under a scoped service account bounded by your RBAC.

Stays in your cluster

  • The agent, and the gate every command passes
  • Investigations and the evidence behind them
  • Briefs, approvals and the record of every change
  • Your runbooks and the context Virgil learns

Leaves your cluster

  • Calls to the model endpoint you configure, only if you choose an external one: the alert, the conversation, command output and summaries of your runbooks
  • The pull of the executor image approved commands run in, unless you mirror it
  • Nothing else: no control plane, no telemetry, no channel back to us

Security and architecture

What it protects

The costly change is the one nobody can explain.

The return is in what does not happen: the incident a tool causes, the audit finding nobody can answer, and the agent that never gets past security.

  • The incident a tool causes

    Automation that writes without a person is the new tail risk. Here nothing reaches production without a named approval, so the worst case stays a proposal.

  • The audit finding

    DORA, NIS2 and ISO 27001 all expect production changes to be approved and documented. Every change here arrives with its approval and evidence already written.

  • The agent you can deploy

    Most regulated teams keep AI away from production. Read-only by construction and one record per change is what gets an agent through the security review.

We size the value with you on the first call, against your incident history and your audit calendar.

Who it is for

Built for teams that answer to an auditor.

  • Regulated enterprises

    Banks, insurers and telcos: a record your auditors accept, in your cluster, under your keys.

    Security and architecture

  • Managed service providers

    One deployment per client, a brief before first response, and a record for every SLA review.

    The MSP model

  • Public sector

    Sovereign by architecture: air-gapped if you choose, no channel to the vendor, every change signed like the administrative act it is.

    The public-sector case

Who we are

A company you can reach, with people you can name.

  • Francesco Niccolò Garau

    Francesco Niccolò Garau

    Co-founder and CEO

    Leads strategy, sales and partnerships. Previously led teams building AI-driven products for startups and enterprises.

  • Alan Chen

    Alan Chen

    Co-founder and CTO

    25+ years in cloud infrastructure. Previously CTO at InfinyOn. Critical infrastructure in aerospace and defence.

  • Laura Emilia Hellqvist

    Laura Emilia Hellqvist, PhD

    Co-founder and COO

    Multi-million international contracts in critical industries across Europe, Asia and the Gulf.

Backed by

  • Tech Europe Foundation
  • B4i, Bocconi for innovation

Member of

  • NVIDIA Inception program member
  • Google for Startups

European cloud programs

  • OUTSCALE for Entrepreneurs program member
  • OVHcloud Startup Program member

Questions

Four objections, answered.

Does it replace my engineers?

No, it changes what they spend the night on. Virgil assembles the context; your engineers keep the decision, because deciding is the job. Approvals scale with changes, not with alert noise. The human is the feature

Is this another dashboard?

No. Infraware is a governed pathway, propose, sign, run, record, not another screen to stare at. The console exists to read briefs and sign changes; most of the work happens before anyone looks. Walk the loop

Does anything leave our cluster?

Only what you choose. Infraware runs in your cluster, entirely. Once running, it calls only the model endpoint you configure and, unless you mirror it, the registry holding the executor image: your own key with Anthropic, OpenRouter or Mistral, or an open-weight model served inside your own boundary with vLLM or llama.cpp. Where data goes

What does it cost?

Flat, annual, scoped to your infrastructure: no seats, no metering. The number arrives on the first call and does not move after. How pricing works

Ten questions to ask any AI SRE, answered by us first

How to start

A live demo, then a ten-week pilot.

  1. 25 minutes

    Live demo

    We break a real cluster with rotelle and you watch the loop close, including a write refused in front of you.

  2. Weeks 1–2

    Install

    One Helm install in staging and one in production. Virgil maps your estate as plain data you own.

  3. Weeks 3–4

    Acceptance

    Three agreed scenarios run end to end with your security lead. Either side can stop at week four.

  4. Weeks 5–10

    Live operation

    Real incidents, signed fixes, your runbooks. A report and the audit extract at the end.

The number is set on the first call, once we know your infrastructure, and it does not move after.