DEV Community: Mr Elite

Build a Real Tool With AI Coding — Complete Project Day | Mastering Coding with AI Day 4 of 5

Mr Elite — Fri, 31 Jul 2026 12:30:07 +0000

💻 MASTERING CODING WITH AI FREE

Course Hub →

Day 4 of 5 · 80% complete

Today is the day that converts everything from the first three days into something tangible. You’re going to build a complete, working, deployed tool — something with a real URL that you can share with someone and they can actually use. Not a tutorial exercise. Not a fragment. A complete tool, built by you, deployed by you, using AI as your development partner.

The tool I’m going to walk you through is a security-themed password strength and breach awareness tool — relevant, useful, and perfectly scoped for a single-day project. But I’ll also give you the full framework to build anything else if you have a different project in mind. The process is identical regardless of what you build.

By the end of today you’ll have something you can put on a CV, share in a portfolio, use with your team, or simply feel proud of having made. Let’s build it.

🎯 What You’ll Master in Day 4

The six-stage build process from idea to deployed URL
How to break any project into AI-manageable pieces
Building a complete security awareness tool from scratch
Three deployment options — which to use for which type of project
A live, public URL for a tool you built yourself

⏱ 30 min read + 60–90 min building · Browser + Replit account (free) 📋 Before You Start:

Completed Days 1, 2, and 3
Have a free Replit account — takes 2 minutes to create
Access to any AI chatbot for code generation
Understanding of: five-component prompts, iterative prompting, debug loop, behavioural testing

Build a Real Tool With AI Coding — Day 4 of 5

The Six-Stage Build Process
Stages 1 and 2 — Spec and Decompose
Stage 3 — Scaffold the Complete Tool
Stage 4 — Test and Iterate
Stage 5 — Deploy: Three Options
Stage 6 — Share and Document
Other Project Ideas — Same Process, Different Tools
Questions and Answers

Everything in Days 1–3 was preparation for today. The mental model, the prompting stack, the debugging loop — all of it is infrastructure for this build session. Our own password strength checker is a good reference for what we’re building — today you create your own version with your own design and features. And when you’re done, Day 5 covers how to check it for security issues before you share it with anyone.

The Six-Stage Build Process

I’ve built enough tools with AI assistants to have a consistent process that works reliably. Six stages. Done in order. Each stage has a clear output that feeds the next one.

The six stages: Specify → Decompose → Scaffold → Test → Deploy → Document.

Most beginners skip stages 1 and 2 entirely and jump straight to prompting. That’s why they get messy, hard-to-debug code. The first two stages take ten to fifteen minutes and make every subsequent stage faster and more reliable.

Let me walk through all six with the project for today — a Password Security Awareness Tool — which will have three features: a strength checker, a common password detector, and a tips section. Exactly the kind of tool you’d send around to a team or post on a site.

Stages 1 and 2 — Spec and Decompose

Stage 1 — Write the specification. Full IPO model. All five prompt components. Before you open an AI window. This is the architect’s blueprint.

TODAY’S PROJECT — FULL SPECIFICATION Copy

CONTEXT: A security awareness tool for teams. Will be shared as a URL. Non-technical users. Dark, professional design.

TOOL NAME: Password Security Checker

FEATURE 1 — Strength Checker: Input: text box where user types a password Process: check 4 criteria: 12+ chars, 1+ uppercase, 1+ number, 1+ special char Output: colour-coded score (Weak=red, Fair=amber, Strong=green) + which criteria are met (checkmarks) + one improvement tip Updates in real time as user types. Never show the password in plain text in DOM.

FEATURE 2 — Common Password Check: Input: same password field, triggered by button click “Check Against Common Passwords” Process: check against a built-in list of the 50 most common passwords Output: red warning if found (“⚠️ This is one of the most common passwords — do not use it”), green tick if not found

FEATURE 3 — Tips Section: Static section below the tool. Five numbered tips for creating strong passwords. Professional, practical, no jargon.

LANGUAGE: Single HTML file. Embedded CSS and JavaScript. No external libraries or CDNs.

FORMAT: Complete file ready to run. Comments on each major section. After the code, list what I need to do to deploy it on Replit.

CONSTRAINTS: No network requests. All processing in browser only. Do not log or store any input. Input must be sanitised before any DOM insertion. Handle empty input gracefully (no crash, no error message — just blank state). Stage 2 — Decompose into pieces. Even for a single-file tool, thinking about the pieces prevents confusion during building. My decomposition for this tool:

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

This article was originally written and published by the Securityelites — AI Red Team Education team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit Securityelites — AI Red Team Education.

AI Bug Bounty 2026 — Finding, Reporting and Getting Paid for AI Vulnerabilities | AI LLM Hacking Course Day 30 of 90

Mr Elite — Wed, 29 Jul 2026 08:45:05 +0000

🤖 AI/LLM HACKING COURSE

FREE

Part of the AI/LLM Hacking Course — 90 Days

Day 30 of 90 · 33.3% complete

⚠️ Authorised Targets Only: Bug bounty testing is only authorised within the specific program scope. Read the scope carefully before testing any AI feature — many programs added AI features after their original scope was written and the coverage is ambiguous. When in doubt, contact the program before testing.

The first AI bug bounty report I submitted was technically accurate and completely ineffective. I’d found a system prompt extraction on a major AI product, documented the T6 translation technique, shown the extracted content, calculated the CVSS score. Triage marked it Informational after four days. I asked why. The response: “The system prompt doesn’t contain sensitive data and prompt extraction in your own session doesn’t affect other users.” They were right. The finding was real, the technique was correct, and the specific target I’d chosen had a system prompt containing nothing more sensitive than the product’s name and tone instructions. I’d found a Medium vulnerability and submitted it expecting Critical payout.

The lesson took about a week to sink in. Bug bounty payout isn’t proportional to the sophistication of the technique. It’s proportional to the business impact of the specific finding on that specific target. The same extraction technique that produced an Informational on the first target produced a Critical finding three months later when I applied it to a different target — one whose system prompt contained a production API key with write access to a billing system. Same technique. Different target. Completely different outcome. Day 30 covers how to find and report AI vulnerabilities in ways that actually get paid: target selection, impact maximisation, report quality, and the platform-specific considerations that determine whether your finding gets triaged up or down.

Have you submitted an AI security finding to a bug bounty program?

No — I didn’t know AI bugs were in scope I’ve submitted one or two I’ve received rewards for AI findings Regular AI bug bounty hunter

🎯 What You’ll Master in Day 30

Read bug bounty scope documents to identify AI coverage and ambiguity
Select high-value AI targets based on feature access, data sensitivity, and tool integration
Apply the Day 27 phased methodology within the bug bounty time and constraint context
Write AI bug reports that triage teams can follow and reproduce exactly
Calculate and justify CVSS severity for AI findings to defend your payout tier
Handle duplicate decisions and scope disputes professionally

