Getting started
Choosing your path: sensor or API
Two ways to bring your non-human identities into TrustFix — the agentless API connectors (no install) or the read-only on-prem sensor (data stays inside your network). Both converge on the same findings, the same platform.
TrustFix collects your non-human identities two ways, because they live in two different places. The choice is only about where the data is read — both paths converge on the same findings, the same trust graph, and the same remediation. This page helps you pick, then points you at the install steps for each.
The two paths
Path A — API connectors (agentless, nothing to install)
TrustFix reaches your cloud, source-control, identity-provider, and secrets-manager APIs directly, using a read-only grant you authorize once (a cross-account role, a GitHub App install, an org-level service account, a read-only token). We fan out from one org-root grant across every account, project, and repository beneath it. Nothing is installed in your estate, and we never write to it during connection or scanning.
Best for cloud-native and SaaS-heavy estates. Amazon Web Services and GitHub work end-to-end today; the remaining connectors are built and in validation.
Path B — On-prem sensor (data collected inside your network)
For estates you run yourself — Active Directory, HashiCorp Vault, Kubernetes, your application database, self-hosted CI — a lightweight read-only sensor runs inside your network. It reads the central systems where access is defined, then forwards signed observations to TrustFix. It is not a per-machine agent: one sensor per network zone reads a handful of services and covers the identity surface of hundreds of machines. You never list a machine's IP address.
Best for on-prem estates, air-gapped networks, or any team that wants collection to happen inside its own boundary for data-residency reasons.
Which path does each system use?
| Your system | Path |
|---|---|
| AWS, Google Cloud, Azure, Oracle, Alibaba | API connector |
| GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins, CircleCI, Buildkite, Argo CD | API connector |
| Okta, Entra ID, Auth0, Ping, JumpCloud, Google Workspace | API connector |
| CyberArk, Akeyless, Doppler | API connector |
| HashiCorp Vault | API connector or on-prem sensor |
| Kubernetes | API connector or on-prem sensor |
| Active Directory / LDAP | On-prem sensor (no cloud API) |
| Your PostgreSQL roles & privileges | On-prem sensor |
| A CI runner's on-host credentials | On-prem sensor |
| Local accounts / SSH keys / cron secrets on individual machines | On-prem sensor (optional per-host sweep) |
Some systems — Vault and Kubernetes — support either path: connect them over the API if you're cloud-native, or read them with the sensor if they live inside your network. Active Directory and your database catalog have no cloud API, so they use the sensor.
Decide in three questions
- Is your identity source a cloud or SaaS API you can grant read-only access to? → Path A. Connect it from Onboarding. AWS and GitHub need no extra infrastructure.
- Is it a system you run inside your own network (AD / Vault / Kubernetes / database / CI), or do you need collection to stay inside your boundary? → Path B. Deploy the sensor from Realtime monitoring.
- Both? → Do both. Connect your cloud over Path A and deploy the sensor for your on-prem systems. They merge into one set of findings automatically.
If you're air-gapped, Path B runs entirely on your network; connectors that would reach an external SaaS host are cleanly disabled, and remediation stays deterministic and offline.
Install Path A — API connectors
Go to Onboarding and connect each provider with its read-only grant. The step-by-step for AWS, GitHub, Google Cloud, and Azure is in Connect your estate. Every grant is read-only, and any token a connector holds is encrypted at rest.
Install Path B — the on-prem sensor
- Generate the ingest secret. In TrustFix, open Realtime monitoring and generate your ingest secret (shown once). The sensor uses it to sign everything it sends; the secret itself never leaves your network in a request.
- Mint least-privilege read-only credentials for each system you'll read (Vault, database, Kubernetes, Active Directory, CI). Each comes with an exact-scope recipe. The sensor only ever reads configuration and metadata — never a secret's value, never row data.
- Fill in one configuration file. It lists each service's endpoint and a reference to where its read-only credential lives — never the secret itself, and never a machine's IP. You can review it, diff it, and keep it in change control safely.
- Validate, prove read-only, and run. A built-in check confirms the configuration, and a second tool proves each credential is read-only by attempting a harmless write and confirming it fails — before the sensor ever runs. Then start the sensor. Findings begin streaming into the same screens your API connectors feed.
If you want to cover local accounts, SSH keys, or hardcoded secrets that live only on individual machines, turn on the optional per-host sweep — it reads that surface agentlessly and reads only metadata, never the secret values, and learns which machines exist from your existing inventory.
One platform, either way
However your data arrives, it lands in one place: the same findings, the same trust graph, the same remediation and evidence. You can start with one path and add the other at any time.