# FAQ
Source: https://docs.privacycommand.privacykey.org/faq

Short answers to the questions that come up first.

**Do I need to give it admin access?**

Not for the core report. Static analysis, the App Store privacy-label
cross-check, batch scan and exports all run unprivileged.

The optional [helper](https://docs.privacycommand.privacykey.org/privileged-helper) unlocks live file-event
monitoring, the Background Task Management audit without a mid-audit
prompt, and the network kill switch. Installing it asks for admin once.

One separate thing, not admin and not the helper: reading *granted*
permissions out of the macOS TCC databases needs privacycommand itself to
hold Full Disk Access. Without it you lose the granted column, any matrix
row that exists only because macOS recorded a grant, the *System access
granted* list that flags the inspected app's own Full Disk Access,
Accessibility, Screen Recording or Input Monitoring, and the Verdict column
— every row reads *Grant unknown* — see
[Requested, granted, used](https://docs.privacycommand.privacykey.org/static-analysis#requested-granted-used).

**Does it run the app I'm inspecting?**

Not unless you ask it to. The first pass is entirely static. Executing the
app only happens in a [monitored run](https://docs.privacycommand.privacykey.org/monitored-runs), which you start
deliberately — and for anything you don't trust, do it in
[VM mode](https://docs.privacycommand.privacykey.org/vm-mode).

**Does it detect malware?**

No, and it doesn't claim to. It reports what a bundle is entitled to, what
it ships, and what it does when observed. A determined adversary can hide
from static analysis. Use it as evidence, not as a verdict.

**Is anything sent anywhere?**

Nothing about you, and no part of the inspected bundle. Three calls happen
on privacycommand's own account: DNS reverse lookups for addresses the
inspected app contacted, Mac App Store privacy-label lookups keyed on the
inspected app's bundle ID, and the Sparkle appcast when you check for
updates — which is off by default.

Two more only happen when you ask for a feature that fetches something:
**Preview next version** reads the *inspected* app's own update feed and
downloads the release it points at, and `auditctl preview --fetch` has
Homebrew download the incoming cask. Full detail in [Security](https://docs.privacycommand.privacykey.org/security).

**Can I audit an app I haven't installed?**

Yes. Drop a `.dmg` on it, or use
[`auditctl preview --fetch`](https://docs.privacycommand.privacykey.org/auditctl) to pull an incoming Homebrew cask
build and diff it against what you have.

**Why does an app show findings after an update to privacycommand?**

Usually because detection improved, not because the app changed. Detectors
are added between releases. If you're tracking an app over time, note which
privacycommand version produced each report — see [Updating](https://docs.privacycommand.privacykey.org/updating).

**Is it free? Is there a paid tier?**

Free, MIT-licensed, no paid tier and no upsell.

**Does it work on Intel Macs?**

Yes — macOS 13 or newer, Apple Silicon or Intel.

**Can I run it in CI?**

Yes, via [`auditctl`](https://docs.privacycommand.privacykey.org/auditctl). Use `--json` for machine-readable output
and `--warn-exit` to fail a build on findings. Run bare with stdout
redirected it prints usage rather than opening the interactive browser, so
it's safe in a pipeline.

**What about iOS apps?**

Different tool — [privacytracker](https://github.com/privacykey/privacytracker)
watches iOS App Store privacy labels and tells you when they change.