Trust & security
Maintained by the Aarmos team. Not an independent audit or certification.

Verify it yourself

Don't take our word for it. The open AVAR reference verifier — Ed25519 signatures + hash chain, Apache-2.0 (@avar-standard/verify), runs offline with zero Aarmos dependency. Verify any signed receipt bundle in one command:

npx -p @aarmos/cli aarmos verify path/to/bundle.avar.zip

Why you can trust the gate

Something has to stand between the model and your tools. Here's why it's this:

  • Local-first. The gate runs in your browser. Prompts and tokens don't transit an Aarmos server.
  • BYO-LLM. Your model, your key, your bill. Calls go directly to OpenAI, Anthropic, Google, Groq, OpenRouter, Ollama, or any OpenAI-compatible endpoint.
  • One gate, every protocol. MCP, OpenAPI, Bearer, deep-links, OAuth, and A2A — all through the same consent, policy, and signed-audit layer.
  • Signed receipts, not marketing copy. Consent decisions land in a chain-linked on-device ledger with verifiable chain integrity; Community and above adds Ed25519-signed run traces exportable as an .avar.zip bundle.

Scope and limits: see the threat model below.

Controls that ship today

On-device vault

LLM keys and OAuth tokens live in an AES-GCM locker in browser storage. Set a device password and the vault key is wrapped via PBKDF2-SHA256 (WebCrypto), with a one-time recovery code. Required before connecting any OAuth service.

Vault →
Per-tool consent

Every call resolves to allow, ask, or deny. Session and 24-hour grants are logged. Writes, sends, deletes, and payments require explicit approval by default.

Permissions →
Tamper-evident audit ledger (AVAR)

Consent decisions append to a chain-linked on-device ledger with verifiable chain integrity. Community and above adds Ed25519-signed run traces — tool calls, provider handshakes, delegation steps — exportable as an .avar.zip bundle any auditor can verify offline in a browser or the portable avar CLI. Open spec: AVAR 1.0 (normative), CC BY 4.0; the verifier is Apache-2.0.

Audit →
Verify a bundle

Drop any receipt bundle to check signatures, chain integrity, and envelope — the same checks the portable avar CLI runs offline. Pin a signed trust manifest first and every governance-stamped entry reconciles against it. Runs on-device; nothing uploaded.

Open verifier →
Verify this build

Re-hashes a sample of the served PWA assets and verifies the release manifest against a hard-pinned Aarmos key. Runs on-device. Never blocks execution.

Verify build →
Kill switch

Operator-controlled kill switch producing signed evidence of every intervention — the oversight primitive referenced by EU AI Act Art. 14 and NIST AI RMF MANAGE-2.3 (mechanism claim, not a compliance claim). Cockpit chip, triple-Esc panic gesture, scoped kill (all / writes / destructive). Every toggle is a signed AVAR receipt on the same chain as tool decisions.

Posture →
Policy-as-code (ASP)

Author signed policy bundles in reviewable YAML. Lint, golden-test, and sign offline with the aarmos CLI, then ship via your GitOps pipeline. Evaluation and signing run on your machines — no hosted control plane.

ASP spec →
Compliance mapping

AVAR receipts map to evidence expectations in EU AI Act Art. 12 & 14, HIPAA §164.312(b), SOC 2 CC7.2, NIST AI RMF MEASURE-2.7 & MANAGE-2.3, and ISO/IEC 42001 §8.4. Mechanism claim, not a certification.

Mapping →
Encrypted portable backup

Export an AES-GCM bundle: vault, connector configs, agents, policy state, optionally the ledger. Restore with the device password or recovery code. Fingerprint verification catches tampered files on import.

Device →
Connector egress observability

Every Connector fetch (MCP, OpenAPI, A2A, deep-link) is stamped into an AVAR receipt with destination, tool, protocol, and outcome. Enforced at the Connector boundary — no TLS decryption. Honest scope: covers Connector fetches only; XHR, WebSocket, SSE, sendBeacon, and OS syscalls are not observed here — daemon and OS tripwires are on the roadmap.

Posture →
Signed org policy + break-glass

Import an admin-signed JSON bundle (Ed25519) pinning allowed MCP servers, tools, and OAuth scopes. Invalid, expired, or untrusted bundles are ignored. A kill-switch bundle disables every tool until admin ships a fresh one. Offline devices keep enforcing the last valid bundle for up to 7 days.

Import policy →
Bounded agent delegation

Delegation depth caps at 4; allowlists intersect at every hand-off — a callee never widens its caller's authority. Every hand-off is stamped in the receipt's delegation chain.

