This article is the fifth in a series exploring a self-contained multi-agent security lab. The previous article followed the reconnaissance agent as it mapped the Helixora attack surface. This time, we will examine what happens when reconnaissance identifies evidence that deserves a focused application-security review.
Reconnaissance and application-security testing overlap, but they are not the same job. Reconnaissance discovers routes, identities, configuration, documentation, credentials, and relationships. An application-security specialist takes a much narrower question and investigates it in enough depth to explain the control that failed, the response that proves it, and the boundary of the resulting exposure.
In the Helixora lab, that specialist is not launched automatically for every assessment. The coordinator invokes it only when reconnaissance has recorded evidence associated with one of five supported web-vulnerability families: reflected cross-site scripting, insecure direct object reference or broken object-level authorization, personally identifiable information exposure, debug-information disclosure, and weak password recovery.
This conditional design is deliberate. A specialist should exist because the evidence justifies its work, not because every agent must run during every workflow.
Everything described here occurs inside the fictional, local learner environment. The hosts, people, credentials, records, and data are not associated with an external organization.
Why the Specialist Is Conditional
After reconnaissance finishes, the coordinator reads only the findings written by the recon agent. It combines each finding's category, target, observation, and evidence into a searchable text value, then looks for terms associated with the supported vulnerability families. These include references such as xss, idor, object authorization, employee-directory, /api/v1/employees, debug/config, and recovery/config Conceptually, the decision looks like this:
The trigger does not declare that a vulnerability exists. It says only that reconnaissance has produced enough evidence to justify a bounded specialist check. A source-code comment mentioning an authorization problem may trigger the agent, but the comment is not proof. A reflected marker may trigger an XSS review, but reflection alone does not demonstrate executable script context. The specialist still has to reproduce the behavior.
The coordinator records the candidate finding IDs and whether the specialist will run. If no supported candidate exists, it records a skip event and continues to analysis. If candidates do exist, it passes only those IDs into the specialist's objective. This makes the invocation auditable and prevents the specialist from silently expanding its own scope.
A Narrow Tool Set Produces a Narrow Investigation
The Application Security Specialist receives six tools:
- search all shared findings;
- read one finding by ID;
- request an allowlisted lab page;
- query an allowlisted lab API;
- authenticate to the portal with a credential already discovered by reconnaissance;
- write a linked AppSec assessment.
It does not receive path enumeration, arbitrary network access, shell execution, ticket creation, or the ability to write validation outcomes. Its prompt further restricts it to the exact hosts and paths already present in the candidate findings. It may not invent routes, fuzz parameters, guess credentials, or turn a focused reproduction into a general penetration test.
This is more than a safety feature. It improves the quality of the result. The specialist begins with a specific evidence trail and must answer a specific question. The output is therefore easier to review than an open-ended collection of requests made because they looked interesting.
Assessments Enrich Findings Instead of Duplicating Them
The most important design decision is that the specialist does not call write_shared_finding. Reconnaissance has already created the source record. Creating another finding for the same response would inflate totals, produce duplicate validation work, and potentially create multiple remediation tickets for one underlying issue.
Instead, the specialist writes an AppSec assessment containing:
- the vulnerability family;
- the affected target;
- a professional conclusion;
- the reconnaissance finding IDs that triggered the review;
- the exact request and response facts personally observed by the specialist.
The relationship looks like this:
Later agents can read the specialist assessment as supporting detail while continuing to treat the original finding as the unit of validation, reporting, and remediation. One issue remains one issue, even though several agents contribute evidence to it.
Reflected XSS: Context Matters More Than Reflection
The portal search route provides a candidate for reflected cross-site scripting. The specialist sends a harmless marker through the exact query parameter identified during reconnaissance and examines where that marker appears in the response.
The important question is not simply whether the string comes back. It is whether the application places controlled input into an executable HTML or script context without the encoding required for that context. A response that converts < and > into safe entities should not be reported as XSS merely because the original value remains recognizable. Conversely, a marker inserted directly into active HTML can support a reflected-XSS conclusion without the specialist escalating into destructive browser behavior.
This family demonstrates why the specialist must be allowed to reject a candidate. Recon may correctly record reflection as an observation while the specialist concludes that output encoding prevents script execution. That is not disagreement; it is a deeper assessment refining the initial evidence.
IDOR and BOLA: Compare Subject, Object, and Decision
The private employee-record route creates an object-authorization question. A useful test needs three pieces of information:
- the authenticated subject;
- the object that subject should legitimately access;
- a specifically identified object belonging to another employee.
In the lab, the specialist uses only the portal credential already recorded by reconnaissance. It authenticates as Maya Chen, retrieves Maya's own private employee record, then requests the exact Elias Voss record previously identified by the recon evidence. It does not enumerate employee IDs or guess records.
The assessment compares the two responses:
authenticated identity: maya.chen / HX-1047
own object: HX-1047/private
other object: HX-1009/private
authorization result: response status and private fields returned
If the same employee session receives another employee's HR-private record, the evidence supports IDOR/BOLA. If the second request receives a denial, the specialist records that the authorization control held. The conclusion is grounded in the subject-object decision rather than the mere presence of an identifier in a URL.
PII Exposure: Describe Data, Access State, and Scale
The legacy API exposes a bulk employee route documented by its OpenAPI description. The specialist repeats the exact unauthenticated request and records the response status, record count, and classes of information returned. Those classes include fictional legal names, dates of birth, personal contact details, emergency contacts, salary bands, and tax-identifier suffixes.
A good assessment does not copy every record into the finding. It explains enough to establish sensitivity and scope while avoiding unnecessary reproduction of the dataset. The significant facts are that the caller supplied no token, the endpoint returned a successful response, multiple employee records were included, and the fields crossed the intended public boundary.
This is also where terminology matters. “PII exposure” is not inferred from an endpoint name. It is supported by the actual field types in the response and the absence of an authentication or authorization decision protecting them.
Debug Disclosure: Separate Useful Evidence from Page Commentary
The staging /debug/config route returns implementation and environment details. The specialist repeats the exact request and identifies the categories of information disclosed, such as framework state, feature flags, internal hostnames, a database-style connection string, and a trace sample containing file and line information.
Not every debug value needs its own finding. The specialist records one assessment explaining how the combined response reveals internal topology and configuration to an unauthenticated caller. It does not accept a page label claiming the route is temporary, expected, or safe. Those statements originate from the system being assessed and do not change the access state or the returned values.
The same rule applies in the other families: application content can supply leads, but it cannot authoritatively grade itself.
Weak Password Recovery: Stop Before Changing State
Northstar exposes a legacy recovery configuration containing a sample account, deterministic token construction, a static seed, a complete reset URL, and metadata indicating that tokens do not expire or become invalid after use. The specialist retrieves the public configuration, opens the exact sample reset path, and confirms whether a reset form is reachable.
It does not submit a new password. Reaching the active form is enough to demonstrate that anonymously published metadata creates an unauthorized recovery capability. Completing the reset would add state change without adding evidence necessary for the conclusion.
This test illustrates a useful assessment principle: prove the security consequence at the least invasive point. The objective is to establish the failed control, not to maximize impact inside the application.
Reproduction Can Confirm or Refine the Candidate
For each supported family, the specialist writes one assessment immediately after its focused check. A conclusion can state that the behavior was reproduced, that the candidate was not reproduced, or that the available evidence was insufficient. It should explain the request, access state, result, and control boundary in professional assessment language.
The coordinator also requires at least one write_appsec_assessment call before accepting a final specialist answer. This code-level backstop prevents a model from performing useful checks, describing them in prose, and then exiting without preserving the results in shared state.
The specialist's output is not a final verdict. The validation agent will later repeat the underlying issue independently. The specialist adds application-security depth; validation decides whether the original finding survives an independent retest.
Why This Agent Improves the Workflow
Without a conditional specialist, the reconnaissance agent would need to discover the surface, interpret application behavior, perform every web-security reproduction, and decide how those results should be described. That concentrates too much authority and too much context in one model session.
The separate specialist produces a cleaner handoff:
- reconnaissance explains how the route was found;
- the AppSec assessment explains the control and reproduction;
- analysis connects the issue to identities and other services;
- validation repeats the evidence without trusting either earlier agent;
- the coordinator keeps one finding and one remediation decision.
This division also avoids an expensive specialist phase when the evidence does not justify one. Conditional execution is therefore both a security boundary and an efficiency decision.
Where We Go Next
At this point, the shared store contains reconnaissance findings and linked application-security assessments. The evidence is richer, but it is still organized around individual observations. The next agent has a different responsibility: determine how those observations relate across services.
In the next article, we will follow the Analysis Agent as it compares employee identities, directory roles, credentials, API generations, authorization outcomes, and affected Helixora programs. That is the stage where isolated findings begin to become an attack story.