Aartiq™ — For The Questions That Matter

"The most important question isn't what you ask AI. It's what AI asks you before it acts."

Aartiq™ is an open-source AI browser that plans tasks, explains non-trivial actions, requests permission when required, and executes through controlled capabilities.

Plan → Explain → Ask → Execute

v0.3.7 — released 2026-09-13.

Latest release: v0.3.7 · full release notes

---

Why Aartiq?

Traditional browsers help you navigate the web.

AI assistants help you understand information.

Aartiq is built for the space between the two: helping AI carry out tasks while keeping the user in control.

Instead of manually opening tabs, searching websites, filling forms, creating documents, moving files, and repeating workflows, you describe the goal.

Aartiq can turn that goal into structured actions, evaluate those actions against its permission model, request approval when required, and execute through registered capabilities.

AI can act. You decide what it is allowed to do.

---

See Aartiq in Action

Prompt:

"Search for today's news, create a PDF summary, move it to my Desktop, and open it."

The workflow:

Understand
    ↓
Plan
    ↓
Explain
    ↓
Ask
    ↓
Execute
    ↓
Result

Permission Workflow

Aartiq searches the web, gathers information, creates the document, requests approval for actions that require it, moves the resulting file, and opens it.

---

Permission-First AI

Aartiq evaluates each command against its registered capability and permission policy.

Actions that require approval are presented before execution with information about what will happen and what resource or capability is involved.

Risk-Based Permissions

Risk tiers are assigned to the capability being invoked, not inferred from the wording of the prompt. They are advisory labels — the control that actually confines execution is OS sandboxing. Read the last column before relying on any row.

For the complete command catalog, risk assignments, and implementation details:

AI Command Reference

---

How It Works

Aartiq converts natural-language goals into structured, permission-aware execution.

┌───────────────────────────┐
│           USER            │
│     Natural-language      │
│           goal            │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│      AI ORCHESTRATOR      │
│ GPT • Claude • Gemini ... │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│      TASK PLANNING        │
│   Structured Commands     │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│   PERMISSION & SECURITY   │
│ Risk • Capability • Scope │
└─────────────┬─────────────┘
              │
              ▼
        ┌──────────────┐
        │   APPROVAL   │
        │   REQUIRED?  │
        └──────┬───────┘
               │
               ▼
┌───────────────────────────┐
│     CONTROLLED EXECUTION  │
│ Browser • Files • OS • OCR│
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│          RESULT           │
└───────────────────────────┘

Actions are exposed through registered capabilities rather than allowing the model unrestricted access to arbitrary system primitives.

---

Security

Aartiq uses a defense-in-depth security model with risk-based permissions, capability controls, directory allowlists, platform-specific sandboxing, encrypted vault storage, and explicit approval workflows.

The security model, including which layers actually enforce and which only advise:

The model has 6 layers. Only 2 of them are enforcement boundaries in the strict sense — controls the OS applies that application code cannot bypass. The rest are policy and first-pass checks, and are labelled as such rather than presented as equally strong.

The full model — risk levels, layer-by-layer detail, encryption & vault migration, and remote-device security — is documented on the Security Model page.

Continuous integration

.github/workflows/jest.yml — on-demand.

Manual dispatch only. There is no push or pull_request trigger, so a green run is not evidence about the latest commit.

Latest green run: #34769503518 (run #52, workflow_dispatch, 2026-09-13, acc703ae, success).

4 jobs. All four jobs were green on the run above. Dispatch inputs can reduce this to 3 (skip-full-suite) or 1 (windows-test-pattern), so this is a default-dispatch count rather than an invariant. Node 24. 30 minutes on the full-suite job; the three sandbox jobs have no timeout configured.

Test counts are generated, not typed. On macOS (local) the full suite reports 1342 passed / 26 skipped / 0 failed of 1368 declared (generated 2026-10-04).

The per-job figures above belong to that run and commit, not to the current tree, which has grown since — for a current figure use the generated macOS line above. The same commit yields a different pass/skip split per platform, which is why every published count carries its environment.

Skip breakdown — macOS (local), 2026-10-04

The suite covers approval gating, params-hash verification, fail-closed sandboxing, directory allowlists, capability scoping, and agent token-binding.

Windows sandboxing (v0.3.7+)

v0.3.7 adds AppContainer + Job Object sandboxing on Windows. Before v0.3.7 the Job Object confined processes only; AppContainer adds OS-layer isolation — filesystem via package-SID ACL grants and network via zero capabilities — by starting the target with CreateProcessW in a suspended state inside the AppContainer and applying the Job Object at creation, so nothing runs even momentarily unsandboxed.

