Trust Center

You're hiring us to attack you. Here's why that's safe.

A security assessment platform should withstand more scrutiny than any other vendor in your stack. This page explains how GhostTrace is built — including, deliberately, the things it does not do yet.

Authorization before anything

GhostTrace does not generate authorization — it consumes yours. Your signed engagement letter or rules of engagement becomes a hard allowlist, and the platform cannot exceed it.

authorization

Contractual, then encoded

Scope is established outside the platform — engagement letter, MSA, or rules-of-engagement document, signed by the responsible owner. That authorization is encoded as the scope allowlist for the run. No paper, no probes.

scope enforcement

One function, three layers, fails closed

A single shared authorization function is the source of truth, called independently by the API that accepts the scan, the worker that executes it, and the engine's HTTP boundary before any request leaves. If the check can't complete, the request is denied. No layer can be bypassed.

scope ledger

Tighten yes, widen never

Every decision — allow or deny — is written to the scope ledger with the target and the rationale. Mid-run, an operator can remove targets but the platform refuses to add any; widening requires re-authorization. Audit the ledger after any run.

Four controls, each one auditable

A platform that actively probes systems must be impossible to misdirect. Each control prevents a failure we've thought about explicitly.

scope governor

Fail-closed, in depth

Enforcement lives wherever a request can originate — API, scan worker, request layer — through one shared function. A misconfigured detector cannot escape the allowlist, and any check that can't complete becomes a denial, not an exception.

cost governor

Predictable runs, no surprises

Every run has a hard ceiling you agree to up front, so it can never become a runaway bill or an endless assessment. Hit the ceiling and the run stops cleanly, everything already proven still delivered. In deterministic mode, AI calls are blocked in code — your "no AI" decision is enforced, not promised.

dry-run gate

Preview before probing

Before anything real happens, the platform shows the operator exactly what it will do — which detectors, which surface, what scope — and waits for approval. An operator's misunderstanding never becomes a live incident.

entitlement boundary

Autonomous, fully accountable

Findings are gate-verified, adjudicated, and delivered without a human bottleneck. Every capability invocation and scope decision lands in the ledgers, so you can reconstruct exactly what happened after the fact — review is available to you, never required of you.

Data handling

Assessment data is among the most sensitive data a vendor can touch. We hold as little of it as possible, isolate what we hold at the database layer, and offer full physical isolation when you need it.

deployment

Hosted service, with a single-tenant option

Delivered as a hosted service — nothing to install, just a browser and an authorized scope. Your data is isolated at the database layer, so one tenant's queries can never read another's rows. For regulated or data-residency needs, a dedicated single-tenant instance keeps all storage in an environment you control. When the AI brain is on, LLM calls go to the model provider; you can run deterministic-only with zero external AI calls.

retention

Keep only what the evidence needs

Raw response bodies are retained in evidence bundles for proven findings only; non-proven candidates don't keep full bodies. What remains is the audit trail — findings, evidence, ledgers — because that's what your team needs to act.

platform secrets

Never in source, never in replays

API keys and database credentials are injected at runtime from a managed secrets store, never committed; automated secret scanning runs on every commit. Proof-replay subprocesses run with a restricted environment, so platform credentials are never exposed to reproduction commands.

database posture

Non-privileged, row-isolated

The application connects to its database through a non-privileged role constrained by row-level isolation. Access boundaries are a database guarantee, not an application-code promise.

How an engagement runs

Every engagement is bounded by signed rules of engagement before any technical work begins — whether you run a single scoped assessment or, with design partners, a continuous cadence.

01

Rules of engagement

Scope, auth paths, testing windows, and escalation contacts are agreed and signed off — including your CISO's sign-off — before the engine is pointed anywhere.

02

Scope encoding

The authorized targets become the allowlist. Anything outside it is denied at three independent layers and logged — by construction, not by configuration.

03

Dry-run preview

Before real probing, you see exactly what will happen: which detectors, against which surface, under what scope. The run proceeds only after the preview is approved.

04

Assessment

The engine maps, probes, and proves within the authorized scope. Every capability invocation and every scope decision lands in the ledgers; you can watch the live trace and halt at any time.

05

Adjudicate and deliver

Findings are autonomously gate-verified, adjudicated, and reported — no human bottleneck in the loop. You receive the evidence bundles — self-contained, independently verifiable — plus the full artifacts with JSON and CSV exports, and a one-click executive report (rolling out).

06

Single run, or continuous

Run it once for a point-in-time assessment, or — rolling out with design partners — on a continuous cadence that re-proves what changed. Every re-run stays inside the same signed scope, and you get deltas between runs (new, resolved, reopened), not another full dump to triage.

What we don't do yet

Most vendors hide their limitations in a contract appendix. We'd rather you plan around them from day one — nothing on this list should ever be a surprise mid-engagement.

Deeper SSO & vault integration for authenticated testing is rolling out

Authenticated testing probes behind the login today when credentials are provided for the engagement. Turnkey SSO (OAuth, SAML) and vault-resolved credentials — so we never hold a long-lived secret — are rolling out with design partners, not yet self-serve.

A few dashboard conveniences are still maturing

Replaying the live trace of a completed run and per-scan pickers on some views are near-term roadmap items. Everything the views show is already in the run artifacts — these are quality-of-life additions, not data gaps.

Access-control detection is keyed to numeric IDs

The IDOR detector works on numeric identifiers today; UUIDs, slugs, and hash-style IDs are on the roadmap. Many modern APIs use non-numeric IDs the detector will catch later, not yet.

Downstream integrations are file-based today

Ticketing, SIEM, and vulnerability-management tools consume our structured artifacts (results.json) directly. A polling API and webhook push for real-time integration are on the near-term roadmap, prioritized by design-partner demand.

Why we publish this list: the reporting discipline is that we only report what we can prove — and the same standard applies to this website. Our build gates check that the capabilities we call live are backed by tests that run them; extending that enforcement across every module class is itself active work. The full honest-limits appendix is provided to your security architect before any engagement begins.

Compliance & contact

GhostTrace is a product of CySecTrust Inc. SOC 2 is in preparation; engagement-level controls — signed ROE, fail-closed scope enforcement, complete audit ledgers, entitlement-bounded execution — are in effect today. In one calibrated run, the scope governor logged 2,738 allowed and 542 denied requests with zero unauthorized widenings.

security contact

Reporting an issue to us

Found something in GhostTrace itself? We practice what we preach — write to [email protected] and include the evidence. We'll respond within one business day.

documents

Available to evaluating teams

The full technical & commercial reference, the verification-discipline and standing-rules documentation, the honest-limits appendix, and rules-of-engagement templates are available on request, under NDA where appropriate.