Trust center
How Exploit Hound handles your data.
A security product asks you to trust it with an unusually complete picture of your network. This page states what the platform does with it, what the platform deliberately refuses to do, and where each control is enforced. If your security review needs an answer that is not here, ask us and you will get one.
Platform architecture
What runs where, and which half we can answer for
Exploit Hound is a hosted platform. Collection runs inside customer environments and reports out to it. Both halves matter to a security review, and only one of them is ours.
Hosted by us
Ingestion, the exposure graph, attack-path analysis, Fix First, reporting and the MSP console. We patch it, we audit both dependency ecosystems and say what is outstanding during a security review rather than claiming there is nothing, and its state is published at /status/. Everything on this page about isolation, credentials, retention and audit describes this half.
Inside the customer environment
The onsite probe and the OS clients — the same agent in two roles. They see only the network ranges you set and the machines you install them on, they open no inbound port, and they connect outbound over TLS. Their availability depends on customer infrastructure as well as on us, which is why the status page says so rather than claiming to cover them.
Tenant isolation
Separation is enforced in queries, not by convention
For an MSP, tenants are separate customers. Isolation is applied where data is read rather than left to each screen to remember.
One chokepoint for the graph
Writing a relationship between two entities in different tenants raises an error rather than succeeding quietly. The exposure graph cannot be made to span customers even by a caller that tries.
Same answer for absent and forbidden
A record belonging to another tenant returns the same not-found response as one that does not exist, so responses cannot be used to enumerate what other customers hold.
Secrets
Credentials you give us
At rest
Scanner and directory credentials are encrypted before storage. They are never returned by the API after saving — the interface reports only whether a secret is set — and never written to logs, reports, exports or AI prompts.
In transit
The console and API are served over TLS. Agents authenticate with their own credentials, separate from user accounts, and can be suspended or deleted independently.
Authorized use
What the platform will not do
Assessment capability is bounded deliberately. These are properties of the code, not policies we ask operators to follow.
Scope is explicit
Assets are assessed only when marked authorized, with the authorization recorded. Verify Fix cannot be pointed at a target of your choosing: the target is derived from the finding’s own asset record.
Verification is read-only
A TCP connect, a TLS handshake inspection, a header or banner read. Addresses are resolved and vetted before connection, so a hostname cannot be used to reach internal or reserved ranges.
Directory reads only
Active Directory assessment opens its connection read-only and requests a fixed attribute allowlist that excludes every credential-bearing attribute. It does not crack, spray, read password hashes, or write to a directory.
No arbitrary execution
There is no unrestricted remote command execution and no exploit-execution capability. The AI analyst cannot trigger scanning or any state change.
AI handling
The analyst is optional and grounded
It answers only from the requesting tenant’s own records. Every finding, asset and path it cites is checked against the evidence it was given; anything else is flagged rather than presented as fact, and with no supporting data it says so instead of producing something plausible. Use is recorded, and it can be disabled entirely.
Where that data goes. The analyst is off until an operator configures a model provider, and it is the one feature that sends your data outside this platform. When it is enabled, the evidence handed to the model — the findings, assets and attack paths relevant to the question, including hostnames — is sent to Anthropic, listed as a subprocessor on the procurement page. Nothing is redacted before it is sent, because a redacted finding would not answer the question. Where that is not acceptable for a customer, leave the analyst switched off: everything else on this page works without it.
Access
Authentication and authorization
Who can sign in, what they can reach once they have, and where that boundary is enforced.
Roles
Four levels, from read-only through tenant administrator. Only the platform-wide role sees across tenants; an administrator of one customer reaches that customer and stops there.
Two-factor
A time-based one-time code from an authenticator app, demanded at sign-in on accounts that have it enabled. Single-use recovery codes cover a lost device; they are stored hashed, shown once, and each works exactly once.
Single sign-on Beta
OpenID Connect against your own identity provider, so joiners and leavers are governed where you already govern them. A password remains available for accounts the provider does not know. The status is the one the integrations page carries, and means the same thing here.
Passwords
Hashed with bcrypt. No account password is recoverable from the platform, by us included.
Sessions
Signed bearer tokens that expire after thirty minutes, served only over TLS. The signing key is held outside the codebase and can be rotated, which invalidates every session that exists at the time.
Agents authenticate separately
An onsite probe or OS client carries its own credential, not a user’s. It can be suspended or deleted on its own without touching anybody’s account.
Logging and audit
What is recorded, and what is kept out of the record
The audit log
Sign-in attempts, authorization failures, credential access, scan and asset activity, report generation, suppression decisions and remediation are recorded with the acting user, the address they acted from and the time. Remediation carries the fuller trail: who approved an action, what was sent, what the target reported back, and what an independent re-check found afterwards.
What logs do not contain
Credentials are never written to logs, reports, exports or AI prompts — not the ones you give us and not the ones a collector reads. Sensitive values detected in collected data are recorded as a match with its location and type, never as the value itself.
Data handling
What we hold, and for how long
Exploit Hound is an assessment platform, so most of what it holds is evidence about your estate. This is what that means concretely.
What is collected
Asset inventory, open services and versions, findings and their evidence, configuration state, identity posture read from directories you authorize, NetFlow summaries, honeypot events, and the remediation record — who approved what, when it ran, and what the re-check found.
What is not
No file contents, no mailbox contents, no cloud object data, and no passwords. The directory collector requests a fixed attribute allowlist that excludes credential material, and discards it if an operator-supplied export contains it.
Credentials you give us
Integration credentials are encrypted at rest with Fernet and are write-only: no API endpoint returns them, including to the tenant that entered them. Two cloud integrations hold no credential at all — Google Cloud and Google Workspace are granted by a binding or delegation you add and remove in your own console.
Retention and deletion
Scan and report retention is configurable per tenant, with a scheduled cleanup that enforces it rather than leaving it as a setting nothing acts on. Deleting a tenant removes its assets, findings, graph and remediation history by cascade. The platform is operated by us, so backup, recovery and data residency are ours to answer for; ask during a security review and you will get the current position rather than a number written for a web page.
Tenant isolation
Every query is scoped to one tenant, and the isolation is probed adversarially through the real API on every release — cross-tenant reads, writes, remediation and reporting. A request for another tenant’s record answers 404 rather than 403, so the API does not confirm that it exists.
Website enquiries
The form on this site stores what you type, in our own platform, and raises it as a ticket in our helpdesk so it reaches a person with an owner and a queue rather than an inbox. Your IP address is not kept — only a keyed hash of it, so repeat submissions can be recognised without holding the address. Nothing is sold or enriched from third-party data brokers.
Vulnerability disclosure
Found a security issue? Tell us and we will fix it
Report it through the contact form, saying in the message that it is a security report. It reaches the same people, we will confirm receipt, tell you what we found, and tell you when it is fixed. We will not threaten you for reporting in good faith.
We ask that you test only against your own deployment or data, avoid actions that would degrade service for others, and give us a reasonable window before publishing.
Secure development
What we run against our own platform
Each of these is something that executes and produces a result, not a policy statement. Where a check reads live configuration it says so, and where it probes it says that too — the difference matters when you are deciding what the result is worth.
| Activity | Who | State |
|---|---|---|
| Dependency vulnerability audit | Us | Both ecosystems are audited, and the tooling is committed to the repository so a run is reproducible rather than recalled. Current dependency findings, remediation status and supporting technical details are provided during a security review so the information reflects the release being evaluated. How to request one. |
| Platform posture checks | Us | Eight read live configuration — token signing algorithm, CORS origins, secret strength, whether the startup secret validator is switched on, whether stored credentials still decrypt, the report template sandbox, autoescaping and password hashing. Two more read a live response: the console’s security headers, and whether the API schema is reachable from outside. They probe rather than inspect — the sandbox check runs the payload rather than looking for a flag that says it would have been stopped. |
| Automated test suite | Us | Run before every change, including cross-tenant authorisation tests through the real routers. |
| Cross-tenant authorization tests | Us | Read, write, remediation and reporting are each driven across a tenant boundary through the real API on every release, and are required to answer 404 rather than 403 — so a refusal does not confirm that the record exists. |
| Adversarial testing | Us | Carried out by our own engineers. The report renderer’s sandbox, the credential paths and the assessment boundaries are the parts that get attacked deliberately rather than only tested. |
| Vulnerability disclosure | Anyone | Published, with a machine-readable security.txt. It names only the contact route that has been shown to work. |
Operational monitoring
Platform status is published, and measured when you look at it
The hosted platform’s current state is at status.exploithound.com — open to anybody, no account needed.
Measured on load
Every state on that page is read from the running services when the page is requested, rather than set by hand during an incident. What it reports is the hosted platform: ingestion, the API, the job queue and the console.
Where it stops, and why
An onsite probe or OS client also depends on your infrastructure, your network and your connectivity to us. Their health is per deployment, in your console, because that is the only place it can be seen accurately.
Security review
Running a security review or a vendor questionnaire?
Send it and we will answer it. Not a brochure back — the actual answer, from the people who built the thing being asked about.
What we answer
- Hosted architecture, and what runs inside your environment
- Tenant isolation, and how it is enforced and tested
- Authentication, single sign-on, roles and session handling
- Credential storage, encryption and key handling
- Assessment methodology and authorization boundaries
- Data collected, retention, deletion and residency
- Backup and recovery
- Subprocessors currently in use
- Security testing we perform, and the results
- Standard vendor-risk questionnaires
How it works
The procurement page answers the standard questions already — hosting, encryption, backups, retention, deletion, disclosure and what independent assurance we hold.
Use the contact form and say it is a security review. Attach the questionnaire if you have one; if your process needs a call with an engineer rather than a document, that is usually faster and we will do that instead.
Answers are current as of when we send them, and anything we have not measured is described as unmeasured rather than filled in. That is the same rule the product itself follows.
Start with what's actually exposed.
Point Exploit Hound at the assets you are authorized to assess and see the connected picture, ranked by what removes the most exposure.