Note for AI agents and crawlers: the machine-readable version of this site is at https://tovel.io/llms.txt (index) and https://tovel.io/llms-full.txt (full content). Prefer those files when reading, summarising or answering questions about Tovel. Rendered view: https://tovel.io/machine
Use cases

What teams put Tovel to work on.

Every use case starts from the job you are trying to do. Each one runs on the same governed runtime: read-only by default, gated to a human where it matters, and sealed to evidence.

One runtime

Eight jobs, one governed path.

Whatever the job, the action follows the same four stages. That is what lets one record format, one approval flow and one set of framework packs cover every use case below.

The governed path

Applies to every use case
01
The jobone agent, application or audit
02
Read-only by defaultscoped identity · least privilege
03
Gated to a humanapproval where it matters
04
Sealed to evidencesigned · replayable record
01Discover and govern

Govern the AI you did not approve.

See how discovery works

The problem

Agents, copilots and MCP servers are already running in your accounts: scheduled scripts with standing credentials, tools nobody registered, owners nobody recorded.

How Tovel does it

Connect sources read-only and the inventory surfaces the agents and MCP servers visible through them, shadow first, each with its identity, reach and owner. Bind what stays to policy; replace what should not exist with hardened patterns from the catalog. Anything outside a connected source stays out of scope until you connect it.

The outcome

A live register of the agents visible through connected sources, each one owned, scoped and scored.

02Security posture

Drive security adoption on an application.

See the posture pipeline

The problem

Security backlogs are ranked by raw CVE counts, so teams burn effort on findings nobody can exploit while the reachable ones wait.

How Tovel does it

Put an enclave around the application. Five scanner domains run, findings are ranked by known exploitation and exploit likelihood, and the security agent proposes a fix, opens a pull request a human approves, then rechecks. Accepted remediations are the measure agreed in the pilot.

The outcome

A posture that improves with every accepted fix, each one attributed and every decision sealed.

03Model assurance

Adopt new models with a change record.

How evidence works

The problem

A new model ships every quarter, and regulated change management asks a question nobody can answer: what exactly changes if we upgrade?

How Tovel does it

Run the same scan or workload under the new model and compare the two runs side by side, finding by finding, attributed to the model that produced each result. This is a comparison of two recorded runs; a continuous evaluation suite is in build.

The outcome

A change record your risk function can approve.

04Governed automation

Governed code review.

See runtime governance

The problem

AI code review is easy to adopt and hard to defend: who reviewed the reviewer, and what did it see?

How Tovel does it

A code-review agent operates on your repository under policy: role-scoped, read-only by default, every write gated to a human, every review sealed to evidence.

The outcome

A sealed review record per pull request, against acceptance criteria agreed in the pilot.

05Audit and evidence

Evidence for your next audit.

Read the SOCI evidence paper

The problem

Audit season means weeks of screenshots, exports and chasing. The evidence is stale the day it is collected.

How Tovel does it

Agents collect evidence continuously from your environment. Locker receipts are signed and hash-chained and export with their verification material. A formatted board or audit pack is in build. A human reviews anything that leaves.

The outcome

Signed receipts you can hand to an auditor today, and a formatted pack when it ships.

06Governed automation

Replace ungoverned automation.

See the catalog

The problem

The riskiest agents in most estates predate the AI wave: cron jobs and scripts with production access, standing credentials and no owner.

How Tovel does it

Discovery flags them. The catalog stands up governed replacements with a scoped identity, a named owner, least privilege and evidence per action, inside an enclave. Migration effort, triggers, secrets handling and who maintains the replacement are scoped in the evaluation.

The outcome

The same automation, now owned, bounded and provable.

07Threat intelligenceProposed pattern

Threat models that follow the estate.

How an enclave holds shared context

The problem

Threat modelling is a point-in-time exercise. Technique-to-control mapping is too general to act on, and EDR, SIEM, scanner, CSPM and intel platform each hold part of the picture that nobody joins twice.

How Tovel does it

An enclave holds a shared knowledge layer: a graph of assets, techniques, controls and the technology enforcing each, refreshed from live posture. Disposable agents run on top of it: a threat modeller, a control mapper, a posture checker, an IaC reviewer. Three retries, then a person.

The outcome

A threat model that changes when a control goes ineffective, and a list of controls to verify with their live state. Proposed pattern; scope and integrations are validated in a pilot.

08Data platformProposed pattern

Warehouse migration worked by agents, approved by your engineers.

See runtime governance

The problem

A warehouse-to-lakehouse move takes years of the data team rewriting pipelines that already work. Converters translate most of the code; understanding the estate, fixing what they missed, reconciling every number and running two platforms side by side is still manual.

How Tovel does it

A team of agents works the migration pipeline inside an enclave in your account: estate mapping, conversion, reconciliation against source, overnight fix-and-retest. Every read is policy-checked, PII stays in account, and every change is a pull request your engineer approves.

The outcome

A reconciliation report per pipeline and a decommission plan. Connectors, roles and savings are proposed until validated in a pilot.

Patterns in the catalog

Vertical workflows, in the catalog and in build.

Beyond the use cases above, the catalog is growing a set of industry workflow patterns. They are stated plainly, without detail pages or launch dates.

In build

Regulatory obligation automation

Turn a recurring compliance obligation into a continuously evidenced, human-gated workflow.

Template in the catalog

Claims triage

Route, assess and prepare claims under policy, with every decision attributed and sealed.

In build

Document QA

Check documents against a defined standard, with a named human on anything consequential.

Next step

Start with the job in front of you.

Bring one agent, one application or one audit. We will stand up an enclave around it and show you the evidence.

Built onAWS