In Development · Waitlist Open

Other scanners tell you what's broken. Aegis fixes it.

Aegis scans your Windows and Active Directory estate, groups the findings into the attack paths an adversary would actually walk, and identifies the single fix that collapses the most of them. Then it applies that fix across your environment, on your approval, with a rollback for every change.

No sales call required. We'll email you once, when early access opens.

Paths to Domain Admin 4 of 4 open
STD USER LLMNR RELAY SMB CAPTURE ACL PATH STALE ADMIN SRV-APP-04 DELEG DOMAIN ADMIN
Two of these four paths share one link. One fix closes both.
Windows & Active Directory Continuous scanning Automated remediation Built by pentesters & AI engineers
The gap

Nobody has a scanning problem. Everybody has a remediation problem.

Most organisations already know what is wrong with their environment. There is a scanner. There is a report. There is a spreadsheet with four thousand rows, sorted by severity score, that has been circulating between IT and security since the last audit.

What is missing is not detection. It is the work of actually closing things: the change requests, the maintenance windows, the testing, the internal negotiation over whose service breaks if legacy protocols are disabled. That work is manual, it is slow, and it is where the exposure lives. Scanning is continuous; remediation runs at the speed of change control.

Worse, the list is sorted wrong. A severity score rates a vulnerability in isolation, and adversaries do not attack in isolation. They chain a medium into a high into domain compromise. Ranking by score means working hard on findings that were never on the path.

How it works

Scan. Prioritise. Remediate.

01 / SCAN

Configuration state, continuously

A lightweight agent runs on your Windows endpoints and servers, collecting protocol and signing settings, OS currency, privilege and delegation relationships, and the misconfigurations that make internal compromise routine. No appliance, no credentialed network sweep.

02 / PRIORITISE

Findings become chains

Findings are correlated into the sequences an adversary would use to move from an unprivileged foothold to domain control. Aegis then identifies the chokepoint: the one change that severs the most chains for the least disruption.

03 / REMEDIATE

Approved, applied, verified

The change is presented as a plan: hosts in scope, settings modified, expected impact, rollback path. You approve it. The agents apply it. Aegis re-scans to confirm the finding is genuinely closed.

Automated security scanners find four thousand vulnerabilities. An adversary only needs three.

Your scanner gives you a tome of remediation steps. We automate it for you.

One fix that breaks four attack paths beats forty patches that break none.

Remediation cycles measured in days, not quarters.

Prioritisation

We don't rank by blind and non-contextualized CVSS scores. We rank by what breaks the chain.

The question is never "what is the worst finding?" It is "what is the shortest path to the biggest domain impact, and where does it break most cheaply?"

Two findings carry the same score. One sits on the only path between a standard workstation and your domain administrators. The other sits on a segment nobody can reach. A severity score cannot tell them apart. Attack-path analysis can.

Aegis models the routes through your environment the way an operator would: what is reachable, what is exploitable, what it yields, and what that yield unlocks next. Then it looks for the chokepoint, the single change that severs the largest number of those routes at once.

Effectiveness is weighted against reality, not theory. A fix that eliminates six paths but requires a domain-wide restart may be scheduled behind one that eliminates four and needs no downtime at all. You see the reasoning, the trade-off, and the expected reduction in exposure before you approve anything.

This is not a language model guessing. Attack chains and the ranked plan are produced by decision tree algorithms over collected configuration state. The same environment always yields the same chains and the same recommendation, and every branch is inspectable. Deterministic, repeatable, and auditable, because nobody should have to take a model's word for which change to make on a domain controller.

Console

One console. Your whole estate. Plain language.

Everything Aegis collects lands in a single dashboard: estate-wide posture, open chains, machines running unsupported operating systems. Every figure drills to the hosts and evidence beneath it.

Acting on it does not require writing a script. State the change in plain language and Aegis turns it into a scoped plan for each affected machine. Guidance is sharpened by anonymised benchmarks from comparable environments, so a 200-seat operator and a 5,000-seat bank are not handed the same sequence.

Enforce SMB signing on all domain controllers
Remediate the top 10 criticals on the finance subnet
Show me every path from a standard user to Domain Admin
Disable LLMNR and NBT-NS estate-wide, staged over three rings

The model only reads the chat box. A language model translates what you type into a change plan you then review. It does not decide what to fix, does not rank findings, and never executes anything. Every instruction produces a proposal, and every proposal requires sign-off.

Why we built it

One of us broke into these networks. The other builds the models.

