Security
Any management agent with execution privileges is a security commitment. We don't minimize it — we engineered for it. This document describes, by threat model, what stands between the model and your machines: the deterministic safety pipeline, the cryptographic verifications on both ends of every connection, and the residual risks we consider honest.
Every remote management tool — ConnectWise, Datto, NinjaRMM, Kaseya, and now Aorka — creates the same fundamental trade-off. You gain centralized control. You also create a high-value target. If the control plane is compromised, every connected endpoint is at risk.
This is not unique to AI-powered tools. It is inherent to the RMM model. What is unique to Aorka is that the AI layer adds security constraints conventional RMM tools lack entirely. In a conventional RMM, an operator types a command and it executes — no analysis, no scoring, no second opinion. Aorka's pipeline introduces three independent safety layers before anything runs.
We built Aorka assuming the control plane would be targeted. Every design decision in this document reflects that assumption.
Threat hypothesis
If an attacker compromises Aorka's central control plane, they could run commands on everything at once.
Threat hypothesis
An attacker could trick the AI into bypassing safety filters and executing unauthorized commands.
This is the most common concern about AI-powered tools, and it reflects a real risk in systems where the AI has direct execution authority. Aorka's architecture is specifically designed so that the AI never has direct execution authority. The safety pipeline that gates every command is not itself AI.
The key insight: prompt injection can make a model suggest a dangerous command. It cannot make a regex filter misclassify it. It cannot make a human click “Approve.” It cannot forge a cryptographic job signature. The layers that matter most are not AI.
Threat hypothesis
If Aorka's update server is hijacked, a malicious agent version could be pushed to your entire fleet.
Threat hypothesis
The agent requires elevated privileges. If it is compromised, the attacker inherits those permissions.
This is accurate and unavoidable. The agent requires elevated privileges because it needs to manage services, query directories, install updates, and perform the operations IT teams require. Every RMM agent has this same requirement.
The mitigation is not reducing privileges (which would make the tool useless) but controlling what those privileges are used for:
The Rule of Two, established by the Chromium security team, states that a component must never combine more than two of three dangerous properties: untrustworthy input, unsafe implementation language, and high privilege. If all three are present, a single exploit can cascade into full system compromise. Security-critical systems are designed so that at least one property is always absent.
Agent side — the classic formulation.
The original Rule of Two addresses code execution: can crafted input exploit a memory-unsafe language to hijack a privileged process?
Two of three. The absent property — unsafe language — means that even if an attacker could deliver malicious input, the managed runtime prevents memory corruption from escalating into arbitrary code execution.
Server side — adapted for AI orchestration.
The classic Rule of Two addresses memory safety. AI orchestration introduces a different class of risk: non-deterministic processing. An AI model interpreting untrusted data can be manipulated in ways that are difficult to predict — analogous to how memory-unsafe code can be exploited by crafted input. For AI orchestration, the three properties become:
If all three combine in a single component, a compromised endpoint can feed crafted data to the AI, manipulate its reasoning, and use its privileged access to poison knowledge, harvest credentials, or influence actions on other endpoints. This is the AI orchestration equivalent of a buffer overflow leading to privilege escalation.
Aorka's architecture prevents this by ensuring deterministic gates stand between the AI and every privileged infrastructure action. Every write operation passes through multiple independent filters: deterministic command classification, AI risk scoring, human approval, and EDR policy enforcement on the endpoint itself. Knowledge mutations are logged with full provenance and are reversible. Credential dispatch and command execution are gated by deterministic validation the AI cannot bypass.
Aorka plays its cards face up. Every layer of the system is designed so that both sides — Aorka and your environment — can independently verify the other. You do not have to take our word for it.
No security architecture eliminates all risk. Here is what we consider the honest residual:
Per threat, what each model does about it.
| Threat | Traditional RMM | Aorka |
|---|---|---|
| Operator runs destructive command | Executes immediately | Blocked if score > 50; write approval required |
| Compromised admin session | Full execution access | Hard ceiling at score 51; unit locks; MFA on sensitive ops |
| Update server hijacked | Varies by vendor | RSA signature + trusted hash verification |
| MITM on agent connection | TLS only | TLS + HMAC challenge-response + trusted hash + device fingerprint |
| AI manipulation | N/A — no AI layer | Deterministic filter + separate evaluator + human gate |
| Agent transparency | Compiled binary (opaque) | Plaintext source, EDR-visible execution, hash-verified integrity |
The architecture above is auditable end-to-end. We will walk you through it with your own infrastructure — your endpoints, your scripts, your EDR watching. Break it if you can.
Request a security walkthrough