The Reconnaissance Agent [Lab Part 4]

This article is the fourth in a series exploring a self-contained multi-agent security lab. We have already examined the idea behind collaborative reconnaissance, the Helixora and Northstar environment, and the restricted tools that keep agents inside the lab. Now we will follow the reconnaissance agent through its first investigation.

Reconnaissance is often described as collecting information about a target. That description is correct, but incomplete.

The real value comes from recognizing relationships. A public page identifies an employee. A JavaScript comment identifies a staging service. A staging file identifies an API client. An API document identifies an older route. A file-sharing reference identifies an anonymous handoff. Each observation changes what should be examined next.

This is the job of the reconnaissance agent in the Helixora lab. It does not begin with knowledge of every weakness. It does not receive a list of vulnerable endpoints. It receives one host at a time, a fixed methodology, a restricted set of tools, and an instruction to record each meaningful discovery as soon as it is observed. The result is not simply a list of pages. It is the first evidence-backed model of the environment.

Reconnaissance turns isolated observations into an attack surface. Later agents turn that attack surface into conclusions.

Everything described here occurs against fictional services and data inside the local learner environment. The names, people, credentials, programs, files, and records are not connected to any external organization.

The Reconnaissance Agent Has a Specific Role

The reconnaissance agent is responsible for discovery and initial evidence collection. It can:

• list the five authorized lab services;
• resolve their fictional names to local addresses;
• request pages from approved hosts;
• query approved API endpoints;
• run a small, fixed path-enumeration pass;
• use credentials it has actually discovered;
• decode the payload of a JWT it legitimately receives;
• read earlier reconnaissance findings;
• write new findings to shared state.

It cannot:

• run a shell command;
• scan an IP range;
• load an arbitrary wordlist;
• brute-force a username or password;
• invent and fuzz API routes;
• modify a file or account;
• create a remediation ticket;
• decide that its own findings are confirmed;
• read the defender's conclusions;
• contact a host outside the lab allowlist.

Those restrictions shape the investigation. The agent has to work from evidence rather than unlimited exploration. This is important because a useful reconnaissance agent should not behave like an unbounded web crawler with an AI-generated request list. It should understand why a path is being requested and where that path came from.

The Coordinator Assigns One Host at a Time

The coordinator does not ask the agent to investigate the entire environment in one enormous prompt. It creates a separate pass for each service:

• portal.helixora.lab
• staging.helixora.lab
• api.helixora.lab
• directory.helixora.lab
• files.northstar-relay.lab

Each pass begins with the same task:

• Investigate only this host.
• Follow the fixed discovery sequence.
• Record each real discovery.
• Do not investigate another host during this pass.

This host-by-host structure has several advantages.

First, it keeps the working context focused. The agent can reason about one application without mixing every route and response from five services.

Second, it creates an audit boundary. Telemetry can show when a pass began, which host it covered, and when it ended.

Third, it prevents a reference from silently becoming a pivot. If the portal mentions staging, the agent records that relationship during the portal pass. It does not immediately abandon the assigned host and begin exploring staging. The coordinator will assign the staging host separately.

After all five initial passes, the coordinator runs one credential and relationship follow-up. At that point, the agent can review its recorded findings and use the exact cross-service references it previously discovered.

five focused passes -> shared findings -> one bounded follow-up

This produces a cleaner investigation than allowing every observation to spawn another open-ended branch immediately.

Every Pass Uses the Same Discovery Sequence

For each assigned host, the agent follows seven steps.

1. Request /robots.txt.
2. Request /sitemap.xml.
3. Request /static/app.js and /static/staging.js.
4. Run the bounded common-path enumerator.
5. Inspect every non-404 path returned by that enumerator.
6. If a response contains a credential, use it through the appropriate named authentication helper.
7. Write each real discovery to the shared store immediately.

The sequence is intentionally ordinary. There is no single magical reconnaissance technique. The value comes from applying a repeatable process and preserving the evidence that connects each step.