Aegis comes out of years of penetration testing and red team work across financial services, energy, and maritime and shipping. The pattern was the same almost everywhere: compromise an estate through a chain of well understood, entirely fixable misconfigurations, write it up, hand it over, and come back the following year to find the same chain intact.

That is not negligence. It is capacity. The IT team knew exactly what the report said. They never had the time, the tooling, or the confidence to make the change safely on a live estate, so the findings aged in a spreadsheet while the paths stayed open. Watching engineers do that work by hand, one host at a time, is the reason this product exists.

The other half of the founding team is an AI engineer who has shipped systems on top of a range of models, and who drew the line we now hold to: a model is good at understanding what you asked for, and the wrong tool for deciding what to change in your domain. So the language model sits on the chat box, and decision trees do the reasoning.

Control

Automated does not mean unsupervised.

Aegis makes changes to production Windows environments. We designed it on the assumption that you will trust it slowly, and that you should.

Approval before execution

No change runs without explicit authorisation. Read-only mode is available indefinitely.

Scoped and staged

Pilot group, then a ring, then the estate. Scope by OU, subnet, host group or tag.

Reversible by design

Prior state is recorded before every modification. Reverting a scope is a single action.

Fully auditable

Every proposal, approval and result logged with operator, timestamp and outcome.

What Aegis is not.

Aegis is not an EDR and does not replace one. It does not monitor process activity, inspect running memory, hunt for live intrusions, or respond to incidents in progress. It scans configuration state, works out what that state makes possible, and fixes it.

It is also not another generic vulnerability management scanner. It does not hand you thousands of unconfirmed findings to triage yourself. Findings are correlated into paths that actually exist in your environment, and the ones that matter are closed rather than listed.

We built the thing that closes the gap your existing tools leave open, not another one that tells you about it.

Aegis is still in development.

Subscribers get early insights and preferential pricing at launch.

One email when we launch. We won't spam or sell your e-mail address.

You're on the list.

We'll be in touch when early access opens, and not before.

Technical overview

From finding to fixed, without the handwork in between.

How Aegis scans, prioritises, and remediates, and what it deliberately will not do without you.

Scope

What Aegis does, and what it doesn't

Aegis is a configuration scanner and remediation engine for Windows and Active Directory environments. It answers one question continuously, what in this estate makes compromise possible, and what is the most efficient way to close it, and then closes it on your instruction.

It is not an EDR, an XDR, or a SIEM. It does not monitor process execution, inspect memory, analyse network traffic for intrusions, generate detection alerts, or isolate hosts. If you are looking for something to catch an adversary already inside your network, Aegis is not that product and we will tell you so.

What it replaces is the manual work between a scan report and a fixed environment.

Two things are worth stating plainly about how it decides. Attack chains and remediation ranking are computed by decision tree algorithms over collected configuration state, not by a language model. A model is used in one place only: translating what you type in the console into a change plan you then review.

Architecture

Two components, one decision point.

Agent. A Windows service deployed through your existing software distribution: Group Policy, SCCM/MECM, Intune, or a script. It reads local configuration and directory state on a schedule, reports it, and executes only the remediation actions you have approved. It does not scan the network and does not sit in the path of running processes.

Management plane. The dashboard your IT administrators work from, and the single point at which everything the agents report is aggregated. This is where findings become chains, chains become prioritised plans, and plans are reviewed, approved, scheduled, and audited.

WINDOWS ESTATE MANAGEMENT PLANE ENDPOINT ENDPOINT FILE SERVER DOMAIN CTRL AGGREGATE CORRELATE AUTHORISE APPROVED CHANGE

Aegis currently supports Windows and Active Directory. This is deliberate. Internal compromise overwhelmingly runs through Windows and AD, and we would rather do that completely than do everything partially.

Coverage

What we scan for

The weaknesses that internal compromise actually depends on, the findings that appear in nearly every internal penetration test report, year after year.

Protocol and authentication

SMB signing not enforced·LLMNR and NBT-NS name resolution enabled·legacy authentication protocols permitted·downgradeable authentication settings·unnecessary listening services

Active Directory configuration

Excessive privilege and nested group sprawl·unconstrained and misconfigured delegation·dangerous object permissions and ACL paths·weak or unmanaged local administrator credentials·stale privileged accounts·Kerberos configuration weaknesses·service account exposure

Host and platform posture

Unsupported or end-of-life operating systems·missing security configuration baselines·local administrator sprawl·audit and logging configuration gaps

Reachability

Which hosts can reach which, and what that reachability enables in combination with the above.

