Privacy Policy.

This policy explains — in plain English — what SentinelFX collects, why, how long we keep it, who sees it, and what you can do about it. It applies to everyone who interacts with the SentinelFX Discord bot, dashboard, in-game FiveM resource, and public website.

Effective: 25 April 2026  ·  Last reviewed: 25 April 2026  ·  Version 2.3

01Who we are

SentinelFX is a community-operated network protection service for FiveM and Discord. We operate:

• A Discord bot that provides moderation, raid protection, threat scoring, and network-wide ban enforcement.
• A dashboard (sentinelfx.net/dashboard) for server operators and SentinelFX staff.
• A FiveM FXServer resource that bridges in-game events to the SentinelFX network.
• A public website (sentinelfx.net) and its subdomains.

For the purposes of applicable data-protection laws, SentinelFX acts as the data controller for the personal data described below. You can contact us at any time via the methods in Section 17.

02What this covers

This policy covers personal data handled by the SentinelFX Discord bot, the SentinelFX API, the SentinelFX dashboard, and the SentinelFX FiveM resource (collectively, the "Service"). It does not cover:

• Discord itself. Your account, message history, and Discord settings are governed by Discord's Privacy Policy.
• Your own FXServer. Game data, logs, and player records stored on your FiveM server belong to you and are outside our control.
• Third-party sites. Evidence links (e.g. imgur, streamable) submitted with reports are hosted by those third parties under their own terms.

03Data we collect

We only collect what the Service actually needs to function. The categories below are exhaustive — if it isn't listed here, we don't store it.

3.1 Discord account data

• Your Discord user ID, username, and avatar hash.
• Guild (server) IDs where SentinelFX is installed, along with roles, channel IDs, and permission metadata needed to operate.
• Audit-log entries and moderation events (bans, kicks, timeouts, warns) issued through or observed by the bot.
• Message metadata (author ID, channel ID, timestamp) for anti-raid, anti-spam, and threat-scoring purposes. Message content is processed in memory only long enough to evaluate detection rules; we do not store a copy of your message history, and the bot does not read direct messages.

3.2 FiveM / in-game data

• Player identifiers reported by your FXServer: license, license2, steam, discord, fivem, xbl, live, and ip.
• Hardware fingerprint tokens issued by CFX/FiveM to each player. These are always collected by the FiveM resource and hashed server-side before transmission — raw tokens never leave your FXServer. They are used exclusively for cross-account ban-evasion detection, are never returned to operators in raw form, and are never shared with any third party.
• Display names (in-game nickname) at the time of an event.
• Event records: joins, leaves, bans, kicks, warns, periodic heartbeats, and player-count samples.
• Server metadata: FXServer display name, cfx.re code (if provided), the guild it belongs to, and its SentinelFX-issued server ID.

The FiveM resource is distributed through the official Tebex / CFX Asset Escrow channel. The CFX runtime checks at boot that the operator's Cfx.re account owns an entitlement to the asset; SentinelFX is not party to that check and does not see your Cfx.re credentials at any point. The resource's per-server signing secret is generated on the SentinelFX dashboard, shown once, and pasted into the resource's local config file by the operator — it is never transmitted through Tebex, never sent to CFX, and not embedded in any download.

3.3 Reports, reviews & network bans

• Content of reports you submit: the accused user, category, evidence URLs, and a narrative description.
• Staff review outcomes (approved, rejected, escalated), reviewer Discord ID, and timestamps.
• Network ban entries: the banned identifiers, the reason, the originating server, and the issuing staff member.
• Appeal submissions, their outcomes, and correspondence related to an appeal.

3.4 Authentication & session data

• Discord OAuth2 tokens (access and refresh) used to authenticate dashboard sessions. These are short-lived and stored encrypted at rest.
• A server-side session cookie identifying your authenticated dashboard session.
• The scopes you granted at login (typically identify and guilds).

3.5 Technical & operational data

• API request logs: IP address, user agent, endpoint, HTTP status, and a correlation ID. Used for abuse prevention and debugging.
• Error traces from the bot, dashboard, and resource, with personal identifiers redacted before long-term storage where feasible.
• Uptime, heartbeat, and player-count samples used to render the operator dashboard and the public status page.

04Where it comes from

