tiga
Identity governance you review in a pull request, not click through in a GUI.
One governed taxonomy in CUE derives every name, tag, and access rule in your estate. Every proposed change is a commit, reviewed before it lands. tiga starts fully read-only, and nothing holds a credential until you turn on gating.
The problem
If you've scoped an identity governance rollout, you already know this list:
- Resource names and tags diverge —
billing-prodin GCP,BillingProdin GitHub,billing-prod-awsin AWS. Nothing speaks the same language, and no rule engine catches it because there's no single source of truth for what the name should be. - Access decisions are scattered across Terraform, GitHub teams, manual role assignments, and exception spreadsheets that are months out of date by the time an auditor asks for them.
- Certification campaigns happen once a quarter and prove what was true when someone clicked "approve," not what's true today.
- Joiners get incomplete access. Leavers keep credentials for months because deprovisioning depends on someone remembering every system they touched.
- Every system integration means another connector holding another set of standing, broadly-scoped credentials.
Why not a traditional IGA suite
This isn't a knock on the engineering behind SailPoint, Saviynt, or the rest. It's what a GUI-first, connector-first architecture optimizes for. tiga starts from different constraints.
Traditional IGA suites
- Rules live in a vendor's GUI; audit means exporting screenshots and configuration reports.
- Certification campaigns are a point-in-time spreadsheet exercise.
- Connectors need broad, standing write credentials from day one, for every system.
- A name or tag is "close enough" across clouds, and people reconcile the rest by hand.
- Rollout is a multi-year, professional-services-heavy project before you see value.
- Proprietary, seat-licensed, and your governance model lives in their schema.
tiga
- Rules live in git. Every change is a pull request with a diff and an author.
- Every grant traces to the commit that approved it: audit is "read the log."
- Starts fully read-only. No credential with write access exists until you switch on gating.
- Names and tags are derived from one taxonomy and proven unique before anything renders.
- Roll out one system at a time, behind a gate that scores blast radius before a human approves.
- Source available, self-hosted, no seat-based licensing. The taxonomy is a file you own.
How you'd actually roll this out
This is a scoping exercise your platform and security architects can run, not a vendor statement of work.
- Model your taxonomy. Write one CUE schema for how your org already names and tags things: environments, business units, systems, roles, who holds what. This is a design conversation, not a deployment.
- Point it at your estate, read-only. tiga's collectors observe your existing systems and surface the drift between what's declared and what's actually there. No write credential exists at this stage, so there is nothing to break.
- Turn on the gate. Every proposed grant or account change becomes a reviewed change. The gate scores blast radius and separation-of-duties before a human approves it. Still nothing writes to a target system.
- Converge one system at a time. Flip a single target from gated to enforced; tiga reconciles desired access as a set against it. Accounts move through a lifecycle: deactivated and reassigned, never silently deleted.
- Audit becomes "read the diff." Every access decision that ever took effect is a commit with an author, a review, and a reason attached. No quarterly certification spreadsheet to assemble.
Where tiga is today: steps 1–3 (taxonomy, read-only observation, and the gate) are built against an in-process target. Step 4, against real systems, is the current work. If you're scoping a future IGA refresh, this is the point to look at the architecture before committing budget elsewhere.
Where tiga sits
Infrastructure creation stays exactly where it is: your Terraform, your pipeline, your review. tiga only supplies a small versioned file of names, tags, and access rules for it to consume — the same way you'd pin any other dependency.
Get involved
If this matches a gap in how you're governing access today, open a discussion. Tell us your environment, your compliance framework, and what your current process actually costs you. Early conversations shape what ships first.