Skip to content
Auctoritas IntelligenceAuctoritasIntelligence
Practice 01 · Cyber defense

Two lines of work, both defensive.

Described at the level of what they are for. We do not publish capability detail, and we would be wary of anyone in this field who does.

01

Cybersecurity protocols

A protocol is the part of security that survives the people who wrote it. Most organizations have documentation; far fewer have something a tired analyst can follow correctly at three in the morning during the worst hour of their year.

We are building protocols for that moment — detection, containment, recovery and the handoffs between them — designed to be executed under pressure rather than referenced in an audit.

What that means in practice

  • Procedures written to be run, with the decision points made explicit
  • Clear ownership at each step, so nothing waits on an unnamed person
  • Deliberate handoffs between detection, response and recovery
  • Structured to be tested, because an untested procedure is a hypothesis
02

AI programs for cyber defense

Offensive and defensive security are not symmetrical problems. An attacker needs one path to work once. A defender needs every path to hold, every time, and has to explain the result afterwards.

Our second line of work is developing new AI capability aimed squarely at the defensive side — the side where being right on average is not the same as being right.

Two commitments that shape the work

  • Defensive by design. We are not building offensive tooling, and we do not publish exploit detail or specific offensive capability.
  • Explainable where it counts. A defensive decision a team cannot account for is a decision they cannot stand behind with a regulator, an insurer, or their own board.
Where we start

The ground we can stand on.

Security is a wide field and we are not going to claim all of it. Our depth today is in cloud infrastructure and network environments — the layer where most organizations actually live, and where our engineering background sits.

That is where the protocols begin. We would rather name the ground we can stand on than describe a perimeter we cannot hold.

What we can take on now

Cloud security architecture
how an environment is segmented, what can reach what, and what happens when something is wrong
Network security engineering
the design and the controls at the layer attacks actually traverse
Detection and response procedures
written to be executed, and structured so they can be tested
Recovery and continuity
the part of a protocol that decides how long a bad day lasts
AI applied to defensive work
in development, and described as such everywhere on this site
How the work runs

Four phases, and the last one is the one that gets skipped.

This is method, not a promise about outcomes. It is the part of an engagement a client can hold us to from day one.

  1. 01

    Scope and constraints

    What the environment is, what must not be touched, who is allowed to decide. Written down before anything is read, because the constraints are the part people remember differently later.

  2. 02

    Read the system as built

    Configuration, segmentation, what can actually reach what. Measured against the running system rather than drawn from a diagram, because the diagram is a record of an intention.

  3. 03

    Write the procedure

    Decision points made explicit, ownership named at each step, handoffs between detection, response and recovery stated rather than assumed.

  4. 04

    Fire it once, on purpose

    An untested procedure is a hypothesis. We run it deliberately, in daylight, before anyone has to run it at three in the morning. A check that did not run is a failure, not a pass.

Diligence

Questions worth asking any vendor in this field.

Including us. These are the questions we find hardest to answer with anything other than evidence, which is why they are the useful ones.

  1. 01
    Can you show me the check running, or only its result?A report is an assertion. A control firing in front of you is not.
  2. 02
    What happens when your detection is wrong?Every detector is wrong sometimes. The answer reveals whether the failure mode was designed for or discovered later.
  3. 03
    Which of your claims can I verify without your help?If the answer is none, the relationship depends entirely on trust rather than on evidence.
  4. 04
    What will you refuse to do?A vendor with no refusals has not thought about the boundary, or is not telling you where it is.
  5. 05
    Who owns the procedure when this ends?If the work leaves with the vendor, it was a dependency, not a capability.
  6. 06
    What would you not publish about me?Ask before you are a reference. The answer is easier to get honestly at the start.

When a product, a customer or a certification exists, it will appear here with evidence attached — and not before.

Today there is no shipped product, no customer, no pricing, no certification and no past performance on this page, because there is none to show.