05Why we process it

• Moderation & safety. Detecting raiders, scammers, cheaters, harassers, griefers, and ban evaders across the SentinelFX network.
• Network ban propagation. When a report is approved, distributing the ban to every connected server so the person is blocked everywhere at once.
• Identity linking. Merging a player's identifiers into one profile so a ban on any account applies to all their known accounts.
• Evasion detection. Matching hardware fingerprints so banned users can't return on alts.
• Operational visibility. Showing server operators live uptime, events, player counts, and review metrics on the dashboard.
• Appeals. Allowing users who believe they were wrongly banned to request a review.
• Service integrity. Preventing abuse, rate-limiting, diagnosing outages, and keeping the platform online.
• Legal compliance. Responding to lawful requests and meeting statutory record-keeping obligations.

06Legal basis

Where the UK or EU GDPR (or an equivalent framework in your jurisdiction) applies to our processing, we rely on the following legal bases:

07Automated & AI-assisted decisions

SentinelFX operates a hybrid auto-action engine that reviews new reports before they reach human staff. Most reports are handled by a deterministic rule engine that we control end-to-end; a minority of genuinely ambiguous cases are also reviewed by an AI model before any action is taken.

7.1 The deterministic rule layer (always on)

• Scores each report against fixed signals: machine-verified evidence (from anticheat or the FXServer bridge), corroborating reports from other servers, the target's prior ban and appeal history, the reporter's historical accuracy, account age, and rate limits.
• Very high scores may produce an immediate network ban with a built-in staff undo window. Scores in an ambiguous middle band may be flagged for fast-track review (one staff approval). Everything else goes to the normal review queue.
• Runs entirely on infrastructure we control. No report, identifier, or evidence leaves our systems as part of this layer.

7.2 The AI judge layer (invoked only on ambiguous cases)

When the rule engine's score falls into the ambiguous middle, a structured summary of the case is sent to Anthropic (our AI sub-processor) for a second opinion. The model returns a recommended action, a confidence value, and a short written reasoning. Hard safety rails apply:

• The AI cannot recommend an automatic ban without machine-verified evidence and corroboration — the same bar the rule engine enforces.
• The AI cannot override any protective gate: the target being staff, the system being paused, the reporter being flooded or untrusted, and targets with prior successful appeals all still bypass the AI entirely.
• An AI recommendation is only honoured when the model's confidence clears a published high-confidence floor; below that, the rule-engine decision stands.
• Network admins can disable the AI layer at any moment. With the AI off, the rule engine continues to operate unchanged.
• The model's reasoning is logged to the audit trail alongside every action it influenced and is visible to reviewing staff and to appellants through the appeal thread.

7.3 What data is sent to Anthropic

The payload sent to the AI judge is structured JSON containing only what's needed to score the report. It does not include raw chat logs, message histories, or Discord conversation content. Specifically:

• The report's category, reason text, and evidence preview (first 400 characters).
• The rule engine's preliminary score and the individual signals that fired.
• Reporter signals: total reports, approval rate, whether they are staff, recent auto-ban volume.
• Target signals: Discord account age, threat score and tier, prior network-ban count, whether their evidence was machine-verified, whether they have prior successful appeals.

Anthropic processes this data under a zero-data-retention contract: requests are not used to train their models, and inputs / outputs are not retained beyond what's strictly needed to return the response. See their Commercial Terms for their own commitments.

7.4 Your rights regarding automated decisions

Under UK / EU GDPR (Art. 22), you have the right not to be subject to a purely automated decision with legal or similarly significant effects. In practice:

• Every network ban is reviewable by a human. Even AI-influenced auto-bans are logged with a built-in staff undo window and are fully appealable afterwards — appeals are always reviewed by a human staff member, never by the AI.
• You can request that an action affecting you be re-reviewed by staff without AI involvement. Use the appeal form and state this in your appeal statement; we will honour it.
• The specific reasoning the AI gave for an action against you is available on request to the banned user via the appeal thread.

08Sharing & disclosure

In addition to the AI sub-processor disclosed in Section 7, SentinelFX operates a shared ban network by design. Some data-sharing between member servers is inherent to the product — we're transparent about all of it:

8.1 Ban propagation modes

