Frequently Asked Questions

This page collects concise answers to questions customers often raise about Breach360.

If something is not working rather than not understood, the Troubleshooting section is the better starting point — it covers connectivity, installation, deployment health and sign-in problems, with the diagnostic commands for each.

Breach360 capability

How does the platform perform exploit validation safely?

All exploit actions are executed by an in-network component deployed on the customer side, which enforces engagement scope and runs riskier tooling inside an isolated container rather than directly against production systems. Validation is evidence-driven — we capture screenshots, request/response pairs and command output as proof rather than sending destructive payloads — and engagements can be paused or cancelled at any time, with customer-defined exclusions and exploitability thresholds applied throughout.

How does the platform reduce false positives during exploit validation?

Every finding passes through multiple independent checks before it reaches the customer: in-test rules that require behavioural evidence, an AI deduplication pass that merges overlapping findings, and a separate confirmation step where each finding is independently re-tested by a different agent — anything that can’t be reproduced is dropped automatically. Severity is then recalculated against the confirmed evidence, and the customer can apply their own confidence and severity thresholds on top.

Does the solution support both authenticated and unauthenticated validation?

Yes — both, across web and API targets. By default, the platform runs unauthenticated (black-box); when credentials are supplied through the portal, a dedicated authentication step performs the login (including multi-factor where the relevant secret is provided) and the resulting session is reused for testing and for the confirmation re-test, so authenticated findings can be reliably reproduced.

Does Breach360 attempt privilege escalation even when only a single credential set is provided?

Yes. The privilege level of the authenticated session is established at login — for example, whether the session carries standard-user or administrative access — and the agent uses that as its starting point. From there, it works through an iterative, AI-guided sequence of steps to attempt escalation to a higher privilege level.

Successful escalations are surfaced in the engagement report as completed attack paths, each recording the sequence of steps taken and the proof-of-exploitation evidence captured along the way. Where no credentials are supplied, the same logic applies from an unauthenticated baseline — a successful escalation in that case means reaching authenticated access, which is equally flagged.

Can I add custom scripts or TTPs to Breach360?

No. Breach360 does not currently support uploading your own exploit or vulnerability-discovery scripts, or custom tactics, techniques, and procedures (TTPs), to run during engagements.

Every exploit script and TTP that the platform can execute today is reviewed manually as part of a human-in-the-loop validation process before it is approved for use on the platform. That approach helps keep testing production-safe, consistent, and reliable in customer environments.

Agentic AI capability

Can you explain technically how the Agentic AI operates during assessments?

An assessment runs as an ordered pipeline of specialised stages — reconnaissance, scanning, validation, web and API testing, confirmation, deduplication, reporting — each independently checkpointed so engagements can pause and resume cleanly. Inside the active-testing stages, narrowly scoped AI agents operate in a perceive-decide-act loop: they observe the target, choose the next action, dispatch it through the in-network execution layer, and feed the result back into their reasoning until the objective concludes. Every decision and action is logged for transparency.

Is the AI workflow rule-based, ML-based, LLM-assisted, or a hybrid approach?

It’s a hybrid by design. Anything that must be predictable and bounded — scope enforcement, CPE/CVE matching, severity scoring, scanner and tool wrappers, exclusion logic — is fully rule-based and deterministic. The judgement work a human pentester would do — selecting the next action, interpreting evidence, confirming findings, writing them up — is LLM-assisted, and we use dedicated machine-learning models for narrow specialist tasks such as hash cracking and similarity-based retrieval of prior knowledge.

How does the AI help reduce noise or prioritise findings?

Each AI agent run targets a single vulnerability class against a single asset, which keeps output focused and prevents the “shotgun” noise typical of generic scanners; findings are then deduplicated, independently re-confirmed, and re-scored against validated evidence, with anything unreproducible dropped before reporting. Prioritisation is further sharpened by exploitability signals (so effort focuses on issues attackers can actually use) and by mapping findings to threat actors known to target the customer’s sector — giving non-technical stakeholders a clear “what matters most, and why” view.

What safety measures does Breach360 take to keep engagements safe?

Breach360 uses multiple large language models (LLMs) for engagement-related functionality, which runs via managed LLM compute that BreachLock hosts within its own cloud environment.

Models are never trained on data from client engagements. Engagement content is not used as training input and is not applied to update model weights.

Breach360 uses highly specialized AI agents that run inside a tightly controlled orchestration framework, which is designed to contain and mitigate hallucinations and similar failure modes. The framework and the agent workflows that use it are sandboxed and run on dedicated compute allocated per engagement, so that processing stays isolated from other customers’ environments at the compute layer.

Engagements

When an engagement starts, what happens?

When you start an engagement, Breach360 queues work against the execution path that matches how you configured it.