Agents →
Decision-level governance

A decision is the smallest governable business action. Aarmos records which participants were required, which inputs they consumed, how each responded, and the composed verdict — then seals it into the receipt. Decision identities are permanent, so the same decision can be replayed and compared later. Aarmos orchestrates the evaluation and records the outcome; it does not invent business rules.

Decision governance →
Evidence delivery (Team and Enterprise)

Forward workspace audit events to Splunk HEC, Datadog Logs, or an HMAC-signed webhook as they are written. Only the event envelope leaves — never chat, tool results, keys, or tokens. Delivery credentials are referenced by env-var name, never stored. Team includes one destination; Enterprise removes the cap.

Evidence delivery →
Append-only evidence, disposable operations

Execution evidence is append-only and leaves only through the retention policy — there is no delete. Governance state changes are receipted: archiving an agent stops it running, restoring it grants authority again, and both are signed. Conversation transcripts are navigation, not evidence, so you can clear them at any time; the run row survives with the prompt and reply removed.

Principles →
Evidence portability

Your evidence is yours to take. Export the full signed corpus at any time as an .avar.zip bundle and verify it with the open-source avar CLI — no account, no network call, no Aarmatix involvement. The receipt format is an open specification (CC BY 4.0) and the reference verifier is Apache-2.0, so a bundle stays readable and checkable long after any contract with us ends.

Verify a bundle →
Evidence relay, if you want one

Governance is local-first. Evidence aggregation is optional. The relay transports governance evidence and never participates in governance: it never transforms, normalizes, enriches, repairs, or interprets, so stored bytes are the bytes your device signed. Evidence arrives under a typed contract with size ceilings; policy evidence is a separate class you can encrypt independently. You choose where the relay runs — hosted by us, your own object storage, or your own environment — and every implementation must pass the same published conformance checks: hashes, signatures, ordering, replay, offline verification, and byte preservation. A relay outage is not a governance outage.

What the server sees →
Stated boundary of the runtime

Aarmos governs the execution of declared governance. It does not determine what governance ought to be. Decision definitions, business rules, participant logic and policy content belong to you; execution, composition, evidence and replay belong to us — and every contribution is named on the receipt. Both lists are published, so there is no gap between what we promise and what the receipt shows.

Shared responsibility →

PWA cockpit + native CLI (not Electron)

Two surfaces on purpose — a security decision, not a packaging shortcut.

  • Native where it matters — CLI and local bridge. Filesystem, subprocesses, and stdio MCP run in the aarmos CLI under your OS account: signed Node binary, real process isolation, OS-level permission boundaries.
  • Web where it matters — the cockpit. Consent, audit review, policy import, and kill switch ship as a PWA: no auto-update trust problem, no code-signing cert to rotate, and reviewers inspect the exact artifact at a URL before installing.
  • Electron wouldn't move the vault threat model. Against a compromised device both lose; against a network attacker both are fine. Extension-isolation wins are already covered by the CLI on the sensitive surfaces.

Want a dock icon? Use "Install app" / "Add to Home Screen".

Enterprise identity (SSO / SAML)

Today: Team uses invite-based membership with signed org policy bundles pinning allowed tools, MCP servers, and OAuth scopes. Every change is a signed receipt on the tool-decision chain.

Enterprise (shipped): SAML 2.0 SSO (Okta, Entra ID, Google Workspace, OneLogin, Ping), domain binding, and SCIM 2.0. SSO binds a per-install Ed25519 keypair to your directory — policy evaluation and enforcement stay on the local runtime; no Aarmos-hosted service sits in the enforcement path. See Enterprise →

Threat model

What the gate defends against, what you inherit, and what it explicitly doesn't cover.