When an FXServer is registered, its operator chooses one of three modes that control how in-game bans interact with the rest of the network:

An operator can change their mode from the dashboard at any time. The chosen mode is recorded with every event so context is never lost.

8.2 Within the network

• When a ban is approved (either by staff review or by auto mode), the resulting entry — identifiers, reason, category, and timestamp — is written to the network ban list.
• Every connected FXServer pulls the network ban list on a timer and enforces it locally. The list is identifier-keyed (license, steam, discord, fivem, xbl, live, hardware tokens) — not server-keyed — so a ban applies to the person across every server that has the resource installed, including servers they have never played on.
• Where the banned user has a known Discord ID, the bot also enforces the ban on every connected Discord guild that has auto-apply enabled. If no Discord identifier is known for the player, only the FiveM side of the ban is applied.
• The reporter's identity is visible to SentinelFX staff during review. It is not shared with other server operators or with the banned user.
• Evidence links you attach are visible to SentinelFX staff. If a link is publicly hosted (e.g. imgur), it is public by nature of where you chose to host it.

8.3 With server operators

• Operators can see events, player ledger entries, and review-queue items for their own server(s).
• When a player on their server has any identifier that matches a network ban, the operator sees the match, the network-wide ban reason, and the category — but not the original reporter or the evidence attached by other servers.
• Operators cannot browse the full network ban list or see data belonging to other servers.

8.4 With processors (sub-processors)

