Arxi Decision Gate Asset Core
Docs
Asset Core Docs

Deterministic world-state engine documentation and API references.

Decision Gate docs

Authorization Model

Asset Core uses a default-deny authorization model. Every request is authenticated, mapped to a principal, and evaluated against role-based permissions and namespace governance rules. The goal is to keep the behavioral contract stable: access decisions are deterministic, auditable, and resistant to information leakage.

This page describes the model you can rely on. It avoids internal implementation details so the contract remains correct even as the runtime evolves.

Core entities

Principals represent authenticated identities. A principal carries a tenant, a set of roles, and optional group or agent context. Authorization decisions always resolve to an explicit principal or deny by default.

Roles map to permissions. Permissions are defined over the public operation catalog (API endpoints and commit-world operations). Unknown roles or unknown operations never grant access.

Reverse commit is a distinct API operation. Grant it explicitly when you want principals to request stored reverse plans against retained commits; do not assume commit access implies reverse commit access.

Namespaces are the primary isolation boundary. Most operations are namespace-scoped and require namespace context to evaluate access.

Default-deny posture

Asset Core assumes untrusted inputs. If any of the following is missing or invalid, the request is denied:

  • No valid principal context.
  • Missing or unrecognized role assignment.
  • Missing namespace context for a namespace-scoped operation.
  • Policy class restrictions that prohibit the requested operation.

This posture is central to the system’s auditability and deterministic behavior in adversarial environments.

Namespace access control (ACLs)

Namespaces can attach access control bindings that grant or deny roles to specific principals or groups. These bindings are additive and override the tenant-level role set for that namespace. The model supports explicit deny bindings and prevents unauthorized access even when a principal is valid at the tenant level.

Use ACLs when you need per-namespace isolation, delegated access, or temporary restrictions during incidents.

Policy classes and risk gates

Namespaces are assigned a policy class (for example, scratch, project, or production). Policy class gates enforce stricter rules in higher-risk environments. This allows you to run lower-friction experiments in scratch environments while enforcing tighter controls in production namespaces.

Policy classes are part of the public contract. If a policy class forbids an operation, the request is denied even if the principal has a broad role.

Disclosure posture (401/403/404)

Authorization outcomes are designed to avoid information leakage. If a namespace is unknown or inaccessible, the system responds with a denial without revealing existence. Authentication failures yield 401, authorization failures yield 403, and quota or throttling yields 429. See the Error Model for the full mapping.

Audit and traceability

Every decision can be correlated through server correlation IDs and optional client correlation IDs. This makes it possible to trace access denials back to an exact request, token, and namespace context in logs and metrics.

Non-goals

The authorization model does not attempt to infer intent or implement business-specific policies. It provides a strict, deterministic enforcement layer; domain-specific rules should be encoded in your application logic or operational procedures.

Next steps