Cloud, security, data & runtime tools

This page documents the Revka tools that advise on cloud and security work, turn project data into reports, manage backups and data retention, change runtime configuration on the fly, and verify commerce-gated intent: cloud_ops, cloud_patterns, security_ops, the vulnerability scan parser, project_intel, report_template, backup, data_management, model_routing_config, model_switch, proxy_config, workspace, and vi_verify. Most are opt-in and config-gated — the tool only registers when you enable it in config.toml — and several are deliberately read-only advisory tools that analyze input without touching cloud resources, files, or money.

Use this page when you need the exact actions a tool accepts and the config keys that enable it. For the broader catalog see Tools overview. The config keys here are also covered in Config: provider, agent & routing and Config: gateway, memory, security & platform. Runtime-config tools mirror the config you would otherwise edit by hand — see the Configuration overview.

Note

Mutating operations run under Revka’s security model: they execute under the Act policy and require approval (or approved: true) in supervised mode. Read-only advisory tools do not act on external systems. See Autonomy levels & approvals and the Security model.

Cloud advisory

cloud_ops

cloud_ops is a read-only cloud transformation advisory tool. It reviews infrastructure-as-code plans, assesses migration paths, analyzes costs, and checks an architecture against the AWS / Azure / GCP Well-Architected Framework pillars. It never creates or modifies cloud resources — it only returns analysis of the text you pass in.

[cloud_ops]
enabled = true

action	Purpose
review_iac	Review an IaC plan (e.g. a Terraform plan)
assess_migration	Assess a migration path for a workload
cost_analysis	Analyze billing / cost data
architecture_review	Review an architecture against Well-Architected pillars

Fields: input (string, required) — the IaC plan text, architecture description, or billing data; cloud (optional) — aws, azure, or gcp.

{ "action": "review_iac", "input": "<terraform plan text>", "cloud": "aws" }

cloud_patterns

cloud_patterns is a cloud pattern library. Given a workload description it suggests applicable cloud-native architectural patterns (containerization, serverless, database modernization, and so on). It registers alongside cloud_ops under the same cloud_ops.enabled = true gate.

Fields: workload (string, required) — the workload description; cloud (optional) — target provider.

{ "workload": "legacy monolithic Java ERP system, 500 users, needs 99.9% uptime" }

Security ops

security_ops

security_ops is the operations tool for managed cybersecurity services (MCSS). It triages alerts, runs playbooks, parses vulnerability output, generates reports, lists playbooks, and reports alert metrics.

[security_ops]
enabled = true

action	Purpose	Key fields
triage_alert	Triage a security alert	alert (object: type, severity, source, description)
run_playbook	Run a response playbook step	playbook, step (0-based index)
parse_vulnerability	Parse raw scan output into findings	scan_output
generate_report	Generate a security report	report_type
list_playbooks	List available playbooks	—
alert_stats	Return alert metrics	—

{ "action": "triage_alert", "alert": { "type": "brute_force", "severity": "high", "source": "firewall" } }

Vulnerability Scan Integration

The vulnerability scan parser (used by security_ops’s parse_vulnerability action) reads scan output from Nessus, Qualys, and generic CVSS JSON formats and turns it into structured findings. It computes an effective priority score that adjusts the raw CVSS for context — +2.0 when the asset is internet-facing and +1.0 when it is production — capped at 10.0.

Each Finding carries cvss_score (0–10), internet_facing (bool), and production (bool, default true). CVSS scores map to severity buckets:

Severity	CVSS
critical	≥ 9.0
high	≥ 7.0
medium	≥ 4.0
low	> 0.0
informational	0

Project intelligence & reporting

project_intel

project_intel is a read-only project delivery intelligence tool. It generates status reports, detects delivery risks, drafts client updates, summarizes sprints, and estimates effort from project data you supply.

[project_intel]
enabled = true
default_language = "en"
risk_sensitivity = "medium"   # low | medium | high

action	Purpose
status_report	Generate a delivery status report
risk_detection	Detect delivery risks
client_update	Draft a client-facing update
sprint_summary	Summarize a sprint
effort_estimate	Estimate remaining effort

Fields: data (object) — the project data to analyze; language (optional) — output language, defaulting to project_intel.default_language. risk_sensitivity controls how aggressively risk_detection flags issues.

{ "action": "risk_detection", "data": { "tasks": [], "deadline": "2026-07-01" } }

report_template

report_template renders a named report template with your variables substituted. It registers alongside project_intel (same project_intel.enabled = true gate).

Fields: template (required), variables (object), language (optional, default en — one of en, de, fr, it).

template	Renders
weekly_status	Weekly status report
sprint_review	Sprint review
risk_register	Risk register
milestone_report	Milestone report

{ "template": "weekly_status", "variables": { "team": "Backend", "week": "2026-W24" }, "language": "en" }

Backups & data retention

backup

backup creates, lists, verifies, and restores workspace backups.

[backup]
enabled = true     # default
# include_dirs = [...]   # directories captured in each backup
# max_keep = ...         # retention: keep the N most recent backups

command	Purpose
create	Create a new backup
list	List existing backups
verify	Verify a backup’s integrity (needs name)
restore	Restore a named backup (needs name)

max_keep enforces retention — older backups beyond the limit are pruned. include_dirs controls which workspace directories are captured.

{ "command": "restore", "name": "backup-20260601" }

data_management

data_management reports storage statistics and purges aged workspace data (logs, session history, results). It is disabled by default and gated on data_retention.

[data_retention]
enabled = true
# retention_days = ...

command	Purpose
stats	Show storage statistics
list	List retained data
purge	Delete data older than older_than_days

Caution

purge is destructive — it permanently deletes the matched data. Confirm older_than_days before running it, and take a backup first if the data may be needed.

