Skip to content
◆Service

Applied AI for Cyber

Machine-learning and agentic systems built to do real work inside security operations.

The aim is not to show analysts more alerts, faster. It is to narrow the queue by deduplicating and enriching automatically, so the human is spending judgement on the few that need it rather than sorting the many that never did.

Most security teams are not short of signal. They are drowning in it, and the incidents that matter are somewhere inside a queue nobody can finish. AI is sold as the answer to this, and generic AI usually is not, because a model that knows nothing about your environment cannot tell a routine administrative action from the same action performed by someone who should not be doing it.

What works is narrower and less glamorous. A classifier trained on your own labelled data, solving one well-chosen problem, evaluated honestly before it is trusted. Agentic automation that does the enrichment an analyst would otherwise do by hand, pulling context from every console so the human starts the decision rather than starting the research. I have built this kind of thing rather than only specified it: a Naïve Bayes anti-phishing classifier for a government agency was a fairly simple model that removed a large and repetitive workload.

The other half of the work is knowing where not to use it. Automating a decision you cannot audit is a liability, not an efficiency. Anything that acts autonomously needs an evaluation set, drift monitoring, and a clear account of what happens when it is wrong. I would rather tell you a problem is not worth solving with machine learning than build something impressive that quietly degrades six months after handover.

You might need this if

  • Analysts spend most of a shift on alerts that were never going to become incidents
  • A tool promised AI-driven triage and the false-positive rate did not move
  • Enrichment is manual copying between four consoles before anyone can make a judgement
  • You want to apply machine learning but nobody can tell you whether it would actually help
  • A model is already in production and no one is measuring whether it still works

Who it's for

Security teams drowning in alerts, and leaders who want AI applied to cyber operations by someone who can actually build it.

How the engagement runs

  1. 01

    Problem selection and baseline

    Pick one problem where the volume is high, the judgement is repetitive, and the ground truth is knowable. Measure the current cost in analyst time, so improvement can be proved rather than asserted.

  2. 02

    Data and labelling

    Assemble and label the data honestly, including the awkward cases. This is the stage that determines whether the result works, and the stage most projects rush.

  3. 03

    Build and evaluate

    Train the simplest model that could work, then test it against held-out data and against the existing process. Simple and explainable beats sophisticated and opaque in an environment where decisions get questioned.

  4. 04

    Deploy with a human in the loop

    Ship it where a person still makes the consequential call, with drift monitoring, a clear failure mode, and documentation your team can maintain once I have gone.

What's delivered

  • Bespoke classifiers for detection, built, evaluated, and deployed
  • Agentic automation for triage and enrichment workflows
  • LLM-assisted analyst tooling that keeps a human in the loop
  • Pragmatic MLOps: evaluation, drift monitoring, and model governance
  • Honest assessment of where AI helps, and where it does not

Proof point

Built a Naïve Bayes anti-phishing classifier for a government agency, applied machine learning solving an operational detection problem.

Common questions

Do we need a data science team for this?
No. That is rather the point of choosing narrow, well-defined problems. The models that solve real SOC problems are usually modest, and I hand over something your existing engineers can understand and retrain.
Won't a large language model just do all of this?
For summarising, drafting, and pulling context together, often yes, and that is genuinely useful. For high-volume classification where you need consistency and a measurable error rate, a small purpose-trained model is usually cheaper, faster, and easier to defend when someone asks why it made a call.
What happens when the model is wrong?
It will be, so the design has to assume it. That means calibrating the threshold to the cost of each kind of error, keeping a human on the consequential decisions, and monitoring for the drift that makes yesterday's accuracy meaningless.
Our dataset feels too small.
It often is not, particularly for classification problems where the classes are reasonably distinct. It is worth an honest look before assuming otherwise, and if the data genuinely will not support it, I will say so rather than build something that looks convincing in testing.

Other services

Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.

Discuss an engagementaspera@antan.co.nzLinkedIn (opens in a new tab)