2. Scope is signed and enforced
Each engagement has a signed scope: the hosts, addresses, applications, accounts and code we may test, the time window, the techniques allowed and a named contact on the client side.
- Every step is checked against the scope before it runs. A step outside the scope is refused and recorded.
- Anything we discover that is not in scope is noted for the client and not tested.
- The client can pause or stop a run at any time, and we stop at once.
3. Proof, then stop
We prove a weakness once and stop there. Unless the scope explicitly allows more, we do not:
- Read, copy or keep client data beyond the minimum that proves the finding.
- Change or delete data, or leave anything behind on a system.
- Run denial-of-service or load tests, or degrade production.
- Phish or socially engineer people, or test physical sites.
- Move from a proved finding into other systems.
4. Evidence and records
Each run writes every step to a signed ledger and lists every file in a manifest, so the client can check the evidence pack independently. Findings, evidence and reports belong to the client and are confidential.
We keep engagement records only as long as the agreement says, then delete them. Credentials the client gives us for testing are kept encrypted, never written into the evidence, used only for that engagement and deleted when it ends.
5. Models and where data goes
An engagement uses several AI models, hosted frontier models and open-weight models we run ourselves. Every report names the models that worked on it and what each one did.
Hosted models process data under their providers' terms, which may include retention for safety monitoring. When data must not leave the client's control, the work runs on open-weight models on our own hardware or the client's.
6. Research
We study how attacks work, including how open-weight models behave once their safeguards are removed, so we can detect and stop those attacks. That research runs only against our own systems, purpose-built test targets or systems we are authorized to test. When we share what we learn with defenders, we say which models we used, and we share only what the program, maintainer or client terms allow.
7. What we refuse
We do not take on, and our software refuses:
- Testing a system without its owner's authorization, including competitors, former employers or partners.
- Building or deploying ransomware or malware meant to spread, or anything meant to destroy data.
- Surveillance of, or collecting data about, individual people.
- Work for sanctioned parties, or work that breaks export controls.
- Anything that could cause physical harm or disrupt essential services.
8. Weaknesses in other people's software
If we find a weakness in third-party software during an engagement, we tell the client and, with their agreement, report it to the vendor or maintainer through coordinated disclosure. We do not publish details before a fix or an agreed date.
9. Reporting misuse and contact
If you believe someone is using Nodejam Security against a system without authorization, or you have found a weakness in Nodejam itself, email security@nodejam.com. We act on misuse reports, including by ending access, and we cooperate with lawful requests from authorities.
This Policy shows its effective date at the top of the page. We will update it before the product changes how it works.