The agent is also told not to guess plausible-looking routes. If /api/users sounds reasonable but no sitemap, source file, API document, or bounded enumeration result identifies it, the agent does not request it. That constraint makes provenance part of the methodology.

The question is not only “What did the agent request?” It is also “What evidence authorized the agent to request it?”

First Pass: The Helixora Portal

The public Helixora portal is the natural starting point. It provides the company's brand, scientific programs, employee context, and links a visitor would expect to find on a modern corporate site.

The reconnaissance pass starts with /robots.txt. The response identifies paths that the site would prefer an ordinary crawler not to index, including an administrative area and a backup location. This demonstrates a familiar lesson: robots.txt is a crawler instruction, not an access-control mechanism.

The sitemap contributes the public route structure. It identifies the normal company, pipeline, science, news, and search pages. That gives the agent a baseline for distinguishing linked public content from unusual paths discovered elsewhere. The client-side source adds more interesting information. /static/app.js contains developer context referring to:

• the separate staging.helixora.lab environment;
• a private employee-directory API route;
• an unresolved authorization check associated with that route.

The agent does not treat the source comment as proof that the authorization failure exists. It records the exposed route and the implementation clue as evidence worth following up.

That distinction matters.

• Source comment = lead
• Reproduced cross-employee response = evidence

Bounded Enumeration Finds the Portal's Unlinked Surface

The agent then invokes enumerate_common_paths for the portal. It cannot supply its own paths. The tool applies the fixed 24-entry list described in the previous article and returns only responses that are not 404. On the Helixora portal, the results include several important surfaces:

• the administrative page;
• the employee login;
• the backup directory and configuration backup;
• the reflected search route;
• a private employee-record route.

The agent requests the exact returned paths one at a time and examines their status codes and response bodies. The administrative page initially returns an authentication boundary. That is useful evidence. It establishes that the route exists and that unauthenticated access is denied. The backup file is different.

/backup/config.json.bak returns a publicly readable configuration containing a fictional employee username and password. The response also associates that username with administrative access.

The agent records the exposed credential immediately rather than waiting until the end of the pass.

• Target: portal.helixora.lab
• Category: exposed_credentials
• Evidence: unauthenticated 200 response from the backup configuration
• Observation: plaintext portal credentials are publicly accessible

This immediate write is important. If the agent later reaches a turn limit, the credential discovery still survives in shared state for the follow-up pass and the other agents.

A Discovered Credential Can Be Used, but Not Guessed

The reconnaissance agent is allowed to use the credential because it obtained the value from a response within the approved methodology.

It calls authenticate_portal, a named helper that submits the credential only to the fixed local Helixora login endpoint. The helper returns an application session token if authentication succeeds. The agent then repeats the request to /admin, passing that session through the exact X-Lab-Session header supported by the lab tool. The page now returns restricted program operations, including cost-center and portfolio-review material. This produces two related but separate observations:

1. a backup file publicly discloses a working credential;
2. the resulting employee session reaches restricted portal information.

The reconnaissance agent can record both facts. It does not yet decide why the employee has that access or whether the role is appropriate. The analysis agent will later compare the identity with the directory record. This is one of the most useful separations in the workflow:

Recon: the credential works and reaches this page. Analysis: the recorded employee role does not justify that access. Validation: the behavior can or cannot be reproduced independently.

The credential helper does not generate variations or try other users. If the discovered value fails, the agent records the result. It does not begin guessing.

Employee-Record Discovery Becomes an Authorization Test

The JavaScript source identified a private route with an employee identifier in the path:

/api/employee-directory/{employee_id}/private

The authenticated employee session belongs to Maya Chen, whose employee ID is HX-1047. The agent first requests her own record. That establishes the expected authenticated behavior. It then requests the specifically enumerated HX-1009 record using the same session. The response contains a different employee's HR-private information, including fictional personal contact details, tax-identifier suffix, emergency contact, and badge-access data. The agent does not enumerate hundreds of employee numbers. It compares two exact records already surfaced by the lab:

authenticated subject: HX-1047
requested object:      HX-1009
result:                200 with another employee's private record

