What is Inth?
Inth is privacy change management for software companies that ship fast. It connects what a company has promised to what its engineers just shipped.
Inth connects what a company has promised to what its product is doing now. It checks code and the running product for privacy changes, turns them into work someone can review, and keeps the decision and proof beside the change.
The product changes every day
Most privacy failures start as ordinary product work. Someone adds an SDK in a pull request, changes a vendor setting, opens a new region, or ships an AI feature. None of it looks like a legal project when it lands in GitHub.
Meanwhile, the privacy record lives elsewhere. It is spread across policies, spreadsheets, screenshots, questionnaires, and Slack. It starts going stale as soon as the next release ships.
That gap is why we built Inth. A company should be able to answer a plain question: does the product still match what we tell users and customers?
The missing layer
Companies already have security scanners, legal tools, privacy platforms, and GRC systems. Each sees a different part of the business. Security can find a vulnerable package. Legal can read the contract. Privacy can record the vendor. GRC can show that a control exists.
Then an engineer ships a change and the company still cannot answer the question that matters: does the product still match what we promised?
That connection is usually left to people, spreadsheets, and Slack. Inth keeps it with the change. The existing tools do not need to disappear; they need a way back to what is happening in the product now.
Inth follows the change
Inth starts with code and production because that is where the facts are. A scan or runtime observation becomes an inbox item with the file, vendor, domain, consent state, or policy mismatch attached.
- Detect change
- Inth spots a new SDK in a pull request or a new domain in production.
- Review it
- The item lands with the team that owns the decision. Engineering can fix it; privacy or legal can review it without asking for a tour of the codebase.
- Keep the proof
- The report keeps the finding, reviewer, rationale, fix, and validation together.
Where c15t fits
We began with c15t because consent forced us to solve privacy inside the product. It gives developers native, inspectable consent controls instead of a blocking script and a black-box dashboard. The cookie banner is our way into the problem; Inth follows the code, production changes, vendors, and decisions around it.
The work crosses teams
Developers install Inth because the work starts in code and production. Privacy, security, legal, and platform teams use it once those changes need a decision.
Privacy work rarely belongs to one role. A developer knows why an SDK was added. Privacy knows what users were told. Legal can judge whether that is enough, and security may need the answer for a customer review.
Inth puts the same item in front of everyone. No one has to reconstruct the story from a pull request, a policy, and a Slack thread six months later.
Where Inth stops
Inth does not give legal advice. It shows what the product did, what changed, and what the team already decided. People still make the call.
A scan is only the start. Inth keeps watching after the first finding so the team can see whether a fix reached production and whether the same problem came back.
The product record we want
We want a company to open Inth and see the privacy history of its product, not a snapshot assembled for the last audit.
Today the pieces are code scanning, website observations, consent, vendors, DSAR, chat, and review history. We are joining them into one record so a change can be found, discussed, fixed, and checked again.
When the product changes, the privacy record should change with it. Nothing to reconstruct six months later.