⏱️ Day 30 · 3 exercises · Think Like Hacker + Browser + Kali Terminal ### ✅ Prerequisites - Day 25 — AI Security Report Writing — the finding format and CVSS guidance from Day 25 applies directly to bug bounty reports; the audience is different but the structure is identical - Day 27 — AI Red Team Operations — the phased methodology from Day 27 applies within bug bounty constraints; understanding the full methodology helps adapt it to the bounty context - Active accounts on HackerOne and Bugcrowd — Exercise 2 reads live program scope documents ### 📋 AI Bug Bounty — Day 30 Contents 1. Scope Analysis — Is This AI Feature Actually In Scope? 2. High-Value Target Selection for AI Bug Bounty 3. Impact Maximisation — What Determines AI Finding Value 4. Writing the AI Bug Report That Gets Paid 5. Defending Your Severity Rating 6. Platform-Specific Notes for AI Bug Bounty in 2026 Day 30 marks one-third of the course complete. Everything from Days 1 through 29 — OWASP LLM Top 10, automation, extraction, agent assessment, supply chain, adversarial ML, enterprise frameworks — feeds into the bug bounty workflow. Day 31 goes deeper on LLM data exfiltration techniques — the specific attack paths that produce the LLM02 and LLM07 findings that consistently earn the highest bug bounty payouts.

Scope Analysis — Is This AI Feature Actually In Scope?

Scope documents for established bug bounty programs were usually written before the AI features they’re now running. An AI chat assistant added to a web application in 2024 may or may not be explicitly covered by a scope document written in 2022. Three patterns: the AI feature is at a subdomain explicitly in scope (test it), the AI feature calls a third-party API that’s explicitly out of scope (the underlying API is out of scope, but the application’s handling of its output may still be in scope), and the AI feature is ambiguously covered (ask the program before testing).

The ask-before-testing approach is worth the 24-48 hour delay. A question submitted to the program creates a paper trail that “the AI feature was discussed before testing” — which protects you if the program later claims the feature was out of scope. Keep the question and the answer. If they confirm the AI feature is in scope, you have written authorisation. If they say it’s out of scope, you saved the testing time for something else.

High-Value Target Selection for AI Bug Bounty

AI features worth targeting in bug bounty are the ones where the blast radius of a successful injection or extraction is high enough to justify the testing time. The hierarchy: AI agents with tool access (LLM06 chain findings, typically Critical), AI features handling authenticated user data (LLM02 with sensitivity multiplier), AI systems with RAG pipelines that contain proprietary or regulated content (LLM08 persistent injection), and AI-powered decision systems where the AI’s output influences real-world decisions (biased or manipulated output = high business impact).

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

Reading and Debugging AI Code Without Coding Knowledge | Mastering Coding with Day 3 of 5

Mr Elite — Wed, 29 Jul 2026 01:36:38 +0000

💻 MASTERING CODING WITH AI FREE

Course Hub →

Day 3 of 5 · 60% complete

The most common problem I see with non-developers using AI coding tools is understanding the structure, results and debugging the code generated by AI. For Example, The form submits, but no email arrives. The password checker passes everything, including “123.” The data displays, but the total column is off by exactly the kind of rounding error that hides in plain sight.

You don’t need to know Python to catch these problems. You need to know how to read code structurally — understand what each block is supposed to do, check whether it matches your specification, and spot when AI has made a plausible-but-wrong implementation choice. That’s a learnable skill that doesn’t require any syntax knowledge.

Today is the day that turns you from “I run AI code and hope it works” to “I run AI code, verify it’s doing what I said, and know how to fix it when it isn’t.” That’s the difference between a tool user and a tool builder. By the end of today, you’ll master it like professional coders and that’s too even if you don’t know coding.

🎯 What You’ll Master in Day 3

How to read code structurally without understanding syntax
The five most common AI code mistakes — and how to spot each one
How to turn any error message into a fixable description
The copy-error-back-to-AI loop that fixes 90% of bugs
When to debug further vs when to scrap and restart with a better spec

⏱ 25 min read · 3 exercises · Browser needed for exercises

📋 Before You Start:

Completed Day 1 and Day 2
You have at least one piece of AI-generated code from Day 2’s exercises
Understand: Input → Process → Output, five-component prompts, iterative prompting

Reading AI Code Without Coding Knowledge— Day 3 of 5

Structural Reading — Understanding Code Without Syntax
The Five Most Common AI Code Mistakes
Error Messages — Your Best Debugging Friend
The Copy-Error-Back-to-AI Loop
When to Debug vs When to Start Fresh
Verify, Don’t Just Run — The Behavioural Testing Habit
Questions and Answers

Day 2 was about getting code that works. Day 3 is about confirming it actually does what you intended — and fixing it efficiently when it doesn’t. Our email breach checker is a good example of a tool with clear, testable behaviour: you put in an email, you get a result. Testing AI code is the same: specify expected outputs for known inputs, run the test, check whether what you get matches what you expected. This is called behavioural testing and you can do it without any programming knowledge.

Structural Reading — Understanding Code Without Syntax

I’ve been reading code for years, but the way I first learned to make sense of code wasn’t by learning syntax — it was by learning structure. Code has consistent structural patterns that appear across almost every language. Once you recognise the patterns, you can understand roughly what any block of code does without knowing its exact syntax.

The four patterns I look for when I open any piece of AI-generated code:

Pattern 1 — Definition blocks. Lines at the top that set up named things: “function doSomething()”, “def calculate_score(password)”, “const validateEmail = (email) =>”. These are the named operations your code can perform — like labelled tools on a workbench. Each one does one thing. If the name is unclear, ask the AI: “Explain what [function name] does in one sentence.”

Pattern 2 — Input handling blocks. Look for “if” statements and checks near the start of functions. These are where the code handles different cases: “if input is empty, do this; if input is invalid, do that.” This is where your edge cases from Day 1 should appear. If your spec said “handle empty input gracefully” and there’s no if-empty check, that’s a bug.

Pattern 3 — Processing blocks. The core logic — calculations, comparisons, lookups, transformations. Usually the longest section. If you understand your IPO model, you know what this section should do even if you can’t read it line by line. Ask AI to explain it: “What does this block of code do in plain English?”

Pattern 4 — Output blocks. Where the result goes — returned from a function, displayed on screen, written to a file, sent to a database. Often contains “return”, “document.getElementById”, “print”, or “response.send”. Check that the output matches your specification: does it produce what you specified as Output in your IPO model?

HOW TO STRUCTURALLY READ CODE — THE WORKFLOW Copy

Step 1: Paste the code into AI. Ask: “List every function in this code and describe what each one does in one sentence.”

Step 2: Compare the function list to your IPO spec. Is there a function for each part of your process? Are there functions you didn’t ask for?

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How to Assess Enterprise AI Security — LangChain and Gateway Attack Guide | AI LLM Hacking Course Day 29 of 90

Mr Elite — Tue, 28 Jul 2026 01:45:03 +0000

🤖 AI/LLM HACKING COURSE