This is the standard internal and Active Directory finding set at launch. Coverage expands continuously, prioritised by what we encounter on live engagements.

Attack chains

Findings become chains

An individual finding is rarely the problem. LLMNR enabled is not a breach. SMB signing unenforced is not a breach. A service account with excessive rights is not a breach. The three together, in the same environment, are a well-worn route to domain compromise that any competent operator will complete in an afternoon.

Aegis correlates findings into those routes. Each chain is presented as a sequence: the position an adversary would need, each step they would take, the technique involved, and what the chain ultimately yields.

This changes the unit of work. Instead of a queue of four thousand findings, your team sees a manageable number of concrete paths, each with an owner, an impact, and a defined way to break it.

FOOTHOLD NAME POISONING RELAY / CAPTURE DELEGATION ABUSE DOMAIN COMPROMISE

Chains are mapped to recognised adversary technique frameworks and informed by how intrusion sets active against your sector actually operate, so they reconcile with your existing coverage and report in language your auditors and board already accept.

Prioritisation

Effectiveness-weighted prioritisation

Once chains are mapped, Aegis solves a different problem: not what is worst, but what should you do first. Every candidate remediation is scored against four factors.

Chain-break value

How many distinct attack paths does this change sever, and how significant are their end objectives?

Implementation effort

How much work is the change in practice: a policy setting, a staged rollout, a project?

Operational cost

Does it require downtime, a restart, a maintenance window, or coordination with a business owner?

Blast radius

How many systems and users does it touch, and what is the realistic risk of disruption?

The output is an ordered plan. Frequently the top recommendation is not the highest-severity finding on the list. It is the modest one sitting at the junction of six separate paths that can be closed on a Tuesday afternoon without a maintenance window.

Deterministic by design. Scoring and chain construction run through decision trees, so the output is reproducible and every branch can be traced. Run Aegis twice against an unchanged estate and you get an identical plan. That property matters when the recommendation is going into a change request that somebody has to sign.

Closing the highest-severity finding feels like progress. Closing the chokepoint is progress.
Remediation

Automated remediation

When you approve a remediation, Aegis translates it into the specific actions required on each affected host and dispatches them to the agents. There is no script for your team to write, test, and maintain.

01ProposalHosts in scope, settings to be modified, expected operational impact, prerequisites, rollback path.
02ScopingConfirm or narrow: a pilot group, an OU, a subnet, a tag, or the full estate.
03SchedulingExecute now, or queue for your next maintenance window.
04ApprovalAn authorised operator signs off. Nothing proceeds without this.
05ExecutionAgents apply the change. Progress reported per host, with failures isolated rather than blocking the batch.
06VerificationAegis re-scans the affected configuration and confirms the finding is genuinely closed, not merely marked closed.
07RecordThe full sequence is written to an exportable audit trail.

Prior state is captured before every modification. If a change causes operational friction, reverting the affected scope is a single action, and the finding returns to the queue rather than silently disappearing.

Console

Centralised intelligence, centralised action

Every agent reports into one place. The dashboard gives estate-wide posture: open chains, exposure trend, machines running unsupported operating systems, and the current recommended plan. Every high-level figure drills to the hosts and evidence beneath it.

The natural-language interface is a faster way to express intent, not a bypass of the approval workflow. The language model parses your instruction and nothing more. It does not select findings, score chains, or trigger execution.

Show me every path from a standard user to Domain Admin
4 chains identified · 2 share a common link
Common link: unconstrained delegation on SRV-APP-04
Breaking this link eliminates 2 of 4 chains
Effort: low · Downtime: none · Blast radius: 1 host
Remediate it
Change plan prepared · 1 host in scope · awaiting approval
Cohort benchmarking

Guidance from environments like yours

Participating environments contribute anonymised configuration and remediation data to aggregated cohorts, grouped by organisation size, industry, and technology stack. Aegis uses those cohorts to sharpen its guidance: which remediations comparable organisations actually completed, which produced operational friction, and what a realistic timeline looks like at your scale.

A remediation sequence appropriate for a 5,000-seat bank with a mature change process is not the right sequence for a 200-seat operator with two IT staff and a fleet at sea.

Data handling

Benchmarking is opt-in and can be disabled at any time without affecting any other function. Contributed data is limited to aggregated configuration and remediation outcomes. No customer identifiers, hostnames, credentials, directory contents, file contents, or business data are included. A Data Processing Agreement setting out the full processing detail will be provided to customers before any environment is onboarded, and we process in line with the GDPR.

Deployment

Getting started

Requirements

