# NADILI: Security Source: https://manaienko.com/projects/nadili/security/ Author: Artem Manaienko # Access, abuse _and data boundaries._ I define access, public request limits and record expiry. The API and jobs enforce these rules. **Access:** Token verification and authorization **Abuse:** Rate limits and provider admission **Retention:** Bounded deletion and audit counts Explore a security boundary 01 Identity and tenancy **A valid token is only the first check** **Access**02 Public endpoint controls **Bound requests before expensive work** **Abuse**03 Data lifecycle **Retention runs as bounded product work** **Retention** Implemented controls. Deployed privacy evidence remains a launch requirement. Identity and tenancy ## A valid token is only the first check The API verifies the signed token and client binding, then maps the identity to internal records. Workspace access and private application access use separate checks. ### The authorization chain **Token:** Verify the signature, issuer, required claims and client binding. **Identity:** Map the provider identity to an internal user. **Workspace:** Resolve an accessible workspace; scope owned data to it. **Role:** Check the account role separately from workspace permissions. ### Workspace ownership does not grant private application access Workspace admin access and account admin access use separate checks. A workspace permission cannot become an unrelated application privilege. Inspect the client-binding and role boundary The verifier checks the configured client binding after cryptographic verification against the issuer. A valid signature is insufficient when the binding is wrong. The workspace selector chooses among workspaces the identity may access. It does not grant membership. Authorization failures keep bounded audit metadata and omit token contents. Public endpoint controls ## Bound requests before expensive work Public requests use separate rate-limit namespaces for traffic, abuse probes and writes. Search embedding and reranking also have admission gates before provider work. ### Controls at different boundaries **Client:** Resolve client identity through the configured trusted-proxy boundary. **Request:** Apply shared limits with separate traffic and abuse buckets. **Provider:** Admit embedding and reranker calls within their execution budget. **Email:** Use confirmation and cooldown rules for public follow requests. ### Forwarded headers are not automatically trusted Client IP resolution checks the socket peer against trusted proxies first. An untrusted peer cannot choose its rate-limit identity with a forwarding header. What happens when shared coordination is unavailable? The shared rate-limit backend has an explicit unavailable outcome. A process-local backend exists for local and test use, and for the configured single-worker fallback. It is not a global counter. Search keeps its own admission and deadline boundary. An embedding failure can drop the vector contribution while leaving lexical retrieval available. Failed reranking falls back to strict lexical results, as described in Applied AI. Data lifecycle ## Retention runs as bounded product work Public-data retention uses workspace-scoped database operations. A job processes bounded batches, records aggregate counts and completes in the same transaction. ### Records with explicit lifecycle rules **Requests:** Expire unconfirmed and terminal verification requests; close old unresolved ones. **Follows:** Remove expired unconfirmed or unsubscribed Country and Path records. **Consent:** Delete consent receipts according to their retention policy. **Audit:** Record operation counts instead of copying deleted personal data. ### Deletion and job completion commit together The retention service checks that the job still owns its lease before deleting. It applies the batch, records counts, marks the job successful and commits in one transaction. Where the implementation stops and launch evidence begins The repository selects records by status, age and workspace with a limit per operation. The default is 100 records, so retention is bounded. Processing registers and privacy runbooks describe the procedure. Deployed settings, processor arrangements and owner-completed launch evidence remain separate checks. These files do not prove blanket compliance. [Back to all six areas](https://manaienko.com/projects/#scope-overview-title)[Next: Operations ↗](https://manaienko.com/projects/nadili/operations/)I design and integrate the product, with coding agents supporting implementation.