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

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.