Security & data handling

How logcat.ai handles access and your data. An EU-hosted deployment is available on request. For compliance specifics (certifications, data residency, DPAs), email sales@logcat.ai.

Authentication

Several sign-in methods, all standard:

• Google OAuth and email/password for the console. Local passwords are stored hashed, never in plaintext.
• API keys for programmatic access. They’re generated per user, returned once, and stored only as a hash (the platform can’t recover your key, so treat the one-time value as a secret and rotate by revoking). Keys carry a fixed expiry.
• JWT session tokens for the web app, including WebSocket connections.
• Enterprise SSO over OIDC, with optional enforcement. See Teams, enterprise & SSO.

Access to the console and API is gated by these mechanisms.

Data at rest

• Uploaded files are stored in object storage and served over signed, expiring URLs, not public links.
• Credentials and keys are never held in plaintext. They’re stored hashed or in managed secret storage.
• All input is validated before it reaches the data layer.

Tenant isolation

Your uploads, and everything derived from them, stay scoped to your organization. Analysis produced for one organization is never reused for another.

Staff access to your data

In the console, our staff can read your organization’s data so they can support you. That includes downloading an uploaded file you deleted, while it is held (see Retention), and every such download is recorded.

Where your organization’s contract requires staff access to be controlled, staff need your approval before they open any source citations in the console, whether into a source tree you uploaded, source we hold for your organization, or the platform source we host, and before they open the findings, dashboards and investigation reports built on them. The approval governs what staff open in the console. When support needs to look, they send a request with a reason, and an owner or admin approves or denies it under Organization → Staff access (an account outside an organization decides in Settings). Every owner and admin is notified in the console when a request arrives and when staff first use an approval, and by email too where your deployment sends email.

An approval covers your organization’s data, not only the account the request names. When the data staff need involves more than one organization that requires approval, such as an account that moved between them, every one of them has to approve. Staff can never approve a request themselves. Only an owner or admin who held that role before the request was made can approve it; a role our staff assigned, and an account outside an organization, can approve only once it is a week older than the request. A request for an account that has since moved to another organization ends.

An approval lasts at most four hours, and you can revoke it at any time. A revocation stops staff reads in the console at once. Every read made under an approval is recorded.

In EU deployments an approval is needed before staff can read any of your organization’s data through the console or staff tools, whatever source it cites, deleted uploads included, and a revocation reaches staff tools reading under the approval within 5 minutes. Staff can still see the account directory, limited to each account’s name and organization, so they know whom to ask, along with platform-wide counts and the messages you send us through the contact form. Approvals govern what staff read through the product. Access by the people who operate the infrastructure your deployment runs on is governed by your agreement with us.

Retention

An uploaded file stays in your workspace until you delete it. Deleting it removes it from your account, though the upload still counts against your storage allowance for the current period (the allowance refills on your reset date).

Deleted content is held for a while and is then destroyed for good. While it is held, uploaded files can be returned on request, without their analysis, and staff can read and download a deleted upload as they can the rest of your data (Staff access); deleted reference files and source trees cannot be returned and are uploaded again instead. How long deleted content is held is set for each deployment and can be set for your organization by contract: either until we destroy it on request, or automatically a set number of days after it was deleted, anywhere from 7 days to 10 years. Content you have not deleted is never removed on a schedule. Copies of destroyed content in our backups are removed as the backups rotate, within 32 days.

An organization can also be terminated, for example when its contract ends. Termination is a deliberate act by us, never automatic, and it can be reversed until removal begins, which is 14 days after the termination at the earliest. Removal then ends every membership in the organization, revokes the API keys issued for it, and destroys its content: its uploads and their analysis, its investigations, its reference files, its source trees, its fix proposals, its team spaces, its sign-in and alert settings, the feedback filed under it, and its deleted content. Platform source we prepared for the organization alone is removed with it. We keep the organization’s own record, its billing, usage and consent records, and the activity log. Each member’s own account and personal workspace are kept, along with anything filed there, including an investigation a member ran on their own uploads; an invitation that was never accepted is removed with the organization.

For formal retention terms, or to set a retention window, email sales@logcat.ai.

One thing is kept on purpose. A fix proposal is stored against the source location it was written for rather than against the capture that led you there, so deleting that capture does not remove it. What stays is the proposed change, the reasoning, and a short description of the finding that prompted it. It stays scoped to your organization, and it goes when the organization does.

Activity history

Your organization’s activity history (sign-ins, uploads, investigations, sharing and admin changes) is kept for 13 months, then deleted. A history that is already longer than that when this takes effect is trimmed over the following days, not all at once.

When an account is deleted through the product, its activity stays in the history so the record of what happened is complete, but the entries no longer name the person: the account’s ID is replaced with a pseudonym, its email address and the network addresses it acted from are removed, and so are the names it gave to captures on the entries that record its own actions or name it. Each entry keeps what happened, when, and which workspace it happened in. If the account had a personal workspace, that workspace is kept under a neutral name, so its entries still belong to it. Accounts deleted before this applied are treated the same way where the activity history recorded their deletion, found by their account ID, and by their email address where that record kept it. A deletion made before the activity history began on 3 July 2026, or one whose record is missing, is not reached.

An account ID or email address is matched only where it stands alone, never as part of a longer address or ID. A mention of one inside free text is removed, but it never makes an entry the account’s: that takes a field whose whole value is the account’s ID or address. Details nested inside an entry are removed only from a part that names the account by its whole ID or address, or that names no one; a part naming someone else is left as it is. Upper and lower case are treated as the same only for the letters A to Z, so an address whose other letters differ in case from the one on the account is not matched. A value that was shortened to the length limit when it was recorded can keep part of an address or ID.

These records still refer to a deleted account:

• usage and billing records, and feedback the account wrote, which are kept;
• retained copies of captures the account deleted, until an administrator purges them;
• entries other people recorded about the account’s captures without naming the account, which keep those captures’ names;
• our record of the deletion request, which keeps the account ID for 7 days after the deletion completes;
• database backups taken before the deletion, until they expire: within 30 days on the service we host, and on a self-hosted installation on the schedule its administrator sets;
• our service logs and error reports written before the deletion, until they expire;
• notifications already delivered outside the product, by email, chat or webhook;
• records of failed attempts to sign in as the account, which keep the network address the attempt came from, since it may not be the account holder’s.

Reporting a concern

If you believe you’ve found a security issue, email security@logcat.ai directly rather than filing it publicly. For anything about data handling specific to your organization, email sales@logcat.ai and we’ll walk through the details.