Building ExeGuard AI: How I Used Switch to Create a Collaborative AI Security Investigation Team
By Sayed Afaan, Solo Developer & Founder at Thynk Software Solutions
Built for the Flip the Switch Hackathon 2026
The Dilemma of the Unknown .exe
Every Windows administrator, security engineer, and developer has faced this dilemma: you download an unfamiliar executable or receive a vendor payload, and you need to know before double-clicking: Is this file safe?
Today, that leaves you with two bad options:
- Blind Trust in Antivirus Badges: You upload a hash to a multi-engine scanner. If it says "Clean", you run it. But traditional detection engines are black boxes. They output a label without showing the underlying evidence, context, or arithmetic that led to that judgment.
-
False-Positive Noise Fatigue: If you run basic static analysis tools, you are flooded with alarms. Common Windows APIs like
GetForegroundWindow,OpenClipboard, orIsDebuggerPresentget flagged as suspicious, even though virtually every legitimate GUI program and standard MSVC C runtime imports them.
When I set out to build ExeGuard AI for the Flip the Switch Hackathon 2026, my goal was simple: build a defensive static analysis system that shows its work, never executes submitted files, and places real AI agents and human analysts into an interactive room to investigate the binary together.
Here is the story of how I engineered ExeGuard AI, how I used Switch to orchestrate an autonomous SOC investigation team, and the real development hurdles I solved along the way.
Technical Architecture & How ExeGuard AI Works
ExeGuard AI is built around an auditable, offline-first, zero-execution architecture.
┌────────────────────────────────────────────────────────────────────────┐
│ ExeGuard AI Architecture │
└────────────────────────────────────────────────────────────────────────┘
[React 18 + Vite] ──(REST API)──► [FastAPI Backend (Python 3.12)]
│ │
│ [SQLite Database]
│ (Scans, Evidence, Reviews)
│ │
▼ ▼
[Executive SOC UI] [7-Stage Static Engine]
(Evidence Brief, - File ID & Cryptographic Hashes
Thread, Review) - PE Structure & Shannon Entropy
▲ - Authenticode via WinTrust / Crypt32
│ - Tiered String & Behavioral Regex
│ - YARA Rule Compilation
│ - Opt-in Hash Reputation Lookup
│ - Deterministic Arithmetic Scoring
│ │
│ (Evidence Brief)
│ ▼
[Mattermost] ◄──(Bridge)──► [Switch Core Server (:52131)]
(#exeguard-security-lab) │
│ [Agent Controller]
│ │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ Collaborative Investigation │
│ │
│ • @static-analysis-agent (Binary Specialist) │
│ • @threat-intel-agent (Reputation Researcher) │
│ • @security-review-agent (Independent Auditor) │
│ • Human Analyst (Final Decision Maker) │
└─────────────────────────────────────────────────────────────┘
The system operates across three core tiers:
- Frontend (React 18, Vite, Tailwind CSS): A responsive interface featuring real-time analysis stages, Shannon entropy visualization, auditable score breakdowns, an executive investigation room, and ReportLab PDF report generation.
-
Analysis Backend (FastAPI, Python 3.12): An offline-first static engine leveraging
pefile,yara-python,cryptography, and Windowscrypt32/wintrustviactypes. -
Collaboration Stack (Switch & Mattermost): A local Matrix-bridged communication layer where Switch connects autonomous AI agents directly into
#exeguard-security-lab.
The Static Analysis Pipeline (Without Running Code)
A core tenet of ExeGuard AI is its Zero-Execution Safety Guarantee. Submitting an unknown binary never endangers the analyst's machine. During automated self-testing (selftest.py), tripwires replace execution primitives (subprocess.run, Popen, os.system, os.startfile, webbrowser.open) with raising exceptions to prove that no inspected binary is ever launched.
Figure 1: ExeGuard AI Static Analysis Results Dashboard
Caption: Inspection view showing cryptographic hashes, Authenticode certificate chain status, Shannon section entropy, and itemized scoring deductions.
The engine executes across seven transparent stages:
- File Identification & Hashing: Magic byte analysis walks the DOS stub and NT headers to extract genuine PE metadata, computing SHA-256, MD5, and SHA-1 hashes.
-
PE Structure & Shannon Entropy: Parses section permissions (
R-X,RW-), entry points, and per-section Shannon entropy. High entropy in.text(> 7.2) or overlays (> 7.5) highlights potential packing or encrypted payloads. -
Multi-Stage Authenticode Verification: Instead of treating digital signatures as a blunt boolean, ExeGuard answers three distinct questions:
- Is there a signature table on disk? (PE data directory 4).
-
Who signed it? (Decodes embedded PKCS#7 structures with
cryptography, matching the signer by issuer and serial). -
Is the signer trusted? (Walks the certificate chain leaf-to-root and matches the root against the local Windows
ROOTstore; catalog-signed Windows binaries are checked viaCryptCATAdmin*).
-
Tiered Import & String Analysis: APIs are split into ambient (common GUI/runtime imports like
GetTickCount, weighted 0) and signature (process injection, token duplication). Extracted strings are categorized into behavioral tiers (PowerShell obfuscation, sandbox evasion). - YARA Pattern Matching: Compiled rulesets inspect the binary against categorized rule files with offset locations and provenance tracking.
- Threat Intelligence: If enabled, checks file reputation by SHA-256 hash lookup via VirusTotal v3. Binaries are never uploaded.
-
Deterministic Risk Scoring: The verdict is derived through arithmetic, not model hallucination:
$$\text{Score} = \text{clamp}\left(\sum \text{Severity Weights} - \sum \text{Mitigations}, 0, 100\right)$$
Scores map to four verdicts:
LOW RISK(< 20),SUSPICIOUS(20–44),HIGH RISK(≥ 45), orINCONCLUSIVE.
Why I Chose Switch for Multi-Agent Collaboration
Most "AI cybersecurity tools" use hardcoded single-prompt chains or simulated chat widgets. When you refresh the page, there are no real participants, no independent perspectives, and no auditable logs.
I chose Switch because it changes the paradigm:
- Real Agents in Real Chat Infrastructure: Switch orchestrates agents inside real chat protocols (Mattermost), backed by Matrix. Every post carries an authoritative post ID.
- Provider Agnostic: Switch connects to the AI providers developers already use (Cursor, Claude Code, OpenCode, Codex, Antigravity) rather than forcing an expensive or proprietary runtime.
- Strict Role Boundaries: Each agent operates under its own distinct prompt, tool privileges, and output contract.
Connecting the AI Agents via Switch Protocol
To integrate ExeGuard with Switch, I registered our backend service with the Switch Core server (http://127.0.0.1:52131) using Switch's Agent Protocol.
In backend/app/agents/switch_protocol.py, ExeGuard registers an identity using Switch's deployment token:
payload = {
"name": "exeguard-analyst",
"display_name": "ExeGuard Analyst",
"description": "Posts static-analysis evidence briefs into the security room.",
"connector_type": "other",
"integration_profile": {
"connection_model": "session_passive",
"message_exchange": True,
"pre_invocation_mediation": [],
"post_invocation_mediation": [],
"event_reporting": [],
},
"overwrite": True,
}
# Dispatched with Authorization: Bearer <AGENT_REGISTRATION_TOKEN>
When an analysis completes, the analyst clicks "Send Findings to Agents". ExeGuard formats a structured Markdown evidence brief and dispatches it through the Switch bridge into #exeguard-security-lab.
Figure 2: Executive Security Evidence Brief in the Investigation Room
Caption: The executive evidence card rendered in the ExeGuard SOC room, displaying verified SHA-256, deterministic score, PE metrics, and tiered indicators.
The Three Implemented Agent Roles
In backend/app/agents/roster.py, I defined three specialized personas with strict boundaries:
| Agent Role | Responsibilities | Strict Restrictions | Output Contract |
|---|---|---|---|
@static-analysis-agent |
Evaluates PE sections, Shannon entropy, imports, and behavioral strings. | Forbidden from executing code or claiming detection without citing fields or offsets. |
OBSERVED, INFERRED, UNKNOWABLE
|
@threat-intel-agent |
Assesses hash reputation, YARA rule provenance, and external intelligence gaps. | Forbidden from uploading binaries or visiting extracted URLs. |
SOURCES CONSULTED, WHAT THEY SUPPORT, WHAT THEY CANNOT SUPPORT
|
@security-review-agent |
Independent reviewer auditing the other two agents for contradictions and false alarms. | Forbidden from inventing claims; must separate observed facts from hypotheses. |
AGREEMENTS, CONTRADICTIONS, FALSE-POSITIVE RISK, RECOMMENDATION
|
Real Agent Debate in Action
During testing with an unsigned sample (gcapi.dll), the agents engaged in real, nuanced analysis in Mattermost:
@static-analysis-agent:
"OBSERVED: PE32 i386, 7 sections, .text entropy 6.69. Imports includeDuplicateTokenEx,ImpersonateLoggedOnUser,OpenProcessToken. No Authenticode signature.
INFERRED: Token duplication plus impersonation is a genuine privilege escalation capability. Legitimate in callers/services, but also the core of token theft tooling.
UNKNOWABLE: True runtime intent without dynamic observation."
@threat-intel-agent:
"SOURCES CONSULTED: Local brief metadata only. Hash lookup was not opted in.
WHAT THEY SUPPORT: Unsigned binary; no known catalogue match. Most DLLs in the wild are unsigned.
WHAT THEY CANNOT SUPPORT: No claim that this file is malicious, and none that it is clean. The correct position is unassessed, not suspicious."
Figure 3: Multi-Agent Collaborative Thread in Mattermost
Caption: Real autonomous responses from @static-analysis-agent and @threat-intel-agent inside the bridged Mattermost channel.
Human-in-the-Loop: The Analyst Holds the Pen
A core architectural rule of ExeGuard AI is: AI agents propose and interrogate; the human analyst decides.
- Direct Room Interrogation: Analysts can challenge any agent directly using the bottom composer in the Investigation Room (e.g., "Why is that section entropy suspicious, and what else could explain it?").
-
Audit Sign-Off: Once satisfied, the analyst records a formal review:
-
Decision:
Approved,Rejected, orNeeds More Analysis. - Verdict Override: The analyst can confirm or override the mathematical verdict with signed reasoning.
- Tamper-Proof Audit Trail: The entire conversation trail, with real Mattermost post IDs, timestamps, and analyst sign-off, is exported into a formal ReportLab PDF report.
-
Decision:
Figure 4: Human Analyst Sign-Off and Formal Review Drawer
Caption: Human analyst recording a formal sign-off with verdict override capability and commentary.
Real Development Challenges & Lessons Learned
Building an end-to-end multi-agent security analyzer in a hackathon sprint presented concrete engineering obstacles:
1. Reverse-Engineering Switch Protocol & Auth Headers
Connecting ExeGuard to Switch initially returned HTTP 401 and 422 errors. By inspecting the Switch Core server's route handlers (switch_core/bridges/agent/api/handlers.py), I discovered two critical requirements:
- Registration tokens must be passed as
Authorization: Bearer <token>in HTTP headers, not in the JSON body. - The registration endpoint strictly requires an
integration_profileobject (session_passive) and aconnector_type. Implementing this inregister_agent.pyenabled seamless automated onboarding.
2. Addressing Policies & Bot Identities
Once connected, our first briefs were met with:
"I only take instructions from my owner, and this chat account isn't linked to a Switch user yet..."
Switch agents default to an owner-only access policy. To enable collaboration with the ExeGuard bot, each agent's addressing policy in Switch Console was updated to "Anyone", allowing open communication across all room participants.
3. Windows Softpub WinVerifyTrust Quirks
On certain Windows 11 environments, WinVerifyTrust returns TRUST_E_PROVIDER_UNKNOWN (0x800B0001) because the softpub provider registration is absent in the registry. Instead of failing silently or marking binaries unsigned, I engineered a direct PKCS#7 certificate walker using crypt32 and cryptography. It decodes the signer directly and matches the root certificate against the local machine's ROOT store.
4. Designing the Executive SOC Room UI
Initial versions rendered the 5,000-character evidence brief as an unformatted raw markdown blob with an overpowering bright blue background. I redesigned Room.jsx to parse markdown sections into clean cards:
- Executive Evidence cards with one-click SHA-256 copying.
- Dedicated agent bubbles with role-specific icons (
Code2,Globe,ShieldCheck). - Quiet, centered pill badges for system join events and tool call counters.
Security Limitations & Future Roadmap
To remain honest, ExeGuard acknowledges what static analysis cannot do:
- Packed & Encrypted Binaries: Packers obscure executable intent. ExeGuard flags high entropy and packing signatures, but it does not unpack code.
-
Trusted Publisher Ceiling: A machine-trusted signature caps static findings at
SUSPICIOUS. Stolen signing certificates do occur; a good signature cannot grant total immunity. - Future Vision (Isolated Dynamic Sandboxing): In future releases, I plan to integrate an optional, air-gapped micro-VM sandbox (using Firecracker or Hyper-V) that runs the binary in an isolated container to record network telemetry, child processes, and memory dumps, feeding dynamic artifacts directly back to the Switch agent team.
Conclusion & Demo Links
Building ExeGuard AI proved to me that collaborative AI is profoundly more effective than single-agent prompts. By using Switch to connect autonomous specialists into a shared chat room, security analysts gain an auditable, transparent, and multi-perspective investigation partner.
- GitHub Repository: https://github.com/sayedafaan/exeguard
-
Live Video Demonstration:
https://youtu.be/ZfXYGds7UZA - Hackathon: Flip the Switch Hackathon 2026
If you are exploring multi-agent workflows or defensive application security, I'd love to connect on GitHub or in the comments below!
Top comments (0)