Core Concepts
Anchor keeps its object model explicit so operators can trace access from intent to evidence.
Users represent people or service actors that authenticate to Anchor and receive permissions. Permissions can be global for platform-wide administration or scoped for delegated operation inside a specific boundary.
Anchor separates broad administration from day-to-day operation. A reviewer can inspect permitted records without inheriting write, rotation, reveal, or session authority, while an operator can be allowed to verify or rotate only the resources that belong to their scope.
Scopes
Section titled “Scopes”Scopes group resources and define an administrative boundary. They are the starting point for delegated operations, inherited visibility, policy assignment, and access review.
Good scopes usually match operational responsibility: an environment, application, infrastructure domain, or team boundary that reviewers can understand.
Resources
Section titled “Resources”Resources are managed targets such as Linux accounts, databases, infrastructure accounts, or other privileged objects. A useful resource record carries host or endpoint metadata, account identity, owner context, scope, status, last verification, last rotation, policy relationship, and job history.
Resources are not passive inventory. They are the object Anchor uses to decide whether privileged work should proceed and what evidence should exist afterward.
Accounts
Section titled “Accounts”Accounts represent privileged identities associated with resources. Account context matters because the same host can contain multiple privileged identities with different owners, risks, lifecycle expectations, and policy requirements.
Anchor keeps account hygiene close to the operating workflow: stale accounts, missing owners, failed verification, overdue rotation, reconcile relationships, and standing access all become review signals instead of spreadsheet chores.
Policies
Section titled “Policies”Policies describe how a resource is accessed, verified, rotated, reconciled, retrieved, brokered through sessions, and reviewed. Policy bindings attach that logic to a scope or a resource so the control model follows the operational boundary.
The important review question is not only “which policy exists?” It is “which policy is effective for this target, where did it come from, and why did Anchor apply it?” Anchor’s effective-policy and resolved-behavior concepts make those answers visible.
Jobs and Ledger Events
Section titled “Jobs and Ledger Events”Execution jobs represent operational work: verification, rotation, reconciliation, bulk actions, scheduler activity, and other controlled workflows. Job steps help operators understand the path from request to result without hiding the details in backend logs.
Event logs and audit logs preserve what happened, when it happened, who initiated it, which object was involved, and what result was produced. Anchor Ledger strengthens that history with tamper-evident integrity for security-relevant events.
Compass and Ratings
Section titled “Compass and Ratings”Anchor Compass turns product state into operational insight. It connects policy coverage, account hygiene, drift, verification, rotation, logs, sessions, and Ledger integrity into reviewable findings.
Compliance Ratings summarize privileged access health so teams can see where attention is needed: missing policy coverage, stale accounts, failed verification, overdue rotation, drift, unresolved failures, and evidence gaps.
Review Posture
Section titled “Review Posture”Users, scopes, resources, accounts, policies, jobs, sessions, logs, and posture signals should stay connected. That shared vocabulary is what makes Anchor easier to operate and easier to explain during review.