Encrypted and sealed
Every managed password and key is encrypted with AES-256-GCM before it is stored. The keys that encrypt them are themselves sealed, and only Core can unseal them; its seal key is root-owned and read-only.
Security & Insight
How Anchor protects the credentials it holds, keeps each part to its own job, controls who can act, and proves what happened.
Built secure, layer by layer
Section titled “Built secure, layer by layer”A privileged access platform is only as strong as its weakest part, so Anchor does not rely on one. Each layer below holds even if another is bypassed.
Each part holds only its own
Web, Compass, Engine and Connect never hold a database address, an encryption key or a signing secret. Engine never carries a session; Connect never changes a credential.
Mutual TLS on every link
Every connection between Anchor's parts uses TLS 1.2 or newer with both ends verified, even on a single host. Database connections check the server against the deployment's own CA.
Nothing listens without a reason
Engine and Compass open no port at all. Every service binds one exact address, and only Web may use a privileged port.
One locked account per service
Each service runs as its own unprivileged account. Anchor's administrative accounts are locked with no shell, and any attempt to sign in to them is audited and alerted.
Contained by default
Every service runs under systemd protections: a read-only system, no new privileges, private temporary files, kernel and namespace restrictions, and only the capabilities it needs.
Signed from download to upgrade
Releases are signed and the installer verifies itself before it runs. Packages come from signed apt and dnf repositories, and upgrades roll out signed releases.
Host changes need two keys
Operations on Anchor's own hosts, such as a database switchover, run only when Core has signed them and an administrator approved them within five minutes.
No password to a stranger
Anchor will not send a credential to a server it cannot identify. Host keys are approved first, and a changed identity stops connections until someone reviews it.
Checked, not assumed
Section titled “Checked, not assumed”Anchor ships with its own hardening check. It runs every time a host is validated, and an administrator can run it from the console at any time. It fails the validation if a required control is missing, and it verifies, among others:
- the seal key and every private key are owner-only and in restricted places;
- database credentials sit in owner-only files, never in shared configuration;
- no secret has leaked into the configuration of Web, Compass, Engine or Connect;
- Anchor’s administrative accounts are locked;
- every database connection verifies the server and its certificate chain;
- service sandboxing matches the chosen profile.
The result is written as a report you can keep with your evidence.
Access is deliberate
Section titled “Access is deliberate”- Roles grant permissions for the whole installation or for one Scope. Every request is checked on the server; what the browser hides is only a convenience.
- Multi-factor authentication with authenticator apps, security keys or passkeys, and sign-in through your directory over LDAPS or StartTLS.
- Sensitive actions ask again. Revealing a password, changing settings or operating Anchor’s own hosts needs a fresh confirmation of identity.
- A break-glass account keeps a way in if every administrator is locked out, with every use alerted and audited.
- Maintenance access to Anchor’s own hosts opens only in an approved, time-boxed window, as a recorded session.
Evidence you can rely on
Section titled “Evidence you can rely on”The audit trail is append-only and cannot be turned off. Each record keeps who acted, under which authority, on what, why, and the result, and is copied to a separate Evidence database that your SIEM reads through read-only views.
What stays yours
Section titled “What stays yours”Anchor hardens only what it owns. Your firewall, SSH server, operating system patching and time source stay under your standards: Anchor never changes them, and its uninstaller removes the host changes it made.
Insight with context
Section titled “Insight with context”Posture & GRCCompassSee ratings, control alignment, and the evidence behind them.
Ratings are evidence-based; missing information remains visible rather than becoming an assumed pass. Framework mappings help connect technical findings to governance, risk, and compliance reviews.
Advisory ReviewInsightsAdd context to what matters and what to investigate next.
Insights adds an advisory perspective to findings and curated evidence. Your team retains authority over changes, with policy and review still part of the decision.
Support With ContextAnchor AssistBring your question and relevant diagnostics into the conversation.
Assist’s approach centers on scoped, sanitized information and a path to human help. Approved diagnostics support the investigation and keep the conversation focused on your issue.
Clear AccountabilityConnected EvidenceFollow who acted, why it was allowed, and what happened.
Evidence stays linked to actions and the resources they affect. This provides context for operational investigation and assessment work, instead of treating history as a separate task.
Insights runs inside Anchor by default; no record is sent to an external AI service unless an administrator chooses a provider, and then only redacted context travels.
Compliance-minded by design
Section titled “Compliance-minded by design”Anchor is designed to support SOC 2 and FedRAMP control requirements. Evidence and control alignment support your compliance work; they do not constitute certification or authorization.