WORM-INTEGRATED ENDPOINT SECURITY

Security on the endpoint. Recovery beyond its reach.

Arivaran Aran is designed to unify endpoint protection with remote, WORM-protected recovery in one agent, one console, and one vendor—from detection and containment through recovery. Current evidence is audit-oriented; containment, enforcement, and recovery choreography remain planned. WORM protection requires the supported S3 adapter with Object Lock enabled; unsupported backends fail closed.

Detect. Contain. Recover. One platform.

Setup neededEndpoint application control

Open the canonical product panel Products

Arivaran Aran protection

Setup needed

The diagram shows the mechanism, its current result, and the limit that remains in force.

Step 1 of 3Detect and record a local decision
Deterministic checks produce a disposition and policy action; the endpoint records the result under the current audit-oriented boundary.
Step 2 of 3Contain and recover — planned choreography
The approved future path coordinates containment with recovery in one platform; current runtime evidence does not make that an available outcome.
Step 3 of 3Evidence boundary
Unknown defaults to AllowWithAlert, not fail-closed block. Coordinated protection and recovery remain planned. WORM applies only to the supported S3 adapter with Object Lock explicitly enabled; other backends fail closed.

Mechanism

Deterministic checks produce a disposition and policy action; the endpoint records the result under the current audit-oriented boundary.

Platform state

Current live endpoint behavior is audit-oriented; real-time endpoint exec-deny remains deferred and platform-specific.

Evidence boundary

Unknown defaults to AllowWithAlert, not fail-closed block. Coordinated protection and recovery remain planned. WORM applies only to the supported S3 adapter with Object Lock explicitly enabled; other backends fail closed.

Before you start

Accepted agent distribution, policy mode, baseline and publisher inputs, audit sink, and platform support.

Evidence reviewed 2026-08-26

Aran products

Overview
Arivaran Aran protection — Setup needed
The shipped local classifier combines baseline, publisher, and behavior-derived evidence into an auditable disposition without an LLM or external analysis service.
1. Mechanism
  Detect and record a local decision
  Deterministic checks produce a disposition and policy action; the endpoint records the result under the current audit-oriented boundary.
2. Current outcome
  Contain and recover — planned choreography
  The approved future path coordinates containment with recovery in one platform; current runtime evidence does not make that an available outcome.
3. Evidence boundary
  Evidence boundary
  Unknown defaults to AllowWithAlert, not fail-closed block. Coordinated protection and recovery remain planned. WORM applies only to the supported S3 adapter with Object Lock explicitly enabled; other backends fail closed.
Platform state
Current live endpoint behavior is audit-oriented; real-time endpoint exec-deny remains deferred and platform-specific.
Before you start
Accepted agent distribution, policy mode, baseline and publisher inputs, audit sink, and platform support.
Arivaran Keybound — Unavailable
The intended clients make hardware use, software fallback, package identity, signing, and provider compatibility separately reviewable.
1. Mechanism
  Custody-aware signing request
  A client requests a bounded operation and reports whether the key remained hardware-protected or used an approved fallback path.
2. Current outcome
  Explicit credential provenance
  The canonical product definition is discoverable while unpublished clients remain non-actionable.
3. Evidence boundary
  Evidence boundary
  Hardware-backed custody is not universal, and no install command is shown until each SDK clears its release gates.
Platform state
Hardware and fallback behavior vary by platform; no language registry or signed client package is claimed available here.
Before you start
Approved product name, package identity, signing, registry publication, hardware matrix, fallback policy, and revocation evidence.
Aran provider verification — Unavailable
The intended verifier or gateway checks a bounded proof and policy context before an upstream service accepts the request.
1. Mechanism
  Proof before provider action
  A gateway validates the request envelope, freshness, identity binding, and configured policy, then returns an explicit accept or reject decision.
2. Current outcome
  A reviewable server integration
  Provider owners can inspect the intended boundary without assuming that in-tree verification code is a supported service.
3. Evidence boundary
  Evidence boundary
  This production-dark panel exposes no endpoint, credential, gateway deployment, or compliance claim.
Platform state
No gateway image, hosted verifier, provider matrix, or SLA is claimed until packaged and accepted.
Before you start
Published verification contract, trust roots, freshness/replay policy, gateway package, provider integration tests, and operations evidence.
Aran Cage — Planned
Copy-on-write materialization, secret exclusion, the Cage execution boundary, and reviewed merge-back form distinct layers of the isolation workflow.
1. Mechanism
  Materialize, confine, review
  The Cage builds a near-free working twin, keeps excluded secrets absent, runs within the platform-specific gate, and inventories changed files for approval.
2. Current outcome
  Disposable work with selective return
  Materialization and merge-back cores are shipped; the cross-platform execution gate retains its own beta and entitlement limits.
3. Evidence boundary
  Evidence boundary
  A disposable twin reduces blast radius but does not imply universal kernel enforcement, entitlement, or platform parity.
Platform state
Materialization and confinement mechanisms differ across Linux, macOS, and Windows; do not infer one platform's gate from another.
Before you start
Accepted Cage package, platform entitlement or fallback, secret policy, execution gate, review surface, and cleanup evidence.
Aran MCP and editor integrations — Unavailable
The intended MCP and editor surfaces reference Aran-owned policy and evidence while retaining independent authentication, signing, and distribution gates.
1. Mechanism
  Tool-to-policy request
  A developer tool sends an allowlisted request, receives a bounded trust result, and links the user to the owning Aran evidence.
2. Current outcome
  Protection context in the workflow
  Integration intent is visible without presenting an unpublished server or extension as available.
3. Evidence boundary
  Evidence boundary
  This production-dark panel exposes no server URL, install command, token, or editor marketplace CTA.
Platform state
No MCP server, editor extension, or marketplace is claimed released until its package and compatibility evidence is accepted.
Before you start
Published protocol and extension packages, authentication scopes, signing, compatibility matrix, and revocation/uninstall paths.