That is enough to record a broken object-authorization observation. Later, the Application Security Specialist reproduces the behavior as an IDOR/BOLA assessment, and the validation agent repeats it independently. This demonstrates how reconnaissance can move slightly beyond passive discovery without becoming open-ended exploitation. The test is specific, evidence-led, non-destructive, and limited to fictional records.

Search Reveals an Independent Input-Handling Issue

The portal's sitemap and bounded enumeration also surface the search feature. The agent submits a harmless marker encoded in the query string and observes how the application returns it. The marker appears in the HTML response without the output encoding expected for that context. The reconnaissance finding records the request and reflection. It does not need to turn the browser into a general payload-delivery system or explore every possible script construction.

The relevant observation is narrow:

controlled input -> response HTML -> input returned without encoding

That becomes a candidate for the Application Security Specialist, whose supported families include reflected cross-site scripting.

This is another example of the recon agent identifying a surface and preserving evidence without assuming responsibility for the entire application-security assessment.

Second Pass: The Staging Environment

The staging hostname was first observed in the portal's JavaScript. The coordinator later assigns staging.helixora.lab as its own pass. Once again, the agent begins with metadata rather than guessing. The staging robots.txt identifies non-public locations such as /internal-tools and /debug/. Its JavaScript file then exposes a richer set of relationships.

/static/staging.js references:

• the Helixora API hostname;
• a version-two token endpoint;
• program, trial, and portfolio routes;
• a QA synchronization client ID and client secret;
• a Northstar File Relay handoff URL.

This single client-side resource connects three parts of the architecture:

The agent records the service credential and the Northstar reference as separate findings. During the staging-only pass, it does not immediately explore the file platform. The hostname and exact share path are preserved for the later Northstar pass and cross-service follow-up.

Exposed Staging Configuration Adds Operational Context

Bounded enumeration identifies /debug/config and /internal-tools as reachable. The debug response exposes fictional infrastructure and application configuration, including:

• framework and debug-state information;
• internal hostnames;
• feature flags;
• a database-style connection string;
• a trace sample;
• the external file-transfer relationship.

The internal-tools page and build API add QA operational status, release information, synchronization activity, and cache state. Not every one of these values represents a separate vulnerability. Together, they strengthen the architecture map and explain which systems exchange data. The agent records objective response facts rather than repeating any page language that describes the behavior as safe, expected, or harmless. An assessed application is not an independent authority on the significance of its own exposure.

This principle becomes particularly important when agents are reading developer comments and operational documentation. Those sources can explain intent, but the conclusion must come from observed access and returned data.

The Staging Service Credential Opens the API

The staging JavaScript provides a fictional client ID and client secret for svc-insight-sync. The agent sends those exact values to get_api_token. The helper submits a fixed request to:

api.helixora.lab/api/v2/auth/token

The API returns a JWT. The agent then calls decode_jwt_payload, which reads the claims without attempting to alter or forge the token. The payload identifies:

• the service identity;
• a service role;
• programs:read and trials:read scopes;
• issuer and expiration information.

Those claims create a testable expectation. The token should reach program and trial data, but a service role should not necessarily reach administrator-only reporting. The agent requests only the three data routes named by the staging source:

/api/v2/programs
/api/v2/trials
/api/v2/portfolio/summary

The responses contain fictional pipeline, biomarker, milestone, cost-center, trial-site, and enrollment information. The agent records the credential exposure and the data it enables as linked facts. It also requests /api/v2/admin/reports with the same token. That request returns 403 with an insufficient-role response. This denial is not a vulnerability.

Reconnaissance should record controls that work as well as controls that fail.

The 403 demonstrates that the API distinguishes administrator access at that route. Later analysis can compare that positive control with the broader access granted elsewhere.

Third Pass: API Documentation Reveals the Legacy Surface

The API pass begins with the same metadata and bounded enumeration process.One of the most important results is /api/v1/openapi.json. The document describes a legacy people API and explicitly lists employee routes without an authentication requirement. The agent now has evidence for requesting:

/api/v1/employees
/api/v1/employees/{employee_id}

This is a good example of why API documentation belongs in reconnaissance. An OpenAPI document can reveal:

• versioned route families;
• deprecated operations;
• authentication declarations;
• object identifiers;
• data models;
• differences between old and new controls.

The agent requests the bulk employee route without an authorization header. The response returns fictional HR-confidential records for eight employees. The fields include:

• legal names;
• dates of birth;
• personal and work email addresses;
• mobile numbers;
• home cities;
• emergency contacts;
• salary bands;
• tax-identifier suffixes.

The agent records the unauthenticated response, classification, field types, and record count. It does not need to send that information anywhere else or use it against another system. The discovery is valuable for two reasons. It establishes a direct data-exposure issue, and it shows how an older API generation can retain a different authorization posture from the newer API.

Legacy Project Data Adds Another Unauthenticated Route

During the bounded follow-up, the agent requests /api/v1/projects/internal without a token. The response returns an internal program-risk record containing a Helixora program ID, owner, operational risk, and mitigation plan. This route matters because it adds another example of the legacy API returning internal data without the authentication enforced by the version-two routes. The recon agent records the direct behavior:

request:  unauthenticated GET
route:    /api/v1/projects/internal
status:   200
data:     internal program risk and mitigation information

It does not yet create the broader conclusion that version one and version two have inconsistent authorization maturity. That comparison belongs to the analysis phase.

Fourth Pass: The Directory Builds the Human Attack Surface

The directory service gives the agent a different kind of visibility. GET /users returns twelve fictional employee records spanning:

• executives;
• clinical and scientific management;
• research personnel;
• clinical operations;
• People Operations;
• systems administration;
• identity and access engineering;
• IT support.

The records contain names, usernames, employee identifiers, email addresses, phone information, offices, managers, skills, program ownership, and system access. GET /departments adds department leads, headcounts, and open-role counts. This lets the agent build several relationships:

Some of the records are more interesting than others. The directory identifies privileged IT staff and the systems associated with their roles. It also records Maya Chen as a scientist and program owner. The recon agent records the exposed directory facts. It does not automatically label every public employee card a critical issue. The analysis phase decides which identity relationships change the meaning of other findings.

For example, the portal backup associates Maya's credential with administrative access, while the directory records a Scientist role. Recon discovers both values. Analysis compares them. That separation reduces the chance that one agent will turn every unusual detail into an unsupported conclusion.

Fifth Pass: Northstar File Relay

Northstar looks like a separate file-storage and sharing platform. Its normal document library requires authentication, which prevents the recon agent from simply browsing every file. That boundary remains intact. The agent does not guess share identifiers or attempt to bypass the library login. It starts with the same approved metadata sequence. Northstar's robots.txt and /static/app.js identify account-recovery configuration. Bounded enumeration confirms that /account/recovery/config.json is publicly reachable. The returned document exposes fictional legacy recovery metadata, including:

• a sample account;
• a token-derivation formula;
• a static seed;
• a complete sample reset URL;
• confirmation that generated tokens do not expire;
• confirmation that tokens remain reusable.

The agent records the configuration exposure and the behavior it describes. It does not submit a password change. This is an important boundary. The assessment can demonstrate that an anonymous user receives enough information to derive a reset token and reach the reset form without changing the fictional account's state.

The Application Security Specialist and validation agent can later reproduce the non-destructive portion of that path.

The Anonymous Share Is Followed by Exact Reference

The Northstar share is handled differently from the recovery metadata. The staging JavaScript and debug configuration previously exposed the exact URL:

files.northstar-relay.lab/s/HX-QA-7Q2M

Because the full reference came from an approved lab response, the follow-up task permits the agent to request that one path without a Northstar session. The page returns a QA handoff document marked Anyone with the link with expiration disabled. The file names Helixora validation context, including:

• the portal hostname;
• the backup configuration path;
• the post-login administrative route;
• a reference to the staging synchronization identity.

This document does not introduce an unlimited new search. The agent follows only the specific Helixora paths named inside it and only if they remain within the five-host allowlist. The share is useful because it demonstrates two perspectives on the same chain.

The portal pass can discover the backup directly through bounded enumeration. The Northstar handoff can independently reveal the same route through an external-style relationship.

Corroborating routes increase confidence in the architecture map, even when one path was already known.

The Final Follow-Up Connects the Passes

After all five hosts have received an initial pass, the coordinator starts the reconnaissance follow-up. The agent first reads the findings already in shared state. It looks for credentials or relationships that were discovered but not yet exercised. The follow-up is explicit rather than open-ended. It directs the agent to:

• use any recorded portal or API credentials not already tested;
• decode any issued JWT;
• request the version-two program, trial, and portfolio routes named in staging source;
• compare the service token with the administrator-only route;
• request the legacy internal-project route without authentication;
• compare Maya's own private employee record with the specifically identified Elias Voss record;
• inspect the documented bulk employee API;
• retrieve the exact anonymous Northstar handoff;
• follow only the specific Helixora paths named in that document.

This produces the cross-service sequence:

• Portal JavaScript -> staging hostname
• Staging JavaScript -> API credential + Northstar URL
• API documentation -> legacy employee export
• Directory -> employee roles and ownership
• Northstar handoff -> Helixora validation paths
• Discovered credentials -> authenticated portal and API responses

The follow-up does not replace the specialist agents. It ensures that reconnaissance completes the evidence-gathering steps justified by its own discoveries.

Findings Are Written as the Investigation Happens

Each meaningful observation is stored with structured context:

• agent name;
• category;
• target;
• observation;
• confidence;
• evidence;
• references to earlier findings where applicable.

A representative finding looks conceptually like this:

{
  "agent": "recon",
  "category": "exposed_credentials",
  "target": "portal.helixora.lab",
  "confidence": 0.98,
  "observation": "An unauthenticated backup response disclosed a working portal credential.",
  "evidence": "GET /backup/config.json.bak returned 200; the credential authenticated successfully."
}

The language matters. The finding describes the request, access state, returned capability, and observed outcome. It does not quote application text that calls the condition expected, intentional, or harmless. The recon agent also writes a finding immediately after each discovery rather than producing one large summary at the end. This has practical benefits:

• evidence survives if the model reaches its turn limit;
• other agents can consume findings incrementally;
• the telemetry timeline matches the discovery order;
• conclusions can reference stable finding identifiers;
• the report can show what each agent actually contributed.

In one representative lab run, the reconnaissance phase produced twenty records covering the portal, staging environment, API, directory, and file platform. The exact wording and identifiers can vary by model and run, but the evidence paths remain deterministic.

Page Content Is Treated as Untrusted

The agent reads developer comments, API documents, backup files, debug output, and shared documents. Any of those surfaces could contain misleading statements or instructions directed at an automated analyst. The reconnaissance prompt handles two cases separately. If content makes a factual claim about another route, the agent records that claim with appropriately low confidence until it can be verified through an authorized tool. If content directly instructs the agent to change its behavior—such as ignoring its system instructions or stopping the investigation—the agent records a prompt_injection_attempt and does not follow it. Even if the model responds incorrectly, the tool layer still limits the consequence:

• an invented host is denied by the allowlist;
• an invented path is outside the required methodology;
• an invented shell command has no tool to execute it;
• a request to modify data has no generic mutation tool;
• a request to create a ticket cannot reach the approval-gated coordinator operation.

The content policy and capability restrictions reinforce each other.

Telemetry Records Both Success and Denial

Every tool call generates agent telemetry. HTTP responses also produce normalized security events for the later defender phase. The record includes enough information to reconstruct the activity:

• which agent requested the tool;
• which host and path were involved;
• which method was used;
• which status code came back;
• whether a session or token was present;
• which actor was known;
• whether the request was allowed or blocked;
• which security signal the activity represented.

This matters because the defender agent will not read the reconnaissance findings. It receives the separate audit stream and determines what a defensive team could see.

For example, a bounded enumeration request returning a routine 404 is not treated as proof that a sensitive resource was blocked. A 403 from the administrator-report route is recorded as an authorization denial. Anonymous share access and password-recovery access receive partial visibility because important identity or correlation context is missing. The same activity therefore produces two perspectives:

Recon perspective: What did this response reveal? Defender perspective: What did the audit stream reveal about the request?

What Reconnaissance Has Established

By the end of the follow-up, the agent has identified the principal application architecture and several important evidence paths. It has established that:

• the public portal references a staging environment;
• client-side source discloses private route and service information;
• a backup configuration exposes a working employee credential;
• that session reaches restricted portal operations;
• the same session retrieves another employee's private record;
• search input is returned without expected output encoding;
• staging exposes configuration and operational metadata;
• staging source contains a working API service credential;
• the issued token provides program and trial access;
• an administrator-only API route correctly rejects the service role;
• legacy API documentation exposes unauthenticated employee routes;
• the legacy employee API returns fictional HR data;
• the legacy project API returns internal risk data without authentication;
• the directory exposes organizational, identity, and system relationships;
• Northstar publishes weak recovery metadata;
• one exact Northstar handoff is anonymously accessible;
• that handoff identifies Helixora validation paths.

That is a substantial attack-surface model, but it is not yet the final assessment.

What the Reconnaissance Agent Does Not Decide

The recon agent is the first specialist, not the entire security team. It does not independently decide:

• which web issues meet the supported AppSec families;
• whether every observation is reproducible;
• how a Scientist role compares with administrative portal access;
• how legacy and current API authorization differ;
• which findings deserve remediation tickets;
• whether the activity was detected or merely logged;
• which observations form the primary compromise chain;
• how the final executive report should prioritize the results.

Those responsibilities move to other parts of the workflow. The Application Security Specialist performs focused checks of reflected input, object authorization, PII exposure, debug disclosure, and password recovery. The analysis agent correlates roles, credentials, assets, and control differences. The validation agent independently repeats important requests. The defender examines the separate audit stream. The coordinator governs sequence and ticket approval.

This division prevents reconnaissance from becoming a single all-powerful model that discovers, judges, validates, remediates, and grades its own work.

Discovery is more trustworthy when conclusion and validation remain separate responsibilities.

The Attack Surface Is Now a Connected Model

At the beginning of the investigation, the coordinator has five fictional hostnames. At the end, the shared store contains relationships between:

• websites and APIs;
• production and staging;
• source files and credentials;
• credentials and issued sessions;
• tokens and scopes;
• people and employee identifiers;
• employees and roles;
• employees and research programs;
• file shares and internal paths;
• legacy and current API generations;
• assessment activity and defensive telemetry.

That connected model is the reconnaissance agent's real output. The individual responses still matter. They provide evidence. But the shared relationships explain why one response changes the interpretation of another.

The credential in a backup file becomes more significant when it authenticates successfully. The authenticated session becomes more significant when the directory records a lesser role. The staging service secret becomes more significant when it retrieves portfolio data. The API denial becomes more significant when it proves that at least one role boundary is implemented correctly. The anonymous share becomes more significant when it corroborates the same Helixora paths discovered elsewhere.

This is what agentic reconnaissance should add above ordinary request automation: structured reasoning about how discoveries fit together, while deterministic tools keep every action inside scope.

Where We Go Next

The reconnaissance agent has now mapped the attack surface and placed its observations into shared state. The next question is what happens to the application-specific candidates it found.

In the next article, we will follow the Application Security Specialist. We will see how the coordinator decides whether that specialist should run, how it limits the review to supported vulnerability families, and how it reproduces reflected input, object-level authorization, PII exposure, debug disclosure, and password-recovery behavior without duplicating the recon findings.

For now, the important lesson is that the reconnaissance agent did not begin with the compromise flow. It built it one bounded observation at a time.

Metadata identified source. Source identified services. Services exposed credentials and documentation. Credentials opened authenticated views. Identity data gave those views context. An anonymous share corroborated the path. Every step remained tied to evidence.

That is how five local hostnames become an attack surface that the rest of the agent team can investigate.