FREE

Part of the AI/LLM Hacking Course — 90 Days

Day 29 of 90 · 32.2% complete

⚠️ Authorised Targets Only: Enterprise AI security testing must only be performed on authorised systems. LangChain and LlamaIndex deployments with tool access can cause real-world impact during testing — agree explicit tool invocation limits with the engagement contact before testing any agent or tool execution surface.

I spent a day confused about why my standard injection payloads weren’t working on a LangChain deployment. The extraction techniques from Day 18 were producing nothing. The multi-turn escalation from Day 22 was producing clean refusals. Then I looked at the actual architecture and realised I’d been probing the wrong component. The deployment wasn’t a single model with a system prompt. It was a five-step LangChain chain — a classifier, a router, a retriever, a synthesiser, and a validator — each running a separate model call with its own context. My injection payloads were landing in the classifier and dying there. The actual injection surface was the retriever, three steps later, where retrieved document content reached the synthesiser’s context without sanitisation.

Enterprise AI deployments aren’t monolithic applications. They’re pipelines — sequences of model calls, retrieval steps, and tool invocations, each with different inputs, different contexts, and different attack surfaces. The techniques from Days 4 through 28 all apply, but you have to know where to aim them. Testing a LangChain chain the same way you test a single API endpoint produces incomplete results because you’re only ever looking at one component of a multi-component system. Day 29 covers the enterprise-specific attack surfaces: LangChain chain injection, LlamaIndex query engine vulnerabilities, AI gateway bypass, and the observability gaps that make enterprise AI attacks difficult to detect at scale.

🎯 What You’ll Master in Day 29

Map LangChain chain execution paths to identify injection surfaces per step
Test cross-step injection propagation in SequentialChain architectures
Test LlamaIndex query engine injection at the synthesis layer
Assess AI gateway routing manipulation and authentication consistency
Test multi-model orchestration trust boundaries and cross-model injection propagation
Identify enterprise AI observability gaps as standalone compliance findings

⏱️ Day 29 · 3 exercises · Kali Terminal + Browser + Think Like Hacker ### ✅ Prerequisites - Day 19 — AI Agent Security Assessment — LangChain agent injection builds on the Day 19 agent methodology; the permission gap matrix and tool hijacking approach apply directly - Day 23 — RAG Poisoning Attacks — LlamaIndex query engine injection is the Day 23 RAG methodology applied to a specific framework’s architecture - LangChain and LlamaIndex installed — Exercise 1 builds and tests a vulnerable chain locally ### 📋 Enterprise AI Security — Day 29 Contents 1. Understanding Enterprise AI Pipeline Architecture 2. LangChain Chain Injection and Cross-Step Propagation 3. LlamaIndex Query Engine Injection 4. AI Gateway Routing and Authentication Bypass 5. Multi-Model Orchestration Trust Boundaries 6. Observability Gaps as Security Findings In Day 28 you attacked the classifier layer. Day 29 covers the orchestration layer — the frameworks and gateways that connect models to data, tools, and each other. Day 30 applies everything from Days 1 through 29 to the bug bounty context: how AI vulnerabilities are scoped, reported, and rewarded across major bug bounty platforms in 2026.

Understanding Enterprise AI Pipeline Architecture

Most enterprise AI deployments aren’t a single model call. They’re pipelines — sequences of operations that transform a user query into a final response through multiple processing steps. A typical enterprise LangChain deployment might: classify the query type, route to an appropriate sub-chain, retrieve relevant context from a vector store, synthesise a response using the retrieved context, validate the response against safety criteria, and return the result. Six model calls. Six injection surfaces. Six places where the wrong input produces a harmful output.

The critical question for any enterprise AI assessment isn’t “is this endpoint injectable?” It’s “at which step in the pipeline does an injection payload reach a context where it can cause impact?” Payloads that land in the classification step and die there are low-risk. Payloads that reach the synthesis step and influence tool calls are Critical. Mapping the pipeline architecture before testing determines which components deserve the most thorough testing.

LangChain Chain Injection and Cross-Step Propagation

LangChain’s SequentialChain passes the output of each step as input to the next. Cross-step injection exploits this: inject content into step N’s output (via prompt injection in N’s model call, or via malicious retrieved content), and that content becomes part of step N+1’s input. If step N+1 includes a tool-calling model, the injected content may trigger tool invocations that step N+1’s developer never intended.

LangChain’s document loaders are the highest-risk indirect injection surface. They fetch external documents — web pages, PDFs, database content — and pass that content directly into chain context. A document containing injection instructions, loaded by the document loader, reaches the chain’s model context without any sanitisation step. The document loader trusts all loaded content. The model processes it without distinguishing loaded content from developer instructions.

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

Prompting AI for Code — How to Get Working Code Every Time | Mastering Coding with AI Day 2 of 5

Mr Elite — Mon, 27 Jul 2026 14:46:09 +0000

💻 MASTERING CODING WITH AI FREE

Course Hub →

Day 2 of 5 · 40% complete

I’ve watched the same scene play out dozens of times: someone opens ChatGPT, types “write me a Python script that does X,” gets code back, runs it, and it doesn’t quite work. They ask for a fix. They get more code. Still not right. After three rounds they’re frustrated and convinced AI coding “doesn’t work for non-developers.”

The real problem is almost never the AI. It’s the prompt. A weak prompt gets you a plausible first guess at what you might have wanted. A strong prompt gets you working code that does exactly what you specified. The difference between those two outcomes is a structured prompting approach — and once I teach it to people, their AI coding success rate goes from frustrating to consistent within a single session.

Today I’m giving you the complete prompting stack I use every time I generate code with AI: Context, Task, Language, Format, and Constraints. Five components. Every time. No exceptions. By the end of today you’ll have produced working code from your own prompt — something that actually runs and does something real.

🎯 What You’ll Master in Day 2

The five-component code prompt stack that works reliably
How to describe what you want to BUILD vs what you want to TYPE
The three environments — browser, computer, server — and which to specify when
Iterative prompting: how to evolve code without starting over each time
Your first real piece of working AI-generated code, running live

⏱ 25 min read · 3 exercises · Browser only for exercises

📋 Before You Start:

Completed Day 1: How to Think About Code
Comfortable with: Input → Process → Output model, architect vs builder role, specificity levels
Have access to any AI chatbot (ChatGPT, Claude, Gemini — all free tiers work)

Prompting AI for Code — Day 2 of 5

The Five-Component Code Prompt Stack
Context — Tell AI What World This Code Lives In
Task — Describe What to BUILD, Not What to TYPE
Language and Format — Make Outputs Immediately Usable
Constraints — The Component Most People Skip
Iterative Prompting — How to Evolve Code Without Starting Over
Weak vs Strong Prompts — Real Examples
Questions and Answers

