A perimeter that actually holds

The hardest part of building a third-party AI risk assessment isn't the scoring — it's that no serious engineering org will let an outside tool see their source code, their logs, or their internal architecture, and they'd be right not to. The architecture exists to make that a non-issue rather than a trust exercise.

The beta connects to IC Cloud

The non-commercial beta is not offline-only. Every participant connects to IC Cloud. Because evidence sources cannot be predicted in advance, IC Cloud identifies the environment-specific telemetry needs and delivers a signed, versioned package from its retained catalog. The participant verifies, explicitly authorizes, and executes that package locally. OpenClaw/Open Cloud or another hard-data integration can be part of the catalog. Raw telemetry, credentials, and sensitive evidence stay local; only allowlisted assessment outputs may return to IC Cloud.

Cloud connectivity is required, but external LLM document handling is not authorized. Telemetry access must be explicit and data-minimized. No carrier is selected or participating in the non-commercial beta, and the scores remain uncalibrated and non-pricing.

The existing scores-only carrier representation remains narrow by design for any possible later commercial phase: a JSON object with per-vector risk scores, not raw evidence.

"vectors": {
  "uncontrolled_internet_access": 45,
  "hallucination_ood": 32,
  "model_drift": 28
  …
}

That boundary isn't a policy note in a doc — it's enforced with a regression test that plants a fake secret, a fake internal path, and a fake vendor name in the local evidence store and asserts none of it can appear in the carrier-facing export. The export path is built from an explicit allowlist of fields, not a full internal object with things redacted after the fact. Allowlisting first means there's no field you forgot to strip; there's just a short list of things that are permitted to leave, and everything else structurally can't.

Why the scoring logic itself is compiled Go, not a script you can read

There's a second trust boundary running the other direction: the company being assessed generally shouldn't be able to read the exact scoring logic either, for the same reason an exam board doesn't publish the answer key. If a company can read precisely how points are assigned, "passing the assessment" and "actually having the control" stop being the same thing.

That's the reason the customer-side container is written in Go rather than Python or Node: Go compiles to a single self-contained binary with no separately readable source, which is difficult to reverse-engineer even with root access to the container. The build pipeline strips debug symbols (-ldflags="-s -w") and compresses the result with UPX — a base binary that starts around 20MB comes down to roughly 10MB, landing around 30–50MB once connectors and embedded assets are included. The carrier-side backend that aggregates sanitized scores across a whole book of business runs on Python/FastAPI instead, where there's no equivalent need to hide anything from the party running it.

Fail-safe direction matters

One deliberate operational choice: if a connector fails, a scan times out, or an assessment can't complete for any reason, the system defaults to the worst-case risk reading for that vector rather than skipping it or defaulting to a neutral score. Insurance pricing isn't real-time, so there's no pressure to guess optimistically when a check didn't actually run — silence about a control's status is treated as evidence of nothing, not evidence of safety.

What actually gets measured inside that perimeter — the ten specific things this system checks for, and how a score gets assigned — is the subject of the next piece: the scoring methodology.