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.zipWhy 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.zipbundle.
Scope and limits: see the threat model below.
Controls that ship today
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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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 →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
aarmosCLI 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.
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.
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.
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
How signed AVAR receipts turn agent activity into evidence auditors can verify offline.
Open →How prompts, tool payloads, and memory are scoped, redacted, and kept on-device.
Open →Policy bundles, kill switch, consent gates, and delegation caps that shape every run.
Open →Where data goes
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 →