{ "command": "purge", "older_than_days": 90 }

Runtime configuration

These tools change live runtime settings without restarting the daemon. They are the agent-facing counterpart to editing config.toml directly.

model_switch

model_switch switches the AI model for the current conversation immediately.

action	Purpose
get	Show the current provider/model
list_providers	List available providers
list_models	List models for a provider
set	Switch to provider + model now

{ "action": "set", "provider": "anthropic", "model": "claude-opus-4-5" }

model_routing_config

model_routing_config manages the default model, scenario-based routes, classification rules, and delegate sub-agent profiles at runtime. It is always registered. Where model_switch changes the active model for one conversation, model_routing_config edits the persistent routing rules that map hint names to provider/model pairs (the [[model_routes]] config) and the delegate agent profiles.

action	Purpose
get	Read the current routing config
set_default	Set the default provider + model
add_route	Add a named model route
remove_route	Remove a route
list_routes	List configured routes
add_delegate	Add a delegate sub-agent profile
remove_delegate	Remove a delegate profile

{ "action": "set_default", "provider": "openrouter", "model": "anthropic/claude-opus-4-5" }

For how routes and classification rules feed the agent loop, see Config: provider, agent & routing and Routing, reliability & tuning.

proxy_config

proxy_config manages Revka’s outbound proxy across three scopes — revka (Revka’s internal HTTP clients only), services (selected service keys/selectors), and environment (also exports process-wide HTTP_PROXY / HTTPS_PROXY / ALL_PROXY / NO_PROXY). It mirrors the [proxy] config section.

Scope	Affects	Exports env vars
revka	Revka internal HTTP clients	No
services	Only selected service keys/selectors	No
environment	Runtime and process environment	Yes

Actions: get, set, list_services, apply_env, disable, clear_env. Allowed proxy URL schemes are http, https, socks5, and socks5h. When scope = "services" you must supply a non-empty services list (concrete keys like provider.openai, tool.http_request, channel.telegram, or selectors like provider.*).

{ "action": "set", "enabled": true, "scope": "revka", "http_proxy": "http://127.0.0.1:7890", "https_proxy": "http://127.0.0.1:7890", "no_proxy": ["localhost", "127.0.0.1"] }

See Network deployment, Raspberry Pi & proxy for the deployment context.

Proxy Agent Playbook

For proxied or air-gapped networks, use this copy-paste sequence. Inspect first, discover valid keys, apply, verify, and roll back if behavior is wrong.

1. Inspect and discover.

{ "action": "get" }
{ "action": "list_services" }

Mode A — proxy only Revka internals (no process env exports):

{ "action": "set", "enabled": true, "scope": "revka", "http_proxy": "http://127.0.0.1:7890", "https_proxy": "http://127.0.0.1:7890", "no_proxy": ["localhost", "127.0.0.1"] }
{ "action": "get" }

Mode B — proxy only specific services:

{ "action": "set", "enabled": true, "scope": "services", "services": ["provider.openai", "tool.http_request", "channel.telegram"], "all_proxy": "socks5h://127.0.0.1:1080", "no_proxy": ["localhost", "127.0.0.1", ".internal"] }
{ "action": "get" }

Mode C — proxy the whole process environment (exports env vars):

{ "action": "set", "enabled": true, "scope": "environment", "http_proxy": "http://127.0.0.1:7890", "https_proxy": "http://127.0.0.1:7890", "no_proxy": "localhost,127.0.0.1,.internal" }
{ "action": "apply_env" }
{ "action": "get" }

Rollback patterns:

{ "action": "disable" }                    // disable proxy (safe default)
{ "action": "disable", "clear_env": true } // disable and force-clear exported env vars
{ "action": "clear_env" }                  // keep proxy enabled, clear env exports only

If a services-scope change fails with proxy.scope='services' requires a non-empty proxy.services list, set at least one concrete key or selector. If the proxy does not apply as expected, re-run {"action":"list_services"} to verify names, then {"action":"get"} to inspect the runtime_proxy and environment snapshot.

workspace

workspace manages multi-client workspace isolation. Each workspace provides separate memory, audit trail, secrets, and tool restrictions — the multi-tenant feature used by consulting and operator deployments.

[workspace]
enabled = true
workspaces_dir = "~/.revka/workspaces"

action	Purpose
list	List workspaces
create	Create a workspace (needs name)
switch	Switch the active workspace (needs name)
info	Show a workspace’s details (needs name)
export	Export a workspace’s profile (credentials redacted)

Switching changes the active config, including which memory namespace, audit namespace, and credential profile are in effect.

{ "action": "switch", "name": "client-acme" }

Caution

Cross-workspace memory search is off by default (workspace.cross_workspace_search = false). Enabling it allows memory to bleed between client workspaces — keep it disabled in multi-tenant deployments.

For the isolation model and per-profile fields, see Config: gateway, memory, security & platform.

Verifiable intent

vi_verify

vi_verify verifies a Verifiable Intent credential chain — Revka’s SD-JWT mechanism for gating commerce actions. It checks the cryptographic binding between credential layers and evaluates the constraints a user attached to a mandate (allowed merchants, amount ranges, budget caps, recurrence, and so on).

[verifiable_intent]
enabled = false
strictness = "strict"   # strict | permissive

operation	Purpose
verify_binding	Check the sd_hash binding between credential layers
evaluate_constraints	Validate constraints against fulfillment data

Fields: credential (object) — the credential chain; fulfillment (object) — fulfillment data for evaluate_constraints. strictness controls how strictly chain-verification errors are reported.

{ "operation": "verify_binding", "credential": { } }

For the full Verifiable Intent specification, mandate modes, and constraint types, see Verifiable Intent (commerce gating).