AI can help turn requirements into architecture proposals and connect operating evidence to the context behind a decision. In Statepoint, Build’s AI Infrastructure Copilot supports design, while AI-powered Assurance explains operating priorities and recommends responses. Engineering validation, evidence, policy and accountable people remain essential in both.
01 · The intelligence boundary
Reasoning is valuable. Unbounded certainty is not.
In infrastructure assurance, the most useful AI is not a generic chatbot attached to a dashboard. It is intelligence operating within a defined evidence boundary: authorised scope, current observations, known provenance and explicit limits on what it may conclude or initiate.
Statepoint Assurance is designed as that governed intelligence layer. It can correlate signals produced by security, compliance, identity, cost and operational capabilities into risks, paths, defensive gaps and recommended actions. It does not turn a model response into a verified fact merely because the response is fluent.
02 · A hierarchy of claims
Every statement should reveal where its authority comes from.
A governed system distinguishes source facts from platform calculations, AI hypotheses, verified conclusions and human decisions. Collapsing those states creates a dangerous illusion: the reader cannot tell whether a claim came from an infrastructure API, a deterministic rule, a model or an analyst.
Each claim should retain source, observation time, freshness, model or rule version, supporting and contradictory evidence, confidence and validation state. When those inputs change, the system can recompute the conclusion without rewriting history.
03 · The Assurance pipeline
Reason over a bounded evidence snapshot, then verify the output.
Statepoint Assurance receives normalised asset, finding, control and evidence objects from the source modules. The reasoning context is scoped to the tenant and the current investigation. It carries identifiers, observation times, freshness and provenance so conclusions can point back to the records that support them.
Structured output is checked against the schema, known identifiers, authorised scope and evidence references before it becomes an Assurance claim. Fluency alone is never accepted as validation.
04 · Explanation before action
An attack path should be inspectable one edge at a time.
AI is well suited to connecting configuration weaknesses, excessive permissions, software vulnerabilities and missing defensive controls into a plausible path. But every relationship in that path should answer three questions: why does this edge exist, what evidence supports it and what would disprove it?
Explainability is not a paragraph beneath the result. It is the structure of the result.
This permits a reviewer to accept one hop, reject another or request more evidence. It also prevents an attractive visual graph from becoming a stronger claim than its underlying data can support.
05 · Human authority
Consequential actions require accountable approval.
A recommendation may suggest changing a security group, rotating a key, isolating a workload or initiating an attack-simulation step. Whether that action should proceed depends on business context, operational risk, authorisation and policy, which is information a model may not possess.
Describe the action, rationale and expected effect.
Check authority, scope, workflow and safety conditions.
Record the accountable decision and its context.
The appropriate boundary varies by action. Low-risk analysis may run automatically. Changes to customer environments, accepted risk and offensive testing require progressively stronger controls. The governing principle remains constant: a model cannot grant itself authority.
06 · Validated closure
Completion is another claim that needs evidence.
A ticket marked done or an automated action marked successful does not prove that risk was removed. Statepoint separates action completion from validated closure. The system should collect new evidence, compare the resulting state with the intended outcome and preserve any residual risk or exception.
This is where governed intelligence becomes accountable assurance: the recommendation remains connected to its evidence, the approval remains connected to an accountable person, and closure remains connected to a verified change in state.
Sources
NIST · AI Risk Management Framework resources NIST · AI Risk Management Framework: Second Draft (2022)