> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-products/build-security/what-an-attestation-publishes.md).

# What an attestation publishes

An attestation exists to be shared. Its value is that someone else — a customer, an auditor, a downstream consumer — can inspect it and decide whether to trust your artifact. That usefulness and its privacy cost are the same property: the more an attestation says about how a build ran, the more it says about the machine it ran on.

This page describes exactly what SALT records, who can read it, and how to control both.

### The attestations registry is readable by anyone

When SALT uploads a signed attestation to the Xygeni attestations registry, **reads are anonymous**. This is deliberate: a third party verifying your artifact is not necessarily a Xygeni subscriber, and requiring them to authenticate would defeat the purpose of publishing provenance at all. Uploads are authenticated; retrieval and search are not.

Two consequences worth planning around:

* Anyone who has an entry's digest can download the full attestation, and search by artifact digest is open as well.
* **There is no delete operation.** An uploaded attestation cannot be retracted by you or by us. Treat every upload as permanent and public.

If that is not what you want for a particular build, do not upload it — see [Choosing what to publish](#choosing-what-to-publish) below.

### What the predicates contain

Beyond the artifact digests in the statement's `subject`, two SALT predicates describe the build machine and the source revision.

#### Environment predicate (`xygeni.io/attestations/environment/v1`)

| Field       | Contains                                           |
| ----------- | -------------------------------------------------- |
| `hostname`  | The build machine's host name                      |
| `username`  | The account the build ran as                       |
| `shell`     | The `SHELL` value                                  |
| `os`        | Kind, architecture and version                     |
| `variables` | Environment variables, filtered as described below |
| `timestamp` | When the predicate was generated                   |

On a hosted CI runner these are generic (`runner`, an ephemeral host name). On a developer workstation they identify a person's machine. If you generate attestations locally, that is worth knowing before you upload.

#### Git predicate (`xygeni.io/attestations/git/v1`)

| Field                                          | Contains                                                   |
| ---------------------------------------------- | ---------------------------------------------------------- |
| `repositoryURL`                                | The remote the working copy came from, credentials removed |
| `commitHash`, `treeHash`, `parentHashes`       | The revision and its ancestry                              |
| `refs`                                         | Branches and tags pointing at the commit                   |
| `commitMessage`                                | Subject and body, on one line, credentials masked          |
| `author`, `authorEmail`, `commitDate`          | Commit authorship                                          |
| `committer`, `committerEmail`, `committerDate` | Committer, when it differs from the author                 |
| `signature`                                    | Commit signature status, signer and key ids, when signed   |

Commit identity is published as-is. It is not treated as a leak: authorship is the substance of source provenance, and it is already visible to anyone who can read the repository.

### What is filtered, and what is not

SALT removes credentials from the places they are most likely to appear:

* **Environment variables.** Variables are dropped when their name appears in a shipped list of known credential variables, or when the name contains `TOKEN`, `PASSWORD`, `SECRET`, `CRED` or `KEY`. Values that survive have any `user:password@` credentials in URLs masked, and are truncated. If the list of known credential variables cannot be read, **no variables are recorded at all** rather than recording them unfiltered.
* **The repository URL.** A checkout token embedded in the remote — as CI systems routinely leave behind — is removed. A remote that cannot be parsed is masked rather than published.
* **The commit message.** Recognisable credentials are masked, keeping the rest of the message intact.

Filtering is **best effort, and you should not rely on it alone.** It recognises credentials by well-known formats and by the words around them, which means:

* A variable holding a secret under a name none of the rules match is recorded.
* An opaque token with no distinctive format and no adjacent keyword is not recognised.
* A secret pasted into a commit message in an unusual form may survive.

The reliable control is not to expose the secret to the build in the first place, and to review what a predicate contains before publishing from an environment that holds credentials.

### Choosing what to publish

Attestation generation and publication are separate steps, so you can keep one without the other.

* `--no-upload` generates and signs the attestation but does not send it to the registry. You keep the signed file and can publish it wherever you choose, or not at all.
* `--no-result-upload` suppresses the upload of build and provenance results to the Xygeni platform.

To inspect an attestation before deciding, generate it with `--no-upload` and read the predicate; the payload is base64-encoded JSON inside the envelope. `salt registry get` retrieves an entry already in the registry.

### Presence in the registry is not proof of authenticity

An attestation is trustworthy because its signature verifies against a key or certificate chain you accept — never because it was found in a registry. The registry stores and indexes what it is given; it does not vouch for it.

When you verify, verify the signature:

* Check the DSSE signature against keys you supply, or against a certificate chain you have validated.
* Confirm the `subject` digests match the artifact you actually hold.
* Confirm the `predicateType` is the claim you intended to check.

`salt verify` performs these checks. Do not substitute "the attestation is in the registry" for any of them.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.xygeni.io/xygeni-products/build-security/what-an-attestation-publishes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.