A Windows AI/security platform combining local models, multi-agent orchestration, controlled execution, verification, threat monitoring, and a live 3D representation of the agent runtime.

ARGUS CITY

More about my work: sodik.eu

I started ARGUS with a relatively simple idea: build a local AI assistant that could understand my voice, interact with Windows, monitor the system, and help with security tasks.

The project quickly became a much harder question:

What happens when an AI can do more than answer questions — when it can actually affect the computer it runs on?

That question became the foundation of ARGUS.

Its most important rule is:

The AI may decide what it wants to do. It may never decide whether it is allowed to do it.

What is ARGUS?

ARGUS — Autonomous Reconnaissance and Guardian Unified System — is a local-first Windows AI and cybersecurity system.

Its documented core combines voice interaction, local AI inference, Windows capabilities, threat monitoring, a multi-agent system, authentication, policy enforcement, auditing, and a desktop HUD. The current agent architecture uses ten logical specialist agents sharing a local inference runtime rather than loading a separate model for every worker.

The system is primarily built in Python. Its documented stack includes FastAPI, Ollama, faster-whisper, Piper TTS, Windows APIs, telemetry sources, and a WebView-based interface.

ARGUS — MAIN HUD

The main ARGUS HUD combines local AI, telemetry, security state, networking and interaction with the system.

What interests me most, however, is not the interface.It is the architecture behind it.

AI reasoning should not equal machine authority

An AI agent can misunderstand a request.

It can receive malicious input.

It can be manipulated by prompt injection.

It can make a technically reasonable decision that the owner never intended.

So I did not want the model itself to decide whether a sensitive action is permitted.

ARGUS separates reasoning from authorization.

Conceptually:

User goal
↓
Understand / plan
↓
Agents
↓
Action proposal
↓
Policy
↓
Authentication
↓
Capability / executor
↓
Observation
↓
Verification

The documented architecture authorizes individual actions before execution, and model output cannot simply lower its own required permission level. Unknown operations fail toward safer defaults rather than automatically gaining access.

That produces a simple rule:

Intelligence can request authority. It cannot manufacture authority.

The Policy + Authentication Gate represents the point where AI intent meets machine authority.

This building in the ARGUS City is therefore more than decoration.

It represents one of the system’s core security boundaries.

From one assistant to multiple specialized agents

ARGUS currently defines ten persistent logical specialists:

SECURITY
THREAT
ASSISTANT
SYSTEM
NETWORK
VERIFIER
PLANNER
DIAGNOSTICS
FORENSICS
RESPONSE

Each has its own mission, allowed context, handoff relationships and operational limits.

They share a model runtime, but their roles are different.

SYSTEM can reason about telemetry.

NETWORK focuses on network state.

FORENSICS works with evidence.

PLANNER helps structure work.

VERIFIER has a deliberately different responsibility:

checking whether the result is actually supported.

That matters because I do not want the lifecycle to be:

Do something
→ claim success

I want:

Plan
→ execute
→ observe
→ verify
→ report

ARGUS AI City

As the agent system became more complex, I noticed that I was observing almost everything through logs, JSON, tables and event streams.

Technically useful — but not always intuitive.

That led to ARGUS AI City.

ARGUS AI City visualizes the multi-agent runtime. Robots represent agents, while locations and activity communicate operational state.

The idea is simple:

turn backend agent state into something spatial and understandable.

An agent might be:

idle
working
waiting
verifying
training

Instead of only seeing that in an API response, I can see the corresponding worker inside the city.

Agent HQ represents the workforce.

The Academy represents training.

The Policy + Auth Gate represents authorization.

Other areas represent capabilities and coordination.

The important requirement is that the visualization should reflect real backend state rather than invent activity.

That follows another ARGUS principle documented in the project: when data is unavailable, the interface should show it as unavailable instead of fabricating telemetry.

The city is therefore intended to become an operational view of the system — not just a visual effect.

Training agents without increasing their permissions

Another part of the current design is ARGUS Academy.

ARGUS Academy represents agent training and evaluation.

The goal is to let an agent improve things such as:

knowledge
procedures
planning
retrieval
task performance

without allowing training to change:

permissions
authentication
security policy
tool authority
access to secrets

I summarize that rule as:

Agents can become smarter. They cannot graduate into more authority.

This distinction is particularly important when experimenting with increasingly autonomous systems.

Self-improvement should not silently become privilege escalation.

Security is part of the system, not a feature added afterward

ARGUS also contains a security-monitoring layer.

The documented threat-monitoring subsystem includes detectors covering areas such as credential-dumping behavior, persistence, defensive tampering, network integrity, suspicious listeners, privacy-sensitive device use, clipboard manipulation and LOLBin activity, with multiple detections mapped to MITRE ATT&CK techniques.

Security state around the AI includes device trust, policy enforcement, authentication, executor privileges, network policy and auditing.

This creates an interesting relationship:

ARGUS can observe the machine.

Agents can reason about what they observe.

But reasoning about a security event does not automatically grant permission to change the machine.

The same authorization boundary remains in place.

Local first, cloud second

Machine control and private system context are deliberately treated differently from general knowledge.

The documented architecture keeps machine-control routing local and makes cloud reasoning optional.

The direction I am working toward is:

Private machine state
→ local
Windows control
→ local
General/public research
→ local or approved cloud
Cloud specialist
→ intelligence only
Machine-changing action
→ local policy + authorization

Or in one sentence:

Cloud can think. Cloud cannot control.

A future cloud ARGUS can stay online continuously, provide safe research or agent coordination, and be reachable from my phone.

But the Windows machine should remain its own protected execution boundary.

What I learned building ARGUS

The hardest part of building an agentic system is increasingly not the prompt.

It is deciding:

What can this agent see?
What can it request?
Who approves it?
What happens if it fails?
Who verifies the outcome?
What reaches the cloud?
What happens when the model is wrong?

ARGUS is still under active development, and several newer components continue to be tested and integrated.

I would rather describe it accurately than call every visible feature complete.

But the project has already changed the way I think about AI engineering.

The question is no longer simply:

“How intelligent can the assistant become?”

For me, the more important question is:

How much autonomy can I safely give it while keeping authority outside the model?

That is the problem ARGUS is being built around.

CLOUD EMBASSY
VERIFICATION INSTITUTE
OPERATIONS ROOM

THANK YOU!

#Cybersecurity #Artificial Intelligence #Jarvis #AI Agents #Security Engineering #Local AI