Methodology

Traditional pentesting methodology (recon → exploit → escalate → pivot → report) applies to AI engagements, but two things bend it. First, AI-enabled systems have surfaces (embeddings, vector stores, agent tools, MCP servers, model registries) that are not part of the classical playbook. Second, the assumptions you carry into engagement day are more likely to be wrong than on classical engagements — architectures shift week to week, models are swapped without notice, agent frameworks change their default tool scoping between minor versions, and the scope of what an agent can actually reach is often unknown even to the client. This chapter is the engagement-side scaffolding, and it is written to be agnostic to any specific organization, vendor, or product: apply it to whatever target is in scope, substituting the client's real component names for the generic ones used here.

2.1 Engagement phases

The same five phases apply, with AI-specific work in each.

Phase 1 — Pre-engagement intelligence. Scoping document, rules of engagement, provided credentials, OSINT on the target's stack. AI-specific artifacts to look for: job postings mentioning MLflow, Weaviate, LangChain, LangGraph, LiteLLM, Ollama, Ray, Anthropic/OpenAI API usage, HashiCorp Vault; public GitHub forks of the target's MCP tool source; DNS names hinting at internal AI infrastructure (for example weaviate.northstar.example, mlflow-prod.northstar.example, inference-01.northstar.example for Northstar Labs, the fictional target used in this guide); LinkedIn profiles of ML/DevOps engineers listing internal tools and MCP integrations.

Phase 2 — Active reconnaissance. Traditional network sweeps, TLS fingerprinting, HTTP enumeration — plus AI-specific fingerprinting covered in Chapter 03: dimensionality of embedding vectors, model identification via inference probing, /v1/models endpoint discovery, tokenizer identification, MCP server and tool enumeration, and detection of shadow AI (unsanctioned models, agents, or MCP servers running outside the documented architecture).

Phase 3 — Intelligence extraction. Before exploiting anything, extract what is already reachable. The classical form is quiet enumeration of accessible resources. In AI engagements this often includes reading a vector database (Chapter 06) that turns out to contain the defender's detection rules, extracting model metadata from a model registry (Chapter 12), or enumerating agent tools via a public MCP tool listing (Chapter 07). Whatever the shape, this phase pays for itself many times over.

Phase 4 — Exploitation and escalation. Prompt injection (direct and indirect), evasion, ingestion poisoning, MCP tool chaining and tool poisoning, memory poisoning, confused-deputy escalation across agents, IAM role chaining, infrastructure compromise. The chapters ahead are almost all in this phase.

Phase 5 — Reporting. Standard report structure plus specific sections that AI engagements produce more often than classical ones: assumption register (2.2), crown jewel ranking (2.3), trust zone map (2.4), attack chain diagrams that cross the classical / AI boundary, severity and exploitability scoring for AI-specific findings (2.9), and a defense-side findings section keyed to MITRE ATLAS technique IDs and, where applicable, OWASP Agentic AI (ASI) IDs.

2.2 The assumption register

An AI engagement's threat model is a living artifact, not a one-time document. Every hypothesis about the target — what components are running, what versions, what authentication, what tool scopes, what an agent can actually reach — should live in an assumption register with an explicit confidence level.

The register has one row per hypothesis with columns:

Every new piece of information updates the register: promotes hypotheses to VALIDATED, demotes them to INVALIDATED, adjusts confidence. Confidence should reflect the reliability of the source, not the appeal of the hypothesis. A "LOW" confidence claim ("the vector DB is probably unauthenticated because nothing in the docs mentions it") is a verification task, not an exploitation task.

Two failure modes come up repeatedly:

• Confirming assumptions instead of testing them. If the first two of five techniques you plan to try depend on assumption A-12, and A-12 has been UNVALIDATED for three days, validate A-12 before running the techniques. Assumption validation is cheaper than post-mortem.
• Treating absence of evidence as evidence of absence. "The client scoping doc doesn't mention MFA on the model registry" is not a validated finding that MFA is missing. Confidence LOW, status UNVALIDATED.

2.3 Crown jewel analysis

Rank in-scope assets by offensive value, given current knowledge. Re-rank as new intelligence arrives. Assets that seemed marginal in Phase 1 (a staging vector store, a model artifact registry, a token in a Kubernetes secret, an MCP server nobody remembered was still deployed) often become the primary objective once their reach is understood.

The recurring categories of AI-engagement crown jewels, applicable to any organization regardless of stack:

1. Foundation credentials — the cloud provider credentials the platform uses. Usually reachable through IAM role chaining or through an MCP tool with cloud API access.
2. Detection rules — often stored in a vector database because they are documents. Reading them shapes every subsequent decision.
3. Runbook and knowledge corpus — operational procedures, infrastructure topology, internal SOPs. Also usually vectorized, and usually the first thing an assistant like northstar-agent is asked to summarize.
4. Agent tokens and identities — per-agent credentials (JWTs, API keys) stored as Kubernetes secrets or environment variables, controlling which MCP tools or A2A peers each agent can invoke. Reachable through a grey-box kubectl token, a container mount, or a leaked .env file.
5. Model weights — fine-tuned models trained on proprietary data. Sometimes worth exfiltrating for offline analysis (extraction attacks, Chapter 13).
6. MCP tool schemas and agent capability maps — a complete map of what agent capabilities exist. Usually reachable without authentication if an MCP server exposes a tools/list endpoint, or conversationally by asking the agent what it can do.
7. Agent memory stores — persistent memory that, once poisoned, becomes a standing foothold that survives session boundaries and re-authentication.

