What AariaSec monitors, per platform

This page states what works, what is partial, and what is absent. The gaps are listed as plainly as the capabilities, because a capability matrix that hides them is worthless to the person doing a security review.

Core capabilities

Where Windows is weaker

Kernel scope lock has run on real Windows hardware, and formal sign-off is the one thing still open. macOS enforces via Seatbelt and Linux via Landlock and seccomp, both verified against a real kernel. The Windows tier — AppContainer isolation with Windows Filtering Platform egress filters — has now been tested directly on a Windows machine, not just cross-compiled and unit-tested. That testing found and fixed four real defects, the most serious being a cleanup bug where a launcher's own state was left behind after every run and corrupted on reuse; the fix was proven with the same policy launched ten times in a row with zero manual cleanup — nine of ten runs crashed before the fix, ten of ten ran clean after it. What has not yet happened is a single clean, fully-captured pass of the complete automated verification script end-to-end (the attempts so far were cut short by a terminal-capture issue during the run, not a code failure, on the evidence gathered — but that is inference, not the same thing as watching the actual transcript). Until that clean run exists, treat this tier as strongly evidenced rather than formally signed off, and don't plan a production rollout around it yet. Proxy-level containment on Windows is proven and available today — destination denial, per-agent routing and throttling, and the kill-switch all work — but that is a network boundary, not a kernel one.

Two further caveats apply to the Windows tier even once verified. There is no user-mode syscall filter on Windows, so the seccomp tier has no equivalent and none is claimed; each enforcement receipt instead reports, per deny-list entry, whether the intent is covered and by what mechanism. And execute scope is all-or-nothing: blocking all child processes is enforced exactly, but a policy naming specific executable paths is not enforced path-by-path as it is under Landlock.

Process termination is partial. Egress blocking is reliable; killing a misbehaving process is not, in every case.

The in-app Containment Escape demo does not run on Windows. It executes against a real scope-lock binary, and there is none for Windows, so it refuses rather than simulating a block it did not observe. We would rather it decline than fake a pass.

Where Linux differs

Enforcement uses Landlock and seccomp, which cannot express a destination deny-list — the kernel has no concept of a hostname. Host-based controls are therefore enforced at the proxy on Linux, not in the kernel. The eBPF monitor observes syscalls; it does not block them, because blocking would require an LSM hook and we ship none.

What gets inspected

Only known LLM endpoints are TLS-terminated. Everything else tunnels through untouched — your email, your banking, your internal systems are not decrypted.

Browser assistants routed through their provider backends are covered, including Brave Leo, Opera Aria, Edge Copilot, Chrome and web Gemini, Perplexity, Arc Max, and any browser running a third-party AI extension.

What this misses: an agent talking to a private inference server we do not know about is not inspected until that host is added. An agent that hardcodes its HTTP client and ignores proxy settings is not visible to the proxy at all — on Linux the eBPF monitor still sees the connect syscall, which is why the gap between what the proxy sees and what the kernel sees is itself a signal.

The privacy boundary

Prompt and response text is reduced to a SHA-256 fingerprint at the moment of capture. No raw content is written to disk, to logs, or to a database, on any platform. What is retained is behavior: which tools ran, in what order, how much data moved, where it went, how long it took.

This is architectural, not a setting you can turn off or forget to turn on. It is also why we can hand you the entire audit trail — there is nothing in it to leak.

Detection review

The debate panel runs on a local Ollama model by default, so no data leaves your machine. You can point it at your own OpenAI-compatible endpoint, at a hosted provider if you accept that egress, or disable it entirely — in which case you get a deterministic rules-based verdict with confidence capped and no automatic blocking. A disabled panel is never a silent one.

Compliance evidence

Generated from real activity, on your hardware:

• EU AI Act, Article 12 — logging and traceability for high-risk AI systems
• GDPR, Article 22 — automated decision-making records
• HIPAA Security Rule — audit-control evidence, cited to the safeguard
• DORA — ICT risk-management evidence for Articles 10, 17, 19 and 13
• SOC 2 and ISO 27001 — control evidence collectors
• OWASP mapping and SARIF export — for tooling you already run

These produce evidence. They are not certifications, and installing AariaSec does not make you compliant. A report over a period with no activity returns not assessed rather than compliant, because "we saw nothing" is not evidence that a control works.

We hold no SOC 2 ourselves yet. The security review section states that position control by control, including the ones only partially met.