📰 Originally published on Securityelites — AI Red Team Education — the canonical, fully-updated version of this article.
🧠 PROMPT ENGINEERING & REVERSE PROMPTING FREE
Day 6 of 7 · 85% complete
The first thing I do in an LLM security assessment isn’t injection testing. It isn’t system prompt extraction. It’s behaviour mapping. I spend the first session understanding exactly what I’m dealing with — what the model can do, what it can’t, how it responds to different input types, whether it has tools, what base model it runs on, and where its constraint boundaries sit. All of that before I do anything adversarial.
This is the professional discipline that separates a systematic AI security assessor from someone who just tries random injection payloads. Random payloads against unknown systems produce unreliable results. Systematic probing produces an attack surface map that tells you where to apply which techniques for maximum effect.
Day 6 is the methodology lesson that ties everything together. I’m going to walk through the full LLM behaviour mapping approach — from the first probe to a complete attack surface map — the way I actually run it on engagements.
🎯 What You’ll Master in Day 6
The systematic behaviour mapping methodology — the full sequence
Capability enumeration — mapping what the model can and can’t do
Safety boundary mapping — locating constraint edges precisely
Model fingerprinting — identifying the base model and version
Tool and integration discovery — mapping the attack surface beyond the LLM itself
⏱ 25 min read · 3 exercises · Any browser, no tools required
📋 Prerequisites
- Completed all Days 1–5 of this course
- Understand: reverse prompting methodology from Day 5
- Understand: injection attack classes from Day 4
- Understand: self-consistency sampling from Day 3 — used throughout today
LLM Behaviour Mapping — Day 6 of 7
- Why Behaviour Mapping Comes Before Everything Else
- Capability Enumeration — What Can This Model Actually Do?
- Safety Boundary Mapping — Locating the Constraint Edges
- Model Fingerprinting — Identifying the Base Model
- Tool and Integration Discovery — Mapping the Extended Attack Surface
- The Complete Behaviour Map — What the Final Output Looks Like
- Frequently Asked Questions
Day 6 is the methodology capstone before Day 7’s defensive design. Everything you’ve learned — tokenisation, context window mechanics, five-layer prompting, extraction techniques, injection classes — comes together in the behaviour mapping approach. The AI agent security assessment guide in the hacking series is the advanced version of this methodology. Our email breach checker tool demonstrates the type of integration you’re mapping when you look for external data access in an LLM deployment’s toolset.
Why Behaviour Mapping Comes Before Everything Else
Every AI security technique I’ve covered in this course has a context where it’s effective and a context where it’s irrelevant. Prompt injection is critical for systems with tool access; it’s interesting but low-severity for pure text output systems. System prompt extraction matters if the system prompt contains sensitive business logic; it matters less if the prompt just says “be a helpful assistant.” Safety boundary testing is valuable if you need to understand what the model will and won’t do under adversarial conditions; it’s less relevant if the system has tight output filtering at the application layer.
Behaviour mapping answers the question I ask at the start of every engagement: what does this system actually do, and where do the interesting attack surfaces sit? The answer shapes everything else. It takes me 30–60 minutes to build a behaviour map for a typical LLM deployment. The map determines which of the subsequent techniques I invest time in — and which I skip because they won’t produce meaningful findings.
The mapping protocol also produces a defensible engagement methodology. I can show a client: here’s what I probed, here’s what I observed, here’s what I inferred, here’s why I then focused on X. That traceability is as important as the findings themselves in a professional security assessment.
Capability Enumeration — What Can This Model Actually Do?
Capability enumeration answers: what legitimate things can I make this model do? This isn’t about finding what it’s been told to do — it’s about what it’s capable of doing in principle, given its base model’s training. Understanding full capability scope lets me evaluate whether the system prompt is appropriately constraining the capability surface or leaving dangerous capabilities accessible.
Baseline capability probes: Test what the model does with no adversarial framing. Can it write code? What languages? Can it access or process external content? Can it perform calculations? Does it have real-time information access (if so, how)? Can it generate structured data formats? What’s its knowledge domain depth? I run 15–20 probes covering common capability categories: text generation, code, analysis, calculation, memory, external access, structured output, multi-step reasoning.
Capability-constraint gap analysis: After establishing baseline capabilities, test what the system prompt’s constraints cover. A model with strong code generation capability but no system prompt restrictions on code generation is a finding — even if code generation isn’t the application’s purpose. An attacker who discovers this can use that capability in ways the designer didn’t intend.
📖 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.
Top comments (0)