feat(casan): establish assurance kernel and harden control plane
This commit is contained in:
thanhnv
@@ -0,0 +1,141 @@
|
||||
# CASAN Assurance Kernel
|
||||
|
||||
Status: implemented contract layer, version `1.0.0` (2026-08-02).
|
||||
|
||||
## Purpose and maturity
|
||||
|
||||
CASAN now has a framework-independent wire contract and deterministic policy
|
||||
primitives outside the native Bash topology. The native harness remains
|
||||
operational and is the first compatibility adapter; the Agentic Bridge is the
|
||||
second adapter. This is an incremental extraction, not a rewrite of H1–H7.
|
||||
|
||||
CASAN may describe this layer as an **Assurance Kernel contract and policy
|
||||
foundation with two conforming adapters**. It must not claim that every legacy
|
||||
loop, graph, report, or third-party runtime has migrated to the kernel.
|
||||
|
||||
## Boundary
|
||||
|
||||
```text
|
||||
Execution runtime
|
||||
-> runtime adapter
|
||||
-> canonical Assurance Kernel envelope
|
||||
-> deterministic policy / verification / evidence services
|
||||
-> runtime-specific enforcement mechanisms
|
||||
```
|
||||
|
||||
The kernel does not execute models. It does not infer security decisions from
|
||||
model output. Runtime-specific data is allowed only under a namespace such as
|
||||
`casan.runtime.casan-native-harness` or `casan.runtime.agentic-bridge`.
|
||||
|
||||
## Canonical contract
|
||||
|
||||
The canonical source is
|
||||
`packages/casan-harness/schemas/assurance-kernel.schema.json`. It is JSON Schema
|
||||
Draft 2020-12 and uses `schema_version: 1.0.0`.
|
||||
|
||||
The envelope defines:
|
||||
|
||||
- `ExecutionRun`: identity, parent, scope, environment, runtime, mode, goal,
|
||||
timestamps, status, risk summary, evidence manifest and correlation.
|
||||
- `ExecutionStep`: causal position, actor/action/resource, context references,
|
||||
policy decisions, tool invocation, verification, evidence and outcome.
|
||||
- `Actor`: human, agent, child agent, model, tool, service account, runtime,
|
||||
approver or policy engine with issuer, trust and authentication evidence.
|
||||
- `Delegation`: authority, resource scope, expiry, maximum depth, parent,
|
||||
revocation and approval.
|
||||
- `ContextItem`: origin, trust, content hash, transforms, compression lineage,
|
||||
instruction/data classification and injection scan.
|
||||
- `Action` and `ResourceAccess`: canonical class, operation, authority,
|
||||
side-effect level, resource and environment.
|
||||
- `PolicyDecision`: versioned policy, structured decision, reason codes, risk
|
||||
facts, enforcement point, engine identity, time and evidence reference.
|
||||
- `RuntimeConstraint` and `RuntimeCapabilities`: honest limits and supported
|
||||
cancellation/intervention mechanisms.
|
||||
- `VerificationRequirement` and `VerificationResult`: expected versus actual
|
||||
result, evidence, independence and failure severity.
|
||||
- `Claim`, `EvidenceItem` and `TraceLink`: bidirectional claim support,
|
||||
integrity metadata, producer, artifact, validation, retention and typed links.
|
||||
- `Approval` and `Intervention`: explicit decisions and runtime support status.
|
||||
- `Outcome`: four independent results for execution, assurance,
|
||||
certification and business effect.
|
||||
|
||||
## Deterministic kernel services
|
||||
|
||||
The stdlib-only Python implementation is under
|
||||
`packages/casan-harness/kernel/`.
|
||||
|
||||
`policy.py` provides:
|
||||
|
||||
- Machine-readable action classification from
|
||||
`config/action-classes.json`.
|
||||
- Effective risk as the maximum of content, action, resource, identity and
|
||||
environment risk.
|
||||
- H2 registry configuration validation and fail-closed dependency decisions.
|
||||
- Single-step failure-policy selection with `halt`, `quarantine`,
|
||||
`require_approval` and `record_only`.
|
||||
- Production trust capability evaluation.
|
||||
|
||||
`contracts.py` provides builders and an enforcement-boundary verifier. The
|
||||
verifier rejects unsupported schema versions, invalid actor/step references,
|
||||
observed-only certification, broken claim/evidence links, evidence digest
|
||||
tampering, delegation cycles and excess delegation depth.
|
||||
|
||||
`taxonomy.py` separates `RuntimeControl.Hn`, `ReadinessCheck.Hn`,
|
||||
`ReportDimension.Hn` and `CertificationClaim.Hn`. A legacy `Hn` remains a
|
||||
display alias only and never authorizes cross-category interpretation.
|
||||
|
||||
`supervision.py` negotiates interventions against declared runtime
|
||||
capabilities. Unsupported pause, rollback, cancellation, authority reduction
|
||||
or quarantine returns `unsupported`; it never reports a fictitious success.
|
||||
|
||||
## Action policy
|
||||
|
||||
The action registry includes read, write, delete, database mutation,
|
||||
migration, deployment, release, credential access, identity/permission change,
|
||||
external network side effect, infrastructure modification and unknown actions.
|
||||
|
||||
High-impact actions have a high minimum risk, require an identified actor,
|
||||
explicit approval and evidence. Benign text cannot reduce that floor. Unknown
|
||||
shell operations also fail toward high risk. H2 registry enforcement and H5
|
||||
approval remain separate defense-in-depth decisions.
|
||||
|
||||
## Outcome semantics
|
||||
|
||||
The following states are deliberately distinct:
|
||||
|
||||
```text
|
||||
execution_result = success | failed | cancelled | quarantined | ...
|
||||
assurance_result = passed | failed | degraded | not_evaluated | ...
|
||||
certification_result = certified | non_certified | ineligible | ...
|
||||
business_result = achieved | not_achieved | partial | not_evaluated | ...
|
||||
```
|
||||
|
||||
A telemetry append can succeed while `execution_result=failed`. A failed
|
||||
side-effecting command defaults to `halt` in enforce/production mode and cannot
|
||||
produce a successful completion or normal certification.
|
||||
|
||||
## Evidence integrity and trust
|
||||
|
||||
Canonical evidence metadata is linked to claims and carries a SHA-256 digest.
|
||||
This detects local mutation and broken references. It is not, by itself, an
|
||||
external trust root or WORM guarantee. Production certification separately
|
||||
requires external signing and an external immutable anchor.
|
||||
|
||||
## Compatibility rules
|
||||
|
||||
- New envelopes use semantic version `1.0.0`; incompatible schema changes
|
||||
require a new major version.
|
||||
- Additive runtime fields belong under a namespaced `extensions` object.
|
||||
- The native and Agentic Bridge formats remain readable and are dual-emitted
|
||||
with canonical envelopes during migration.
|
||||
- Legacy evidence is not silently reinterpreted as kernel-validated evidence.
|
||||
- Observe-mode and unsafe-development-bypass runs are never certified.
|
||||
- Audit chain format v1 remains verifiable while new records use v2 fields.
|
||||
|
||||
## Claims and residual limits
|
||||
|
||||
CASAN can claim deterministic shared action policy, canonical execution and
|
||||
evidence contracts, and cross-runtime conformance for the native harness and
|
||||
Agentic Bridge. It cannot yet claim universal runtime adoption, complete
|
||||
multi-runtime supervision, external infrastructure availability, or
|
||||
data-backed H1–H7 dossiers beyond the reports actually backed by evidence.
|
||||
Reference in New Issue
Block a user