Security & Privacy

How Foxl keeps your data local, transparent, and under your control

Foxl is designed with a local-first architecture. Your data stays on your machine, your memory is transparent, and you control what the agent can do.

Core Principles

  1. Local execution: The agent runs on your machine (Mac, Windows, or Linux). Data does not leave your machine unless you explicitly use cloud services.
  2. Transparency: All memory is stored as readable markdown files. No hidden databases or opaque data stores.
  3. User control: You decide what the agent can and cannot do, per tool, in Settings > Safety.

Tool Permissions

A new install auto-approves every tool, on purpose. Read this before you leave it that way.

Foxl is a 24/7 agent on your own machine, so a confirmation dialog stops the work the app exists to do - and it stops it while nobody is watching. A scheduled run, a run you started from your phone, and a Slack mention all stall on a prompt with no one in front of the screen, and the tool call then times out and reads as a failure rather than as a question. So the shipped default is auto approve all tools, and the per-tool rules below take effect when you turn that off.

What it costs, stated plainly: anything the agent reads - a web page it fetched, a file in your workspace, a Slack mention, the body of an issue - can ask it to run a shell command, and there is no prompt in the way. If your machine holds work where that matters, turn auto-approve off in Settings > Safety and the shell routes go back to asking.

Turning it off sticks. It is seeded once per install, not re-applied on every launch, so an explicit off stays off.

One transition to know about: an install that predates this default - including one where you had already turned auto-approve off - receives it once on the next launch, because there was no record of your choice to preserve. Turn it off again and that decision is kept for good.

Each tool has a permission level, and these are what apply once auto-approve-all is off:

PermissionToolsBehavior
Auto-approvedfile_read, web_fetch, memory_save and memory_recall, reading and searching workspace files, code_search, conversation_searchRuns without asking
Asks firstexec (shell), terminal, process (background commands), file_write, browser, channel_send, writing or editing workspace files (workspace_memory_save, workspace_memory_edit)Asks before executing (can be set to "always approve" per tool)
Restrictedbrowser on financial sitesBlocked by default

Git operations run through exec, so they are gated by that row rather than by a rule of their own.

Seven routes that can change the machine, or reach past it, ask: running a command, opening a terminal, managing a background process, writing a file, driving the browser, sending a message or file to a chat channel, and writing or editing a workspace file - the files your system prompt is built from (SOUL.md, HEARTBEAT.md and AGENTS.md are refused by that tool outright; edit them on the Workspace page). Reading a terminal, polling a running command and fetching its log do not interrupt you, because those are how the agent watches work it already started. Typing into a terminal the agent did not open, and writing to or killing a background command, are gated too.

Custom tools are covered by the same rules. A custom tool that runs a shell command, evaluates JavaScript or writes a file is gated exactly like the built-in exec - the gate matches on a tool's name and used to treat an unrecognised name as allowed, so custom tools ran unattended even with auto-approve off. See Agent Tools.

Inbound channels deny by default, and that is independent of the switch above. A bot in Slack, Telegram or Signal can only reach the agent from a channel or a person you have added to the allowlist under Settings > Connect > Integrations > Channels - Slack per channel (with an optional allowed-users list), Telegram per user, Signal per phone number. An empty allowlist allows nobody, so auto-approve-all does not put a shell one stranger's message away.

Browser Security

  • Domain allowlist/blocklist: Configure which sites the agent can access
  • Financial site blocking: Banking and trading sites are blocked by default
  • Visual indicators: The Chrome Extension shows what the agent is doing in your browser
  • Every action is on the record: each browser action is a tool call, shown in the chat as it runs and kept with the conversation in the app's local database

Code Execution

