Skip to content

What we do with your code, and what we will not claim

This page describes controls and commitments rather than certificates. Everything below is a property of the system you can point at, or a commitment we are answerable for — and where we do not hold an attestation, we say so instead of implying one.

Submitted source is parsed, scored and discarded

The four questions a reviewer asks first: is it stored, where does it go, how much of it is sent, and is it bounded. The short answers are no, to a model for the length of one request when a model pass runs, as little as the task needs, and yes.

  1. Submitted source is discarded with the response

    The contract sandbox parses and scores your source inside the request handler and returns the result with the response. There is no database, no queue and no object store behind these routes, and no log line is written that contains submitted source. Nothing is persisted server-side and nothing is kept for training.

  2. When a model pass runs, the request is the only place the text goes

    If this deployment has a model key configured and you run the review or triage-notes pass, the text is sent to the Anthropic API for that request and is not retained by this application. The request goes to the commercial API, whose terms state that API inputs and outputs are not used to train models by default. Read their terms rather than this summary of them.

  3. What is sent is bounded, and a truncation is marked

    Source is clipped to 14,000 characters before it is placed in a prompt, and the prompt states when it was cut, so the reviewer is never reasoning about a silent truncation. The clip is a ceiling on the request, not a licence to send more than the task needs.

  4. Every request body is bounded before it is parsed

    Each engine route refuses a raw body larger than 256 KB before it parses anything, and each engine applies its own ceiling: 60,000 characters for a source file, 40,000 for a bug report. A route that reads unbounded input from an anonymous client is a denial-of-service surface, so the limit is enforced first.

  5. Nothing identifies you

    These routes set no cookie and identify no visitor. The application loads no analytics, advertising or third-party script, so using the sandbox does not create a record anywhere that you visited it.

Why the web scanner sends no traffic

The web posture tool is a labelled simulation. It accepts a hostname, derives a stable report from an FNV-1a hash of that name through a seeded generator, and never opens a socket. That is not a limitation to be worked around — it is the correct behaviour for a public endpoint, and it is worth explaining why.

The tool would become the vulnerability

If this endpoint accepted a visitor-supplied URL and issued requests to it, anyone could point our infrastructure at any host on the internet and have us scan it for them. That is unauthorised scanning, performed from our addresses, attributed to us, with no authorisation from the target.

It would be a server-side request forgery primitive

A URL parameter that the server fetches is the textbook SSRF shape. Aimed at a link-local metadata address or an internal service name, it would let a stranger use this application to reach networks they cannot reach themselves. The safe public behaviour is to fetch nothing.

So the report is derived, not observed

Because results are seeded from the hostname, the same URL always produces the same report, which is what makes the demonstration legible rather than random. The response carries a notice field saying it is a simulation, and the interface shows it rather than hiding it in a footer.

Live scanning is an engagement, not a web form

Real web assessment runs against a scoped, contractually authorised target list under the rules of engagement below. A version of this tool that probed arbitrary hosts would not be a better demo; it would be a worse product.

Scope and rules of engagement

Live assessment happens only under two documents signed before any test traffic is sent: a scope agreement and a rules-of-engagement document. Together they answer the questions that decide whether a test is legitimate.

A named target list

The in-scope hosts, endpoints and assets, and an explicit out-of-scope list alongside them. If something is not named as in scope, it is out of scope.

Testing windows

The hours in which traffic may be sent, agreed with the people who run the estate, so a test does not land in the middle of an unrelated incident.

Rate limits and forbidden techniques

The request rate we will stay under and the techniques we will not use — denial of service, destructive actions, and social engineering unless it is separately agreed in writing.

An emergency contact and a stop condition

A named person who can stop the assessment, and the condition under which we stop on our own: a service becoming unstable, or any sign that a test is affecting production users.

Credentials for authenticated testing

Test accounts the client provides, used only for the engagement and revoked at its close. We do not use, and do not ask for, a real user account.

No third party without their consent

We do not test a third party, a shared provider or an inherited asset on the strength of the client relationship alone. Written authorisation from that party is a precondition, not a formality.

Repository access

For a code engagement we ask for the least access that lets us do the work — read-only, scoped to the repositories in scope, and revocable by the client without a conversation.

Read-only
We request read access to the named repositories. We never request production write access, and we will not accept it if it is offered.
Granted on the client own Git host
Access arrives through an installation the client approves on their own GitHub, GitLab or Bitbucket organisation. It is theirs to grant, and theirs to revoke.
Revocable without contacting us
The client can revoke the installation at any time from their own settings, and the pipeline loses access immediately. No email to us is required, and none should be.
Not cloned before the origin is proven
A scheduled run is triggered by a signed webhook, and the signature is verified before anything is fetched. A payload that fails verification is dropped without a response body.
Revoked at the close of the engagement
When the work ends, the installation is removed unless the client wants continuous monitoring, in which case it stays because it is still doing a job they asked for.

The controls the platform runs on

These are the operational properties an engagement inherits: least-privilege access, records that survive a review, and a defined authorisation boundary around every target. They describe how the work is done, not a certificate that it was.

Continuous posture tracking

A single score that moves as your estate changes, with the delta attributed to specific findings.

Least-privilege by default

Read-only repository scopes, short-lived tokens, and no source retained after the engagement closes.

Edge-native delivery

The deterministic engines run on Cloudflare Workers, at the edge closest to the reader. The reasoning pass runs in the Node runtime beside them.

Audit-ready evidence

Immutable finding history, remediation timestamps and closure letters for your next compliance review.

Cloud and on-prem targets

Assessments cover managed cloud, self-hosted and hybrid estates, including private networking paths.

Scoped and authorised

Every engagement runs under a signed scope agreement with an explicit rules-of-engagement document.

Reporting a vulnerability in this service

If you believe you have found a vulnerability in this application or in the infrastructure behind it, we would rather hear it from you than read it somewhere else. Report it and we will work it.

Include in the report

  • A description of the issue and the affected host or endpoint.
  • Steps to reproduce it, specific enough that we can follow them from a clean session.
  • Any proof of concept — a request, a payload, a script — that shortens the path to a fix.
  • How you would like to be credited, or a note that you would prefer not to be.

Send it to security@namada.site, and say in the subject line that it is a disclosure so it is routed to a person rather than a queue.

What we commit to

  • We will acknowledge your report and tell you whether we were able to reproduce it.
  • We will keep you informed as we investigate, and tell you when a fix has shipped.
  • We will credit you in the write-up if you want credit, and we will not name you if you do not.
  • We will not pursue legal action against research conducted in good faith, within the scope of this application, and without degrading the service or touching data that is not yours.
  • We will ask for a short period of coordinated silence so a fix can ship before the issue is public, and we will not extend that window without telling you why.
What we do not offer

We do not run a paid bug bounty programme for this service, and there is no payout table to quote. Reports here are welcomed on the terms above, not bought.

Attestations we do not hold

The fastest way to lose a technical reader is to claim a certificate you cannot produce. None of the following is claimed anywhere on this site, and each one was removed on purpose — the description of a control is checkable, while the name of an audit you have not had is not.

SOC 2
We do not hold a SOC 2 report and we do not claim one.
ISO/IEC 27001
We are not certified against ISO/IEC 27001, and we do not claim certification.
A third-party penetration test of our own infrastructure
We do not claim an independent test of this service has been performed.
A bug bounty for this service
There is no programme with a payout table. Disclosure works on the commitments above.

Ask the question this page does not answer

If a control you need is not described here, ask and we will tell you whether we have it, rather than let you assume.