Evidence before claim.
Four commitments. They are the part of an early company that can be judged today, because they cost something to keep.
Four, and each of them costs something to keep.
- 01
We do not claim what we cannot show
No customer we cannot name, no capability we have not built, no credential we do not hold. In defensive security, a company that overstates its own position has already demonstrated the failure mode it is selling against.
- 02
Defensive by design
We build for the side that has to hold. We do not develop offensive tooling, and we do not publish exploit detail or specific offensive capability — including our own.
- 03
Measured, not asserted
A configuration file tells you what it says, not what a system does. We prove controls by firing them, and we treat a check that did not run as a failure rather than a pass.
- 04
Discretion about our counterparts
We do not publish customer-identifying security architecture, and we would not publish yours. A vendor that advertises the defenses of its clients has misunderstood the job.
The questions we get, answered the way we would want them answered.
None of these answers improve our position. They are here because a reader can check them, and because the alternative is making them ask.
- Do you have a product?
- No. There is nothing to buy on this site and no trial to start. The protocols and the AI work are in development, and every page here says so in the present progressive rather than the present tense.
- Can you take on work now?
- Yes, in the areas named on the cyber defense page: cloud security architecture, network security engineering, detection and response procedures, and recovery and continuity. Outside those, we will say so rather than stretch to fit.
- Who are your customers?
- There are none to name. When there are, they will appear here with their agreement, named and dated, and not before. A logo wall assembled from goodwill rather than contracts is the first thing a diligence process takes apart.
- Why are there no certifications listed?
- We hold professional certifications and deliberately do not list them on the site, because a certification named on a web page is a claim a reader cannot check and we cannot keep current. In a proposal or a diligence conversation they are provided in full, named and dated.
- What will you not do?
- We do not build offensive tooling. We do not publish exploit detail or specific offensive capability, including our own. We do not publish customer-identifying security architecture, and we would not publish yours. And we do not describe capability we have not built.
- How do I check any of this?
- Ask us to show a control running rather than to describe it, ask what we would refuse to do, and ask which of our claims you can verify without our help. Those three questions separate evidence from language, and they work on any vendor in this field.
What exists is in development. What does not exist is not described as though it does.
The convention in this sector is to write about a company as though it were already the company it intends to become. The language is available to anyone, which is exactly what makes it worthless as a signal.
When there is a product, it will be here with evidence. When there are customers, they will appear with their permission and not before. If that reads as modest, it is worth noticing that it is also the harder position to hold — and the only one that stays true as the company grows into it.