Security & Data Handling

SecCheck is a security tool, so it is held to a security tool's standards. This page states plainly how it authenticates you, what it records, and what does — and does not — leave the Cert-IX perimeter.

Authentication & entitlements

• Every request to https://mcp.cert-ix.com/seccheck must carry a valid API key as Authorization: Bearer <key>. Requests without one get 401; the backend never sees unauthenticated traffic.
• Keys are free and self-service: request one at cert-ix.com/tools/seccheck-mcp, confirm your email address, and the key arrives by email. A self-service key is the Community edition, lasts 90 days, and can be renewed from the reminder email sent before it expires. Treat a key like a password: keep it in your MCP client's config or a secret store, never in source control, and rotate it if it may have leaked.
• All traffic is over TLS. Do not send keys over plain HTTP.

Your edition travels with your key, and this is the part worth understanding:

Entitlements are resolved at the edge, per request

The Cert-IX edge authenticates your key and then sets your entitlements on the proxied request — unconditionally, on every request, even when empty. A caller therefore cannot assert its own tier by sending entitlement information itself; whatever you send is overwritten before the backend sees it.

The server refuses to boot in hosted mode if a process-wide licence file is configured, because a single environment variable would otherwise promote every caller at once. Entitlements come from your key, one request at a time, or not at all.

If a tool returns a paywall error you did not expect, call license_status — it reports exactly what your credential unlocks.

Rate limits & abuse protection

The hosted endpoint enforces limits at the edge (host nginx), before any work is done:

Scope	Limit
Per API key	20 requests/second (short burst to 40), 20 concurrent connections
Per source IP	40 requests/second (burst 80), 40 concurrent connections

Per-IP limits are applied before authentication, so unauthenticated floods are bounded too.

Exceeding a limit returns 429 Too Many Requests with a Retry-After header. Honour it and back off exponentially; a well-behaved client should sit comfortably under 10 requests/second per key. These ceilings are far above normal agent use — a handful of searches and one or two loads per task — and exist to stop floods, not to throttle real work.

Repeated authentication failures are treated as abuse: an IP that produces many 401s in a short window is temporarily blocked (fail2ban). A valid key-holder never hits this, because a correct key never 401s.

What you send, and what happens to it

SecCheck's tools are read-only lookups against a fixed corpus. Here is exactly what each kind of input is used for:

You send	What SecCheck does with it
A search query and filters	Scores them against the in-memory catalog and returns matching playbook summaries.
A skill id	Returns that playbook's SKILL.md.
A skill id + resource path	Returns that bundled file, resolved strictly inside the skill's own directory.

You never send SecCheck your code, your logs, your findings, or anything about your environment — the tools take a query string and identifiers, and nothing else. The hosted server has no access to your filesystem and no ability to reach into your systems.

What operational data is kept

Two records exist, and both are deliberately narrow:

• Usage metering — aggregate per-tool and per-client call counts, for capacity and monitoring. A live gauge, not a billing ledger.
• An audit record per tool call, containing the tool name, the argument names only, your client label, your tier, and whether the call errored.

Search queries are never logged

The audit record logs that you called search_skills with a query argument — not what the query said. A search query is user input and can describe an incident in progress; recording the key without the value is what makes the log access-review evidence rather than a debug dump of your security posture.

Both are exposed only on an internal, token-gated /metrics endpoint that is never reachable from the public internet, and which fails closed — with no token configured it refuses to serve at all.

Data residency — where the content lives

For SecCheck, the answer is simple:

• The entire 857-playbook corpus is embedded in the SecCheck server and served from memory. Search, load and resource reads are all answered by the server that received the request.
• SecCheck makes no outbound calls to third-party services at query time. There is no upstream API, no fallback lookup, no telemetry to an external vendor — the same server answers with networking switched off entirely. Your query is answered on Cert-IX infrastructure and is not forwarded anywhere else.
• Your MCP client, and the AI model behind it, also see everything your agent sends and receives. That side is governed by your client and model provider, not by Cert-IX.

Want a fully offline deployment?

Run SecCheck locally over stdio — the binary carries the corpus and needs no network at all, which suits air-gapped and high-assurance environments. See Getting started → Option 2. The local build is not a public download today: talk to your Cert-IX account team.

Network posture (hosted)

• The endpoint is fronted by host nginx, which is the sole ingress and does the auth, rate-limiting, entitlement resolution and TLS termination.
• The SecCheck container is published to host loopback only, so it cannot be reached from the internet except through that nginx.
• The Go server refuses a non-loopback bind unless explicitly overridden, because the application layer has no authentication of its own — auth is the edge's job, and a wildcard bind would publish an unauthenticated MCP server.
• /seccheck is the only path exposed publicly for this server. Operational paths (/metrics) are internal-only.

Content integrity

An empty or partial corpus would be this product's version of a false-clean verdict: search_skills would return "no results" and a model would read that as "no such security work exists". The server therefore refuses to start in hosted mode with an empty catalog, and its health check reports unhealthy rather than serving one — a corpus-less image cannot pass deployment.

Licensing & attribution obligations

The playbooks are third-party content redistributed under permissive licences (Apache-2.0 and MIT), with all rights of the original authors retained.

• get_attribution returns the upstream, author, licence identifier, homepage and full licence text for every library.
• If you redistribute any playbook content — internally at scale, in a product, or in a deliverable to a client — reproduce those notices. Access through SecCheck does not change the underlying licence terms.

Compliance notes

• SecCheck processes search queries and document identifiers — technical input, not personal data. Query values are not retained.
• API keys identify a client/organisation, used for access control, entitlement resolution and aggregate rate accounting — not for profiling.
• The embedded-corpus design answers every query on Cert-IX infrastructure: SecCheck itself has no third-party lookup path to opt out of.

If you need a data-processing addendum or a residency guarantee for a regulated workload, talk to your Cert-IX account team about a dedicated or fully offline deployment.

Acceptable use

The library includes offensive material — exploitation, credential attacks, post-exploitation, web attack methodology. It is published for authorized security work: systems you own, engagements you have written permission for, CTFs, training environments, and defensive research.

Using it to attack systems you are not authorized to test is a misuse of the service and your liability. Cert-IX may revoke a key used that way.

Good practice checklist

• ✅ Store the API key in your MCP client's secret config, not in the repo.
• ✅ Rotate the key on staff changes or suspected exposure.
• ✅ Have the agent state it clearly when a search returns NO MATCH, rather than improvising a procedure (see Agent workflows).
• ✅ Read a playbook before running its commands — it is third-party guidance written for someone else's stack.
• ✅ Where the playbook has a verification or validation section, run it before calling the work done.
• ✅ Reproduce the attribution notices if you redistribute any content.
• ✅ Keep SecCheck as one layer — pair it with review, testing, and your existing controls.