• CI-verified on real Windows (windows-latest): the runtime matrix passes — suspended AppContainer start, OS-enforced ACL allowlist, verified job assignment, grandchild containment, secret isolation, and KILL_ON_JOB_CLOSE all return verified sandbox results.
• Audited: design + source review in Audit Report/2026-09-13_Windows_AppContainer_Sandbox_Audit/SECURITY_AUDIT.md.
• Fail-closed: any policy or setup failure returns a structured SANDBOX_* error; there is no fallback path that runs the command unsandboxed.

Network listeners

Every socket the application opens, and what actually protects it:

One of these binds all interfaces by default with no switch to restrict it. If you run Aartiq on a shared or untrusted network, that is the part to think about first.

Known limits

• Runtime sandbox tests execute only on their own OS. There is no single job that exercises Seatbelt, bubblewrap, and AppContainer at once.
• OS-automation tests skip wherever the native tooling is absent (xdotool/xte on Linux, cliclick on macOS).
• The CRX3 signature-verifier suite is skipped because verifyCrx() hangs on a Node 24 / OpenSSL header parse. It is counted as skipped, never as passing, until the verifier is fixed.
• SecurityValidator.js does not guarantee that non-blocked commands are safe — it is a fast first-pass reject layer.
• Visual extraction reduces the DOM-based prompt-injection surface. It does not prevent prompt injection, and it cannot give semantic immunity against instructions rendered into the viewport.
• Seatbelt profiles start from (allow default), so not every IPC class is denied by default; Mach IPC stays usable because node/python/shell require it.
• Apple Events cannot be filtered by the current sandbox-exec — the operation is not exposed — so a sandboxed command could still ask another app to act on its behalf.
• The WiFi sync server (3004) still binds every network interface by omission and has no token, Host or Origin check; it was changed by neither the listener-authentication work nor the bind-default change. The background task service (3999) and the PDF sync server bound 0.0.0.0 with a wildcard CORS header until the bind default became 127.0.0.1, with AARTIQ_SERVICE_HOST as the explicit opt-in and no CORS allow-origin header sent at all. See network.servers.
• The session token is per-process, so it changes on every restart. A client configured once — a phone, another machine, a scheduled job — has to be reconfigured, and remote mode is not a finished design because of it.
• The token has to travel in the mcp-remote URL, because mcp-remote accepts a bare URL and nothing else. It can therefore appear in a process argument list and in a client's own logs. See aartiq-browser/docs-audit/issues/pairing-token-in-url.md.
• "Allow Always" is keyed on the full normalised command line, which is narrower than before but is still text matching, and a permanent grant has no lifetime. See aartiq-browser/docs-audit/issues/allow-always-granularity.md.
• A permanent grant requires a binary that appears in the classifier's table. One that does not — including anything we have never seen — is offered Allow Once only, because a grant that repeats a command nobody can describe is a promise about behaviour rather than about the text. Local writes such as cp, mv, mkdir and touch are in the table and keep exact-match permanent grants.
• The native bridge and the Agent API both defaulted to port 46203, so if both started one failed to bind and the error was logged and swallowed — not visible from outside. The Agent API now defaults to 46204 and the native bridge keeps 46203, so the two no longer collide.

---

Agent API & Tool Server

Aartiq exposes its browser capabilities to AI agents through a single, security-enforced tool registry served over two transports:

• MCP (Model Context Protocol) for clients such as Claude Desktop, and
• HTTP for local scripts, the in-product assistant, and remote access over Tailscale / LAN.

Every tool call — navigation, tab control, form filling, extension management, snapshots, theming, or OS actions — is routed through the SecurityPipeline before it runs. The pipeline performs risk classification, capability matching, and approval-gating.

Multiple agents, one browser

More than one agent can be connected to the same browser at once. Each connection is registered with a trust level that scopes its verbs and origins. A per-tab lock manager ensures two agents can't collide on form filling.

Accessibility snapshots with stable @ref ids

Instead of raw DOM dumps, agents receive an accessibility (AX) tree. Each interactive node carries an identity-bound @ref id derived from the page's backend node id, so a reference stays stable across navigation and DOM changes.

Form filling

Stored credentials and profiles are kept in an encrypted vault (AES-GCM, passphrase-derived key; the same E2EE2 scheme used elsewhere). A field matcher maps page inputs to stored values by autocompleting password fields and typed text.

Chrome extensions

Extensions can be loaded from an on-disk unpacked directory or installed from the Chrome Web Store. Web Store packages are checked as CRX3 before extraction: installFromWebStore calls the verifier and rejects an invalid signature (fail-closed) — src/lib/extensions/ChromeExtensionManager.js:256-266. The verifier's own test suite is currently skipped because verifyCrx hangs on Node 24's OpenSSL (src/tests/extensions.crx-verifier.test.ts:12-16), so signature verification is not covered by CI and is not claimed here to be runtime-verified.