Windows endpoints and servers · Active Directory environment · agent deployment via Group Policy, SCCM/MECM, Intune, or script.

First run

Deploy agents to a pilot group · review the first chain map in read-only mode for as long as you want · enable remediation when you're ready, starting with the pilot scope.

Roadmap

What's next

Aegis launches focused on Windows and Active Directory because that is where internal compromise happens and where our operational experience is deepest. Planned expansion, in current priority order:

Linux server support Cloud identity & Entra ID Expanded configuration coverage Ticketing & change management integration

Design partners have direct influence over this order.

See it against your own environment.

The fastest way to evaluate Aegis is a pilot deployment on a limited scope of your estate, in read-only mode. No changes, no commitment, just an honest map of the paths that exist in your environment today.

Get in touch

Aegis is pre-release. Whether you want early access, a technical conversation, or to talk about becoming a design partner, this reaches us directly.

Received.

Thanks, we've got it. We reply to every genuine enquiry, usually within two working days.

General enquiries: info@hardlinelabs.com

Responsible disclosure: security@hardlinelabs.com

Version 1.0 · Last updated 20 August 2026

Privacy Policy

This notice explains what personal data Hardline Labs collects through this website, why, for how long, and what you can require us to do about it. It is written to satisfy Articles 13 and 14 of the GDPR.

It covers this website only. Aegis is not yet generally available, so we do not currently process data from any customer environment. Before any customer is onboarded we will put a separate Data Processing Agreement in place.

1. Who is responsible for your data

HARDLINE LABS, LTD trading as Hardline Labs is the data controller for everything described here.

Registered address: [REGISTERED ADDRESS]
Company registration number: [NUMBER]
VAT number: [VAT NUMBER]
Email: info@hardlinelabs.com

We are not required to appoint a Data Protection Officer and have not done so. Privacy requests go to the address above and are handled directly by a founder.

2. What we collect, and why

We collect only what you type into a form, plus the minimum technical data needed to deliver and defend the site. We do not buy data, and we do not obtain data about you from third parties.

A. Waitlist signup

Data: your email address; the date and time of submission; a salted one-way hash of your IP address; your browser user agent string.
Purpose: to notify you once, when Aegis becomes available.
Lawful basis: your consent, GDPR Article 6(1)(a).
Retention: until we have contacted you at launch, or until you withdraw, whichever is first. If we have not launched within 24 months we will delete the list.

B. Contact form

Data: your name, email address, company, the enquiry category you selected, your message, the date and time of submission, a salted one-way hash of your IP address, your browser user agent string.
Purpose: to answer you and, where relevant, to continue a commercial conversation.
Lawful basis: steps taken at your request prior to entering a contract, Article 6(1)(b); and our legitimate interest in responding to business enquiries, Article 6(1)(f).
Retention: 24 months from our last exchange with you.

C. Abuse prevention

Data: a salted one-way hash of your IP address and the time of your last submission.
Purpose: to rate limit automated abuse of our forms.
Lawful basis: our legitimate interest in the availability and integrity of our systems, Article 6(1)(f).
Retention: 30 days.

D. Hosting and application logs

Data: standard request data recorded by our hosting platform, which may include your IP address, request time, requested URL, and user agent.
Purpose: service delivery, availability, diagnostics and security.
Lawful basis: legitimate interest, Article 6(1)(f).
Retention: our provider's standard retention period, currently 90 days.

We store a salted hash of your IP address rather than the address itself wherever we control the storage. The hash cannot practically be reversed to identify you, and exists only so we can throttle repeated submissions.

You are not obliged to provide any of this. If you choose not to, we simply cannot add you to the waitlist or reply to you.

3. Special category data

We do not seek, and have no use for, special category data as defined in Article 9: health, biometrics, political opinions, religious beliefs, trade union membership, sexual orientation, or racial or ethnic origin. Please do not include such information in a message to us. If you do, we will delete it.

4. What we deliberately do not do

We do not use analytics, advertising, remarketing, tracking pixels, fingerprinting, or session recording.

We set no cookies whatsoever, for any purpose, which is why this site has no cookie banner. Nothing is written to your browser's local or session storage.

We do not sell, rent, or licence personal data. We do not share it with anyone for their own marketing. We do not build profiles, and we carry out no automated decision-making or profiling producing legal or similarly significant effects, within the meaning of Article 22.

We will not use a waitlist address for unrelated marketing. If that ever changes, we will ask for your consent first rather than assume it.

5. Who else processes your data

We keep the list of processors deliberately short. Each acts only on our documented instructions, under a written contract meeting Article 28.