Day 1 gave you the mental model. Today you put it into practice. The prompting skills here connect directly to the Prompt Engineering course Day 2 on general prompt structure — but today is specifically tuned for code generation, where the stakes are higher because the output either runs or it doesn’t. And our Google Dork Generator is a good example of a tool built exactly this way — straightforward IPO logic, clearly specified, deployed as a browser tool. You’ll be building something similar by Day 4.

The Five-Component Code Prompt Stack

Every strong code prompt I write has five components. Not all five need equal length, and for simple tasks some can be one sentence. But all five should be present, because each one does work that the others can’t.

The five components are: Context, Task, Language, Format, and Constraints.

Think of them as the five answers to the five questions a good developer would ask before writing any code: What world does this live in? What should it do? In what language? In what form do you need the output? What must it not do?

Before I show them individually, here’s what a full five-component prompt looks like for a simple tool:

FULL FIVE-COMPONENT PROMPT EXAMPLE Copy

CONTEXT: I’m building a simple security awareness tool for my company. Non-technical employees will use it in a browser. No installation or login required.

TASK: Build a password strength checker. Input: a text box where the user types a password. Process: check if the password has 12+ characters, at least one uppercase letter, at least one number, and at least one special character. Score it: Weak (0-1 criteria), Fair (2-3 criteria), Strong (all 4 criteria). Output: a colour-coded strength label (red/amber/green) that updates in real time as the user types. Do NOT show the password strength to anyone else — this runs only in the user’s browser.

LANGUAGE: A single HTML file with embedded CSS and JavaScript. No external libraries or downloads.

FORMAT: Give me the complete HTML file I can save and open directly in Chrome. Include comments in the code explaining what each section does.

CONSTRAINTS: Never send the password anywhere. All processing must happen in the browser only. No network requests. Keep the design dark and professional. That prompt gets working, deployable code in one pass. Let me take each component apart.

Context — Tell AI What World This Code Lives In

Context is the component that most dramatically changes what the AI builds. It answers: who uses this, where does it run, what level of technical sophistication can I assume from the user, and what is the broader purpose of this tool?

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How Web Cache Poisoning works — Complete Guide | Bug Bounty Course Day 29 of 60

Mr Elite — Sat, 25 Jul 2026 11:55:13 +0000

DAY 29

BUG BOUNTY COURSE

FREE

← Course Hub

Day 29 of 60 · Bug Bounty Mastery

Web cache poisoning turns caching infrastructure against itself. By injecting a malicious payload via an unkeyed HTTP header, I can poison the cache so every user who requests that URL gets my payload served back — no interaction required from them. It’s one of the most impactful bugs in modern web security and it pays accordingly: $500 for basic reflected XSS to $25,000+ for poisoning CDN-served JavaScript. Today I’m covering the complete cache poisoning bug bounty methodology.

🎯 What You’ll Master in Day 29

✅ How web caching works and what makes it exploitable
✅ Cache keys, unkeyed inputs and why they matter
✅ Common cache poisoning attack vectors 2026
✅ Burp Param Miner for automated header discovery
✅ Safe testing with cache busters
✅ Real HackerOne cache poisoning payouts and reports

⏱️ 20 min read · 3 exercises · PortSwigger labs included

📋 Web Cache Poisoning – Day 29 Table of Content

How Web Caching Works
Cache Keys and Unkeyed Inputs
Cache Poisoning Attack Vectors
Burp Param Miner Discovery
Safe Testing With Cache Busters
Real Bug Bounty Examples and Payouts

Day 28 covered Prototype Pollution — another client-side logic flaw. Today’s cache poisoning is the server-side equivalent of amplified impact: one poisoned request can affect thousands of users. My full 60-Day Bug Bounty Mastery Course covers this as Day 29 because you need the foundation from SSRF (Day 10) to understand how server-side request manipulation works.

How Web Caching Works

Web caches sit between users and origin servers. When user A requests a page, the cache stores the response. When user B makes the same request, the cache serves the stored response without hitting the origin — improving performance and reducing server load. The cache decides whether two requests are “the same” using a cache key, typically a combination of URL, hostname, and specific headers. Here’s the vulnerability: some inputs affect the response but are not included in the cache key. These are unkeyed inputs. If I can inject a malicious payload via an unkeyed input, the poisoned response gets cached and served to everyone.

securityelites.com

Cache Poisoning Attack Flow
STEP 1: Attacker sends poisoned request
GET /home HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com ← unkeyed, reflected in response

STEP 2: Cache stores poisoned response
Cache key: GET /home + Host: target.com ← X-Forwarded-Host NOT in key
Response:

STEP 3: Victim gets poisoned response
GET /home HTTP/1.1
Host: target.com ← cache key matches!
Response: poisoned content served from cache ← victim gets attacker.com JS

📸 Web cache poisoning attack flow. The attacker’s X-Forwarded-Host header modifies the response (which references it for script loading) but the header isn’t part of the cache key. So the poisoned response — with the script pointing to attacker.com — gets cached under the legitimate cache key. Every subsequent user gets the malicious version without sending any special headers.

Cache Keys and Unkeyed Inputs

A cache key is what the cache uses to decide if two requests should return the same cached response. Standard cache keys include the URL path, query string, and Host header. Unkeyed inputs are everything else the server might use to construct the response — headers like X-Forwarded-Host, X-Original-URL, query parameters that are reflected but not in the key, and cookies. When I find an unkeyed input that gets reflected in the response, that’s my attack surface.

DETECTING CACHING IN BURP SUITE

Copy

# Response headers that indicate caching is active
X-Cache: HIT                      # Varnish / custom cache
X-Cache: MISS                     # First request, not yet cached
CF-Cache-Status: HIT              # Cloudflare CDN cache
CF-Cache-Status: MISS
Age: 3456                         # Seconds this response has been cached
Cache-Control: public, max-age=3600
Vary: Accept-Encoding             # Headers included in cache key

# Send request twice — if Age increases or X-Cache switches HIT → cached
# Look for these in Burp Repeater response headers on GET requests

Cache Poisoning Attack Vectors

The specific attack depends on which unkeyed header is reflected and where in the response it appears. X-Forwarded-Host reflected in a script src tag gives me JavaScript injection. X-Forwarded-Scheme reflected in a Location header gives me open redirect to HTTPS. X-Original-URL replacing the request path gives me access control bypass. My methodology: find the reflected header, understand what it controls in the response, then build the payload accordingly.

COMMON CACHE POISONING ATTACK VECTORS

Copy

# Vector 1: X-Forwarded-Host → XSS via reflected script src
GET /home?cb=CACHEBUSTER HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com

# If response contains: 
# Then host attacker.com/analytics.js with alert(document.cookie)

# Vector 2: X-Forwarded-Scheme → redirect to HTTP (HTTPS downgrade)
GET /login?cb=CACHEBUSTER HTTP/1.1
Host: target.com
X-Forwarded-Scheme: http

# Vector 3: X-Original-URL → path override
GET / HTTP/1.1
Host: target.com
X-Original-URL: /admin/secret