For internal engagements, that typically means work is scheduled against the deployment you selected inside your environment. The assessment performs discovery against the scope you defined. For network-oriented scope, that means host and service discovery across the assets you included. Where the scope includes web applications or APIs, the workflow extends into HTTP(S)-based interaction—browser-style exercise of sites where that applies, and structured client-style traffic against API surfaces where that applies. Findings feed the platform’s autonomous assessment engine, which continues with deeper analysis. You do not need to run separate tools yourself; it is one continuous workflow from start through analysis.

For external engagements, testing targets your external attack surface from an outside-in perspective. The same broad pattern applies—discovery and analysis driven by your scope and settings—but what the engine can observe and how it reaches targets differs because traffic is driven from the internet toward your exposed assets rather than from a deployment inside your environment.

How do I start a web application engagement, and can I specify a URL as the entry point?

The process differs depending on whether the target is internal or external.

For internal web application engagements, the Scope step of the engagement creation flow includes a URL input field. Enter the URL of the application and click Add URL — Breach360 fetches the page through your deployment and presents a screenshot of the rendered application for you to confirm the target before it is added to scope.

For external web application engagements, scope is drawn from assets already catalogued under the Discover tab: add the application to Discover first, and once it appears there it can be selected during the Scope step. You can optionally specify a more precise starting point by enabling the Use specific engagement entry point toggle, which reveals a URL field for the exact URL the engagement should begin from.

What traffic should you expect, and what does intensity change?

During a run you should generally expect:

• Traffic toward in-scope targets, shaped by what you are testing: discovery and service-oriented checks for network assessments; realistic browser-style HTTP(S) traffic for web targets; request patterns typical of API clients for API targets; and, when exploitation is enabled, follow-on traffic that reflects safe validation attempts consistent with your configuration.
• Traffic between your environment and Breach360 for internal engagements: command and result traffic between the deployment and the Breach360 service is normal product coordination. External engagements still generate traffic toward your exposed assets, but the path and volume of back-and-forth with Breach360 may differ because testing is not anchored to an in-environment foothold in the same way.

Intensity mainly shapes how fast and busy the earlier discovery and probing phases feel: lower settings favor slower, gentler probing; higher settings complete those phases faster and can put more load on networks and services. Optional behaviors you enable at launch—for example credential-assisted checks in Additional Parameters—can add further traffic depending on what you turned on.

What IP addresses should we allow for external engagements?

Allow inbound traffic from 131.189.166.82 and 172.205.8.197, which are the addresses from which external engagement traffic originates. If you are a proof-of-value (PoV) customer, also allow 9.141.187.111 and 20.105.26.90. These are distinct from foothold outbound domain rules; see Allowlist source IPs for external engagements for the full table and context.

Can multiple credential sets be used within a single engagement — for example, to test different user roles?

Each engagement currently supports one credential set. To test multiple roles, run a separate engagement per credential set — each engagement will independently authenticate, test, and report findings for that role.

How do I provide an MFA secret during web application engagement configuration?

During web engagement creation, the Authentication step includes fields for a username, a password, and an optional TOTP secret. If the target application requires time-based one-time codes, enter the underlying TOTP secret in that field — Breach360 uses it to generate codes internally during both the initial login and the confirmation re-test.

Does MFA TOTP timing depend on how quickly an authenticator app refreshes codes?

No. Breach360 requires the underlying TOTP secret rather than a one-time code from an authenticator app, so it generates codes internally and is independent of authenticator app refresh cycles.

What happens when authentication fails during an engagement?

If authentication fails for a target — for example, because the application redirects to a third-party identity provider that Breach360 cannot authenticate against — the engagement continues against that asset in black-box mode. The asset is not automatically excluded from scope; testing proceeds without credentials and any findings made in that unauthenticated context are reported normally.

Can you define a scanning window?

There is no built-in “only test between these hours” schedule in the product today. If you need activity confined to certain hours, handle that operationally by pausing or unpausing engagements at the times you want testing to stop or resume.

Does the Pause action suspend an engagement mid-execution, and does it resume from the same point when restarted?

Yes. Pausing an engagement suspends it immediately and preserves all accumulated state — completed stage outputs, findings, and attack paths gathered so far. When the engagement is resumed, it continues from the next incomplete stage rather than restarting from scratch, so no previously completed work is repeated.

What is the difference between the Terminate and Pause actions? Are partial results available after an engagement is terminated?

Pause suspends execution while keeping all engagement state intact so that the engagement can be resumed later. Terminate permanently stops the engagement and clears that state — a terminated engagement cannot be resumed.

Terminating an engagement clears all partial results from the platform.

What happens when the engagement finishes?

When the assessment completes, the engagement is marked finished in the product, and outcomes appear in the platform according to your configuration—findings, reporting, exploitation paths, and related views you use elsewhere in the documentation. No further automated testing runs on that engagement unless you start something new.

For internal engagements that used a deployment, that deployment is shown as ready to take new work again. External engagements likewise finish with a completed engagement and no further automated testing on that run until you start something new.