Microsoft Corporation and its affiliates. Website hosting, storage of form submissions, application telemetry, and email. Primary processing region: North Europe.

Google LLC. This site currently loads two typefaces from Google Fonts. Your browser requests them directly from Google, which necessarily discloses your IP address and user agent to Google at that moment. We receive nothing back.

We will disclose personal data to a court, regulator or law enforcement body only where we are legally obliged to, and we will notify you unless we are legally prohibited from doing so.

6. Transfers outside the EEA

Our processors are global and some processing may take place outside the European Economic Area. Where it does, the transfer is protected by the European Commission's Standard Contractual Clauses, an adequacy decision, or another lawful transfer mechanism under Chapter V of the GDPR, together with the supplementary technical measures those providers apply. You may request a copy of the relevant safeguards from us.

7. How we protect it

The site is static and served only over HTTPS, with HTTP Strict Transport Security and a strict Content Security Policy. Form submissions travel over TLS and are validated and length-limited on the server. Submitted content is never placed into email headers, and is escaped wherever it is rendered.

Stored submissions are held in an access-controlled Azure account. Access is limited to the founders, using accounts protected by multi-factor authentication. We do not retain raw IP addresses alongside submissions.

If a personal data breach occurs that is likely to result in a risk to your rights and freedoms, we will notify the supervisory authority within 72 hours as required by Article 33, and will inform affected individuals directly without undue delay where Article 34 requires it.

8. Your rights

You have the right to:

· Access the personal data we hold about you, and receive a copy (Article 15).
· Rectify data that is inaccurate or incomplete (Article 16).
· Erase your data (Article 17).
· Restrict processing in certain circumstances (Article 18).
· Data portability, receiving your data in a structured, machine-readable format (Article 20).
· Object to processing based on legitimate interests (Article 21).
· Withdraw consent at any time, where processing relies on consent (Article 7(3)). Withdrawing does not affect the lawfulness of processing before you withdrew.

To exercise any of these, email info@hardlinelabs.com. We will respond within one month, extendable by two further months for complex requests, in which case we will tell you within the first month and explain why. There is no charge, and you do not need to give a reason or use any particular form of words.

We may ask you to confirm the email address the request relates to, purely so that we do not disclose or delete someone else's data on the strength of an unverified email.

Leaving the waitlist is deliberately trivial. One line to the address above and the record is deleted, along with the notification copy in our mailbox. No retention offers, no confirmation loops.

9. Complaints

If you believe we have mishandled your data, please raise it with us first so we can fix it. You also have the right to lodge a complaint with a supervisory authority, in the EU member state of your habitual residence, your place of work, or where you believe the infringement occurred.

10. Children

This is a business-to-business site and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child has submitted data to us, tell us and we will delete it.

11. Links to other sites

Where we link to a third-party site, this notice stops at that link. We are not responsible for how other operators handle your data.

12. Reporting a security issue

Our vulnerability disclosure contact and policy are published at /.well-known/security.txt and summarised in our disclosure policy. We credit good-faith reporters who wish to be named.

13. Changes to this notice

If we change this notice we will update the version number and date at the top of this page. Where a change materially affects people already on the waitlist, we will email them rather than rely on them noticing. Previous versions are available on request.

Vulnerability disclosure

Responsible disclosure policy

We spend our working lives finding other people's vulnerabilities. It would be poor form to handle reports about our own badly.

Scope

In scope: hardlinelabs.com, www.hardlinelabs.com, and the form endpoint at /api/submit.

Out of scope: our third-party providers, including Microsoft and Google, which have their own disclosure programmes. Also out of scope: findings from automated scanners with no demonstrated impact, missing headers with no exploitable consequence, rate limiting on non-sensitive endpoints, and social engineering of our staff.

How to report

Email security@hardlinelabs.com with enough detail to reproduce the issue. Proof-of-concept code is welcome.

What we commit to

· Acknowledgement within 3 working days.
· An assessment, including whether we consider it in scope and our intended fix timeline, within 10 working days.
· Credit in our acknowledgements if you want to be named, or anonymity if you prefer.
· No legal action against researchers acting in good faith under this policy.

What we ask

· Give us reasonable time to fix an issue before disclosing it publicly.
· Do not access, modify, or delete data belonging to anyone else. If you encounter personal data, stop and tell us.
· Do not degrade our service. No automated high-volume testing, no denial of service, no spam.
· Stay within scope.

Bounty

We do not currently run a paid bug bounty. We will say so honestly rather than imply otherwise, and we will still credit you.