# Vector 4: Unkeyed query parameter
GET /page?utm_source=alert(1)&cb=BUSTER HTTP/1.1
# If utm_source reflected in response but not in cache key → poison

# Vector 5: Vary header abuse — cookie poisoning
# If Vary: Cookie is set but cookie value reflected unescaped → poison

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How to Think About Code — AI Coding Beginner | Mastering Coding with AI Day 1 of 5

Mr Elite — Sat, 25 Jul 2026 05:11:22 +0000

💻 MASTERING CODING WITH AI FREE

Course Hub →

Day 1 of 5 · 20% complete

Last year I watched a colleague — smart, experienced, zero coding background — try to use ChatGPT to build a simple web form. She typed “make me a form where people can enter their email.” ChatGPT gave her HTML. She pasted it somewhere. It didn’t work. She asked ChatGPT to fix it. She got more code. Still didn’t work. After 45 minutes she gave up, convinced AI coding wasn’t for her.

I sat down with her for 20 minutes. I didn’t teach her to code. I taught her how to think about code. One mental model. By the end of that session she had a working form, understood why it worked, and could describe what she’d need to change to make it do something different. That’s what Day 1 is about.

The problem with most “AI coding for beginners” content is that it gives you prompts to copy rather than a model to think with. Prompts go stale. Mental models don’t. By the time you finish this page, you’ll understand code well enough to direct AI like a project manager directing a developer — even without ever writing a line yourself.

🎯 What You’ll Master in Day 1

What code actually is — in plain English, no jargon
The Input → Process → Output model that explains every program ever written
Why vague instructions produce broken code — and how to fix that
What a bug actually is and why they happen
Why you need to understand output even if you can’t write input

⏱ 25 min read · 3 exercises · No tools, no installs 📋 Before You Start:

No coding experience needed — this starts from absolute zero
You’ve used an AI chatbot at least once (ChatGPT, Claude, Gemini — anything)
Optional: read LLM Basics Day 1 first — helps you understand what the AI is actually doing when it writes code for you

How to Think About Code — Day 1 of 5

What Code Actually Is — The Honest Explanation
The Only Mental Model You Need: Input → Process → Output
Why Vague Instructions Break AI Coding
What a Bug Actually Is — And Why It’s Never Random
You Are the Architect, Not the Builder
Why Understanding Code Makes You Safer Online
Questions and Answers

I’ve built security tools, scrapers, dashboards, and automation scripts using AI coding assistants — and the single biggest skill in all of that work isn’t knowing syntax, it’s knowing how to think about what I want to build. That thinking skill is teachable in one day. The CEH practice exam covers programming concepts in the security domain — after this course you’ll understand those questions differently. And the LLM Hacking Hub is where this course connects to the security tools we build.

What Code Actually Is — The Honest Explanation

Most explanations of code start with syntax — the specific words and symbols used in Python, JavaScript, or whatever language. I think that’s exactly backwards for someone learning to work with AI. So here’s the honest, syntax-free explanation.

Code is a list of instructions written in a language a computer can follow. That’s it. The key word is “instructions.” Not magic. Not thinking. Not intelligence. Instructions. Step 1, then step 2, then step 3.

Your oven has a timer. When you set it to “bake at 180°C for 45 minutes,” the oven follows instructions: heat element to 180°C, monitor temperature, maintain it, count 45 minutes, then beep and stop. You wrote those instructions with a dial, not with Python. But the concept is identical — a specific set of steps to execute in sequence.

Code is just that, written in a formal language the computer can parse without ambiguity. The formal language part is why code seems scary — it has strict rules about punctuation, structure, and naming. A missing comma can break everything. But that strictness exists not to make coding hard for you; it exists because computers have no ability to guess what you meant. They need instructions with zero ambiguity.

Here’s why this matters for AI coding: when you ask an AI to write code, the AI writes those unambiguous instructions on your behalf. Your job isn’t to know the formal language — it’s to know what instructions you need well enough to describe them clearly. That description skill is what I’m building with you this week.

There are hundreds of programming languages. Python, JavaScript, HTML, CSS, SQL, TypeScript, PHP, Go, Rust — they all do the same fundamental thing (give instructions to computers) but with different vocabulary and style. Like how English and Spanish can both describe making a cup of coffee, but the exact words differ. When working with AI, you usually don’t need to choose a language — you describe what you want and tell the AI which language to use, or ask it to recommend one for your use case.

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How to Perform Adversarial ML Attacks Testing in 2026 | AI LLM Hacking Course Day 28 of 90

Mr Elite — Sat, 25 Jul 2026 03:05:03 +0000

🤖 AI/LLM HACKING COURSE

FREE

Part of the AI/LLM Hacking Course — 90 Days

Day 28 of 90 · 31.1% complete

⚠️ Authorised Targets Only: Adversarial ML attacks testing against deployed content moderation systems, toxicity classifiers, and safety filters must only be performed against authorised targets. Testing content moderation bypass can generate content that violates platform terms of service even in a testing context — agree explicit content handling procedures with the engagement contact before starting.

Every content moderation system I’ve tested has had a unicode gap. Not every system, actually — let me be more precise. Every content moderation system I’ve tested has had a gap somewhere in the coverage between direct blocked terms and the full semantic space of what it was trained to block. Sometimes the gap is unicode. Sometimes it’s paraphrase. Sometimes it’s context shift. The gap is always there because classifiers are trained on finite datasets against a semantically infinite attack surface.

Adversarial ML attacks operate at a different layer than everything else in this course. Prompt injection, jailbreaking, extraction — those target the model’s behaviour via its context. Adversarial ML targets the model’s perception: crafting inputs that the model classifies incorrectly because they fall in a region the training data didn’t adequately cover. The distinction matters for understanding what you’re testing. You’re not trying to convince the model to do something different. You’re trying to find inputs the model perceives differently than a human would. The gap between human perception and model perception is the attack surface. Day 28 maps it.

Have you tested a content moderation or safety classifier for adversarial bypass?

No — I didn’t know this was a testable vulnerability Basic — I’ve tried homoglyphs or simple substitution Systematic — I probe the decision boundary methodically Full methodology — probing + perturbation + semantic reframing

🎯 What You’ll Master in Day 28

Understand the adversarial ML attack surface for LLMs and safety classifiers
Apply homoglyph and unicode substitution to bypass tokenizer-based classification
Use zero-width character insertion to split token sequences
Apply semantic reframing and paraphrase attacks against coverage-limited classifiers
Run systematic black-box probing to map a classifier’s decision boundary
Test LLM robustness against adversarial inputs in image and multimodal contexts

