Proposed architecture · v0.1

Intelligence ≠ authority.

An AI agent may understand a problem and propose a repair. Independent services decide whether that repair can execute, then check what actually happened.

A design to implement and test.

The boundaries below are requirements for the prototype. They are not claims of proven isolation or released functionality.

The proposed service boundaries

01 · Observe and reason

A collector reads configuration. A local model receives bounded observations and returns a structured proposal.

02 · Evaluate and authorize

An independent policy service and human approval bind authority to the specific proposal.

03 · Execute the approved action

A broker validates the authorization and uses scoped credentials for an allowlisted operation.

04 · Verify and preserve evidence

A separate verifier reads the resulting state. The evidence service records and signs the chain.

Proposed order: observation → proposal → policy → approval → execution → independent check → evidence.

Component	Responsibility	Required boundary
Collector	Read the explicitly selected configuration.	Read-only cloud access; no permission to perform repairs.
Local AI	Explain the finding and propose a structured change.	No cloud credentials, privileged host access, or direct executor authority.
Policy and approval	Evaluate the action and record a human decision.	Approval is bound to the resource, payload, policy version, and validity window.
Broker / executor	Revalidate authorization and apply the allowlisted change.	Scoped credentials, payload validation, replay protection, and current-state checks.
Verifier	Independently read the resulting state.	Separate read-only identity; never accept only an executor assertion.
Evidence / recovery	Preserve the observation, decision, action, and verification.	Protected signing keys and an encrypted, verifiable local recovery package.

The first reference workflow

Select one synthetic test storage account in Canada Central and declare allowBlobPublicAccess=false as the required state.
Read the actual setting. Record a finding if it deviates, including the observation time and resource identity.
Let the local model propose the bounded repair using sanitized observations. Relate the proposal to the owning configuration or IaC source.
Evaluate the exact proposal against independent policy. Require human approval for this first scenario.
Have the broker reject expired, replayed, modified, or out-of-scope requests. Recheck current state before executing the authorized action.
Have the verifier read Azure independently. Mark the result as verified only if the observed setting matches policy.
Preserve the evidence chain and exercise local export and recovery.

Disabling this setting prevents anonymous blob reads. Allowing it at the account level alone does not prove that any container is publicly readable; container configuration also matters. This scenario does not by itself demonstrate that the storage network is private. See Microsoft’s anonymous access guidance.

One VM to start

The planned reference package is a bootstrap installer plus containerized services on one documented Linux VM. The installer should prepare or validate the host, configure service identities and storage, load the approved bundle, and run installation checks. A customer-managed Kubernetes cluster is not a prerequisite.

Separate containers on the same VM still share a host security boundary. Host or hypervisor compromise is a residual risk. The design must prevent an untrusted agent from reaching the host’s privileged runtime, other services’ credentials, or cloud instance credentials; container packaging alone does not establish that isolation.

Connected and disconnected are different modes

The Azure scenario needs authorized connectivity to Azure management and identity services. A private deployment with restricted egress is not fully air-gapped. A future disconnected mode must use locally reachable targets and local artifacts, with explicit admission and verification before transfer.

Evidence has a defined meaning

A proposed evidence package includes the target resource, before-and-after observations, proposal digest, policy version, approval identity and scope, execution result, verifier result, timestamps, and artifact versions. A signature helps detect modification and establish the signing source; it does not prove the observation itself was correct.

The recovery design includes configuration, policies, manifests, approved artifact references, and evidence. Secrets and private keys need a separate, explicit recovery policy. Keeping an encrypted local archive is useful only when restoration has been tested.

What this does not claim

There is no certification, government authorization, guaranteed sovereignty, or promise that compromise is impossible. Canadian security and sovereignty profiles are a planned direction. Evidence should support accountable review of specified controls.

Design documentation · Updated 15 September 2026 · Nomiarch · Architecture in development.