/ai-surface-recon

name: ai-surface-recon
description: "Maps an authorized AI system's externally observable models, retrieval paths, agent tools, guardrails, endpoints, and privileged consumers. Use when scoping an AI security assessment or building an evidence-bound attack-surface inventory."
metadata:
  portability: universal
  discipline: penetration-testing
  domain: ai-systems
  tags: [ai, reconnaissance, models, rag, agents]

AI surface recon

Build an evidence-bound map of an AI system before deeper testing. Separate what is observed from what is inferred, and separate passive collection from actions that contact the target.

When to Use

• Scoping an authorized AI security assessment.
• Inventorying model, retrieval, agent, guardrail, API, or privileged-consumer

surfaces from supplied evidence and approved observations.

• Reconciling public documentation, client architecture material, and bounded

target responses without treating any one source as authoritative.

When NOT to Use

• Do not use this skill as authorization to probe an endpoint or enumerate an

adjacent service.

• Do not use it to generate jailbreaks, exploit payloads, persistence, or

destructive tests.

• Do not turn an unverified product label, error string, or model claim into a

confirmed implementation fact.

Workflow

1. Record the written scope: named systems, tenants, identities, environments, approved contact methods, exclusions, time window, and disruption ceiling. 2. Create an evidence register. Give each source an identifier, origin, collection time, collection method, integrity note, and handling limit. 3. Classify every collection action before using it:

• `passive`: supplied artifacts or third-party material that does not contact

the target;

• `target-contact`: an approved request to a named in-scope service;
• `prohibited-or-unapproved`: anything outside the written authority.

4. Inventory the visible surfaces:

• user and service entry points;
• model providers, routers, versions, and fallback behavior;
• retrieval sources, ingestion paths, indexes, citations, and freshness;
• agents, tools, plugins, connectors, memories, and approval gates;
• system prompts, policy layers, filters, and output handling;
• credentials, workload identities, callbacks, queues, and data stores;
• logs, evaluations, monitoring, administrative planes, and deployment

boundaries. 5. Map service handoffs. For each transition, record the producer, consumer, data or instruction crossed, trust change, identity used, and supporting evidence. 6. Identify privileged consumers: components that execute, retrieve, publish, approve, or act on model output. Rank these by consequence, not proximity to the model. 7. Record each claim as `observed`, `reported`, `inferred`, `contradicted`, or `unknown`. Keep inference and its supporting observations in separate fields. 8. Note candidate assessment surfaces without prescribing exploit steps. For each candidate, state the exact authorization needed, safe validation class, expected evidence, stop condition, and likely defensive owner. 9. Report coverage gaps. A surface not observed is `unknown`, not absent.

Deliverable

Return:

• scope and collection-method table;
• evidence register;
• component and endpoint inventory;
• trust-zone and service-handoff map;
• privileged-consumer list;
• claim register with confidence and contradictions;
• bounded validation candidates; and
• unknowns, exclusions, and owner-assigned follow-ups.

Rationalizations to reject

• **“The model named itself, so the fingerprint is confirmed.”** Model output

is attacker-influenceable metadata, not implementation proof.

• **“A public hostname is fair game.”** Public reachability does not establish

authorization.

• **“The vector database is behind the app, so it is not part of the surface.”**

Retrieval handoffs can change model behavior and downstream actions.

• **“The callback proves command execution.”** A callback proves only the

interaction represented by its receipt.

• **“No error appeared, so the guardrail is absent.”** Missing evidence cannot

support a negative architecture claim.

• **“One endpoint represents the whole product.”** Routers, fallbacks, admin

planes, and privileged consumers can have different trust boundaries.