PrivacyFence
Security
A summary for security reviewers and IT. Each part links to the full technical reference, Security and compliance, which states every default and limit.
The model
On one person's own computer (local mode), or on a server the organization runs, with sign-in through its own identity provider (organization mode). There is no PrivacyFence-operated service in either: every call goes from the machine running PrivacyFence straight to Google, Slack, Salesforce, Atlassian or Telegram.
Deployment modes →On a packaged install, an AI client with shell access still cannot approve its own request, add an always-allow rule, change the PII policy, enroll its own passkey, or rewrite the audit log without it showing. It can read what is waiting on the approvals page, but not release it.
Trust boundary →A web session opened through the companion app, after it asks you, can approve. A session anything else on your account starts can only look. No MCP tool can obtain a sign-in link, and every sign-in code issued is audited.
Human and unattested sessions →On a packaged install, approving a write or a read flagged as personal data takes a fresh passkey assertion: Touch ID, Windows Hello or a security key. Wherever passkeys are required, the default on a packaged install, so do sensitive settings changes such as adding an always-allow rule. An organization deployment turns step-up on in its config bundle.
Passkey step-up →A one-time recovery code gets you back in when every passkey is lost. Only a salted hash is stored, attempts are rate-limited and audited, and on a packaged install only a person's session can use it.
Recovery code →Every packaged install runs PrivacyFence under a dedicated service account, with its policy, passkeys, audit key and connector credentials in a directory your own account cannot write or read. A packaged install that finds itself unseparated refuses to serve.
Privilege separation →Every gate decision, approval and security event is written to a weekly log, each entry chained to the one before with HMAC-SHA256, so an edit, insertion or deletion made without the chain key shows when the log is verified. Organization mode can also forward every entry to syslog or an HTTP endpoint, off the machine.
Audit log integrity →Every card and audit entry names the AI system that made the request, and says how far to trust that name. The only verified identity is an OAuth client an organization administrator has pinned. A name never changes an outcome: it selects no rule and releases nothing.
Which AI system the audit log names →Only what it already had: the tool, the arguments it sent, and a status. PrivacyFence may fetch and scan the data first to build the card, but that stays inside PrivacyFence. On a denial the AI client gets nothing from it, and errors never carry credentials or unreleased content.
What the AI sees before approval →Session cookies, CSRF and same-origin checks, a host allowlist and a per-response Content Security Policy on the web pages; limits on the organization's OAuth server; a validated, optionally signed organization config; signed installers and CycloneDX SBOMs for every release.
Other controls →Limitations
Read this before you rely on PrivacyFence for production or regulated data.
pip install).The full list, with the reasons, is in Security and compliance. To report a vulnerability, follow the security policy.
Evaluating PrivacyFence
Every control above is in the open-source code under Apache 2.0. For an organization-wide rollout, compare local mode with a central deployment.