Managed cloud collectors

Veriom's cloud collector reads inventory through an already-authenticated provider CLI, converts it to the typed veriom-cloud-evidence-v1 contract, and submits it to exactly one workspace. The collector invokes read-only inventory commands. It does not accept provider credentials as arguments and it cannot change cloud resources.

Install the collector

From a checked-out Veriom release, install the versioned collector with uv:

./scripts/install-cloud-collector.sh
veriom-cloud-collector --help

Create a workspace API token with evidence:write, keep it in the scheduler's secret store, and authenticate the provider CLI with a dedicated read-only workload identity.

export VERIOM_API_TOKEN=vat_...
aws sts get-caller-identity

veriom-cloud-collector sync \
  --provider aws \
  --region eu-west-1 \
  --workspace-id 7f38cf23-0416-4968-9d30-9c343d45ae76

export VERIOM_API_TOKEN=vat_...
az account show

veriom-cloud-collector sync \
  --provider azure \
  --workspace-id 7f38cf23-0416-4968-9d30-9c343d45ae76

export VERIOM_API_TOKEN=vat_...
gcloud auth list

veriom-cloud-collector sync \
  --provider gcp \
  --project payments-production \
  --workspace-id 7f38cf23-0416-4968-9d30-9c343d45ae76

Schedule inventory

Run the same sync command from a provider scheduler, CI job with workload identity federation, or a customer-managed runner. Use a stable schedule and let the collector generate a unique sync identifier. A second submission with the same provider, account, and sync identifier is replay-safe.

The response makes coverage operational rather than decorative:

{
  "provider": "aws",
  "account_boundary": "aws:123456789012",
  "sync_id": "scheduled-20260902T010000Z",
  "collection_status": "partial",
  "resource_count": 184,
  "relationship_count": 183,
  "freshness": "current",
  "age_seconds": 14,
  "stale_after_seconds": 86400,
  "warnings": ["vpc: collector identity lacks the optional read scope"]
}

Query GET /v1/workspaces/{workspace_id}/cloud/snapshots with ingestion:read to monitor account boundaries and freshness. The default stale threshold is 24 hours and can be set between five minutes and seven days per request.

Typed evidence boundary

Every submitted snapshot contains:

• provider: aws, azure, or gcp;
• account_ref: the account, subscription, or project established by the provider identity;
• sync_id: a replay key for one collection attempt;
• collection: collector version, timestamp, completeness, completed scopes, and warnings;
• resources: up to 500 allowlisted inventory records;
• relationships: up to 1,000 typed edges that only reference resources in the same snapshot.

{
  "schema_version": "veriom-cloud-evidence-v1",
  "provider": "aws",
  "account_ref": "123456789012",
  "sync_id": "scheduled-20260902T010000Z",
  "collection": {
    "collector": "veriom-cloud-collector",
    "collector_version": "0.1.0",
    "collected_at": "2026-09-02T01:00:00Z",
    "status": "complete",
    "completed_scopes": ["identity", "tagged-resources", "vpc"],
    "warnings": []
  },
  "resources": [
    {
      "external_id": "aws:account:123456789012",
      "name": "AWS account 123456789012",
      "resource_type": "AWS::Account",
      "category": "account",
      "observed_at": "2026-09-02T01:00:00Z",
      "confidence": 1,
      "properties": {"account_id": "123456789012"}
    }
  ],
  "relationships": []
}

Credentials, tokens, raw environment variables, customer payloads, and unrestricted provider metadata are rejected by the contract. Older snapshots remain traceable, while workspace context selects the latest accepted sync for each provider account.

MCP compatibility

MCP clients can submit the exact same object through submit_cloud_snapshot. HTTP collectors and MCP clients share one normalization and replay path, so the architecture model does not depend on which transport delivered the evidence.