Charter

Why we exist

Security tooling has a culture problem. Half is built by vendors who hide how it works so they can charge for it; half is built by the underground with no regard for who gets hurt.

The people in the middle — the MSP carrying the pager, the consultant on an authorized engagement, the blue-teamer who has to prove the network is clean — get the worst of both: tools they can't fully trust, and a community that treats "white hat" as a costume. TechMages.org is for the middle. The professionals. The ones who do this for a living and have to answer for it.

Who we serve

• MSPs — the first audience, by design. You defend networks you don't own and have to demonstrate due care, so every action against a client system is scoped, authorized, logged, and provable after the fact.
• Security professionals — pentesters, red / blue / purple teams, incident responders, and field operators on authorized engagements.
• Serious students — people genuinely training for the work above, who learn by building the tool and reading the source.

Who we are not

We are not a hacker group, and these are not toys for "play hackers." We don't build for people who want to break into systems they have no authorization to touch — and the tools are deliberately built to make unauthorized use awkward, loud, and self-incriminating rather than easy.

The dual-use reality

Every serious security tool is dual-use. nmap maps your network or someone else's. Kali is a defender's lab or an attacker's kit depending on the hand on the keyboard. A lockpick is a burglar's tool or a locksmith's trade. You cannot build a tool that only the good guys can use — the capability is the capability.

So we don't pretend we can stop abuse. People will try; that's true of every tool in this category and always has been. What we refuse to do is use that as an excuse to be careless. Our answer to dual-use is not denial — it's accountability engineered into the tool itself:

• Authorization is explicit. Offensive capability does nothing until an operator declares an engagement with an explicit scope. No engagement, no offense. The default state is safe.
• Scope is enforced, not suggested. Every offensive action is checked against the authorized scope at execution time — including when an automated agent makes the request.
• Everything is audited. Every job, refusal, and scope violation writes a durable record. The record is the point.
• Records are provable. We sign records with asymmetric cryptography (Ed25519, did:web) so a third party can verify exactly what a device did, offline, without having to trust us. Verifying must never let you forge.
• There is always a kill switch. One action stops every in-flight operation and restores a safe state, reachable from every interface — including the AI.
• Radio emission gets the strictest gate. Anything that transmits requires not just an active engagement but a specific, named, in-scope target before it will key the transmitter.

Our values, in the engineering

These aren't slogans. In our flagship project, Warlock OS, they are literally code:

Value	How it shows up in the build
Authorization-first	The engagement gate — offensive modules are inert until a scoped engagement is armed.
Scope is real	A scope allowlist checks every target (host / subnet / SSID / BSSID) at run time; out-of-scope is refused + logged.
Accountable	Every job / refusal writes an audit row; the kill switch reaches every queue.
Provable	Signed Agent Attestation Records (Ed25519 / JCS / did:web) — verify what the deck did without trusting it.
Safe by default	Ships in SAFE mode; the AI operator acts only inside an active engagement and can't arm one itself.
Understandable	Build-your-own from a documented BOM; open source; no black boxes.

The line

Use these tools on systems you own or are authorized to test. Keep your scope honest. Keep your records. If you wouldn't want the signed audit trail read back to you in a room with the client and their lawyer, don't do it.

Build wisely.