Method

How Sifr works, and how you can check it

Sifr reads your identity platform, never changes it, and puts a named expert's signature on everything it tells you. This is how, in the order it happens.

From your tenant to your inbox

  1. Read

    We collect 13 kinds of signal from your SailPoint tenant: source health, sync runs, provisioning errors, virtual appliances, identity errors, certifications, ownership, API credentials, configuration and more.

    Every request goes through one read-only client. It allows GET, and POST only to a short list of read-only operations, such as search queries and the configuration export. Anything else is refused before it leaves our process, and a test covers every connector.

  2. Decide

    Deterministic rules decide what is wrong and how serious it is, from P1 (joiners or leavers are broken, or an exposure is live) to P3 (hygiene). The same data always gives the same result. No AI sets a severity.

  3. Explain

    An AI model groups related findings into root causes and explains them in plain English. Before it sees anything, names, email addresses and other personal details are removed; it gets configuration, counts and error text.

    Tenant text is passed to it only as data, never as instructions. It has no tools, its answer must fit a fixed format, and every object it mentions must exist in your data. If not, the answer is rejected.

  4. Sign

    A named expert reviews every root cause against the evidence, confirms or changes it, and signs it with an Ed25519 key. Nothing is signed automatically, and nothing unsigned reaches you.

  5. Verify

    Every report carries the signatures and hashes needed to check it against the keys we publish. The sample letter on our home page checks its own signature in your browser as you read it, and our Verify page will do the same for any report, with nothing uploaded.

What we need from you

A dedicated service identity in your tenant, holding a personal access token limited to read scopes. The Health Check page lists every scope and what each one is for.

In SailPoint, a token's rights are the overlap of its scopes and its owner's user level. Some read endpoints, such as the configuration export, need an admin user level, but a token with read scopes can still only read.

What we keep, and for how long

  • Each snapshot of your tenant is hashed, and the raw responses are encrypted at rest.
  • We keep 13 months of history, so we can show what was known, and when, for any date in that period. Older snapshots are deleted.
  • An append-only, hash-chained ledger records what the engine did. Each signed report records the ledger's latest hash, so an edited, deleted or reordered entry is caught.
  • Your token is never logged and never sent to an AI model.

Where it runs

The engine runs as a container. It can run inside your own network, so your data never leaves it, or be hosted by us. Either way, you receive the same signed findings.

What we don't do

  • We never change your tenant, not even a one-click fix. We hand your team the exact change to make.
  • We don't replace SailPoint's own alerts or Harbor Pilot. We sit above them: we group, look ahead, and sign.
  • We don't give you another dashboard to log into. You get a letter.