> For the complete documentation index, see [llms.txt](https://sonic-ai-works.gitbook.io/sonic-networks-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sonic-ai-works.gitbook.io/sonic-networks-docs/sonic-1.0.0-rc-production-architecture/security-and-access.md).

# Security & Access

SONIC r30 authorization, key rotation, wallet proof, receipt integrity, public trust keys, secret isolation and secure documentation policy.

SONIC applies least privilege across users, applications, administrators, providers, signers, workers, and chain execution.

## Authorization layers

```
authenticated principal
→ account / workspace membership
→ role
→ permission
→ resource state
→ environment / cluster policy
→ authentication assurance / risk
→ authorize(action, resource)
```

`OWNER`, `ADMIN`, and `TOKEN_MANAGER` may administer Token Sale releases, but role membership never bypasses release state, cluster policy, activation-signature verification, terms acceptance, quote verification, or audit requirements.

## Public trust vs secret signing material

r30 separates verification material from signing material:

| Material                         | Public? | Surface                     |
| -------------------------------- | ------- | --------------------------- |
| Sale Release Ed25519 public keys | yes     | `/api/v1/trust/keys`        |
| Receipt Ed25519 public keys      | yes     | `/api/v1/trust/keys`        |
| public key fingerprints          | yes     | `/api/v1/trust/keys`        |
| quote HMAC secrets               | **no**  | server secret store only    |
| signer bearer tokens             | **no**  | service secret store only   |
| private Ed25519 keys             | **no**  | external signer / KMS / HSM |
| legacy receipt HMAC secrets      | **no**  | migration-only secret store |

## Wallet proof is not payment authorization

Wallet control uses a nonce-bound, domain-bound, cluster-aware message. A verified wallet link proves control of the address for the authenticated SONIC account; it does not authorize a transaction and must not silently switch the authenticated account.

## Receipt integrity

Production receipt signatures use Ed25519 through an external signer. The worker verifies the returned signature before persistence. The receipt verification route recomputes the deterministic hash and selects the verification key by `receiptKeyId`.

## Secret handling

Never publish or capture private keys, seed phrases, `.env` contents, session/access/refresh tokens, quote HMAC keys, signer credentials, legacy receipt HMAC secrets, service credentials, provider API keys, Payment Kernel credentials, billing webhook secrets, storage secret keys, or raw payment credentials.

`.env.example` contains variable names and safe placeholders only.

## Audit evidence

Audit records capture workflow, actor, action, cluster, policy decision, and outcome while avoiding secret material. The tamper-evident database hash chain remains audit evidence; it is not represented as blockchain notarization.

{% hint style="warning" %}
`design ≠ configured ≠ built ≠ tested ≠ deployed ≠ verified ≠ activated ≠ live`.
{% endhint %}


---

# 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://sonic-ai-works.gitbook.io/sonic-networks-docs/sonic-1.0.0-rc-production-architecture/security-and-access.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.