ARGUS
ARGUS (Autonomous Reconnaissance and Guardian Unified System) is a local-first voice assistant and security monitor for one Windows machine. It listens for a wake word, acts on the PC, watches that same machine for threats and offers guided repair when it finds one.
- Role
- Design, engineering and security
- Year
- 2026
- Status
- In active development
- Code
- Private repository
- Lines of code
- 63K+
- Test suites
- 109
- ATT&CK-tagged detectors
- 16
- Permission-scoped skills
- 48
ARGUS City
Every robot is a real ARGUS agent. Every light is backend state.
A team forms
“Why is my PC slow?” The Agent Manager staffs a team, and they head for Agent HQ.
Policy and auth gate
The agents decide what they want to do.
Policy and auth gate
Only the policy and authorization gate decides whether they may.
The only road to machine control. Every action stops here for policy, and for you.
Built by Sodik Tursunboev
ARGUS City
Designed, engineered and secured by one person, and still in active development.
ARGUS in 51 seconds
Ask “Why is my PC slow?” and ARGUS staffs a team of agents to find out. Every robot in the city is a real agent and every light is live backend state. The agents decide what they want to do; only the policy and authorization gate decides whether they may.
- ARGUS
A personal AI operating system: voice, local AI and security, on your own PC.
- The HUD
Local AI, live telemetry and a voice you can talk to, all running on this machine.
- Security first
Sealed files, a policy engine and a tamper-evident audit chain. The AI never decides what it is allowed to do.
- ARGUS City
Every robot is a real ARGUS agent. Every light is backend state.
- A team forms
“Why is my PC slow?” The Agent Manager staffs a team, and they head for Agent HQ.
- Agent HQ
Planner, System, Diagnostics and Network work the task graph. A Log Analysis specialist is hired for the job.
- Verification Institute
Nothing is accepted until the Verifier has checked the evidence.
- Cloud Embassy
A cloud specialist researches here, outside the secure city. Cloud can think. Cloud cannot control.
- “Send everyone to the academy”
One spoken order, and all ten agents walk to class.
- ARGUS Academy
Lessons run one at a time on the local model, and a verifier grades every one.
- Policy and auth gate
The only road to machine control. Every action stops here for policy, and for you.
- Built by Sodik Tursunboev
Designed, engineered and secured by one person, and still in active development.
Overview
Problem
A voice assistant with control of the PC is itself an attack surface. It can launch and kill processes, type keystrokes, read the clipboard, capture the screen and power the machine off, and a language model is the wrong component to decide whether any of that is allowed.
What I built
A voice-driven assistant that runs on one PC, with a continuous threat-detection suite over the same machine. The wake word, speech recognition, speech synthesis, every skill that touches the machine, and the decision about which skill runs all execute locally.
A cloud model is used for general conversation only, and only when a gate decides the sentence is safe to send.
Why it matters
The security layer governs the AI, not the other way round. ARGUS cannot modify its own authorization code, delete its audit log or grant itself a permission. Those rules are enforced in code and filesystem ACLs, not by instructions in a prompt.
Key results
- Voice commands matched without a model
- 180
- Files under a signed integrity manifest
- 84
- Security findings fixed across two reviews
- 9
Architecture
Two processes: a voice process that owns the microphone and speaker, and an orchestrator that decides policy. Every spoken command takes the same path.
- Wake wordopenWakeWord, on-device
- Speech to textfaster-whisper
- Intent routing180 fixed patterns, then a local model if unmatched
- Authorization gateOnce per action, fail-closed
- Skills48 permission-scoped modules
- Spoken replyPiper TTS, streamed by sentence
Running alongside: a threat monitor with 16 detectors, a tamper-evident audit log, and a HUD served over loopback only.
Routing stays local
Deciding which skill runs is the imperative half of every command (“open my banking folder”, “delete the invoices”). That decision is always made by a local Ollama model. There is no code path from a command to a cloud provider, and a test proves it.
One gate for every action
The dispatcher calls the authorization gate exactly once before every skill invocation, and a denial returns instead of continuing. The order is verified by a test that parses the dispatcher's AST, not just drawn in a diagram.
Plan, execute, observe, correct
Multi-step goals are decomposed by the local model, validated against a code allowlist, described in words and run only on approval. Each step is authorized again at the moment it runs, and the run stops the moment a step doesn't do what the plan expected. Nothing irreversible can be planned.
An interface that shows real state
The HUD is a single self-contained file served over loopback with a per-session token and Origin checking. It shows live telemetry, detector health, the audit log and a MITRE ATT&CK coverage grid colored by which detectors are actually running.
Three models, split by trust
The split is a security boundary, not a performance choice.
| Model | Job | Leaves the machine? |
|---|---|---|
| Ollama (local) | All PC control: classifying commands, plus private conversation | Never |
| Groq (cloud) | Fast answers to general questions | Only when the cloud gate allows |
| Gemini (cloud) | Fallback when Groq is rate-limited | Only when the cloud gate allows |
Stack
Security
An assistant that can type keystrokes and power the machine off is treated as a real attack surface. These are the controls that matter most.
Six authorization levels, fail-closed
Unknown actions fail closed to L2. A failed authentication never reveals which factor failed, and PIN lockout persists across restarts.
| Level | Requires | Examples |
|---|---|---|
L0 | Nothing | Time, weather, arithmetic, small talk |
L1 | Unlocked session | Apps, windows, volume, diagnostics |
L2 | Fresh authentication (within 120 s) | Files, vault, screen capture, UI automation, repairs |
L3 | Fresh auth + spoken confirmation | Dictation, clipboard write, forgetting memory, website tasks |
L4 | Two independent factors + confirmation | Delete, shutdown |
L5 | Hardware-backed only | Nothing qualifies yet; it refuses rather than downgrading |
Core controls
Guardrails the AI can't edit
No code path writes, deletes or executes ARGUS's own installation, state or vault, and filesystem ACLs back that up. Before this existed, “delete auth” resolved to
auth.pyand staged it for the Recycle Bin.Signed integrity manifest
SHA-256 digests over 84 files, with the HMAC key sealed by Windows DPAPI. A critical-tier failure aborts the boot.
Capabilities checked against the code
Each skill declares what it may use (network, filesystem, subprocess, keystrokes, clipboard, screen). At every boot the declaration is checked against what its AST actually imports and calls; a mismatch aborts the boot.
Execution sandbox
An allowlist of five executables, no shell ever, no metacharacters, a hard timeout, and Win32 job objects so a timeout kills the whole process tree. PowerShell is deliberately not allowed.
Egress restrictions and SSRF protection
Each component's network egress is pinned to a fixed host set, and unknown components get no network. Research fetches resolve DNS and check the resulting IP against private, loopback, link-local and reserved ranges.
Loopback-only control plane
Bound to 127.0.0.1, with a fresh per-session token compared in constant time, Origin validation and a limit of 30 commands per minute.
Tamper-evident audit log
Every command, reply and blocked request goes to an HMAC-chained log that ARGUS cannot delete. API keys, JWTs, private keys and card numbers are redacted before anything is logged, spoken or stored.
Prompt-injection containment
Fetched web content can influence what ARGUS says, never what it does. Command dispatch is driven only by the owner's own words.
What the threat model deliberately doesn't claim
Voice is not authentication
Anyone near the microphone can issue non-destructive commands. Destructive actions need a typed PIN or a second factor, never a spoken “yes”.
Face recognition is never a lock
An RGB camera can't tell a face from a photo of one, so face presence greets and never unlocks.
Integrity has limits
An attacker already running as this user could rewrite the verifier and re-seal. Integrity stops ARGUS tampering with itself and catches accidents; it doesn't stop a determined local attacker.
Liveness, not identity
The voice check is a challenge-response that defeats a recording. It doesn't identify who is speaking.
Detection
Sixteen detection modules watch the same machine ARGUS controls. Every finding is tagged with MITRE ATT&CK and written to the tamper-evident audit log.
| Detector | Watches | ATT&CK |
|---|---|---|
| lsass | Credential access against LSASS, including elevated dumpers | T1003.001 |
| lolbin | Encoded and proxy execution | T1059 T1218 T1105 |
| persistence | Five autostart surfaces, as a diff | T1547 T1543 T1053 |
| netconfig | Hosts file, DNS and proxy | T1565.001 T1557 T1090 |
| defenses | Windows' own protections being turned off | T1562.001 T1548.002 |
| privacy | Camera and microphone use | T1123 T1125 |
| clipboard | Wallet-address swaps | T1115 |
| canary | Decoy files nobody should touch | T1083 |
| listening | New network listeners | T1571 T1021 |
| tamper | ARGUS's own protection | T1562 |
Detection discipline
Baseline first
The first pass of every diff detector never alerts. It records the baseline.
Floods collapse
A burst of related changes becomes one finding instead of hundreds.
Blind spots stay honest
A surface that fails to read is excluded from the diff rather than reported as mass deletion.
Guided repair, never automatic
ARGUS offers to remove a malicious autostart (journaled so it can be restored), quarantine a file (moved, never deleted) or stop a flagged process, and never acts without a yes.
Seeing elevated credential dumpers (T1003.001)
The main process permanently drops SeDebugPrivilege at startup, which is the right trade for a prompt-fed process, but it means it can't see an elevated tool dumping LSASS. That case is covered by a separate single-purpose helper that holds the privilege and does one thing: scan. It has no model, no HTTP and no network path.
The two halves talk over a named pipe that only the owner can open, and each side verifies the other's process image before trusting it. Every finding is re-validated before it enters the audit log. When the helper isn't installed, the ATT&CK grid shows that cell as degraded instead of pretending.
Testing
The key claims about ARGUS, that every action is authorized and routing never leaves the machine, are asserted by tests, not just described.
- Lines of test code
- 19,173
- Share of the codebase
- ~30%
What the tests prove
Architecture
test_architecture.pyparses the dispatcher's AST and asserts the authorization gate is called exactly once before every skill invocation, and that a denial returns instead of continuing.Privacy
test_local_control.pyproves there's no code path from a command to a cloud provider.Failure paths
The LSASS helper suite covers the wire protocol, pipe trust and finding gates. Reads are deadline-bounded, so a peer that connects and sends nothing is dropped after about 6 seconds.
Boot-time checks
Integrity verification and the AST capability scan run on every boot, and a failure aborts it. A self-test runner executes the regression suites in-process and reports pass/fail by suite.
Security review
Two dedicated security passes found and fixed nine issues, including XSS-to-RCE, unauthenticated local API access, SSRF and credential disclosure.
