Uploads and MCP evidence

File uploads

Uploads enter the same ingestion pipeline as GitHub snapshots but have stricter provenance. Upload either one repository ZIP or a bundle ZIP containing two or more repository ZIPs. Bundles are unpacked into one isolated audit source while each nested archive is independently inspected. The service enforces combined compressed and unpacked size limits, file-count and decompression-ratio limits, path and symlink traversal protection, MIME inspection, and malware scanning.

No uploaded hook, script, binary, package lifecycle command, build, test, or customer source is executed.

MCP gateway

The Streamable HTTP MCP service exposes a narrow evidence-ingestion surface:

• get_ingestion_capabilities
• submit_evidence_batch
• submit_cloud_snapshot
• create_artifact_upload
• complete_artifact_upload
• get_ingestion_status
• start_audit

Connect with a workspace API key

In Veriom, open Settings → Automation, create an API token, and apply the MCP preset. Store the token in your client's secret manager as VERIOM_API_KEY; never commit it to a repository.

{
  "mcpServers": {
    "veriom": {
      "type": "http",
      "url": "https://mcp.veriom.ai/mcp",
      "headers": {
        "Authorization": "Bearer ${VERIOM_API_KEY}"
      }
    }
  }
}

The key is bound to one workspace and expires on the date selected by its creator. Revoking it in Settings immediately removes MCP access. The MCP preset grants evidence:write, uploads:write, ingestion:read, and audits:write only.

Existing OAuth clients remain compatible during the API-key migration, but API keys are the recommended connection method for automation.

Prove the connection before sending real evidence

1. Ask the connected client to call get_ingestion_capabilities.
2. Confirm the response is bound to the intended workspace and lists evidence:write as the required write scope.
3. Pass the returned sample and sample_batch_id to submit_evidence_batch.
4. Open Source Readiness in Veriom. MCP becomes ready only after the capability check, sample collection, and reconciliation into current truth all succeed.

The capability response is the canonical sample. It is versioned, schema-valid, and safe to replay: the sample batch ID is idempotent within a workspace.

Upload and audit one repository or a repository bundle

1. Create a ZIP of one repository. For a multi-repository architecture, create one outer ZIP containing at least two repository ZIPs.
2. Call create_artifact_upload with the outer file name, byte size, and SHA-256 digest.
3. Upload the ZIP to the returned short-lived signed URL using the exact returned headers.
4. Call complete_artifact_upload with the ingestion ID.
5. Poll get_ingestion_status until it reports ready.
6. Call start_audit with the ingestion ID and a stable idempotency key of at least eight characters.

The ZIP travels directly to quarantine object storage rather than through the MCP request body. This keeps the connection fast and preserves the existing size, malware, and archive-safety controls.

Validation reports durable stages—queued, downloading, archive inspection, malware scanning, and complete—plus a percentage that the web app streams live. Rejected archives return a stable code for invalid ZIPs, unsafe paths, symbolic links, file-count limits, decompression limits, size limits, collisions, or detected malware. Transient evidence-storage and malware-scanner failures are reported separately so operators know when retrying is appropriate.

Evidence acceptance

Structured batches are schema-validated, tenant-bound, provenance-stamped, and normalized before reconciliation. Raw artifacts use scoped signed uploads and pass through malware and archive-safety checks. Neither is passed directly to an agent prompt.

submit_cloud_snapshot accepts a bounded provider, account, region, resource, and relationship graph for AWS, Azure, or Google Cloud. Resource properties are allowlisted, identifiers must be unique inside the snapshot, and every relationship endpoint must refer to a resource in that same snapshot. A newer snapshot for the same provider and account supersedes the previous current view while preserving audit history.