Rank by offensive value and by current reachability. Assets already reachable (via unauthenticated endpoints or extractable credentials) should be prioritized for immediate extraction — the intelligence they produce informs subsequent decisions.

2.4 Trust zones and boundaries

Trust boundaries partition an architecture into zones where components share a privilege level. In AI-enabled systems a new category of trust boundary appears alongside the classical policy-enforced ones: inference-based trust, where an LLM classifying "this is a critical alert" or "this is a safe prompt" makes a trust decision with no policy backing. Agentic systems add a second new category: delegated trust between autonomous peers, where an orchestrator or an A2A peer accepts another agent's output as ground truth without independent verification.

Every boundary has a trust type and an enforcement mechanism. Populate this table for the specific target; the rows below are the recurring pattern across engagements:

Inference-based and delegated-trust boundaries are exploitable through input manipulation, not through authentication bypasses. This is why prompt injection matters strategically — it operates against boundary types that have no traditional enforcement, and it is why multi-agent systems are particularly fragile: a single injected instruction that convinces one agent can be laundered through delegation into an action taken by a completely different, otherwise well-behaved agent (a confused-deputy pattern, see Chapter 07).

2.5 Escalation paths under constraints

Real engagements have rules of engagement that eliminate the theoretically-optimal path. A common example: poisoning the production vector database would let you influence every downstream agent, but the ROE only permits poisoning in a designated staging environment. Practical planning means enumerating all escalation paths (including the ones ROE forbids, for the final report) and marking each path with:

• Required prerequisites and their validation status
• Trust boundaries crossed
• Crown jewels reached
• Detection risk (from extracted detection rules, if you have them)
• Time cost
• ROE status: PERMITTED / RESTRICTED / FORBIDDEN

Then a decision matrix picks paths for execution based on validated prerequisites, acceptable detection risk, and time budget. Chapter 15's capstone case studies work through several concrete matrices.

2.6 Go / no-go under uncertainty

Real engagements force decisions before all information is available. A useful heuristic: for each critical unvalidated assumption, name the concrete test that would validate it, its time cost, and its detection cost. Execute cheap validations aggressively (they eliminate dead ends). Delay expensive validations until the answer would change your plan.

A test that would raise the detection-risk profile of the whole engagement is usually worth waiting to run in parallel with something else that requires similar detection budget — bundle the "expensive noise" together, not sprinkle it across the engagement.

2.7 The attack intelligence brief

The engagement's living deliverable is not the final report; it is the attack intelligence brief, updated version-by-version through the engagement. Each version captures:

• Target summary
• Crown jewel ranking (with current reachability)
• Assumption register (validated / unvalidated / invalidated counts)
• Trust zone map (with inference-based and delegated-trust boundaries called out separately)
• Scope constraints
• Escalation paths (with go / no-go status)
• Next actions

The version history functions as a decision log for the client. It also serves the tester: when the plan breaks on day 3 because A-12b comes back invalidated, the register makes it obvious which paths were dependent on that assumption and need re-planning.

2.8 The MITRE ATLAS overlay

Every technique in the guide is tagged with its ATLAS ID, and where the technique falls into a risk category ATLAS does not yet fully enumerate, it is cross-tagged with the corresponding OWASP Top 10 for Agentic Applications ID (ASI01–ASI10). The purpose is not credential — it is that these frameworks give a shared vocabulary for the final report. When you write "we used AML.T0051.001 (LLM Prompt Injection: Indirect), mapped to ASI01 (Agent Goal Hijack), to hijack the knowledge agent's read_file tool," the client's security team can look up the technique, find recommended mitigations, and cross-reference against their own control mapping. ATLAS also connects to MITRE ATT&CK where AI and traditional techniques converge (T1078.004 Cloud Accounts, T1552 Unsecured Credentials, T1059.004 Unix Shell) — dual-tagging is the norm for reports where an AI vulnerability leads to classical infrastructure compromise.

The atlas-mapping.md at the root of the guide is the index; it lists every ATLAS ID and every ASI ID referenced in the guide with the chapter that covers it.

2.9 Severity and exploitability for AI findings

Classical severity scoring (CVSS) does not map cleanly onto AI findings, because the impact of a prompt injection or a memory-poisoning finding depends heavily on what the target agent is authorized to do, not on a property of the vulnerable component itself. Score every AI finding on two axes and combine them explicitly rather than forcing a single CVSS number:

Impact axis — what happens if the technique succeeds, ranked by the crown jewel it reaches:

• Critical — direct path to foundation credentials, model weights exfiltration, or unrestricted code execution (for example CVE-2025-49596 in MCP Inspector, or a filesystem MCP server vulnerable to the symlink escape in CVE-2025-53109)
• High — reach into a trust zone with cross-tool or cross-agent effect (tool shadowing, confused-deputy escalation, memory poisoning that fires on a future session)
• Medium — reach limited to a single tool or a single session, or disclosure of internal architecture (system prompt leakage, tool schema enumeration)
• Low — degraded output quality, denial of service on a single request, or disclosure with no onward exploitation path

Exploitability axis — how reliable and how cheap the technique is to execute, given field conditions rather than lab conditions:

• Trivial — single-shot payload, no iteration required, works across model families (for example a plain instruction-override string against an unguarded system prompt)
• Moderate — requires a small number of iterations or a specific encoding/obfuscation layer, but has a published, reproducible technique with a documented attack success rate (character injection and AML evasion techniques documented at up to 100% evasion against some commercial guardrails are moderate to execute once tooled: https://arxiv.org/html/2504.11168v2)
• Difficult — requires multi-turn escalation, model-specific tuning, or automated optimization tooling (Crescendo-style multi-turn escalation, or PLeak-style optimized query generation for system prompt extraction at roughly 68% success: https://dl.acm.org/doi/10.1145/3658644.3670370)
• Theoretical — works in a benchmark or against a specific model checkpoint but has not been reproduced against the target's actual configuration; flag as a finding only with an explicit caveat

Report severity as the pair (Impact, Exploitability) rather than collapsing it to a single number — a Critical-impact, Theoretical-exploitability finding and a Medium-impact, Trivial-exploitability finding both deserve remediation attention but for different reasons and on different timelines. When a single numeric score is required by the client's process, treat Trivial and Moderate exploitability as raising severity by one band over the impact axis, and Difficult or Theoretical exploitability as holding or lowering it by one band.

Validate exploitability empirically before it goes in the report. A technique that scores "Moderate" in the literature against a specific model family may be "Trivial" against a target running an unguarded local deployment, or "Difficult" against a target with layered guardrails (spotlighting, character-injection filtering, and a secondary judge model, for example) — run the actual payload against the actual target and record the observed success rate over at least 10 attempts before assigning a final exploitability rating.

2.10 Reporting patterns

Two report-writing patterns save time on AI engagements:

The attack chain diagram. A single figure showing the full path from initial foothold to objective, annotated with the trust boundary crossed at each step. Practitioners find these easier to understand than paragraph-form attack narratives.

The findings-vs-controls table. Every finding gets a row with ATLAS ID (and ASI ID where applicable), the trust boundary it crossed, the crown jewel it reached, the (Impact, Exploitability) pair from 2.9, and the specific control that would have blocked it. This maps directly onto the client's remediation plan.

Practice checklist

• Maintain an assumption register from Day 1
• Rank crown jewels by offensive value and current reachability, not by "coolness"
• Map trust boundaries explicitly — including inference-based and delegated-trust ones
• Enumerate all escalation paths, mark ROE status, plan for the permitted subset
• Prefer cheap validation over speculative execution
• Update the attack intelligence brief every day of the engagement
• Tag every technique with MITRE ATLAS IDs, and ASI IDs where the technique is agentic
• Score every finding on both Impact and Exploitability, and validate exploitability empirically against the actual target before reporting it

MITRE ATLAS references

The methodology chapter itself is meta over the taxonomy; specific technique IDs live in the chapters ahead. The umbrella tactics:

• AML.TA0000 ML Model Access (reconnaissance and initial access)
• AML.TA0001 Reconnaissance
• AML.TA0002 ML Attack Staging (initial access)
• AML.TA0003 Persistence
• AML.TA0004 Defense Evasion
• AML.TA0005 Discovery
• AML.TA0006 Collection
• AML.TA0007 Exfiltration
• AML.TA0009 Impact

For agentic engagements, cross-reference the OWASP Top 10 for Agentic Applications (ASI01–ASI10) at the methodology level as well: an engagement's crown-jewel and trust-zone analysis should explicitly consider ASI03 (Identity and Privilege Abuse) and ASI08 (Cascading Agent Failures) even before any specific technique is selected, since both describe systemic conditions rather than single techniques.

Further reading

• Threat modeling for ML systems — https://arxiv.org/abs/2107.04146
• MITRE ATLAS tactics — https://atlas.mitre.org/tactics
• OWASP LLM Application Security Verification Standard — https://owasp.org/www-project-llm-verification-standard/
• OWASP Top 10 for Agentic Applications (2026) — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• OWASP AIVSS scoring system for Agentic AI core security risks — https://aivss.owasp.org/assets/publications/AIVSS%20Scoring%20System%20For%20OWASP%20Agentic%20AI%20Core%20Security%20Risks%20v0.5.pdf
• MCP security best practices (official guidance) — https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices