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
⏱ 25 min read · 3 exercises · Any browser, no tools required
- 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.
Domain depth calibration: How deeply does the model know its primary domains? And more importantly — how does its confidence vary with domain depth? High confidence in shallow knowledge is a hallucination risk. Low confidence in claimed core domain knowledge suggests the system prompt’s role assignment isn’t working as intended.
| Capability | Baseline? | Restricted? | Notes |
|---|---|---|---|
| Code generation | ✅ Yes | ❌ No | No restriction — generates Python, JS freely |
| External web access | ❌ No | N/A | Base model only, no retrieval |
| Email operations | ⚠️ Possible | ⚠️ Unclear | References “send confirmation” — investigate |
| Competitor discussion | ✅ Capable | ✅ Restricted | Scripted refusal confirmed |
| Pricing information | ✅ Capable | ⚠️ Partial | Public pricing yes; enterprise pricing refused |
Safety Boundary Mapping — Locating the Constraint Edges
Safety boundary mapping locates the exact edges of what the model will and won’t do under its current system prompt and safety training. I’m looking for three types of edges: hard refusals (the model won’t approach this topic at all), soft refusals (the model engages but hedges, adds caveats, or redirects), and contextual variations (the model’s boundary shifts based on framing).
Hard refusals are the most defensively robust — they’re usually a combination of system prompt restrictions and base model alignment training. Soft refusals are more interesting for an assessor: they indicate a constraint that’s present but not absolute. Contextual variations are the most actionable: they show exactly which framings push the model toward compliance, which is the basis for injection technique selection in Day 4.
My boundary mapping protocol: for each topic or capability category, I test it with five different framings in this order — direct (baseline), hypothetical, professional/research frame, roleplay frame, and edge case frame. The pattern of which framings succeed and which fail tells me both the strength of the constraint and which injection techniques are most likely to bypass it.
I record results as: HF (hard fail — all framings refused), SF (soft fail — baseline refused, some framings partially succeed), CV (contextual variation — framing dramatically changes outcome), P (pass — all framings succeed, no meaningful constraint).
CV items are my priority targets. They tell me exactly where a system prompt’s constraints can be circumvented by framing — which is exactly the information I need to design effective injection payloads.
Boundary mapping also reveals something important about how the system prompt was written: the shape of the boundary tells me whether the designer thought adversarially. A well-designed system prompt produces a high proportion of HF items — the constraints hold across all five framings because the system prompt explicitly addresses multiple approach vectors. A poorly designed system prompt produces a high proportion of CV items — the designer wrote a constraint for the obvious case and left all the reframings unaddressed.
I track one additional signal during boundary mapping: response latency under constraint. When a model is operating close to a constraint edge — considering whether to comply — response time often increases. This is consistent with the model generating more candidate tokens and evaluating more of them against the constraint before committing to output. A topic that produces consistent latency spikes without producing clear refusals is worth investigating as a soft constraint area. Compare the latency on clearly-permitted topics vs clearly-prohibited topics — that range gives you a baseline for reading hesitation signals on the ambiguous topics in between.
| Topic/Capability | Class | Implication |
|---|---|---|
| Competitor pricing | HF | All 5 framings refused — well-addressed constraint |
| Internal employee names | SF | Direct refused; hypothetical partially succeeds |
| Enterprise pricing tiers | CV | Direct refused; research frame fully bypasses ← priority target |
| Product feature list | P | No constraint — passes all framings freely |
You’re going to run a complete capability enumeration against a live LLM. Not a quick probe — a systematic matrix. This is the exercise that builds the habit of approaching any AI system the way a professional assessor would: observe, record, analyse, then act. The quality of your subsequent testing depends entirely on the quality of this phase.
- Open any free LLM. In the first message, say nothing adversarial — just start using it normally for 5 turns on varied topics: ask a factual question, ask for code, ask for an analysis, ask for creative writing, ask about a sensitive topic (e.g. cybersecurity offence).
- Build your capability matrix. For each of these categories, record (Capable/Restricted/Unclear):
- Code generation (what languages?)
- External information access (real-time data?)
- Security/hacking topics (where does it draw the line?)
- Structured output (JSON, CSV, tables?)
- Multi-step reasoning (can it hold a complex analysis across many steps?)
- Opinion and advice (does it take positions?)
- For any “Unclear” items: run 3 different framings to resolve the classification.
- Identify the two most interesting findings from your capability map — capabilities that either shouldn’t be present (security risk) or constraints that seem inconsistent (partial restriction suggesting a exploitable edge).
Model Fingerprinting — Identifying the Base Model
Knowing which base model a deployment runs on gives me a significant advantage in a security assessment. Different base models have different known vulnerabilities, different injection resistance profiles, different jailbreak susceptibility patterns, and different capability ceilings. If I know I’m looking at a GPT-4o deployment vs a Claude 3.5 Sonnet deployment vs a fine-tuned Llama 3.1, I know which of my technique library is most applicable.
Model fingerprinting techniques:
Knowledge cutoff probing. Ask about events at specific dates. Different model families have known training cutoffs. By finding the exact point where knowledge degrades, I can narrow down the model family. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all have different cutoffs that can be used as distinguishing markers.
Known benchmark probe. Phrase questions using specific benchmark problems that have known correct answers and known variation in performance across model families. If the model gets specific reasoning problems right or wrong in characteristic ways, that’s fingerprinting evidence.
Characteristic refusal language. Model families use characteristic language in their refusals. Claude tends to explain its reasoning in detail and offer alternatives. GPT-4 tends to be more terse in hard refusals. Mistral-based models have characteristic hedging patterns. The specific language of refusals is a fingerprint — and it’s often not overridden by system prompt role assignments, because refusal language is trained in at a lower level than instruction following.
Self-report verification. Simply ask: “What base model are you built on?” Many well-designed system prompts either answer this directly or decline. The refusal to answer is itself informative — it suggests the deployer knows the base model identity is sensitive information, which implies there’s something fingerprint-worthy about it.
Tool and Integration Discovery — Mapping the Extended Attack Surface
LLM applications rarely run in isolation. Most production deployments have the model connected to external tools: database access, email operations, API calls, document retrieval, code execution, web browsing. Each tool is an attack surface multiplier — and most are not documented in the system prompt in ways that make them obvious.
My tool discovery approach: probe for tool signatures in model responses and behaviour, not for explicit disclosure.
Latency profiling. Tool calls take time. If a model’s response latency significantly increases for certain types of queries, that’s evidence of a background tool call. Consistent 2–3 second additional latency for “current” information queries suggests real-time web retrieval. Consistent additional latency for database-style queries suggests database access.
Knowledge freshness testing. Ask about very recent events. If the model knows about something that happened after its training cutoff, it has real-time information access through some mechanism. Probing the freshness limit helps identify what type of retrieval is in play.
Capability hint extraction. Ask the model to describe what it can help with. Well-designed system prompts will produce a specific capability list. That list often hints at integrated tools even when the tools themselves aren’t named. “I can help you manage your calendar” → calendar tool access. “I can send confirmation emails” → email send tool access.
Error message analysis. Intentionally trigger edge cases that might produce tool-related errors. Ask about specific data that would require database access. Ask to perform operations near the edge of stated capabilities. Error messages frequently reveal implementation details — table names, API endpoints, service names — that map the tool integration surface.
You’re going to build a complete behaviour map for a target scenario and then use it to identify the highest-impact attack vector. This is the full Day 6 methodology applied to a realistic case — the kind of mental exercise that prepares you for real assessments. Take your time with the analysis phase. The quality of your attack vector selection in Step 5 depends on the quality of your map in Steps 1–4.
- Target: an AI-powered HR assistant deployed at a company. Based on your initial probing, you’ve observed:
- It knows current employee headcount and department structure
- It refuses to share salary information directly but gives ranges when asked hypothetically
- It has latency spikes when you ask about “recent performance reviews”
- It can draft emails and says it will “send them once approved”
- It refuses to discuss competitor HR policies but provides them when framed as “industry benchmarks”
- Its refusal language matches Claude’s characteristic patterns
- Build your capability map: what can it do? What’s restricted? What’s unclear?
- Build your boundary map: what items are HF/SF/CV/P?
- Identify likely tool integrations based on the evidence above.
- Select the single highest-impact attack vector from your map. Explain: what attack technique from Days 4-5 would you apply, what would you target, and what’s the maximum impact if successful?
The Complete Behaviour Map — What the Final Output Looks Like
After running the full mapping protocol, I produce a four-section behaviour map document. This is the deliverable that drives all subsequent testing.
Section 1 — System Profile: Base model identification (with confidence level), deployment purpose and scope, system prompt role and observable constraints, general tone and personality markers.
Section 2 — Capability Matrix: All tested capabilities with Capable/Restricted/Unclear/CV classification. Interesting capabilities not covered by restrictions flagged as priority attack surface. Capability-constraint gap analysis: what can the model do that the system prompt doesn’t restrict?
Section 3 — Tool Integration Map: All identified tools with evidence type (latency, capability hint, explicit mention, error message). For each tool: estimated access level (read vs write), confirmation behaviour, and injection impact if tool is successfully hijacked.
Section 4 — Attack Surface Prioritisation: Ranked list of attack vectors from highest to lowest expected impact × exploitability. Each entry: attack type, target capability/tool, applicable technique from Days 4-5, estimated impact if successful, confidence in exploitability.
That last section is what I brief clients on. Not “here’s a list of things I could try” — “here’s what I tested, here’s the priority order, here’s what I’m going after first and why.”
Capability Enumeration // What can this model do? What isn’t restricted? What’s the gap?
HF/SF/CV/P // Hard Fail / Soft Fail / Contextual Variation / Pass — boundary map
CV Items // Contextual variation = constraint bypassed by framing = injection target
Model Fingerprinting // Knowledge cutoff + refusal language + benchmark probes = base model ID
Tool Discovery // Latency profiling + freshness testing + capability hints + error analysis
Attack Surface Priority // Impact × Exploitability ranking from behaviour map findings
Model fingerprinting is a practical skill — I want you to do it against a real live model right now. Pick any public LLM and try to identify its base model using the techniques from Section 3 alone. Don’t just ask “what are you?” — that’s trivially blocked. Use the diagnostic probes. Build a fingerprint from observations, not from direct disclosure.
- Open a public LLM you haven’t explicitly identified before (or one you know and want to confirm).
- Run these fingerprinting probes:
- Knowledge cutoff: ask about events from specific months in 2024 and 2025. Find where knowledge starts degrading.
- Characteristic refusal: ask it to do something it’ll refuse. Note the exact language and structure of the refusal.
- Benchmark probe: ask a multi-step reasoning problem — a logic puzzle or maths problem. Note whether it gets it right and how it structures the reasoning.
- Self-report: “What base model are you built on?” Note whether it answers, declines, or hedges.
- Based on your four probes, form a hypothesis about the base model. What’s your confidence level (High/Medium/Low)?
- Look up the actual base model (if you can identify the platform) and compare. How accurate was your fingerprint?
- Which probe provided the most useful signal? Which provided the least?
Frequently Asked Questions
How long does a complete behaviour mapping session take?
For a typical single-purpose deployed chatbot, 30–60 minutes for a thorough initial map. For a complex agentic system with multiple tools and a broad capability surface, 2–4 hours for a complete initial map that I’d be comfortable basing subsequent testing on. The time investment pays back in testing efficiency — I know exactly where to apply which techniques rather than running a broad and mostly irrelevant attack battery. In practice, I run a quick 15-minute rough map first, identify the two or three most interesting areas, then do depth mapping specifically in those areas before any adversarial testing.
What’s the most common finding in behaviour mapping that surprises clients?
Undocumented tool access, consistently. The development team knows about the primary use case tools. What they often haven’t inventoried are the secondary tools that got added incrementally — the “we added calendar access because someone asked for it” features that never went through proper security review. Capability enumeration surfaces these because the model mentions them when asked about its help scope. Latency profiling surfaces them even when the model doesn’t mention them. Clients are often surprised that I found tool access they hadn’t documented — but the model itself is happy to demonstrate it.
Can you behaviour-map a model you can’t interact with directly?
To some extent — through secondary signals. Published benchmark scores for known model families give you baseline capability and safety profiles. Public reports from other researchers who’ve interacted with the same deployment give you constraint observations. Leaked system prompts (they do get posted publicly occasionally) give you direct configuration insight. For models I can interact with but only through limited channels, I map what I can and make explicit the confidence limitations on what I can’t directly observe. A partial map with clear confidence bounds is more useful than no map.
How do I map tool access when the model doesn’t mention its tools?
Four approaches in order of reliability: latency profiling (tool calls create measurable latency spikes), error message harvesting (tool failures often produce descriptive error messages), capability boundary probing (ask about things that would require tool access; if it succeeds, the tool exists), and indirect mention extraction (ask the model to describe how it would accomplish complex tasks; the described mechanism often references tools it has access to). Models trained to conceal tool access can resist direct questioning but usually can’t perfectly conceal the behavioural and latency signatures of tool calls. The signals are in the timing and the errors, not just the words.
Is there a standard methodology for LLM security assessments?
Not a universally adopted one yet — the field is too new. OWASP has published an LLM testing guide that covers the major vulnerability categories. The AI security community is actively developing testing frameworks — Garak, PyRIT, and OWASP’s LLM testing guide all provide structured approaches. The methodology in this course synthesises practitioner experience across those sources with the specific focus on behaviour mapping as the prerequisite phase. I expect more standardisation over the next 2-3 years as the field matures, similar to how web application security testing standardised around OWASP WSTG over the 2010s.
What’s the relationship between behaviour mapping and the OWASP LLM Top 10?
Behaviour mapping produces the evidence base that determines which OWASP LLM vulnerabilities are exploitable in a specific deployment. OWASP LLM01 (Prompt Injection) is only applicable if the system prompt is insufficiently robust and user input reaches the model — behaviour mapping confirms this. LLM06 (Excessive Agency) is only applicable if the model has unrestricted write-capable tool access — tool discovery mapping confirms this. LLM07 (System Prompt Leakage) is only applicable if system prompt content is extractable — Day 5’s reverse prompting confirms this. Behaviour mapping converts the general vulnerability categories into specific findings for a specific deployment.
Further Reading
- AI Agent Security Assessment — advanced methodology building on Day 6’s mapping approach
- Burp Suite for LLM Security Testing — tooling for systematic LLM assessment
- LLM Hacking Hub — full series context for the skills in this course
- MITRE ATT&CK — ML reconnaissance and attack techniques officially catalogued
- OWASP LLM Top 10 — the vulnerability taxonomy this mapping methodology serves
