Security

1. API key handling

LLMtrack API keys are created for ingesting usage events.

Raw API keys are shown only once at creation. After creation, LLMtrack stores protected verification data, such as hashed key values and key prefixes, instead of storing the raw key in plain text.

Users should copy their key at creation time and store it securely.

If a key is exposed or no longer needed, users should deactivate or delete it.

2. Deactivating and deleting keys

Users may deactivate an API key to stop it from receiving data without permanently removing the key record.

When a key is deactivated:

• the key can no longer ingest data
• historical usage data remains available according to plan and retention rules
• the key can be reactivated if needed

When a key is deleted:

• the key is permanently removed from key management
• future requests using that key fail
• the raw key cannot be recovered

3. Data sent to LLMtrack

LLMtrack is intended to store usage analytics, not confidential application payloads.

Typical event data includes:

• provider
• model
• feature name
• token counts
• cost
• latency
• status
• timestamp
• optional metadata

Users should not send passwords, private keys, payment card data, sensitive personal data, or confidential prompt/completion content unless they intentionally choose to do so and understand the risk.

4. Workspace isolation

LLMtrack uses workspace-based access controls so users can only access data belonging to their own workspace.

API keys are associated with workspaces. Incoming events are assigned to a workspace based on the authenticated key, not on user-provided workspace values.

Client-provided workspace identifiers should not be trusted for authorization.

5. Transport security

LLMtrack should be accessed over HTTPS.

Users should send API requests to:

https://llm-track.com/api/ingest

Do not send API keys or usage events over insecure connections.

6. Access controls

Access to production systems and user data should be limited to what is necessary to operate, maintain, and secure the service.

Administrative access should be protected with strong credentials and least-privilege practices.

7. Data deletion and retention

When users delete data, LLMtrack removes it from active product systems where it is used to provide the service.

Backups, security logs, or infrastructure-level records may remain for a limited operational period according to backup, security, and legal retention practices.

Deleted data is not used as active product data.

8. Security responsibilities of users

Users are responsible for:

• keeping their account credentials secure
• protecting API keys
• avoiding public exposure of API keys
• not sending unnecessary sensitive data
• deleting or deactivating compromised keys
• reviewing who has access to their workspace

9. Incident response

If we become aware of a security issue affecting user data, we will investigate and take appropriate action.

Depending on the nature of the issue, we may notify affected users through the dashboard, email, or other reasonable communication channels.

10. Reporting security issues

To report a security concern, contact:

support@llm-track.com

Before publishing, verify that support@llm-track.com is configured. If it is not configured, ask the project owner for the correct security contact before deployment. Do not publish a fake or unreachable contact email.