Every step of the way “Automated via MCP server”: what your agent does, what the NOCIP systems do, when a person at NOCIP becomes active and who decides.
Your AI agent (through the MCP server) or your build system (through the REST interface), with the token of your case. It sends statements, evidence and answers. Everything it sends is a claim, not a finding.
The interface on nocip.com accepts submissions and checks them for completeness. The audit server takes them every minute, checks domain and self-assessment, fetches evidence itself, downloads the release itself, tests it in the isolated lab and writes every step, signed, to the case log. Program code decides measurable criteria by the thresholds of the catalogue.
An auditor of be next GmbH. Opens the case after the application, reads terms and documentation, decides on disputes and signs award, refusal and suspension. No interface and no agent can trigger these steps.
| Step | Your agent | NOCIP systems | Person at NOCIP | Decided by | Duration |
|---|---|---|---|---|---|
| S0 Access | active | active | active | person at NOCIP | once; reply by e-mail |
| S1 Prove the domain | active | active | program code | 1 to 2 minutes | |
| S2 Self-assessment | active | active | program code | at once and after about 2 minutes | |
| S3 Evidence and connection manifest | active | active | program code | 1 to 2 minutes | |
| S4 Test target | active | active | program code | depends on the file size, usually under 5 minutes | |
| S5 Technical test in the lab | active | active | program code | a few minutes (LexITanon: under one minute) | |
| S6 Review of the documents | active | active | person at NOCIP | working days, depending on the scope | |
| S7 Findings | active | active | only when needed | program code | minutes; with a person, working days |
| S8 Draft report | active | active | active | program code | 1 to 2 minutes |
| S9 Award | active | active | person at NOCIP | working days | |
| S10 Seal and disclosure | active | active | only when needed | program code | ongoing |
| S11 New versions | active | active | only when needed | program code | a few minutes |
active only when needed
A person at NOCIP is planned in four steps: access, review of the documents, draft report and award. In three more only when needed: on a dispute, when a re-check is not green, and when checking the disclosure. Everything else runs without waiting.
A person of your company applies through the contact form (topic “Application for an audit”): product, tier, domain(s), contact.
Creates the case, pins the catalogue version (with SHA-256), creates the domain code and keeps only the hash of the token. The first case log entries are signed.
Checks the company (commercial register) and the contact once, opens the case and sends case number and token by e-mail.
Sets the DNS TXT record _nocip.<domain> with the code, or puts it as domain_proof into https://<domain>/.well-known/nocip.json, then prove_domain.
Queries DNS and the file and records the result. It then fetches the connection manifest of the domain.
not involved
Sends the self-assessment as JSON: one answer per criterion of the tier, the AI functions with their location, the index points claimed, evidence as an address or file hash.
At once: missing criteria, wrong tier or catalogue version (answer 422). Within about two minutes: schema, contradictions (e.g. Gold with an AI function outside the customer), answers “no” or “partly” as findings; every address named is fetched.
not involved
Names further evidence (address or file up to 25 MB) and publishes the connection manifest at /.well-known/nocip.json: every destination with purpose and frequency (I-5).
Fetches every address itself and keeps a snapshot with SHA-256. Checks the manifest against the schema and against the tier.
not involved
Names the release: public download address (or one behind a login, through an uploaded header line), SHA-256, size and how the program starts without its interface and processes a document.
Downloads the file itself and compares checksum, size and, if given, the published checksum. A file sent by the agent is never tested.
not involved
Requests the test (at most 5 a day).
Starts the program in an isolated network. Every connection attempt is recorded, every name lookup answered and noted. A test corpus with canary values generated for the case is processed; then all files and output of the program are searched for the canary values, and the destinations compared with the manifest. Result for G-01, G-02, C-04 and C-06.
not involved
Nothing; questions come as findings.
Provides the stored snapshots with their checksums. Planned: an AI model that runs at NOCIP itself prepares the review with verbatim quotes; program code checks that every quote is in the snapshot.
Reads terms, privacy policy and documentation for C-01, C-02, C-03, C-05, C-07, C-08 and the index groups, enters result and reasons (German and English) and raises findings.
Answers every open finding: “fixed” (with a new version or document), “evidence” or “dispute”.
Checks newly sent statements and tests new versions; what no longer applies is closed automatically.
Becomes active on a dispute, after the third answer to the same finding and for findings from the review of the documents.
Can read the draft (German and English).
Builds the draft audit report from the case log: tests, result per criterion, index, open points. The draft is marked as such.
Triggers the draft once the review of the documents is finished.
Nothing.
Allows the award only if every criterion of the tier is passed, every index group is scored, no blocking point is open and the last test of the current release is green. Then builds audit report, certificate, seal and register entry.
Reads the result and the differences between statement and measurement and signs at the audit server with a typed confirmation: award, or refusal with reasons. The register entry appears with the next update of nocip.com.
Fetches seal, badge and HTML code (get_seal) and states the tier and where the AI runs on the website and in the documentation (C-01).
The badge always shows the state of the register; the verification page detects whether it is embedded on a registered domain. Planned: automatic check of the statements after 7 and 30 days.
Checks the disclosure at re-checks.
Announces every new version before its release (C-05): test target, release notes and whether the AI architecture changes.
Downloads the new version and tests it. Green and no change to the AI architecture: the label also covers this version (register entry with the next update). Red, a new connection or a changed AI architecture: a suspension proposal to the auditor.
Decides only if the re-check is not green or the AI architecture changes.
| MCP tool | REST | Purpose |
|---|---|---|
get_status | GET /cases/{case} | state of the case and next steps |
prove_domain | POST /cases/{case}/domain-proof | have the domain proof checked |
submit_self_assessment | POST /cases/{case}/self-assessment | send the self-assessment |
add_evidence | POST /cases/{case}/evidence | evidence: address or file |
set_test_target | POST /cases/{case}/test-target | name the release to test |
request_test | POST /cases/{case}/test-runs | request a lab test |
list_findings | GET /cases/{case}/findings | read the findings |
answer_finding | POST /cases/{case}/findings/{id}/answer | answer a finding |
get_case_log | GET /cases/{case}/log | signed case log |
get_report_draft | GET /cases/{case}/report-draft | draft report |
get_seal | GET /cases/{case}/seal | seal and HTML code after the award |
notify_release | POST /cases/{case}/releases | announce a new version |
get_criteria | GET /criteria | criteria catalogue with SHA-256 (no token) |
withdraw | POST /cases/{case}/withdraw | withdraw the application |
MCP server: https://nocip.com/mcp/ · REST: https://nocip.com/api/v1/ · OpenAPI · for language models: llms.txt
Every entry has the fields seq, time, case, step, action, actor, inputs, data, prev, hash and sig. hash is “sha256:” and the SHA-256 of the entry without hash and sig, as JSON with sorted keys, no spaces, UTF-8. prev is the hash of the entry before (null for the first). sig.ed25519 is the Ed25519 signature of the text of hash with the public key of NOCIP.
import base64, hashlib, json
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
key = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))
prev = None
for i, ev in enumerate(events, 1):
body ={k: v for k, v in ev.items() if k not in ('hash', 'sig')}
raw = json.dumps(body, sort_keys=True, separators=(',', ':'), ensure_ascii=False).encode()
assert ev['seq'] == i and ev['prev'] == prev
assert ev['hash'] == 'sha256:' + hashlib.sha256(raw).hexdigest()
key.verify(base64.b64decode(ev['sig']['ed25519']), ev['hash'].encode())
prev = ev['hash']Your documents, releases and test results stay on NOCIP's servers. No document goes to a cloud AI service. The test corpus with the canary values stays private and is different for every case. NOCIP keeps only the hash of the token; a new token makes the old one invalid.
No. The REST interface can be called from any build system or script, even by hand with curl. The MCP server makes it especially easy for an AI agent.
Any MCP client that supports Streamable HTTP with a header for the token, for example Claude Code. Everything else through the REST interface.
No. There is no tool and no call for it. A person at NOCIP signs award, refusal and suspension.
Yes: the same criteria, audit checklist, audit report and label. The signed case log comes on top.
Nothing, like the way “With documents”.
Then we audit with documents for now; you can still send the self-assessment and evidence through the interface. The lab for Windows, macOS and cloud services follows.
Everything on this page, plus set-up, formats with examples and verifying the case log: to pass on to your team or your agent.