Designed to protect against
  • Casual filesystem inspection of your browser profile

    Keys and OAuth tokens live in an AES-GCM vault (WebCrypto). With a device password, the vault key is KEK-wrapped via PBKDF2-SHA256 at 600k iterations (OWASP 2023 minimum). Required before connecting any OAuth service.

  • Silent tool execution by an LLM agent

    Calls resolve to allow / ask / deny against rules you own. Session and 24-hour grants are logged. Writes, sends, deletes, and payments are denied by default.

  • Server-side theft of prompts, tokens, or agent history

    Chats go directly from your device to your LLM provider. There is no chat proxy and no server-side store of prompts, API keys, or OAuth tokens. Accounts, licenses, team pointers, and — if you enable it — relayed receipts do live on our servers; see the privacy notes for exactly what each holds.

  • Tampered audit trail

    Chain-linked on-device ledger with verifiable chain integrity; Community and above adds Ed25519-signed run traces reviewers can verify from the JSONL export.

  • SSRF from model-directed HTTP calls

    The http_request tool blocks private, loopback, and link-local ranges (RFC 1918, 169.254, ::1, mapped IPv6, numeric-form tricks), disables redirects, enforces HTTPS, and caps body size and timeout.

  • Untrusted org policy bundles

    Ed25519-verified against a trusted issuer set; invalid, expired, or untrusted bundles are ignored. A 60-second heartbeat re-verifies the active bundle so rotation, expiry, or tampering flips enforcement immediately.

  • Runaway sub-agent delegation

    Depth caps at 4; allowlists intersect at every hand-off — a callee never widens its caller's authority. Both bounds are hard-denies and appear in the receipt.

  • Accidental credential leakage into prompts, logs, or the ledger

    A pattern scrubber redacts known credential shapes (sk-*, Bearer *, JWTs, provider-prefixed keys). Custom regex rules supported. Reduces leakage; doesn't replace keeping secrets out of prompts.

  • Off-device ledger tamper claims

    Export an anchor receipt (chain head, counts, device pub-key) and pin it off-device (email, S3 object-lock, webhook); later tampering can't reproduce the anchored head.

  • Injected scripts and third-party frames in the PWA

    Strict CSP pins script, style, frame, object, and worker sources; frame-src 'none'; base-uri and form-action locked to 'self'. Referrer 'no-referrer'. Permissions-Policy denies camera, mic, geolocation, payment, USB, and cohorts.

Residual risks you accept by using Aarmos
  • Your LLM provider sees prompts and tool arguments

    Inherent to BYO-LLM. Pick a provider whose terms you accept. For maximum privacy, use Ollama — chats never leave localhost.

  • OAuth providers see the API calls you make

    Google, GitHub, etc. see requests under your existing scopes — unchanged from using them directly.

  • Vault security depends on password strength

    600k PBKDF2 iterations is the OWASP 2023 minimum. A weak password lowers the bar for offline attacks on a stolen export.

  • MCP servers you connect can misbehave

    You trust each server you configure. Aarmos blocks tools outside a signed allowlist but can't audit third-party server internals.

  • License enforcement is local

    License check runs client-side. Exists for honest billing, not DRM.

Does NOT protect against
  • A compromised device or OS

    If your machine is rooted, keylogged, or has a hostile admin, no browser vault saves you. Aarmos raises the cost of a filesystem grab — that's all.

  • Malicious browser extensions

    Extensions with page access can read the vault after unlock and see prompts in flight. Audit your extensions.

  • XSS in a connected MCP server's rendered output

    If a compromised MCP server returns HTML a downstream tool renders unsafely, that's outside our surface. Aarmos doesn't use dangerouslySetInnerHTML on model output.

  • Physical access to an unlocked device

    Auto-lock (5/15/60 min) and lock-on-tab-hide shrink this window; they don't eliminate it.

  • Supply-chain attacks on browser dependencies

    We pin and audit npm dependencies but aren't immune to a poisoned upstream.

  • Regulated-data compliance (HIPAA, PCI, FedRAMP, SOC 2)

    Not certified against any of these today. Don't use it for workloads requiring attested controls.

  • Nation-state adversaries

    If you're a target, you need OS attestation, hardware tokens, and air-gapped review — well beyond a browser app.

Deep dives

Where data goes

Chat prompts & tool argumentsYour chosen LLM provider (direct)
LLM API keysOn-device; encrypted backup only
OAuth tokensOn-device AES-GCM vault
Tool call payloadsDirectly to the MCP server / API you configured
Consent decisions & audit logLocal ledger only
Receipts, if the workspace relay is onYour Aarmos workspace (opt-in, Team/Enterprise)
Account, license & team recordsAarmos servers
Static app assetsAarmos CDN (page load only)
Ollama traffic (if configured)localhost:11434 — fully on-device
Shared responsibility

Aarmos ships the gateway, vault, consent engine, ledger, and kill switch, and executes the governance you declare. You pick which LLM, MCP servers, and APIs to trust; hold the device password and recovery code; author the policies; and decide what agents can do. Aarmos does not determine what your governance ought to be, and nothing on this page is a certification, audit opinion, or legal advice. Providers handle requests under their own terms.

Reporting a security issue

Found a security or privacy issue? Send reproduction steps — and a proof of concept if you have one — to support@aarmatix.com or through Support. We aim to acknowledge reports quickly and do not intend to pursue good-faith research conducted without harming users or data.

Contact support →
Last updated: August 6, 2026.