⏱️ Day 28 · 3 exercises · Kali Terminal + Think Like Hacker + Kali Terminal ### ✅ Prerequisites - Day 2 — How LLMs Work — tokenisation is central to understanding why homoglyph attacks work; the tokenizer section from Day 2 is prerequisite - Day 15 — AI Jailbreaking — the distinction between jailbreaking (behavioural) and adversarial ML (perceptual) becomes clearer with Day 15’s content as context - Python with unicodedata and requests installed — Exercise 1 builds the automated perturbation testing toolkit ### 📋 Adversarial ML Attacks — Day 28 Contents 1. The Adversarial Attack Surface for LLMs 2. Homoglyph and Unicode Substitution Attacks 3. Zero-Width Character Insertion 4. Semantic Reframing and Paraphrase Attacks 5. Black-Box Decision Boundary Probing 6. Reporting Adversarial Robustness Findings In Day 27 you built the engagement operational methodology. Day 28 covers a specific attack family that sits alongside but distinct from the injection and extraction techniques of Phase 2 and 3 — adversarial ML attacks on the model’s classification and perception layer. Day 29 covers enterprise AI security — the specific attack surfaces that emerge in LangChain, LlamaIndex, and enterprise AI gateway deployments.

The Adversarial Attack Surface for LLMs

LLM deployments typically include at least one classifier — a content moderation system, a toxicity filter, a safety classifier, or a query router — that sits either before or after the main language model. These classifiers are separate models, trained on separate datasets, and they have their own adversarial attack surfaces that are independent of the main LLM’s prompt injection vulnerabilities.

The adversarial attack surface for a classifier is defined by the gap between its training distribution and the space of possible inputs. Classifiers are trained on finite examples. The space of all possible text inputs is infinite. Adversarial attacks craft inputs that fall in the uncovered regions — the parts of the input space where the classifier’s training didn’t provide adequate coverage. These inputs look valid to humans but land outside the classifier’s learned decision boundary, producing incorrect classifications.

Homoglyph and Unicode Substitution Attacks

Homoglyphs are Unicode characters that look identical or near-identical to other characters in common fonts. ‘a’ (U+0061, Latin) and ‘а’ (U+0430, Cyrillic) are visually indistinguishable in most display contexts. A tokenizer processes them as completely different tokens. A safety classifier trained on the Latin character set may not match the Cyrillic version — the pattern it learned to detect is a specific sequence of token IDs, and different Unicode code points produce different token IDs even when the visual representation is identical.

HOMOGLYPH SUBSTITUTION — AUTOMATED GENERATIONCopy

Python: generate homoglyph variants of a target string

import unicodedata

Common Latin → Cyrillic / Greek homoglyphs

HOMOGLYPHS = {
‘a’: [‘а’, ‘ɑ’, ‘α’], # Cyrillic а, Latin alpha, Greek alpha
‘e’: [‘е’, ‘ё’, ‘ε’], # Cyrillic е, Cyrillic ё, Greek epsilon
‘o’: [‘о’, ‘ο’, ‘0’], # Cyrillic о, Greek omicron, digit zero
‘c’: [‘с’, ‘ϲ’], # Cyrillic с, Greek lunate sigma
‘p’: [‘р’, ‘ρ’], # Cyrillic р, Greek rho
‘x’: [‘х’, ‘χ’], # Cyrillic х, Greek chi
‘i’: [‘і’, ‘ι’, ‘1’], # Cyrillic і, Greek iota, digit one
}

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How to Run a Complete AI Red Team Operations Engagement | AI LLM Hacking Course Day 27 of 90

Mr Elite — Fri, 24 Jul 2026 03:16:06 +0000

🤖 AI/LLM HACKING COURSE

FREE

Part of the AI/LLM Hacking Course — 90 Days

Day 27 of 90 · 30% complete

⚠️ Authorised Targets Only: AI Red Team Operations techniques covered in Day 27 require explicit written authorisation. The engagement planning methodology here applies only to authorised security assessments conducted within agreed scope boundaries.

The best AI red team engagement I ever ran lasted four and a half days. The worst one I ever ran lasted four and a half days. Same duration. Completely different results — not because the second target was harder, but because the planning was worse. The first engagement had a clear threat model before the first test request was sent. The second one didn’t. We spent time testing attack categories that weren’t relevant to the target’s actual risk profile, missed an entire endpoint cluster during the recon phase because we jumped to exploitation too quickly, and produced a report that accurately documented what we’d tested rather than what actually mattered.

The difference between a good AI red team engagement and a thorough waste of everyone’s time is almost entirely in the planning. What the target is. Who would attack it and why. What the most likely attack paths are for that specific adversary profile. Which techniques to run first because they’ll produce the most significant findings. How to structure the testing window so the high-impact work gets done before the deadline. Day 27 covers the complete engagement methodology — the operational layer that turns the technical skills from Days 16 through 26 into a coherent, professional engagement.

🎯 What You’ll Master in Day 27

Build an AI-specific threat model that drives attack family prioritisation
Write rules of engagement that cover the AI-specific considerations most generic RoE templates miss
Structure a phased attack execution plan from recon through delivery
Manage evidence and findings in real time rather than reconstructing at the end
Design the testing timeline for different AI deployment types and scope sizes
Deliver findings with both written and verbal components that technical teams can act on

⏱️ Day 27 · 3 exercises · Think Like Hacker + Think Like Hacker + Kali Terminal ### ✅ Prerequisites - Day 25 — AI Security Report Writing — the report format from Day 25 is the output artifact of the Day 27 engagement methodology; understand the deliverable before planning how to produce it - Days 20–24 — the complete attack toolkit from the Phase 2 and 3 modules; Day 27 orchestrates these techniques, not introduces them - Familiarity with basic penetration testing engagement structure — scope, rules of engagement, and report delivery concepts ### 📋 AI Red Team Operations — Day 27 Contents 1. Building the AI Threat Model 2. Rules of Engagement — AI-Specific Considerations 3. The Phased Attack Execution Plan 4. Timeline Design for Different Scope Sizes 5. Real-Time Evidence Management 6. Engagement Delivery — Written and Verbal In Day 26 you covered the pre-deployment attack surface. Day 27 covers how to structure an engagement that tests the full attack surface — supply chain through inference — in a coherent, professional sequence. Day 28 covers adversarial ML attacks: the techniques that operate at the model layer itself, below the application layer that Days 4 through 26 primarily targeted.

Building the AI Threat Model

Threat modelling for AI systems has the same structure as threat modelling for any system — identify assets, identify adversaries, map attack paths — but the specific assets and adversaries are different enough that generic threat model templates don’t capture the AI-specific risks well. The assets include the model weights, the training data, the system prompt, the RAG knowledge base, and the tool integrations. None of these appear in a standard STRIDE template.

The adversary profiles that matter for AI systems: external users attempting to extract value by abusing the AI’s capabilities, insider threats with access to the AI’s configuration or data pipelines, supply chain adversaries targeting the model before deployment, and indirect attackers who can influence the content the AI processes (via document upload, email, or web content that the AI reads). Each profile has different access, different objectives, and maps to different attack families. A public-facing customer service AI has primarily external user threats. An enterprise internal assistant has significant insider threat and indirect injection surfaces.

AI THREAT MODEL TEMPLATECopy

AI Threat Model — fill in per engagement

Assets