• Discord Inc. — the bot runs on the Discord platform; bot-to-user communication and guild-level actions transit Discord.
• CFX.re / Cfx.re Platform Services — the FiveM resource relies on CFX-issued identifiers and hardware tokens. Those identifiers are provided to our resource by the FXServer runtime; we do not query CFX directly. CFX also enforces the asset-entitlement check that gates the resource to the Cfx.re account that claimed it.
• Tebex (Overwolf Inc.) — handles distribution of the FiveM resource as a free CFX-escrowed asset. Tebex sees only the public details of an asset claim (the claimer's Cfx.re account); it does not see your SentinelFX dashboard data, server identifiers, or signing secret. The signing secret used by your FXServer is generated on the SentinelFX dashboard, never embedded in the Tebex download.
• Anthropic PBC — powers the AI judge layer of the auto-action engine described in Section 7. Only the structured case summary defined there is transmitted; content is not used to train Anthropic's models and is not retained beyond what's needed to return the response.
• Our hosting provider — operates the servers and database that run the API, bot, and dashboard. Data is encrypted in transit; sensitive secrets are encrypted at rest (see Section 10).
• Edge / CDN provider — TLS termination, caching, and DDoS protection for the public website and API endpoints. Only request metadata passes through this layer; application data is not retained by them.

All sub-processors are bound by their own security and confidentiality obligations. We do not sell your data, we do not share it with advertisers, and we do not use it to train third-party models.

8.5 Legal disclosure

We may disclose data where required by a valid legal process (a court order, subpoena, or equivalent lawful request). We review every request for scope and legitimacy, disclose only the minimum necessary, and will notify affected users where we are legally permitted to do so.

09Retention & deletion

We keep data only as long as it's useful to the purposes in Section 5, or as long as we're legally required to. The guiding targets below are what we aim for; exact periods may vary where an active investigation, appeal, or legal hold makes short-term retention impractical.

10Security measures

We treat every piece of data as if it were our own. The safeguards below are what the Service is actually built with — not aspirations.

• Encryption in transit. All connections to the API, bot, dashboard, and FiveM resource use modern TLS. Plain-text fallbacks are not accepted.
• Encryption at rest for secrets. Webhook signing secrets are encrypted in the database using authenticated encryption. The encryption key lives outside the database in the application's environment, so a database snapshot alone is not enough to unlock them.
• Signed payloads. Every request from an FXServer carries a cryptographic signature tied to that server's secret. Unsigned, tampered, or replayed payloads are rejected before the event handler runs.
• Outbound-only resource. The FiveM resource opens no inbound ports. Installing it does not expose your game server to the public internet in any new way.
• Per-server isolation. Each FXServer has its own unique signing secret. A compromise on one server cannot be used to forge traffic for another.
• Secret rotation. Operators can revoke and reissue their FXServer signing secret from the dashboard at any time. The old secret is invalidated immediately.
• Rate limits. Every public endpoint is rate-limited, both inbound and outbound. The resource cannot accidentally flood the API, and the API cannot be turned into an amplifier against your server.
• Least-privilege access. SentinelFX staff only see data relevant to their role. Network ban approvals, lifts, and appeal decisions are recorded with the responsible staff member's ID for audit.
• Backups. Backups are encrypted and kept only as long as needed for disaster recovery.
• Incident response. Where a confirmed personal-data breach occurs and notification is required by applicable law, we will notify affected users and the relevant supervisory authority within the statutory deadline (in the UK/EU, that's 72 hours of becoming aware).

11Your rights

Depending on where you live, you may have some or all of the following rights:

• Access. A copy of the personal data we hold about you.
• Rectification. Correction of inaccurate or incomplete data.
• Erasure ("right to be forgotten"). Deletion of your data, subject to exceptions such as active ban enforcement or legal retention.
• Restriction. Asking us to pause processing while a dispute is resolved.
• Objection. Objecting to processing based on legitimate interests.
• Portability. Receiving a machine-readable copy of data you provided to us.
• Withdraw consent. Where we rely on your consent, you can withdraw it at any time (this does not affect prior lawful processing).
• Complain. To your local data-protection authority (in the UK: the ICO, ico.org.uk).

To exercise any of these rights, contact us (see Section 17). We respond within 30 days and never charge a fee for reasonable requests.

12Appeals, removal & fresh-start

If you believe you've been banned in error, you can appeal. Appeals are reviewed by SentinelFX staff against the original report, any new evidence you provide, and network-wide history — and, where an AI judge participated in the original action, the appeal is always reviewed by a human without AI involvement. Where an appeal succeeds, the ban is lifted across every connected Discord server and every FXServer running the resource. Appeal instructions are shared in our support server.

Erasure requests (to remove your personal data entirely) are handled through the same contact channels. An active network ban may prevent full erasure until the ban is lifted or expires — in those cases we keep the minimum data needed to enforce the ban and remove the rest. We'll explain clearly which records we can remove and which we cannot, and why.

Fresh-start profile wipes. In cases of demonstrable exoneration — for example, after an investigation concludes a ban was issued against the wrong person, or as part of a community's own internal clean-slate policy — network admins can perform a profile wipe: every moderation record for that user (warnings, reports filed against them, reports they filed, appeals, auto-actions, reputation, active network ban, per-guild ban log) is deleted and any active ban is lifted across the network. FiveM identity data, Discord server memberships, staff tags, and the immutable staff audit trail are preserved. Every wipe is audit-logged with the performing admin's identity and a written reason, and announced to the staff server.

13Cookies & tracking

The public marketing website uses no third-party analytics, advertising, or tracking cookies. The dashboard sets a single first-party, httpOnly, secure, SameSite=Lax session cookie used solely to keep you logged in. We do not use fingerprinting, pixel trackers, or cross-site advertising identifiers on our websites.

The FiveM resource does read hardware fingerprint tokens inside your game server for evasion detection (see Section 3.2). These tokens never leave the SentinelFX network and are not used for advertising.

14Children

SentinelFX is not directed at children under 13 (or the minimum digital-consent age in your jurisdiction, whichever is higher). We do not knowingly collect data from children. If you believe a child has provided us data, contact us and we will delete it promptly.

15International transfers

SentinelFX serves a global FiveM community. Our sub-processors (notably Discord and our edge / CDN provider) operate globally, so data may be processed outside your country of residence. Where a transfer is subject to data-protection law, we rely on the lawful transfer mechanisms available to that provider — typically an adequacy decision or Standard Contractual Clauses — to ensure an equivalent level of protection.

16Changes to this policy

When we make material changes to this policy, we will update the "Effective" date at the top and announce the change in our support server and on the dashboard. Continued use of the Service after a change constitutes acceptance of the updated policy. Minor clarifications (typos, formatting, non-material wording) may be made without notice.

17Contact us

The fastest way to reach us is through our Discord support server. For formal privacy or data-protection requests, write to privacy@sentinelfx.net. For security vulnerabilities, please use the responsible-disclosure channel set out in our security.txt.