Nebula: An Autonomous AI Security System (Whitepaper)

An AI security system needs to do more than suggest the next command. It needs to understand the task, use the right tools, preserve useful context and leave a result that a person can review.

Nebula is the autonomous AI security engineer inside BreachLine. BreachLine is a SaaS platform: your organisation gets a workspace for conversations, projects, tools, integrations and findings. This overview explains the workflow, the role of autonomy and the decisions that stay with you.

Watch the product

The current app images in this paper use a demonstration workspace. They show how the interface brings a task and its results together.

The system at a glance

The product is designed around an ongoing piece of work. You can start with a conversation, follow the tool activity and return to the project when a result or decision needs attention.

The engineer’s workspace

The Engineer view gives Nebula a workspace for ongoing work. Your daily briefing brings together current objectives, approvals and scheduled tasks. The Work board organises the plan, while the calendar provides day, week and month views of scheduled work.

Recurring tasks let you define work that should return on a schedule. The task still needs suitable scope, access and available credits. You can review the plan and the results from the same workspace.

From a request to a result

A task starts with an objective and a boundary. “Check our staging app before release” gives a direction. The approved targets, test accounts and restrictions make that direction actionable.

Nebula then works through a loop:

1. Read the objective and available context.
2. Decide which step can make useful progress.
3. Use an available tool within the authorised scope.
4. Inspect the response and update the plan.
5. Record useful evidence and report the result or blocker.

This loop lets the system adapt. A response that rules out one idea can point to a different check. A tool error should lead to an informed recovery or a clear blocker, rather than an invented success.

For larger tasks, Nebula can divide suitable work between agents. Parallel work is useful when the jobs are independent. When one result is needed before another step can begin, the work has to happen in order.

What autonomous means

Autonomy is the ability to carry out several steps without asking you to write each command. It does not remove the need for permission, access or judgement.

You define the targets, connect the accounts and decide which actions are allowed. You can follow progress and send instructions while work is running. If access is missing or a decision requires your input, the system should make that visible.

Onboarding sets up the account and workspace. You can then configure recurring work and supported integrations so every task does not need to begin with a fresh dashboard visit. You still use the workspace to manage permissions, review important results and understand usage.

This is the practical aim: an AI system that can carry useful work forward while keeping its actions understandable. The value should be assessed through completed tasks and evidence, not through a label alone.

Tools and the working environment

Nebula works with browser, terminal and security tools in a sandboxed environment. A tool is a way to interact with a system; its output is evidence to inspect, not a guarantee that the task is complete.

Browser interaction is useful for sign-in, account permissions and other user journeys. Terminal and security tools support tasks that need structured requests, scripts or inspection of technical responses. Available connections and test access determine what can be covered.

A network test requires access to the approved network. Mobile testing needs a supported, connected device. Cloud work depends on the accounts and permissions you provide. These are part of setting up a meaningful test, just as they are for a human engineer.

Projects and memory

A project groups related conversations. Pinning keeps frequently used sessions easy to reach. Project memory helps carry useful context between related tasks, including earlier notes and findings.

That context matters when an investigation spans several sessions. A later task can begin with what is already known and concentrate on the new question. The project gives you a place to review the history and correct outdated assumptions.

Memory is useful context, not proof that an old observation is still true. When a release changes the system, a fresh check is needed. Reports should distinguish current evidence from earlier notes.

Findings people can use

A finding should connect an observation to its impact. The supporting evidence lets the reviewer assess the result, reproduce the relevant behaviour and decide on a fix.

The findings view keeps issues organised while the conversation preserves the surrounding investigation. A developer can review the evidence without having to reconstruct every tool action from memory.

After a fix, a retest is a new task. It should check the changed behaviour against the original issue. AI-written reports, investigations and retests use credits; exporting existing findings does not add an AI credit charge.

Connected work

The integration catalogue includes 300+ entries for connecting tools and accounts to the workflow. Choose the connection and review the access it requests. A configured staff mailbox provides another way to continue work through email.

The workspace remains the shared point of reference. It keeps the task, activity, findings and usage accessible even when some interaction starts in a connected application.

For an organisation, the important question is not how many logos appear on a page. It is whether the required connection works with the correct account and permissions, and whether its actions can be reviewed.

Responsible operation

Before testing, confirm written authorisation for the targets. Keep the scope specific and use suitable test accounts. Review the permissions attached to each connection.

Treat information from websites, files and tool responses as data to evaluate. It should not silently redefine the task or expand the authority you granted.

Review significant findings before acting on them. Keep track of which environment was tested, what access was available and when the evidence was collected. These details make a result useful to both the engineering team and its reviewers.

The security page describes the platform controls and disclosure policy. The terms set out the conditions for platform use.

How to evaluate Nebula

Start with a bounded task on a system you own or are authorised to test. Decide what a useful result would look like before the run begins.

Assess the whole workflow:

• Did the task remain within its approved scope?
• Could you understand the plan and follow the work?
• Did the tool activity support the reported findings?
• Were errors and missing access reported accurately?
• Could another person review the evidence?
• Did a retest check the behaviour that changed?
• Were usage and credit charges visible?

A convincing evaluation includes both successful tasks and limitations. It should show where the system saved work and where a person still needed to intervene.

Getting started

Choose a platform plan for your workspace. Plans include an AI staff member and monthly usage credits, with prepaid top-ups for additional work. For a project delivered by our team, penetration testing services are scoped and quoted separately.

Book a demo to see the workflow and discuss a first task. The documentation covers setup and API access.

Sources

• BreachLine platform
• Platform and model API documentation
• Plans, metered usage and credit allowances
• Security controls and disclosure policy
• Platform-use terms