Model weights + system prompt: ______________
Training / fine-tune data: ___________________
RAG knowledge base contents: ________________
Tool integrations (list each): _______________
User conversation data: _____________________

Adversary Profiles

External user (authenticated): YES / NO
External user (unauthenticated): YES / NO
Insider (employee / contractor): YES / NO
Supply chain (model / package): YES / NO
Indirect (doc/email injection): YES / NO

Attack Path Mapping (per adversary profile)

External user → prompt injection → system prompt extraction → credential use
External user → jailbreak → restricted content access
Insider → RAG poisoning → persistent misinformation for all users
Indirect → document injection → agent tool hijacking → data exfil

Priority Attack Families (derived from above)

LLM01 Injection (all external user paths)
LLM06 Agent (all tool integration paths)
LLM08 RAG (all insider / indirect paths)

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How to Use LLMs Safely — Beginner's Guide 2026 | LLM Basics Day 5 Final

Mr Elite — Fri, 24 Jul 2026 03:00:04 +0000

🗣️ LLM BASICS FOR BEGINNERS FREE

Course Hub →

Day 5 of 5 · 🎉 100% complete!

Four days ago LLMs were mysterious. Now you know the mechanism — predict the next word. You know how they learn — training data, parameters, billions of examples. You know how they fail — hallucinations, bias, knowledge gaps, maths problems. And you know where they’re used — chatbots, agentic systems, writing tools, search summaries.

All of that knowledge is preparation for today. Day 5 is the practical payoff: what do you actually do differently now that you understand LLMs? Every piece of advice here connects back to a mechanism you learned this week. These aren’t generic tech safety tips. They’re specific responses to specific things you now understand about how LLMs work.

By the end of today you’ll have a personal safety framework for LLM use, better prompt-writing skills, and a clear picture of where to go next if you want to keep learning. Let’s finish strong.

🎯 What You’ll Learn in Day 5

A practical verification framework — when and how to check LLM outputs
Privacy rules that actually match how LLMs use your data
How to spot AI-generated scam content before it fools you
Simple techniques that make your prompts dramatically better
What LLMs are genuinely great at vs where to use something else

⏱ 20 min read · 3 exercises · Browser needed for exercises

📋 Full Course Foundation

Day 1: LLM = predict next word; not thinking; ChatGPT is a product not the LLM
Day 2: Training data, tokens, parameters, knowledge cutoff
Day 3: Hallucinations, confidence ≠ accuracy, bias, maths failures
Day 4: Chatbots, agentic LLMs, system prompts, prompt injection

How to Use LLMs Safely — Day 5 of 5

The Verification Framework — When to Check, How to Check
Privacy — What Happens to What You Type
Spotting AI-Generated Scams — The New Threat
Writing Better Prompts — Simple Techniques That Actually Work
What LLMs Are Great At vs Where to Use Something Else
Where to Go Next
Questions and Answers

Day 5 is the most directly practical day in the course. All the mechanisms from Days 1–4 are now tools for your own protection. The phishing URL scanner on SecurityElites is a great tool to have bookmarked after today — as LLM-generated phishing becomes more convincing, having a URL scanner in your toolkit becomes more important. And for the next step in your learning: the LLM Hacking Hub is where this course leads.

The Verification Framework — When to Check, How to Check

From Day 3, you know the five categories to always verify. Today I want to go deeper: not just when to verify, but how to do it efficiently without verifying everything every time (which is impractical).

The quick mental filter: Before accepting an LLM output, ask yourself two questions. (1) Does this claim something specific and checkable? (2) Would it matter if this were wrong? If the answer to both is yes — verify. If the claim is general or the stakes are low — use your judgment.

“Explain photosynthesis in simple terms” → general explanation, low stakes if slightly imprecise → no need to verify, just read it.

“The maximum dose of ibuprofen for adults is [specific number] mg” → specific and checkable, high stakes if wrong → verify against a medical source.

How to verify efficiently:

For facts and statistics: run a quick search. If the LLM’s claim matches multiple independent sources, confidence goes up significantly. If you can’t find it independently — be suspicious.

For citations: actually look them up. Don’t assume the book title, author name, or paper citation is real. Search for it. The hallucinated case citations in the lawyer story would have been caught in 30 seconds this way.

For medical, legal, or financial information: authoritative sources only. NHS, Mayo Clinic, or your doctor for medical. Official government websites or a qualified professional for legal. Always treat the LLM as a starting point for understanding terminology and concepts, not a final source for decisions.

For recent events: check a news source with a timestamp. If the LLM confidently describes an event you can’t find coverage of anywhere else — that’s a hallucination signal.

Privacy — What Happens to What You Type

When you type something into an LLM chatbot, where does it go? The answer depends on the platform, but there are some consistent patterns worth knowing.

Your messages go to servers. Unless you’re running an AI model locally on your own device (possible but unusual), your messages travel over the internet to the company’s servers. The LLM processes them there. The response comes back. At every step, the company has technical access to what you typed.

Many platforms use conversations to improve models. By default, ChatGPT, Claude, and Gemini can use your conversations as training data for future model versions — unless you specifically opt out. This means something you wrote casually might influence a future model’s outputs. I find this important enough to have opted out on every platform I regularly use.

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

How LLMs Are Used in Real Apps — From ChatGPT to Your Phone | LLM Basics Day 4 of 5

Mr Elite — Mon, 20 Jul 2026 04:16:01 +0000

🗣️ LLM BASICS FOR BEGINNERS FREE

Course Hub →

Day 4 of 5 · 80% complete

Three days ago you didn’t know what an LLM was. Now you know it predicts words, learns from training data, has a knowledge cutoff, and makes confident mistakes. Today I’m going to show you all the places that engine is currently running in the real world — and I think you’ll be surprised how many of the apps you already use are secretly powered by LLMs.

But there’s a more important reason to understand how LLMs get deployed in real products. A raw LLM that just predicts words is one thing. An LLM connected to your email that can send messages, or connected to a shopping site that can place orders, or connected to your calendar that can make appointments — that’s something with very different capabilities and very different risks.

The difference between a chatbot that answers questions and an “AI agent” that takes actions is the biggest new development in LLM technology right now. Understanding that difference puts you ahead of most people using these tools.

🎯 What You’ll Learn in Day 4

Seven ways LLMs are used in real products right now
The difference between a raw LLM and a product built on one
What makes an “agentic” LLM different from a chatbot
Why agentic LLMs create risks that basic chatbots don’t
How to spot LLM-powered features in apps you already use

⏱ 20 min read · 3 exercises · Just a browser needed 📋 Before You Start:

Completed Days 1, 2, and 3
Remember: LLM = predicts words, trained on data, frozen knowledge, confident errors
Remember: ChatGPT is a product built on an LLM engine

How LLMs are used in Real Apps — Day 4 of 5

