Product

One platform for machine identity
discovery, detection and rollout-safe control.

Identrail does the three things every team is currently stitching together with scripts and CSVs: see every identity, prioritise the ones that can reach something dangerous, and remediate without breaking production.
Production workspace

Reachable risk path

Critical
01GitHub OIDC
02AWS IAM IdP
03billing-prod role
04PostgreSQL ledger
Ownerpayments-api
FixRestrict subject claim
The four pillars

What's actually inside Identrail.

Each pillar maps to a real subsystem in the open-source repo. Click through to the source if you want to see how a specific control is implemented.
01 · Trust graph

A single graph of every machine identity and every path it can take.

Identrail ingests IAM principals, role chains, OIDC trust policies, Kubernetes service accounts, RBAC bindings and resource ACLs across every environment you connect, then resolves the closure: who can reach what, through which hops, under which conditions.

  • Cross-account AssumeRole resolution
  • OIDC federation through GitHub Actions, EKS, GKE
  • Conditional policies (PrincipalTag, source IP, MFA) honoured
  • Workload identity → cloud identity stitching
02 · Detection

Severity tied to what an identity can actually reach.

A "high severity" finding only counts when the path resolves to data, money or control. Identrail prioritises by reachable resource sensitivity, not by signature counts, and explains each score with the exact chain it scored.

  • Path-grounded severity, not heuristic
  • Detections shipped as inspectable rules in OSS repo
  • False-positive feedback closes the loop in the same UI
  • Suppression rules scoped to identity + path, not detection ID
03 · Simulation

See the smallest safe fix before you ship it.

Every recommendation runs through a policy simulator that replays recent activity against the proposed change. You see exactly which workloads — by name — would have lost access, and you can scope the fix down until none do.

  • Policy diff with annotated impact
  • Workload-named blast radius, not just resource counts
  • Dry-run, canary, enforce — three rollout gates
  • Rollback is one click and reverses cleanly
04 · Operator surface

A console designed for the people who actually own the resource.

Findings route to the resource owner, not into a security queue. The operator surface is the same trust graph the security team sees — so the conversation is "we both look at the same path" instead of "let me forward you a CSV."

  • Auto-derived ownership from tags, repos, namespaces
  • Per-finding playbook with the safe fix pre-staged
  • Slack, email, GitHub PR — no extra dashboard to learn
  • Audit trail of who saw what, who fixed what, when
Stack coverage

The systems Identrail watches today.

Each connector is read-only by default. New stacks land in the open-source repo before they ship in the hosted product.
Read-only by default

No write scopes until you explicitly opt in.

Connector setup uses scoped read-only credentials. Policy enforcement is gated behind a separate opt-in with named approvers. We can't change something we can't write to.

Self-host the same binary

Identical artifact for OSS, hosted, and private tenancy.

We don't run a separate "enterprise" fork. The hosted plan and the self-host run the same image, with the same detections, the same simulator, and the same audit log.

See it on your data

Connect once. See your first trust path in minutes.

A free scan covers a single AWS account or Kubernetes cluster, returns findings in under ten minutes, and writes nothing back.