The exec tool (shell command execution) has these limits:

  • Working directory restriction: Commands run in a designated directory
  • Timeout: Long-running commands are automatically terminated
  • A short deny list: four patterns are refused outright - rm -rf /, rm -rf ~, mkfs*, and dd if=... of=/dev/*
  • Approval rules: your own allow / ask / deny rules per tool, in Settings > Safety

The deny list is not a sandbox and must not be relied on as one. It is four literal patterns, matched as substrings anywhere in the command - so rm -rf /* and /bin/rm -rf / are caught, but ordinary variations are not: rm -fr /, rm -r -f /, rm -rf --no-preserve-root / and find / -delete all miss all four. exec runs as your user with your permissions; there is no container and no syscall filter. The thing that actually gates a command is the approval rule above, which is why the default in the callout at the top of this page is worth a decision rather than a shrug. Your own allow rules, by contrast, are exact: an "Always allow" on ls -la saves the rule exec(ls:*), which approves ls as a whole word followed by plain arguments - ls -la, ls /etc - and nothing else. lsof -i, ls; <anything>, ls | sh and ls $(...) are different commands and ask again. If the command you approved itself contains a shell operator (; & | < > $, a backtick, parentheses, a backslash or a line break), that one call runs and no rule is saved at all. A saved rule also never covers a call that brings its own environment variables, since those decide which program a command word runs - such a call falls back to asking.

Memory Privacy

All memory files are plaintext markdown stored locally:

~/.foxl/workspace/
  SOUL.md      # Agent personality
  USER.md      # Your preferences
  MEMORY.md    # General knowledge
  memory/      # Daily summaries

You can read, edit, or delete any file at any time. There is no encrypted or hidden memory - what you see is exactly what the agent knows.

Network Security

  • Localhost only: The agent server listens only on localhost. It is not accessible from other devices on your network.
  • Connection token: every request to the local API must carry a random token the app generates - fresh at each launch when the app starts the server itself, or minted once at install and kept in ~/.foxl/daemon.json (readable only by your user, beside the relay refresh token the service signs in with) while the background service is on, and wiped when you turn the service off. The token is required whatever the letter case of the path, and the comparison is constant-time.
  • No telemetry from the app: the Foxl desktop, iOS and Android apps send no usage data, crash reports, or analytics. Our websites (foxl.ai, docs.foxl.ai, app.foxl.ai, code.foxl.ai) use Google Analytics for page-view measurement, and only if you accept analytics cookies - see the privacy policy.
  • Sign-in on a phone is bound to the request that started it. The iPhone and Android apps mint a one-time value before opening the system browser and require it back on the foxl:// return, so a web page cannot hand the app someone else's session.

Code signing and updates

  • macOS builds are Developer ID signed, run with the hardened runtime and are notarized by Apple.
  • Windows builds are signed with a self-signed certificate, so SmartScreen shows Unknown publisher on a fresh download - see Troubleshooting. The updater still refuses an update whose publisher name is not Foxl AI.
  • Linux AppImages are unsigned.

Cloud Relay

The relay server at relay.foxl.ai handles:

  • Authentication: Sign in with Google, Apple, GitHub, or email (magic link); a password can be added afterwards as a second door onto an already-verified account - there is no sign-up with a password
  • Cross-device sync, the desktop tunnel, Channels and DMs, push notifications, and shared folders
  • Metering: machine time for Foxl Code work on Remote, and - on the accounts Foxl has enabled for it - the Notes Foxl Relay transcription engine. Model usage is metered only when hosted inference is on

It does not serve models right now. Foxl is free and the model access is yours to supply, so a completion request to the relay is refused with 409 hosted_inference_disabled - see Cost & model access.

What it stores. Your account, sessions, devices and push tokens; usage counters (token, request and transcription-second counts) rather than message text; the Channels and DMs you post to; the folders and docs you share; Foxl Code conversations, Task Documents and task events; the credentials you give Foxl Code's cloud agents (a Claude or ChatGPT subscription login, or a Kiro, Cursor or Anthropic API key), encrypted at rest; and an audit record of tunnel connections that is kept until you delete your account. It does not store your desktop conversations, your memory, your Notes transcripts or the provider keys you enter in the desktop app - those never reach it. The full list is in the FAQ below.

What it can read in transit. Since v0.6.27 your browser or phone and your desktop set up their own encryption with keys the relay never holds - ECDH P-256, one session per connected device, AES-256-GCM payloads, and since v0.6.28 the payload is compressed before it is encrypted, so a long conversation downloads about as fast as it did in the clear. Your desktop also has a permanent identity key, kept in ~/.foxl/tunnel-identity.json, so reinstalling the app leaves it in place; it changes when the ~/.foxl data folder is reset or the desktop moves to a new machine. Your browser or phone pins that key the first time it connects and refuses to set up the encrypted session if it ever changes, so after a device's first connection a swapped key is noticed rather than accepted. The short code derived from it (a safety number) is computed on both ends but is not yet shown anywhere for you to compare; today a changed key surfaces as a refused connection and a warning in the browser's developer console. The encryption covers terminal input and output, every API and file response, and the method and path of the requests your phone makes to your desktop. Four payloads, plus one identifier, are outside it, on purpose and for now:

  • notification previews, because the relay builds the push your phone shows;
  • the chat message you send from the phone or web app - its text, any images or documents attached to it, and the model name - which the app posts to the relay as plain JSON rather than inside the envelope. The app sends the current message only, so your earlier messages do not cross the relay on this path; a Foxl Code chat turn that runs its model on your desktop travels the same way and does carry the conversation so far;
  • a chat reply while it streams, and a file preview's raw bytes, which arrive over an HTTP response the relay holds open rather than over the encrypted socket (the request that asks for a preview names the file's path in the clear too);
  • the conversation id on a chat request, so a "reply finished" push can open the right conversation.

The encryption engages per device, and only when both ends can do it. A client that cannot complete the handshake is served in the clear instead, deliberately: the relay serves a spread of client versions, and a phone runs the web bundle that was signed into the app build you installed rather than the one on app.foxl.ai. The browser and phone side shipped in v0.6.27, so a browser tab, a phone app or a desktop older than that runs over TLS alone, and for that one session the relay reads everything in the list above as well - terminal output and what you type, every API and file response, and the method and path. Nothing stops working, and the other devices on the same desktop are unaffected. This is not a rare case: when this page was last measured, in September 2026, most clients that had connected in the previous week were still on builds older than v0.6.27.

So live chat through the relay is TLS-only, not end-to-end encrypted, in both directions: the relay can read what you send and what streams back, and it stores neither. Everything else, between two devices that have both completed the handshake, is protected from the network by TLS and encrypted with keys the relay never holds - and that list is gated: a check in CI holds the readable message types exactly against the code, so a type cannot join or leave it without a deliberate change. If that is not acceptable for your data, run the desktop with remote access off - and note that bring-your-own-key requests never involve the relay at all. See Desktop Relay for the per-message-type detail, #538 for the remaining envelope work and #965 for the chat request.

What this section used to say

An earlier version claimed end-to-end encryption before the software did it. It was then corrected to say the relay read everything it forwarded, which was true at the time. The encryption described above has since shipped, with the exceptions listed. All three versions are recorded here because the first was one you might have made a decision on.

Bring Your Own Key

When you use your own API keys (Settings > Model & provider), requests go directly from your machine to the AI provider. The Foxl relay is not involved. If you turn on Automatic fallback in the same pane, a turn that falls back is sent to the fallback model's vendor instead, so that vendor sees the conversation - the switch is off unless you enable it.

Supported providers for BYOK:

  • Anthropic (Claude API direct)
  • OpenAI (GPT-5.6 Sol, Terra and Luna, GPT-5.5, and the rest of the API catalog)
  • Google (Gemini)
  • Amazon Bedrock (your own AWS account)
  • OpenAI-compatible vendors with your own key: OpenRouter, DeepSeek, Groq, Z.ai, Kimi, Qwen, Together, Mistral, Fireworks, Perplexity, xAI, Cerebras, SambaNova, AI21, Hugging Face, MiniMax
  • Ollama, vLLM, LM Studio (local models, completely offline)
  • A subscription you already have: Claude Code (OAuth), OpenAI (OAuth, via Codex), Gemini CLI

API Key Storage

The desktop app's API keys are stored locally in its configuration - model keys and the Notes transcription keys (Deepgram, AssemblyAI, OpenAI, ElevenLabs) alike. The desktop never sends them to Foxl's servers - only to the respective AI provider when making API calls - and a transcription key is never handed to the browser or the phone either: the desktop opens the connection to the provider and passes the audio through. (The credentials you give Foxl Code's cloud agents are a different store: they live on the relay, encrypted at rest, so a task can use them inside its microVM - see Where does Foxl Code run.)

They are encrypted at rest with a random key kept in a separate protected file. Before v0.6.5 that key was computed from the machine name and the install path - both guessable by anyone holding a copy of the database file, so the encryption added nothing against a stolen backup. Existing keys are re-encrypted the first time they are read.

The endpoint that tests a key will only ever send your stored key to the address you configured. A custom address has to come with its own key; previously the address and the key were independent inputs, so a request naming an outside address and no key was answered with your stored key in plain text.

For maximum privacy, use Ollama with local models, and in Notes pick On device transcription (Apple Silicon Mac). Your conversations never leave your machine, no API calls are made, the audio of a recording stays on the Mac, and no credits are consumed.

Frequently asked questions

The questions a security review asks first, answered against what the software does today rather than what it is meant to do. Where a control has a limit, the limit is stated next to it.

Is Foxl secure?

Foxl is a local-first agent with several independent controls, and this page is explicit about the ones it does not have.

In place today:

  • The agent runs on your machine. Conversations, memory, files and provider keys live under ~/.foxl; the desktop server binds to 127.0.0.1 only, and every request to it must carry a random connection token (fresh at each launch, or minted once at install when the background service is on).
  • Per-tool approval rules (allow / ask / deny) in Settings > Safety. Once auto-approve-all is off, the built-in ask rules take effect: shell, terminal, background process, file write and the browser ask first, and so do sending a message or file to a chat channel and rewriting the workspace memory files the system prompt is built from.
  • Inbound channels deny by default. A Slack, Telegram or Signal bot answers only in the channels or to the people you list, and the list starts empty.
  • Remote access is scoped to your account, and encrypted per device once both ends can do it. Only a device signed in to your Foxl account can reach your desktop through the relay, and most of what they exchange is encrypted with keys the relay never holds - on a device new enough to complete the handshake. A browser tab, phone app or desktop older than v0.6.27 gets TLS alone.
  • The desktop's provider keys are encrypted at rest under a random key kept in a separate file only your user can read, and the desktop sends them to the provider only. The credentials you give Foxl Code's cloud agents are stored on the relay instead, encrypted at rest - see the Foxl Code question below.
  • No telemetry in the apps. The desktop, iOS and Android apps carry no analytics SDK and no crash reporter.

Not in place, so you can decide with the facts:

  • No OS-level sandbox. exec runs as your user with your permissions. The deny list is four literal patterns, not a syscall filter or a container.
  • A new install auto-approves every tool. Until you turn that off, anything the agent reads - a web page, a file, an allowed channel message - can steer it into running a command with no prompt in the way. That is the prompt-injection surface; the allowlists and approval rules above are the mitigations.
  • The relay reads four payloads in transit - notification previews, the chat message you send from the phone or web app (with its attachments), a chat reply while it streams, and a file preview's bytes - plus the conversation id on a chat request. Live chat through the relay is TLS-only, not end-to-end encrypted. See Cloud Relay.
  • A client too old to encrypt runs in the clear, and that is most of them today. The handshake shipped in v0.6.27 and engages per device, so an older browser tab, phone app or desktop gets TLS alone - and for that session the relay reads terminal output, every API and file response and the request paths as well. When this page was last measured, in September 2026, most clients that had connected in the previous week were on builds older than v0.6.27.
  • The safety number has no screen yet. A changed desktop identity key refuses the encrypted session, but the code is not displayed for you to compare against the desktop, and there is no button to accept a reinstalled desktop's new key.

Where does my data live, and what leaves my machine?

Foxl Desktop keeps conversations, memory, workspace files and provider keys on your machine, at ~/.foxl (%USERPROFILE%\.foxl\ on Windows). Nothing leaves it unless you use a feature that needs the network. What does leave, and where it goes:

TrafficDestinationWhen
Model requests: your prompt plus the files, snippets and tool results the agent needs for that turnThe provider you configured, straight from your machine. Foxl's relay is not in the path.Every model turn - unless the model is local (Ollama, vLLM, LM Studio), in which case nothing leaves
Sign-in, account and device recordsrelay.foxl.aiWhen you sign in or connect a device
Desktop tunnel trafficrelay.foxl.ai, which forwards it to your phone or browserOnly while Remote Access is on
Channel messages and DMs, shared folders and shared docsrelay.foxl.ai - Cloudflare D1 for text, an access-blocked, encrypted-at-rest AWS S3 bucket for shared filesOnly when you post or share into them
Meeting audio, when cloud transcription is usedAmazon Transcribe - over a short-lived session the relay presigns for you, or your own AWS account - or the transcription provider you chose under Settings > NotesOnly while a Notes recording runs; the audio is not kept afterwards. With on-device transcription (an Apple Silicon Mac, chosen under Settings > Notes) no audio leaves the machine
Browser actionsYour own Chrome, over a localhost WebSocketWith the Chrome Extension installed

Foxl Code is different by design: a task's conversation, plan and event history are stored on Foxl's servers so the task survives you closing the app, and the repository is cloned into an isolated microVM in Foxl's cloud. See the Foxl Code question below - or run tasks on your own computer, in which case nothing about them reaches Foxl's cloud.

Who processes what, and for how long, is in the privacy policy.

What does the relay store, and what can it read?

The relay at relay.foxl.ai is the account, sync and forwarding layer. It stores:

  • your account, sessions and device records, and a push token for each device with notifications on;
  • usage counters - token and request counts, transcription seconds - not message text;
  • Channels and DMs: the messages, reactions and attachments you post to a team channel;
  • shared folders and shared docs: the files and documents you share;
  • Foxl Code: conversations, Task Documents, task events and per-repository memory;
  • Foxl Code credentials: the Claude or ChatGPT subscription login you sync from your desktop or upload in the browser for the cloud agents, and any Kiro, Cursor or Anthropic API key you enter in Foxl Code's settings. They are encrypted at rest (AES-256-GCM), decrypted only on the server to start a task or renew an expiring login, and never returned to the browser;
  • an audit record of tunnel connections (device, action, time, IP address) for abuse investigation. It is append-only - nothing purges it - and it is deleted with your account.

It does not store your desktop conversations, your memory, your Notes transcripts or the provider keys you enter in the desktop app. The relay-side chat fallback (used when your desktop is offline) stores nothing either, and it is switched off today because Foxl serves no hosted models.

What it can read while forwarding is the short list under Cloud Relay.

Is Foxl open source? Can I inspect what it does?

No. Foxl Desktop, the relay and Foxl Code are proprietary software. What is public and auditable:

What you can inspect without source:

  • Memory is plaintext markdown under ~/.foxl/workspace/.
  • Every skill the agent can use is a plain SKILL.md under ~/.foxl/skills/; read it before you install it.
  • Every tool call - each shell command, file write and browser action - shows in the chat as it runs and is kept with the conversation in the app's local database.
  • The Chrome Extension's permissions are listed in Chrome's extension settings.
  • This page records its own corrections. When a control was overstated, the correction stays on the page rather than being rewritten away.

Does Foxl train on my data, or see my prompts?

Foxl trains nothing: it builds no models. It also serves no hosted models today, so every model request goes from your machine to the provider you chose, under your agreement with that provider, and Foxl's servers are not in the path. A local model keeps the prompt on your machine entirely.

When you use the phone or web app through your desktop, live chat crosses the relay readable in both directions: the app posts your message - its text, any images or documents attached, the model name and the conversation id - to the relay as plain JSON rather than inside the encrypted envelope, and the reply streams back the same way. TLS protects that exchange from the network; it is not end-to-end encrypted, and the relay stores none of it - see Cloud Relay.

Every third party that processes data - Cloudflare, AWS, the providers you choose, Resend for email, Apple and Google for push, GitHub if you connect a repository, Google Analytics on the websites with consent - is named in the privacy policy.

Who can talk to my agent?

Three doors, each with its own gate:

  • Your own devices, through the relay. Only a device signed in to your Foxl account can connect to your desktop: the relay addresses the tunnel by your user id, and a browser needs a single-use ticket bound to its device. On first connect a device pins your desktop's identity key and refuses the encrypted session if it ever changes; the matching code (a safety number) is computed on both ends but not yet displayed, so a changed key shows up as a refused connection and a browser console warning rather than a prompt. Turn Remote Access off and the tunnel disconnects.
  • Chat platforms. A bot answers only where you allow it: Slack per channel, optionally narrowed to listed users; Telegram per user; Signal per phone number. An empty list allows nobody. A Slack bot sees only messages that @-mention it, and Slack DMs do not reach it.
  • Software on your machine. The desktop server listens on 127.0.0.1 and requires the connection token on every API call. The Chrome Extension talks to it over a localhost WebSocket.

Can anyone in my Slack workspace use my bot?

Only in channels you have allowed, and only by @-mentioning it. Within an allowed channel, though, any member can start a run unless you also fill in the allowed-users list, and that run uses your local tools on your machine under your auto-approve setting. So treat the channel list as the boundary: allow a private channel with the people you would hand a shell to, not #general.

The Slack side is your own Slack app - you paste its bot token and app-level token into Settings > Connect > Integrations > Channels - connected over Socket Mode, so nothing about it is exposed on a public endpoint. Installing an app is a workspace-level act your admin can approve or restrict, but Slack does not gate which member may address an installed bot; Foxl's allowlist does. Several people who each want their own agent each run their own Foxl with their own Slack app.

Foxl runs while I am away. What can it do unattended?

Whatever you have allowed it to. A schedule, a message from your phone and an allowed channel message all run the agent with nobody at the screen, and with the shipped default of auto-approve-all there is no prompt in the way. Three settings bound it:

  1. Settings > Safety - turn auto-approve-all off, or set deny on the tools you never want to run unattended.
  2. Settings > Connect - keep the channel allowlists short, and turn Remote Access off if your phone does not need your desktop.
  3. Background service - Keep running when closed keeps the machine reachable after you quit the app. Leave it off if you want quitting to end the exposure. See Background service.

Cost follows the same rule as everything else: Foxl is free, and each model turn - a scheduled one included - costs whatever your provider charges, or nothing on a local model. See Cost & model access.

Where does Foxl Code run, and what can it reach in GitHub?

By default a task runs in an isolated Amazon Bedrock AgentCore microVM in Foxl's cloud. The repository is cloned into the VM's session storage at /mnt/workspace, the coding CLI runs there, and the branch is pushed back to GitHub. Agents from different users never share a VM or session storage. That storage survives across a task's invocations so a retry keeps its clone, and AWS reclaims it 14 days after the VM is gone. The conversation, Task Document and event history are stored in Foxl's database so the task survives you closing the app; you can delete a task, and account deletion removes all of them.

The cloud agents run on credentials you give Foxl: a Claude Pro/Max or ChatGPT login synced from your desktop or uploaded in the browser, or a Kiro, Cursor or Anthropic API key. Foxl stores them on the relay encrypted at rest (AES-256-GCM), decrypts them only on the server - to start a task or renew an expiring login - never returns them to the browser, and deletes them with your account.

GitHub access goes through the Foxl GitHub App, installed on the repositories you choose. Each task receives an installation token minted for it, scoped to that installation, valid for about an hour and never stored. Foxl acts on the issue, pull request, review, check and workflow events. Comment events are a different matter: the App is still subscribed to them, so a comment on your issue or pull request is delivered to Foxl's webhook endpoint - where it is signature-checked and then dropped before its body is read, with only the delivery id, the event type and the sending address written to the server log. The text of a comment is never parsed or stored, but the delivery itself does reach Foxl. The App's permissions are listed under GitHub integration.

To keep code off Foxl's cloud entirely, run tasks on your own computer: the clone, the CLI, the commit and the pull request all happen on your machine, with the CLI login and GitHub credential you already have.

Can my team or company use Foxl?

Yes, as a per-person tool. Each person installs the app, signs in with their own account and brings their own model access; their agent, memory and files stay on their machine. Channels and DMs give a team a shared space inside the app.

What does not exist yet: a company admin console, single sign-on, fleet-wide policy, or one audit log across people. Governance is per install - each person sets their own Settings > Safety rules and allowlists. Because the agent acts with exactly the credentials it is given, the practical control is to give it least-privilege ones: a GitHub installation limited to the repositories it needs, a provider key with a spending cap.

How do I delete my data?

  • On your machine: quit Foxl and delete ~/.foxl. That is everything Foxl Desktop holds - conversations, memory, keys and skills.
  • Your account: Settings > Account has Export my data (a JSON copy) and Delete my account. Deletion is permanent and removes your account and the records keyed to it - sessions, devices, push tokens, usage records, the tunnel audit record, the Foxl Code credentials you stored, and Foxl Code conversations, tasks and events.
  • What it does not remove today: messages you posted in a team channel and files you shared into a shared folder stay where you put them.

How are updates delivered and verified?

Desktop updates come from the GitHub release feed; the app checks about every four hours and installs on quit. On macOS the app is signed with a Developer ID certificate, built with the hardened runtime and notarized by Apple. On Windows the updater refuses an update whose signature is not from the publisher Foxl AI. That Windows certificate is self-signed, which is why SmartScreen warns on a fresh download; the update path is pinned to the publisher name all the same.

How do I report a security issue?

Email support@foxl.ai, or open a private ticket in the #private-support channel of the Discord. Please keep details out of public channels until there is a fix.

On this page