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?

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

1. 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.
2. 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.
3. 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

Each component you run inside your network enrolls itself with a one-time code and receives its own credential. There is no organization-wide secret to copy around, and nothing is ever pasted into a configuration file.

1. 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.
2. Mint a one-time code. An owner or admin opens Realtime monitoring → On-prem, selects + Add component, picks Sensor (or Policy enforcement point, to front your MCP servers) and a site, and selects Mint one-time code. The console shows the code once, together with four commands. The code works once, expires 15 minutes after it is minted, and is bound to your organization, that site, and that kind of component.
3. Download and unpack the signed kit. On the host, run the first three commands: paste the code at a hidden prompt (it never goes on a command line, so it stays out of the process list and your shell history), download the signed kit with it, and unpack it. The download does not use up the code.
4. Fill in the sensor's configuration file (trustfix.sensor.yaml, in the kit). It lists each service's endpoint and a reference to where its read-only credential lives — never the secret itself, never the one-time code, and never a machine's IP. You can review it, diff it, and keep it in change control safely.
5. Install. Run the fourth command. The installer verifies the kit's signature and checks every argument before it spends the code; the component then redeems the code inside its own container and receives its own credential, written straight into its own state volume. If the code expires before you get here, mint a new one.
6. Prove read-only and run. Every time the sensor starts, before it collects, it proves each credential-bearing source is read-only — a harmless write must be refused — and refuses to collect otherwise. Findings then begin streaming into the same screens your API connectors feed.

Agent passports are delivered the same way: open Agent Authority, select the passport, and choose Deliver by code. The code is bound to that passport and a site, and the agent host generates its own key when it redeems it.

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.