Access Control
Understand how ACC represents who is asking, what exact action is requested, which entitlement applies, why a decision was reached, and what evidence an enforcement boundary must consume.
Current release scope: The exact-permission and protected identity model continues in this release. Server resource binding and controlled action admission add scoped evidence checks without enabling broad operational mutation. Production server observation remains a separate read-only pilot with authority NONE; canonical V2/V3 records stay analysis-only. Review release trust and lifecycle boundaries.
Access control overview
ACC 1.3.3 models access as a chain of narrow, immutable records. No role name, approval flag, successful shell exit, or generic ALLOW string is sufficient on its own.
The canonical runtime access-control surface is distinct from older permission-named compatibility code. The hardening permission guard checks path readiness; the legacy pipeline and middleware checks are not authoritative protected-operation gates. Canonical access decisions come only from the validated canonical chain.
From identity to enforcement
Each stage proves one thing and is prohibited from silently assuming the next.
Identity
Resolve a principal and, for protected paths, bind a time-bounded invocation to authenticated subject and actor evidence.
Entitlement
Validate exact principal-role bindings, permissions, role-permission assignments, and target namespace records.
Decision
Record the request, evaluate matching policy evidence, and persist an immutable ALLOW or DENY decision with its reason.
Enforcement
Resolve the exact adapter mapping and bind the decision, freshness evidence, and protected invocation to the intended operation.
Identity belongs to one invocation
Protected invocation identity is time-bounded, nonce-backed evidence—not a credential store or a reusable session token.
The record binds an authenticated namespace and subject to an operational actor and canonical principal for one intended invocation. Validation checks schema, digest, storage path, permissions, lifecycle, timestamps, expiry, and replay state. Missing, mismatched, expired, replayed, malformed, or permission-unsafe evidence fails closed.
ACC does not implement authentication protocols, password or credential storage, federation, impersonation, delegation, quorum, or break-glass behavior in this record. Authentication happens outside this capability; ACC validates and propagates the resulting bounded identity evidence.
Roles organize membership; permissions name one capability
A role label is not itself permission, and an active membership is not an access decision.
A principal-role binding records membership. A permission names one exact resource type and action, such as permission-module-restart. A role-permission assignment connects those two records. The current exact-permission model intentionally excludes wildcards, inheritance, negative permissions, role-name bypasses, delegation, and dynamic conditions.
Enforcement consumes exact, fresh evidence
An ALLOW decision is necessary but not sufficient to reach a protected adapter.
The downstream binding requires the expected decision, target namespace, adapter mapping, intended invocation, protected identity, and enforcement-evidence freshness to agree. It validates record identity, digests, ownership and private permissions, exact relationships, lifecycle state, and non-replay rules. Missing or ambiguous mapping produces no fallback.
These records preserve EXECUTION_ALLOWED=false. They establish admissible access evidence; they do not themselves execute the operation.
A request to restart one module
The chain answers separate questions instead of collapsing them into “admin allowed.”
- Resolve the caller to a canonical principal and create fresh protected-invocation identity for this restart request.
- Record the target namespace and exact requested tuple: resource
module, actionrestart. - Validate the principal's active role binding and that role's exact
permission-module-restartassignment. - Persist the policy evaluation and immutable access decision, including a DENY reason when entitlement or evidence does not match.
- At the protected boundary, bind the decision to the exact adapter and revalidate freshness and invocation identity before any separate execution system may proceed.
What this capability does not provide
The access chain is deliberately narrower than a complete enterprise identity platform.
Not host access control
It does not create operating-system users, ACLs, sudo policy, network policy, or filesystem sandboxing.
Not authentication
It does not authenticate credentials or establish the truth of an external identity provider.
Not broad RBAC
This exact-permission model has no wildcard, inheritance, deny precedence, resource ownership, tenancy, or dynamic-condition semantics.
Not execution authority
Access, approval, authorization, admission, and execution remain different responsibilities.
Review the contracts behind the claims
The website summarizes the v1.3.3 behavior; repository contracts remain the detailed technical authority.
docs/architecture/contracts/protected-invocation-identity-contract.mddocs/architecture/contracts/permission-contract.mdandrole-permission-assignment-contract.mddocs/architecture/contracts/access-decision-contract.mddocs/architecture/contracts/access-enforcement-binding-v3-extension-contract.mddocs/product/canonical-access-control-downstream-integration-audit.md