UI themes and modes

The interface supports selectable themes and UI modes (normal, focus, reader, zen, presentation) that adjust what is shown and how the assistant presents itself, independent of the underlying authentication state.

---

Example Prompts

Try Aartiq with tasks such as:

For every available command and its risk classification:

AI Command Reference →

---

AI Providers

Aartiq supports multiple AI backends, including:

• Google Gemini
• OpenAI GPT
• Anthropic Claude
• Groq
• xAI
• Azure OpenAI
• Ollama (local)
• LM Studio (local, OpenAI-compatible)
• Apple Intelligence on macOS

Provider availability depends on the platform and configuration. Local models (Ollama, LM Studio) keep request content on the device; an OpenClaw-compatible local-agent bridge is also supported for remote inference.

---

Performance

Aartiq opens the Chromium window immediately and loads background services asynchronously, so the interface is usable before every subsystem has finished starting. Long-running automation runs as a background task, not a blocking modal.

Benchmark

Measured on a MacBook Pro M4 Pro, 12-core CPU, 24 GB RAM, macOS 26.5.

2026-07-20 — benchmarked on v0.3.4. Current release: v0.3.7.

Startup means time to first visible window, not complete service initialisation. Results vary by hardware, operating system, and configuration.

These figures predate the current release (v0.3.7) and were taken on v0.3.4. TODO(verify) — no benchmark script, raw output file, or instrumentation exists in either repository. These figures cannot currently be reproduced or checked. A published page also claimed the benchmark scripts were included in the repository; that claim was false and has been removed.

Detailed measurements and methodology:

Performance Benchmarks →

---

Installation

Pre-built Binaries

Download the latest release from:

Aartiq Releases →

macOS

If macOS blocks the application:

xattr -cr /Applications/Aartiq.app

Build From Source

git clone https://github.com/Latestinssan/Aartiq.git
cd Aartiq/aartiq-browser

npm install

# Next.js development server
npm run dev

# Electron shell
npm run electron-start

Android

cd flutter_browser_app

flutter pub get
flutter run

---

Documentation

The GitHub README provides the product overview. Detailed architecture and implementation documentation lives on the Aartiq documentation site.

---

Contributors

Built by Latestinssan with contributions from the community.

Fetched from the GitHub API. Refresh with npm run docs:repo-facts.

---

[!IMPORTANT]

🚧 Project Status

Aartiq is a solo project maintained in an AI-assisted rhythm: AI agents handle day-to-day issue triage, analysis, and fix preparation, and a human reviews and approves every change to security, permissions, user data, or releases before it ships. Development currently runs at a limited pace around academic commitments — feature work pauses and resumes in bursts rather than on a fixed schedule. The repository stays public, existing releases stay available, and bug reports go to GitHub issues, triaged in the order things break. In short:

• Every change to security, permissions, user data, releases, or project direction is reviewed and approved by a human before it ships.
• CI must be green before any release goes out (see the Security section above for the current test numbers).
• The maintainer remains responsible for the project's direction and correctness.

Why this setup: it lets a solo project keep shipping fixes and improvements without requiring full-time human bandwidth on every routine task, while keeping a human in the loop for anything consequential — which is the same philosophy Aartiq applies to its own permission model.

Bigger roadmap items (new features, larger refactors, community contribution workflows) are paused until there's more bandwidth or contributors to support them. Bug fixes, security patches, and documentation stay actively maintained.

Issues, PRs, and questions are welcome — response time may vary, but nothing ships without review.

— Latestinssan

Terminology

---

License

[!NOTE] Licence conflict resolved (2026-10-04). aartiq-browser/LICENSE.txt now carries the same Apache-2.0 text as the repository root, the package manifest declares Apache-2.0, and the Windows installer points at that same file — so installer, manifest and repository agree. The decision, including the EULA it replaced, is recorded in aartiq-browser/docs-audit/licence-decision.md. docs:check rule (j) fails if the copies ever disagree again.

The MCP server is MIT-licensed for compatibility with Claude Desktop and other MCP clients.

Trademark

Aartiq™ is a trademark of Latestinssan.

Aartiq™ is a trademark of Latestinssan. The open-source licence permits use, modification, and redistribution of the source code. It does not grant permission to use the Aartiq name, logo, trademarks, or visual identity. Modified distributions must be rebranded under a different name and must not present themselves as official Aartiq releases.

---

For The Questions That Matter.

The most important question isn't what you ask AI. It's what AI asks you before it acts.

Plan → Explain → Ask → Execute

Aartiq™

© 2026 Aartiq™. All rights reserved.