How GhostAudit handles your data, stated plainly.
This page describes what the product does today. It includes a list of what we do not have yet, because a security review goes faster when nobody has to guess.
The sensors cannot leak what they never collect.
The most sensitive part of GhostAudit is the software on employee devices, so that is where the strictest rule applies: metadata only.
Sensors report which AI tool was used, by hostname or application name, and for how long. They do not collect prompts, responses, page content, keystrokes, screenshots, file contents or full URLs. Matching against your AI tool list happens on the device, and anything that does not match is discarded there.
By default the browser extension injects no script into any page: it sees the hostname of the active tab and nothing inside it. The desktop agent performs no packet capture and no TLS interception, opens no listening ports and runs no commands sent by the server. Privacy by design has the full list.
Two features added in version 1.1 go further than hostnames, and each is built so that the sensitive part stays on the device.
On-device sensitive-data warnings are optional and off by default. When you turn them on, the extension registers one content script on the AI tool sites in your catalog and nowhere else. It listens for paste, drop and file selection, checks the text against patterns such as card numbers and API keys inside the tab, and shows a warning. It reports a category and a count. The text, its length, a hash of it or the name of a file are never sent, and the server ignores any other field on these events.
AI agent and MCP server discovery has the desktop agent read the configuration files of AI agent clients in the signed-in user's home directory. Those files often contain tokens. The agent keeps server names, package names and hostnames, and nothing else: no env values, headers, arguments, paths or URL paths. The server validates each field again on arrival. An admin can turn discovery off for the organization.
The sensor compares hostnames and app names with your AI tool list, in memory. Anything not on the list is discarded on the spot.
One aggregate per listed tool per five-minute window: tool, hostname or process name, seconds active, and identity as your setting allows.
Our cloud or your own infrastructure. Sensors talk to this server and nothing else: no analytics, no third-party endpoints.
Five roles, enforced on the server.
Access inside a workspace is role-based. Permissions are checked by the server on each request, not only hidden in the interface: a viewer's write requests are rejected.
Each organization's data is separated by organization throughout the application. Passwords are stored as salted bcrypt hashes. Sign-in and other public endpoints are rate limited.
Who can see usage data about individuals is a question of both role and identity mode. In pseudonymous or anonymous mode the sensors never send a name, so there is none to see.
Single sign-on. On the Govern and Enterprise plans people can sign in through your identity provider using OpenID Connect: Okta, Microsoft Entra ID, Google Workspace and other compliant providers. The flow is authorization code with PKCE; ID tokens are accepted only with asymmetric signatures. Your email domain is verified with a DNS record before it can be used, and a domain can belong to one workspace only. You can require SSO for everyone except owners, whose password remains as the way in if the provider is down. New people are created at first sign-in with the role you chose as default, member or viewer. SAML is not supported; see the list below.
User provisioning. On the same plans, your identity provider can manage accounts through SCIM 2.0: it creates, updates and deactivates users on the email domains you verified. Deactivating or deleting a user at the identity provider ends that person's GhostAudit sessions immediately; the account is kept, inactive, so the audit log keeps its author. SCIM covers users only. Groups are not synchronised, roles are set in GhostAudit, and an owner can never be deactivated through SCIM. The SCIM token is shown once and stored as a hash, and each change is recorded in the audit log.
Sessions. A session lasts at most 12 hours. Anyone can sign out everywhere from their profile, an owner or admin can sign a teammate out, and all of a person's sessions end when they are deactivated, when their password changes, or, for everyone but owners, when single sign-on becomes required.
Partner access. If you work with a managed service provider or virtual CISO, an owner can approve that firm's request to work in your workspace as admin or read-only viewer, never as owner, and can revoke it at any time; billing, single sign-on settings and deletion stay with you, and every action by partner staff is recorded in your audit log as theirs, "via" the firm.
| Role | Can |
|---|---|
| Owner | Everything, including transferring ownership |
| Admin | Manages people, integrations, sensors and settings |
| Compliance manager | Runs assessments, approves documents, manages the inventory |
| Member | Works on the systems and documents assigned to them |
| Viewer | Read-only. The server rejects every write request |
Every change, with a name and a time.
Changes to the inventory, tool statuses, assessments, documents and settings are written to an audit log with the acting user and the time. The log can be filtered and exported as CSV.
That serves two purposes. It is the evidence your own auditors ask for. And it is a control over GhostAudit itself: an administrator who changes the identity mode or enables blocking leaves a record.
Example workspace. Names and figures are illustrative.
- 09:42M. Okafor approved Algorithmic Impact Assessment v3
- 09:15J. Lindqvist set status Unsanctioned on Cursor
- FriR. Patel marked Met EU AI Act Art. 14 · Candidate screening
- FriS. Brandt generated AI Acceptable Use Policy v1
Send events to the security tools you already watch.
On the Govern and Enterprise plans, GhostAudit can stream its events to an HTTPS webhook, a Splunk HTTP Event Collector or Datadog Logs. Each destination chooses its streams:
- Audit: changes made in the console.
- Policy: warnings, blocks and decisions to proceed.
- Discovery: each new AI tool found.
- Usage: daily totals per AI tool.
By default no exported event identifies an employee or a device. A destination can opt in to include who, and that option only works while your identity mode is named. There is no prompt or page content to export, because the product does not hold any.
Delivery is at least once, in order, with retries and backoff; events carry a stable id so the receiver can de-duplicate. Destination secrets are encrypted at rest and are never shown again after they are saved.
{
"id": "0b0c6a3e-9d0f-5a67-8a55-0d7a4f1c2e11",
"type": "policy.blocked",
"stream": "policy",
"time": "2026-11-10T14:03:22Z",
"schema_version": 1,
"organization": { "id": 42, "name": "Northwind Group" },
"data": {
"policy_event_id": 5531,
"action": "blocked",
"tool_key": "deepseek",
"tool_name": "DeepSeek",
"host": "chat.deepseek.com",
"process": null,
"occurred_at": "2026-11-10T14:03:22Z"
}
}Secrets are encrypted or hashed, according to what they are for.
- Integration credentials
- Tokens and keys for Google Workspace, Microsoft 365, GitHub, Okta, Jira, Slack and other integrations, the single sign-on client secret and log export secrets are encrypted with authenticated symmetric encryption (Fernet: AES-128-CBC with HMAC-SHA256) before they are stored. The key is derived from the server secret and is not stored in the database.
- Device credentials
- Each sensor has its own credential. The server stores only a hash of it. A device can be revoked individually; a revoked sensor stops reporting.
- Enrollment tokens
- Created by an admin, shown once, used only to enroll. They can be given an expiry and can be revoked.
- User passwords
- Stored as salted bcrypt hashes.
- Sensor transport
- HTTPS only, TLS 1.2 or later. Sensors do not follow redirects, so a credential cannot be forwarded to another host.
Our cloud, or entirely inside yours.
Hosted. We operate the service. Customer data is stored in: DigitalOcean, New York, United States. The third parties involved are listed on the subprocessors page.
Self-hosted. The GhostAudit server is a single container image with a Postgres database. It binds to localhost behind your own TLS-terminating proxy, ships with install, update and backup scripts, and serves its own sensor downloads. Sensors enroll against your server address, so usage data, documents and the audit log stay on infrastructure you control, and we have no access to them. Self-hosting is part of the Enterprise plan.
Language models. The hosted service uses no language-model provider today; none is on the subprocessors page, and one would be listed there, with notice, before it is used. Documents, questionnaire answers, remediation suggestions and the screening of unrecognised apps are all produced by fixed rules.
The software also contains optional AI assistance for those four features, which is off unless a deployment is given a provider key. A self-hosted customer can enable it with their own key, and an owner or admin can switch it off for a workspace. It is built so that employee activity never reaches a model: usage events, employees, devices, licence seat lists, discovery evidence and the audit log are excluded in code, and email addresses and names are stripped from what is sent. Assessment scoring, regulation applicability and on-device sensitive-data checks are rule-based in every deployment. If a self-hosted deployment configures a model to refine the wording of generated documents, names, email addresses and device counts in the draft are replaced with placeholders before it is sent and restored afterwards; if the model alters a placeholder, the template draft is used instead.
What the trust center, the employee hub and the free tools can and cannot reach.
- Trust center page
- A customer's public page at /trust/their-company is rendered on the server from the snapshot taken when they pressed Publish, and from nothing else. The snapshot is built by an allow-list that names every field it copies; risk tiers, owners, comments, usage data and employee identities are not on it. The page runs no script and sets no cookie. Draft edits are never public. How it works.
- Document requests
- A visitor's request is stored for the customer to approve. An approved requester gets an expiring link; only a keyed hash of its token is stored, and each file is a PDF marked with the requester's name on every page. The form has a honeypot field and accepts five requests an hour from one network.
- Employee hub sessions
- An employee's hub session is a separate credential, signed with its own key and held in an httpOnly cookie scoped to the hub's API. It names a hub person, never a console user: it cannot call a console route, and a console token is not a hub session. State-changing hub requests need a custom header and the hub's own origin. Sessions last 7 days by default.
- What an employee can see
- The approved tools, their own requests, the policy, the course, the monitoring notice and their own recorded activity. Never the inventory's risk data, a reviewer's internal notes, or anything about another person. Employee AI hub.
- Vendor page checks
- Once a month the server re-fetches the vendor pages behind the vendor fact cards to see whether a quoted sentence is still there. It requests only the addresses in the shipped data set, identifies itself in its user agent, and sends no customer data. Tool icons are fetched the same way and served from our own origin; a visitor's browser is never sent to a third party for an image or a font.
- Free tools
- The policy generator and the questionnaire tool need no account and read no organization's data. Answers are used to produce the result and are not stored. Downloading the policy as a file stores the email address given, as a sales enquiry. Both are rate-limited per network.
What we do not have yet
We are an early-stage company. These are the things a security questionnaire will ask about where today's answer is no.
- SOC 2
- A SOC 2 audit has not yet been completed. We do not hold a SOC 2 report.
- ISO 27001 and ISO/IEC 42001
- We are not certified against either standard.
- Independent penetration test
- We do not yet have a third-party penetration test report to share.
- SAML
- Single sign-on uses OpenID Connect, on the Govern and Enterprise plans. SAML sign-on is not supported.
- SCIM groups and gallery listings
- SCIM 2.0 provisioning covers users only: groups are not synchronised, and roles are set in GhostAudit, not by your identity provider. The connection is set up as a custom SCIM application; GhostAudit is not listed in the Okta or Microsoft Entra application galleries and has not been certified by either. Our tests replay the requests Okta and Entra ID send; we have not yet verified the integration against a live tenant of each.
- Signed agent installers
- The desktop agent's binaries and installers are not yet code-signed or notarized. The agent deploys by script through your endpoint management, and a SHA-256 checksum is published for each build. If your policy requires signed software, deploy the browser extension first and add the agent when signed packages are available.
- Enforcement for AI agents
- MCP servers found on desktops can be marked approved or not approved as a record. Nothing is blocked or removed on the device.
- Retention for existing workspaces
- New workspaces delete usage records after 365 days unless an admin chooses another period. A workspace created before the retention setting existed keeps everything until an admin chooses a period; nothing is removed for it silently. Warning and block events are deleted with the records, not folded into the anonymised totals.
- Microsoft Sentinel connector
- Log export supports an HTTPS webhook, Splunk and Datadog. Sentinel is reached through the webhook with a Logic App or Azure Function in between.
- Data residency options
- The hosted service runs in one region. If you need your data in a specific country, self-hosting is the answer today.
If one of these is a blocker for you, tell us at [email protected]. Knowing which matter most to customers is how we decide the order.
Security questions
- Can we review the sensors before deploying them?
Yes, and we encourage it. Field-level documentation covers every value each sensor sends. The browser extension is plain, unminified JavaScript, and the desktop agent can print exactly what it would send with
collect --once --dry-runandinventory --dry-run.- Do you support SAML single sign-on?
No. Single sign-on uses OpenID Connect, which Okta, Microsoft Entra ID, Google Workspace and most other identity providers offer alongside SAML.
- Do you support SCIM provisioning?
Yes, SCIM 2.0 for users, on the Govern and Enterprise plans. Your identity provider can create, update and deactivate GhostAudit users, and deactivating someone there signs them out of GhostAudit immediately. Groups are not synchronised and roles are not set through SCIM. It is configured as a custom SCIM application: GhostAudit is not in the Okta or Microsoft Entra galleries.
- Can a managed service provider work in our workspace?
Only if one of your owners approves it. A partner firm can request access; an owner chooses whether it gets the admin or the read-only viewer role, and can change or revoke that at any time. Partner staff are never owners, cannot touch billing, single sign-on settings or deletion, and everything they do is in your audit log with their name and firm. See partners.
- What access do the Google Workspace and Microsoft 365 connections have?
Read-only access to metadata, with credentials you create in your own tenant and can revoke there. Google: one scope for the admin audit log. Microsoft: directory read, and optionally the sign-in log. No mail, files or calendar content is requested. See shadow AI discovery.
- Can GhostAudit staff see our data?
In the hosted service, access to production systems is limited to the people who operate it. If that is not acceptable for your data, self-host: then we have no access at all unless you grant it.
- What happens to our data if we leave?
You can export documents and the audit log. After termination, customer data is deleted as set out in the data processing addendum.
- How do we report a vulnerability?
Write to [email protected]. Please give us a reasonable time to fix an issue before disclosing it. We will acknowledge your report and keep you informed.
- Will you complete a security questionnaire?
Yes. Send it through the contact page. We will answer it accurately, including where the answer is "not yet".
- Privacy by designWhat the sensors collect, written for employees and works councils.
- Data processing addendumOur role as processor and the measures we commit to.
- For ITDeployment, privileges and footprint of the sensors.
- AI agent discoveryExactly what the desktop agent reads from AI client configuration.
- AI usage monitoringSensitive-data warnings and what stays on the device.
- Questionnaire answersFor the questionnaires your own customers send you.
Send us your security questionnaire.
We will answer it accurately and quickly, and tell you where the answer is not yet. You can also start a trial and review the sensors yourself.