Your environment or ours. Self-hosted, air-gapped or hosted.
Discover it. Measure it. Govern it. Build it responsibly.
Try the demo Book a briefing

Shield360 › Company › Trust & security

How we protect your environment.

Shield360 is built so the information it handles stays protected, and so you can check how. This page covers how the product is designed, how releases are signed, and how to report a security issue to us.

Last updated 15 October 2026

By design

How Shield360 protects your environment.

Properties of how the product is built, not settings that depend on someone remembering them.

Outbound only

The collector opens connections to Shield360 and listens for none, so it adds no open port to your machines.

Runs as the signed-in user

On macOS the collector runs as a per-user launch agent, not as root. Installing it into the system path needs an administrator once; running it does not.

No root certificate

Discovery needs no proxy and no root certificate, and there is no TLS interception. The AI proxy is optional: applications reach it by base URL, so it needs no root certificate either.

Prompt storage off by default

Data protection checks a prompt on the machine before it is sent. Whether its text is stored is your setting, off unless you turn it on; an environment can only store less.

Detected values stay masked

When a secret or personal data is found, Shield360 keeps its kind and a keyed fingerprint, never the value itself. That includes API keys seen on machines.

Encrypted credentials

Keys and credentials you connect, such as vendor billing keys, are encrypted at the application level with AES-256-GCM.

A database per customer

On the hosted service each organization has its own database, not a shared table with a customer column.

Your environment, if you prefer

Shield360 can run in your own environment, including air-gapped, against your own databases, with no license check-in to us.

Releases

How releases are signed.

  • Shield360 platform container images are signed with Sigstore cosign when they are published.
  • Every collector download is published with a SHA-256 checksum, and the install script refuses a download whose checksum does not match.
  • macOS notarization and Windows code signing for the collector: planned.

Reporting a vulnerability

Tell us, and we will respond.

Email security@thinkfleet.ai

You can encrypt your report; ask and we will send you a key.

What to include

  • What you found and where: a URL, an endpoint, or a binary and its version.
  • Steps to reproduce it, and the impact you expect.
  • Anything you needed to reproduce it, such as an existing account.

What you can expect from us

  • An acknowledgment within 3 business days.
  • An assessment, with a severity and an intended fix window, within 10 business days.
  • Progress updates until it is resolved.
  • Credit in the release notes, if you would like it.

We will not pursue legal action against researchers who act in good faith and follow the guidelines below. We do not currently run a paid bug bounty.

Testing guidelines

Test responsibly.

  • Only access, change or delete data that belongs to you. To test separation between customers, use a second account of your own.
  • No denial-of-service, load testing or resource exhaustion.
  • No social engineering, phishing or physical testing against our staff, customers or suppliers.
  • No spam, and no automated scanning that degrades the service.
  • Give us reasonable time to fix an issue before you disclose it publicly.

Not in scope

We usually close these without action unless they come with a demonstrable exploit:

  • Missing security headers, or missing flags on non-sensitive cookies.
  • SSL/TLS configuration findings with no working attack.
  • Clickjacking on pages with no state-changing action; CSRF on anonymous forms or logout.
  • Rate limiting on endpoints other than sign-in; username or email enumeration.
  • Content spoofing or text injection with no attack vector.
  • Reports produced only by an automated scanner, with no analysis.
  • Issues that need physical access to an unlocked machine, a rooted or jailbroken device, or an unsupported browser.
  • Anything affecting only an end-of-life version of the collector.

Disclosure

What we publish.

If a vulnerability affected customer data or required customers to act, we will publish an advisory: what happened, what we changed, and how to tell whether you were affected. If the fix needs a collector upgrade, the advisory will say so.

Contact