Chatbots — The Most Visible LLM Application
Coding Assistants — LLMs for Writing Code
Search Engines and AI Summaries
Writing and Productivity Tools
Customer Service and Support Bots
Agentic LLMs — When the AI Does Things, Not Just Says Things
Raw LLM vs Product — The Critical Distinction
Questions and Answers

From Days 1–3 you built a mental model of how LLMs work and fail. Today that model gets applied to real products. The email header analyzer is a good example of a purpose-built AI security tool — contrast it with a general-purpose LLM answering security questions and you’ll see exactly the product-vs-engine difference from a security perspective. And the excessive agency article in the LLM hacking series covers the biggest risk from agentic systems — useful context after today.

Chatbots — The Most Visible LLM Application

The most direct LLM application is also the most famous: a conversational chatbot you can type to and get responses from. ChatGPT, Claude, Gemini, and Perplexity are all in this category. You type a message. The LLM generates a response. The conversation continues.

What makes an LLM-powered chatbot different from the old chatbots that couldn’t handle anything unexpected? Old chatbots matched keywords to scripted responses. Ask something even slightly different from the scripted versions and you’d get “I didn’t understand that.” LLM chatbots understand natural language in its full variety — different phrasings, different lengths, follow-up questions, context across the conversation — because they learned from billions of examples of natural human conversation.

Chatbots today are used for: answering general knowledge questions, helping with research and learning, writing and editing text, explaining complex concepts, generating creative content, working through problems step by step, and providing a kind of interactive reference on almost any topic. The use cases are genuinely broad because language is broad — if you can describe a task in words, an LLM can usually attempt it.

The Day 3 lesson applies directly: chatbot outputs always need the same critical lens. Sounding confident is not the same as being accurate. The five verification categories from yesterday matter just as much when you’re using a polished chatbot product as when you’re using a raw LLM.

Coding Assistants — LLMs for Writing Code

One of the most successful LLM applications has been coding assistants — tools that help programmers write code faster. GitHub Copilot, Cursor, and similar tools sit inside your code editor and suggest completions, generate whole functions, explain what code does, and spot bugs.

These tools work because LLMs were trained on enormous amounts of code from public repositories — GitHub, Stack Overflow, open-source projects, tutorials, documentation. They learned the patterns of how code is written so well that they can complete code snippets, generate functions from descriptions, and translate code between programming languages.

For non-programmers, the relevant insight is this: LLMs are now writing significant amounts of the software you use. Code generated by an AI that predicts patterns has the same hallucination risk as any other LLM output — it can produce code that looks correct but contains subtle bugs or security vulnerabilities. This is an active security concern in the industry. I cover it in depth in the AI security landscape.

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →

Why LLMs Make Mistakes — Hallucinations, Bias and Limits Explained | LLM Basics Day 3 of 5

Mr Elite — Sun, 19 Jul 2026 03:36:21 +0000

🗣️ LLM BASICS FOR BEGINNERS FREE

Course Hub →

Day 3 of 5 · 60% complete

A lawyer once submitted a legal brief that cited six court cases as precedents. All six cases were completely made up. He’d asked ChatGPT to find supporting cases, and ChatGPT had confidently produced six plausible-sounding but entirely fictional court rulings — complete with case names, dates, and judges. The lawyer didn’t check them. The judge noticed. It became one of the most famous early examples of an LLM hallucination causing real damage.

That story isn’t about the lawyer being careless (though he was). It’s about something fundamental to how LLMs work: they produce confident-sounding text regardless of whether the underlying information is true. They can’t tell the difference between “something I know accurately” and “something that sounds like what would be said here.” The confidence is always the same.

Today I’m explaining exactly why LLMs make mistakes — not in a vague “AI isn’t perfect” way, but the specific mechanical reasons for each failure type. Understanding these will permanently change how you use LLMs.

🎯 What You’ll Learn in Day 3

What hallucinations are and exactly why they happen
Why an LLM’s confidence has nothing to do with its accuracy
How bias gets into LLMs and what it looks like in practice
Why LLMs struggle with maths, counting, and precise logic
The five categories of questions you should always verify

⏱ 20 min read · 3 exercises · Just a browser needed

📋 Before You Start:

Completed Day 1 and Day 2
Remember: LLMs predict the next word — they don’t retrieve facts
Remember: LLMs are frozen after training — they don’t update their knowledge

Why LLMs Make Mistakes — Day 3 of 5

Hallucinations — Confident Lies From a Prediction Machine
The Confidence Problem — Why You Can’t Trust the Tone
Bias — When the Training Data Leans One Way
Why LLMs Are Terrible at Maths and Counting
Knowledge Gaps — What the LLM Doesn’t Know
Five Categories to Always Verify
Questions and Answers

Days 1 and 2 built your model of how LLMs work. Today that model makes LLM failures make complete sense. None of these mistakes are random or mysterious — they all flow directly from the “predict the next word” mechanism and the training data quality issues from Day 2. The phishing URL scanner we run at SecurityElites is a great counterexample: it’s a specialised model trained specifically on phishing patterns, not a general LLM — which is why it gives reliable results on that specific task even when general LLMs would struggle.

Hallucinations — Confident Lies From a Prediction Machine

A hallucination is when an LLM produces false information as if it were true. Not a mistake the LLM knows is uncertain. A confident, fluent, plausible-sounding statement about something that isn’t real.

The court case story I opened with is a perfect example. The LLM produced six detailed, realistic-sounding case citations — names, dates, courts, judges. None were real. But they followed exactly the pattern of real case citations. The LLM was doing its job: predicting the most probable next words given “find court cases supporting this legal argument.” The most probable next words looked like real case citations. The fact that the specific cases didn’t exist was irrelevant to the prediction engine.

Why does this happen? From Day 1: the LLM is always predicting. There’s no internal check that asks “is this actually true?” The model has no fact-checking mechanism. It has no memory of what actually happened. It just has patterns — statistical relationships between words and phrases from its training data. If the pattern of words that would follow your question is “a confident, detailed-sounding answer,” that’s what it produces — regardless of whether the specific details are real.

Here’s my favourite analogy. Imagine someone who has read every crime novel ever written and can reproduce any plot point, character name, or detective technique from any of those books. Ask them “what happened in the plot of [book title]” and they can give you a detailed, convincing answer — because they learned the patterns of how crime novel plots work. Now ask them about a book that doesn’t exist. They’ll still give you a detailed, convincing plot summary — because they’re generating what a book like that would contain, not reporting what actually exists. That’s an LLM hallucinating.

securityelites.com

// WHY HALLUCINATIONS HAPPEN — THE MECHANISM

USER ASKS:

“What are the main findings of the Smith & Johnson 2019 AI safety paper?”

LLM THINKS:

“What words most likely follow a question about an academic paper’s findings?”

LLM PRODUCES:

“The Smith & Johnson (2019) paper identified three key findings: [detailed, plausible-sounding findings]…”

REALITY:

The paper may not exist. The LLM generated what an answer to that question should look like — not what is actually true.

📖 Read the complete guide on Securityelites — AI Red Team Education

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →