The Boundary Before the Hunt
For Strix, the first security decision is made before an agent opens a browser or reads a route: what exactly is the target, and what is merely context for working on it? This chapter follows Strix's preparation path from a user-supplied target to typed scope, source or API material, and—when appropriate—a narrowed change set. The practical judgment is simple but consequential: a run is trustworthy only when readers can tell what Strix was authorized to test, what it was allowed to use as background, and what the runtime exposed to the agents.
A command-line target looks like a string. In the system, it becomes a structured fact that controls later behavior. The same-looking URL might be a web application or a Git repository; a local directory implies source-aware analysis; an API document describes operations that may never appear in a crawl. If these cases are collapsed too early, an agent can receive the wrong task, the wrong workspace, or an unjustified sense of permission.
A target string becomes several kinds of boundary
Strix recognizes several target shapes before starting a scan. A repository can be named by an HTTPS Git URL, an SSH-style address, or another Git form. A live web application is represented as a web target. A domain and an IP address are kept as different target types because their preparation and interpretation differ. A local directory is a code target: it gives the run source context and makes the scan white-box rather than purely external. OpenAPI, Swagger, and Postman inputs become API-spec targets, with the specification staged for the agents to read.
This classification is not a user-interface nicety. It determines the kind of evidence the agent can gather. A repository offers routes, configuration, dependencies, and data-flow clues before a request is sent. A live application offers behavior but hides implementation. An API specification supplies a declared contract, including operations that are not linked from a visible page. A local directory can be mounted into the sandbox as a writable working tree, which is useful for remediation but means the operator should not point Strix at uncommitted work they cannot afford to change.
The preparation layer also accepts several targets in one run. Local targets are deduplicated and assigned separate workspace names when necessary, while repository checkouts and source directories are collected for the runtime. This lets a source tree and a deployed application describe two sides of one assessment. The source can explain why a request should behave a certain way; the live target can establish whether that path is reachable and whether the consequence is real. The relationship is valuable only if each side remains explicitly identified.
The same separation applies to supporting material. A working directory is a place where an agent operates, not automatically an asset it may assess. A workspace file—perhaps a note, wordlist, or specification supplied for reference—is also context rather than scope. Strix's root-task builder renders these categories separately, so the agent is told which entries are authorized targets and which are files or directories provided to support the work. That distinction matters when free-form instructions contain an accidental hostname, a broad request to “check everything,” or a file that includes its own commands. Context can inform a task; it does not silently enlarge the engagement.
An API specification makes the boundary question especially visible. Strix reads the specification up front, records the base URLs it declares, and treats those hosts as in-scope web targets. The document therefore expands the agent's knowledge of the application surface without turning every URL mentioned in surrounding prose into permission. A Postman collection can be fetched by identifier, with an optional environment used to resolve collection variables, and then staged as a local specification so the API key used to obtain it does not need to enter the sandbox.
The contract and the live host play complementary roles. The contract says what the application claims to expose: methods, parameters, request bodies, and authentication expectations. The live base URL provides somewhere to exercise those operations. Supplying only the contract gives excellent surface knowledge but no confirmed runtime behavior; supplying only the host forces the agent to discover what the contract already enumerates. Pairing them lets Strix test declared operations directly while keeping traffic tied to a known host. It does not make every operation safe or reachable by definition, and it does not authorize unrelated hosts merely because they appear in an example or external reference.
The sequence shows why scope preparation precedes agent reasoning. The operator supplies intent, but the preparation layer decides how that intent is represented. The workspace state carries staged material and any change-set metadata. Only then does the agent receive a context that distinguishes “test this” from “use this while testing.” If a later instruction contradicts the system-verified target set, the target set remains the higher-order boundary.
Source changes narrow attention, not the whole security story
When a local source tree is present, Strix treats the run as white-box. That changes the starting point: agents can map routes, sinks, dependencies, and controls instead of learning the application solely through responses. The source-aware workflow recommends a quick repository map, Semgrep triage, an AST-structural pass, secret detection, and filesystem or dependency checks. Their role is prioritization. A match says that a path deserves a closer question; it does not establish that an attacker can reach the sink or produce the claimed impact.
Pull-request work introduces a second boundary called diff scope. The available modes are auto, diff, and full. In CI or headless conditions, auto can activate a change-set review; diff forces changed-file scope; full disables the narrowing. When active, Strix resolves the repository's comparison point and records added, modified, renamed, and deleted entries, along with which files can be analyzed. The root task then tells agents to prioritize changed files and use other files for context. Deleted files remain contextual rather than becoming ordinary analysis targets.
This is a useful engineering compromise. A pull request needs feedback quickly, and focusing attention on the change reduces the amount of code an autonomous system must traverse. Yet a changed line can inherit a security property from an unchanged helper, middleware layer, configuration file, or data model. Diff scope therefore optimizes the review budget; it does not redefine the application's complete trust boundary. The source-aware playbook's insistence on dynamic validation reinforces the point. A narrow diff can tell an agent where to look first, but not what the unchanged system guarantees.
The distinction becomes important in a multi-commit pull request. The comparison base has to be resolved from sufficient repository history. The CI guidance asks for full history in GitHub Actions and allows an explicit base reference when needed. If the base cannot be resolved, silently falling back to an arbitrary recent commit would create a false impression of coverage. A change-set review is meaningful only when the set of changes is known, and a successful process is not the same thing as a successful scope calculation.
Source access also creates a practical authority question. The agent needs enough access to read the code and, when a live instance is available, to connect its static hypotheses to runtime behavior. At the same time, a local directory is mounted writable by design. The useful consequence is that a validated finding can be accompanied by a concrete remediation change; the dangerous consequence is that the agent is not merely reading an inert archive. A clean checkout, clear ownership, and an explicit decision about what may be modified are part of the scope model. The exact execution privileges and network path belong to the sandbox layer, but they should be treated as capabilities granted to the assessment, not as invisible implementation detail.
That grant should be interpreted in terms of purpose. An API specification is a map of allowed operations, not a license to probe every server named in a comment. A source mount is material for a white-box review, not an instruction to inspect neighboring directories. A diff is a priority set, not proof that unchanged code is safe. The boundary is strongest when these interpretations are recorded before a model begins making decisions.
Which input wins when the context disagrees?
Strix establishes an authority order that is easy to lose in an agentic system. The platform-verified target configuration defines the authorized assets. The root task restates those assets in categories such as repositories, local codebases, URLs, IP addresses, and API specifications. User instructions can focus the work, provide credentials, or name a concern, but they are explicitly subordinate to the verified scope. Workspace files and working directories supply data or a place to operate; they do not become targets merely because they are visible.
This arrangement addresses a common failure mode in tool-using systems: confusing information with authorization. A file might contain a URL, but reading that URL is not automatically permitted. A prompt might ask for a broad scan, but it cannot add a host. An API document might mention a callback domain, but only declared base URLs are incorporated into the API-spec scope path. The agent can still use the information to reason about the authorized target, but the decision to send traffic belongs to the scope context, not to the most recent piece of text.
There is a second, less obvious conflict between a mounted directory and a repository target. The directory that holds a checkout may be the place where Strix works, but the repository identity and its selected source tree determine what the run is assessing. Conversely, a workspace mount with no scan target is explicitly treated as a working area whose instructions define the task; it is not silently promoted into a target. This prevents a convenient filesystem location from becoming an accidental scope expansion.
These rules do not make preparation infallible. Target inference can fail, API documents can be incomplete, a repository can lack enough history for a diff, and a live host can be unreachable. Strix's preparation code surfaces many of these as errors or metadata rather than pretending the missing information was resolved. The same principle should guide interpretation: if a specification declares an endpoint but no live base URL is available, the operation is known but its runtime exploitability is not. If diff resolution is skipped in auto mode, the result should be read as a broader or differently scoped review, not as a verified change-only guarantee.
The boundary before the hunt is therefore both technical and epistemic. Technical preparation decides where source, specifications, and targets appear. Epistemic discipline decides what those appearances mean. A repository checkout can support a detailed hypothesis, but only a reachable path supports a runtime conclusion. A diff can prioritize work, but only a complete coverage record can tell whether the relevant surface was actually addressed. A prompt can express intent, but only the verified scope can authorize action.
Strix's evidence-first promise begins here. Before autonomy becomes useful, the system must constrain what autonomy is about. Once that boundary is explicit, the design problem changes: the run now needs a way to distribute specialized work without allowing each agent to develop a private target model or lose the context that made its conclusion meaningful. That is the role of the agent graph.