Skip to main content
AcornOps uses defence in depth. A platform decision does not replace the controls already present in a Kubernetes cluster or Linux VM. Each request must pass the platform’s identity and policy checks, any required human approval, and the target’s local enforcement.

​
Defence in depth

Authorization is checked again at dispatch and before tool execution. Changing a user’s role or a target’s policy therefore does not silently widen an already compiled run.
An approval authorizes one requested operation. It does not bypass workspace permissions, the run scope, Kubernetes RBAC, or a VM’s local policy.

​
Secure connectivity model

Targets initiate their connection to the central platform. You do not need to expose an inbound AcornOps control port on each connected cluster or VM. AgentK and AgentV authenticate with target-specific credentials and establish outbound WebSocket connections to the control plane. AgentK uses its existing cluster-key flow. AgentV onboarding exchanges a 15-minute one-use token for a durable credential that is returned only to the root installer. The connection carries heartbeats, capability metadata, snapshots, and bounded tool requests. Target access stays with the connector inside the environment. AgentV is read-only by default. Read-write onboarding binds one to 32 exact non-AgentV systemd services to the one-use enrollment. The root installer writes that policy and enables the privileged socket; the copied command cannot widen it. The local allowlist remains a capability ceiling. The VM run permission policy independently chooses read-only, approval-required, or reviewed non-destructive automatic changes. Updating the host allowlist requires another one-use root command, pauses writes until commit, and rolls back to the previous policy and credential on failure. No control-plane setting can authorize a service outside the applied local allowlist. Outbound connectivity describes the direction in which the session is established. Administrators must still restrict egress to the expected AcornOps endpoint, validate TLS, protect connector credentials, and apply least-privilege target policy.

​
Credential boundaries

AcornOps uses different credentials at different boundaries:
  • Browser users authenticate through the configured identity provider and use a cookie-backed control-plane session.
  • Target connectors use target-specific credentials; AgentV durable credentials are stored only on the VM and hash-only in the control plane.
  • Internal services use dedicated service credentials.
  • Model and tool calls use run-scoped tokens that bind the workspace, target, run, provider, model, tools, and output budget.
Secrets for providers and remote MCP servers remain in the configured secret backend. They are not included in prompts or ordinary run events.