Plant. Continue. Investigate.
FalseTrail is one system with three parts, named the way the operator console groups them: Placement Fabric creates the false opportunities, the Deception Runtime gives them somewhere believable to lead, and Operations is where your team reads and runs the result.
Every false opportunity, accounted for.
A placement is one planted artifact at one location on one host. FalseTrail creates it from a pack, your tooling puts it in place, and the console tracks it from creation to retirement.
| Pack | What is planted | It carries | Leads to |
|---|---|---|---|
deploy-env-v1 | A deploy .env file | a service credential and a service URL | Auth service, Admin API |
mcp-config-v1 | An MCP client configuration | a service credential and a service URL | Auth service, Admin API |
kubeconfig-context-v1 | A standalone kubeconfig | a cluster token | Cluster API |
- Unique to its location. Every planted value belongs to one placement, so any use names where it came from.
- A bundle, not an agent. Each placement produces the file, a manifest (path, mode and SHA-256, never the value), a create-only install script, Ansible tasks and a receipt template.
- Create-only. A placement never replaces or edits an existing file. The kubeconfig pack is a standalone file and is refused at real cluster configuration paths.
- Receipts from your tooling. Deployed, verified and removed receipts must match the manifest’s checksums, and can name the asset in your inventory.
- A plan with limits. Target groups say where trails belong; prohibited zones say where they must never go, and are enforced when a placement is created.
- Lifecycle: Learning → Armed → Retired. A use after retirement still reports, with the placement shown as retired.
- FalseTrailCreatedbundle ready for your tooling
- Your toolingDeployedreceipt · Ansible job 4411 · create-only copy
- Your toolingVerifiedreceipt · checksum confirmed on the runner
- LearningLearning reportwhat legitimately touches it
- LifecycleArmedhealthy report, or an override with its reason
- LaterRetiredremoved by your tooling, with a receipt
Learn first. Arm what’s clean.
Scanners, backup, indexing and CI automation touch files. New placements start in Learning, so FalseTrail can see what legitimately reaches them before they count at full severity. Uses still alert while learning.
Nothing unexplained touched it. Ready to arm.
Something touched it that no pattern or tester explains.
Legitimate activity keeps reaching it. Probably the wrong spot.
Not enough time or traffic to judge yet.
- Arming needs a healthy report or an override with a recorded reason.
- Narrow benign patterns. Known automation is described by at most a /24, optionally a client fingerprint, for one placement, and expires within 90 days.
- Registered testers let your own red team’s uses be recognised as testing, with the match shown on the finding.
- History stays as recorded. A new pattern or tester applies to future uses. Existing findings are never rewritten.
Not a dead end. A controlled synthetic trail.
A planted opportunity leads into synthetic services that answer like the real thing. Each one can hand out material for the next, so the actor keeps moving, and every step stays on a path you control.
- enters from kubeconfig context→ a synthetic Secret holds a client secretS4Cluster API
A Kubernetes API server with read-only RBAC in one namespace. Writes are refused, and recorded as attempts.
- enters from .env or MCP config credential→ issues an admin tokenS2Auth service
An OAuth client-credentials service. It exchanges a client secret for an admin token that only works here.
- enters from service referenceS3Admin API
The decision point: five synthetic opportunities offered side by side. Privileged actions are performed in the synthetic world.
Bounded: one synthetic world from a versioned template, holding no real data.Reachable only through what you planted; never in your production path.The Cluster API is optional, chosen at install.
Bounded, synthetic and recorded at every step.
The services answer from one synthetic world built from a versioned template. Material they issue works only inside that world, and each piece is recorded before it is shown, so the next step can be linked back to the trail that produced it.
- Issued material: admin tokens, service credentials and export job IDs, each tied to the chain that led to it.
- Responses are never built from request bytes. Names a request supplies are not echoed back; the world answers with its own identifiers.
- Refusals are real behaviour. The Cluster API refuses writes with RBAC errors; the admin API refuses disabling audit logging. Both are recorded as attempts.
- Template upgrades in place. A newer world template starts a new epoch with the same seed; material issued under the previous epoch keeps working.
The Decoy runtime view: how far trails went at each synthetic service, counted from facts and causal links only, and which opportunities were taken at the decision point.
Give the trail a choice. Record the choice.
With an admin token, a trail reaches the synthetic admin API, where five opportunities sit side by side: service account credentials, a data export, credential rotation, a role grant and audit log settings. Which ones are taken, in what order and with what outcome becomes evidence on the finding.
A finding your team can investigate.
A finding names the placement, the source and the decoy, draws only causally linked steps as the path, lists observed choices, keeps correlated activity as context, and carries an Investigate panel and a JSON export. It reaches your SOC as a notification line your forwarder ships.
Run it like your own infrastructure.
The console shows whether the installation is healthy, what is deployed, what needs a person and what was caught. A first-trail checklist takes a new installation from install to its first finding.
- Overview: health, deception coverage, what needs a person, and what was caught in the last day and week.
- System: readiness checks the service will not start without, durable delivery queues between components, version and world template, backup and self-test.
- Kill switch for decoy responses, and an audit trail of operator actions in the console.
- Is this installation healthy?running, every readiness check passes
- Can an operator use the console?an operator account exists
- Does the decoy path reach your SOC?safe self-test: notification written
- What will you deploy?a placement and its bundle
- Do you have the deployment material?files, manifest, install script, Ansible tasks
- Did your tooling report the deployment?deployed, then verified
- Is the placement live?armed after Learning
- Can you see a finding?the first use of your placement
Each unanswered step shows the exact command to run next.
Put a false trail in front of your next attacker.
Evaluate FalseTrail on your own estate. We start with a walkthrough on a sample environment, then scope an evaluation inside your network.
- A finding followed from first interaction to evidence trail
- Where placements would fit in your estate
- How it deploys and what stays inside your network