Security
Understand the checks ACC actually performs, the records it validates, where execution remains blocked, and what the security surface does not claim to provide.
Security overview
ACC applies security-related checks across configuration, runtime governance, evidence, architecture, and release integrity rather than treating one status screen as a security guarantee.
The core/security subsystem exposes a baseline view and validator. Additional, narrower controls live with the systems they protect: runtime approval and authorization chains, immutable evidence records, architecture guards, and release verification. A healthy result means the implemented checks passed for their stated inputs; it does not certify the host or every dependency.
Baseline checks
The security validator confirms that the policy file exists and that runtime protection, audit, and integrity flags are enabled.
Domain controls
Runtime, architecture, evidence, and release subsystems validate their own contracts and fail when required state is missing or inconsistent.
Trust boundaries
Persisted files and command inputs cross a boundary before ACC interprets them as valid state.
Repository inputs
Configuration, policy, manifests, release metadata, and persisted runtime records are inputs to validation. Their presence alone does not establish integrity.
Runtime records
Identifiers, enums, booleans, modes, hashes, and linked record fields are validated before eligible workflows produce another record.
Module and architecture boundaries
Module lifecycle guards and canonical layer policy constrain which operation or dependency may proceed.
Release artifacts
A package, its manifest, version and commit identity, and its SHA-256 sidecar are separate inputs that must agree during release verification.
ACC does not establish a single repository-wide trusted-input designation. Each subsystem validates the fields and relationships it consumes. Operators must still protect the host, repository checkout, configuration sources, and release download channel.
Permission model
Directory access checks, lifecycle ownership, operator decisions, and authorization metadata are distinct controls.
The Security hardening permission guard checks that ACC_ROOT is available and that the runtime and configuration directories are accessible. It does not implement operating-system users, roles, or an ACL system. Module and runtime workflows add stronger domain-specific gates.
The runtime execution guard requires a consistent decision, governance, plan, and approval chain. Missing fields, mismatched targets or actions, unsafe modes, rejected decisions, and expired approvals block or invalidate the chain. Runtime authorization can then issue short-lived, non-replayable capability metadata, but that analysis-only layer explicitly keeps operational execution disabled.
Integrity protection
Do not interpret every use of “integrity” as the same depth of verification.
Security hardening guard
The hardening integrity check verifies that core, runtime, config, and storage paths exist. It is an availability check, not a content hash.
Release verification
Release integrity compares the package filename and computed SHA-256 digest with its sidecar. Release verification also validates versioned release inputs and manifest relationships.
Runtime integrity
The runtime integrity subsystem scans registered runtime state and produces evidence consumed by its gate. Treat its verdict as scoped to registered providers and manifest coverage.
Record chains
Recovery and execution records carry identifiers and hashes that downstream stages validate before accepting the next record in the chain.
Runtime protection
Runtime protection combines basic state checks with subsystem-specific validation and explicit recovery boundaries.
The Security hardening runtime guard checks for the runtime state directory and.acc persistence. Governed runtime workflows separately validate typed inputs, record linkage, freshness, operator decisions, and analysis-only mode. They reject incomplete or inconsistent chains instead of inferring approval.
The analysis-only recovery chain records recommendations, plans, review, approvals, attempts, results, history, audit, and ledger evidence without granting operational recovery. Module lifecycle recovery is a separate controlled path; an analysis record must not be treated as authorization to bypass its guards.
Evidence and audit
ACC records scoped operational facts so later stages can validate provenance and reviewers can reconstruct a workflow.
The Runtime Evidence Vault validates identifiers, action and evidence enums, payload presence, a 64-character SHA-256 digest, duplicate status, chain state, and analysis-only execution flags. Accepted records contain the payload hash and metadata, not the raw payload. Duplicate payload metadata is rejected rather than appended as new evidence.
Recovery evidence stages use exclusive creation for new records, restrictive record and directory modes, and checks against unsafe symbolic-link paths where implemented. Audit and ledger entries preserve linked identifiers and chain hashes. These records are append-only by construction in those workflows; ACC does not claim an external write-once storage guarantee.
Secret handling
The public security profile declares secret protection, but ACC 1.0.0 does not expose a general-purpose secret manager in the Security subsystem.
Do not place secrets in command arguments, identifiers, tracked configuration, logs, manual notes, or audit fields. The Runtime Evidence Vault is the documented narrow exception for raw evidence handling: it hashes the supplied payload and persists the digest with metadata rather than persisting that raw payload in the vault record.
The ACC_SECRET_PROTECTION policy value and the Security Center status line are configuration declarations, not evidence of encryption, rotation, redaction, or integration with an external secret store. Supply and protect sensitive configuration outside this surface.
Security commands
The ACC 1.0.0 command router exposes one view and one baseline validation operation.
acc security
Render the configured baseline profile and the controls reported by the Security Center. This is a status view, not a deep scan.
acc security validate
Load configuration and security policy, then require runtime protection, audit, and integrity policy flags to be enabled. Returns non-zero when the baseline is unhealthy.
No additional acc security subcommands are implemented in this version. Use the release, runtime, architecture, evidence, and audit command groups for their respective domain checks; they are not aliases of security validate.
Operational guidance
Preserve the distinction between a configured baseline, validated evidence, and host-level security.
- Run
acc security validateafter changing the security policy, but do not use it as a substitute for domain-specific guards. - Verify a downloaded release package and its SHA-256 sidecar before installation; keep the manifest, package, checksum, and expected version together.
- Do not bypass module, runtime, approval, architecture, or release guards to force a healthy result.
- Preserve evidence and audit chains; investigate missing fields, hash mismatches, stale approvals, duplicates, and invalid links.
- Keep raw secrets outside tracked configuration and operator-visible command or evidence fields.
- Review warnings and non-zero exits in the scope of the command that produced them.
Security limitations
ACC governs operational integrity inside its implemented workflows; it is not a general endpoint or network security product.
Not host protection
ACC is not an EDR, antivirus, malware detector, firewall, sandbox, operating-system access-control system, or vulnerability scanner.
Not a supply-chain proof
A matching SHA-256 digest proves agreement with the supplied sidecar, not that the publisher, download channel, build host, or dependencies were uncompromised.
Not universal immutability
Exclusive file creation and chain hashes detect or prevent specific workflow failures; a privileged host user can still alter ordinary filesystem data.
Not comprehensive secret management
The baseline flag does not provide encryption, credential rotation, automatic redaction, or a managed secret vault.
Apply the scoped controls
Follow the Runtime guide for governed execution and evidence boundaries, or the Architecture guide for dependency policy and fail-closed guards.