01
A joiner, mover, or leaver event is triggered by your HR system or IdP
A joiner, mover, or leaver event is triggered by your HR system or IdP
SOLUTION · BROWSER AUTOMATION
SOLUTION · BROWSER AUTOMATION
Browser Automation for SaaS Provisioning and Deprovisioning
Govern the ~40% of mid-market SaaS apps without SCIM or an API. KINT runs deterministic browser automation with signed SOC 2 evidence, in one JML workflow.
14-day trial · No card · Live in under an hour
KINT runtime
Browser Automation for SaaS Provisioning & Offboarding
Browser automation is one routed execution path inside the same governed joiner-mover-leaver workflow: SCIM where it's supported, direct API where one exists, browser automation for the rest.
Event fires
HRMS / IdP
Engine routes
SCIM / API / browser
Evidence
signed per action
PROOF PATH
How browser automation runs.
02
For every app in the user's access set, KINT picks the correct method automatically
For every app in the user's access set, KINT picks the correct method automatically
03
For a browser-automation app, KINT opens the admin console headlessly and removes or deactivates the account
For a browser-automation app, KINT opens the admin console headlessly and removes or deactivates the account
04
A screenshot and structured action record are taken at each step
A screenshot and structured action record are taken at each step
05
Each record is signed with Ed25519 and appended to the same audit packet as SCIM and API evidence
Each record is signed with Ed25519 and appended to the same audit packet as SCIM and API evidence
WHAT IT HANDLES
The execution paths KINT routes.
SCIM, direct API, and browser automation all land in one signed, timestamped evidence packet that covers access removal across the entire stack.
Source truth
Governed action
Audit evidence
Roughly 40% of mid-market SaaS apps don't support SCIM, and many have no provisioning API at mid-market plan tiers
Browser automation drives the admin console the way an IT admin would, but deterministically and with signed evidence
KINT runs SCIM, API, and browser automation paths inside the same joiner-mover-leaver workflow
Adobe Admin Console is live today; Figma, Canva, Notion, Loom, and Miro are in progress
WHY IT MATTERS
What browser automation does
Browser automation provisions and deprovisions SaaS apps that don't expose a SCIM endpoint or a provisioning API. It scripts the exact actions an IT admin takes by hand — sign in to the admin console, find the user, remove or deactivate the account, unassign the license — and runs them automatically when a joiner, mover, or leaver event fires from your HR system or IdP.
That matters because the standard lifecycle model has a blind spot. Identity providers and most lifecycle tools push changes to apps over SCIM. SCIM works well for the apps that support it. For the rest, nothing happens automatically. Industry research suggests around 40% of mid-market apps don't support SCIM at their plan tier, and a large share of those have no usable API either. Browser automation is how you govern that part of the stack without paying an enterprise-tier upgrade for every app.
KINT treats browser automation as a first-class execution path, not a fallback of last resort. A leaver event revokes a user's GitHub access over the API and their Adobe Creative Cloud seat over browser automation in the same workflow, and both produce the same signed evidence.
Why SCIM and APIs don't cover the whole stack
The SCIM tax
Vendors gate SCIM behind an enterprise plan. Notion offers SCIM only on Enterprise; its Business plan includes SSO but deliberately excludes provisioning. Asana puts SCIM on its Enterprise tier (~$35/user/month) when most teams are on Advanced (~$25) or Starter (~$11). Adobe's Teams plan has no SCIM at all, and even Adobe Enterprise SCIM only syncs from Microsoft Entra or Google Workspace and won't assign licenses.
No provisioning API
Some apps just never built a provisioning API at the mid-market tier. There's no endpoint to call, gated or otherwise.
The real options
The IT operator has the same three real options: pay the enterprise-tier tax, accept manual offboarding for those apps, or automate the admin console directly. Browser automation is the third option.
Deterministic, idempotent, fail-closed
Three properties separate governed browser automation from a brittle script:
- Deterministic: the flow takes the same path every run, so the evidence is consistent and reviewable.
- Idempotent: if the flow runs twice (a retry, a duplicate trigger), it detects the account is already removed and logs "already completed" instead of erroring or double-acting.
- Fail-closed: if the vendor changes the admin UI and a step can't complete, the workflow alerts IT and waits, rather than silently skipping the deprovision and reporting success.
Live apps versus in progress (honest, as of June 2026)
Browser automation is an expanding subset of KINT's connector catalogue. Here's the real state, not the roadmap.
The source of truth for what's live today is /connectors. Across the whole catalogue, KINT runs 50+ live API and SCIM connectors (Starter) and 200+ mapped (Growth); browser-automation apps are the growing subset, with new ones shipping regularly. SCIM and API connectors are the majority of the live count today.
We'd rather tell you Adobe is the only fully live browser-automation app than imply five are live when they aren't. When Figma or Notion ship, /connectors flips first.
| App | Status | What KINT does |
|---|---|---|
| Adobe Admin Console | Live | Removes the user from each licensed product, screenshot per action, signed evidence, ~5 seconds per seat. Full walkthrough: /resources/blog/adobe-admin-console-deprovisioning-automated |
| Figma | In progress | Not live — do not rely on it yet |
| Canva | In progress | Not live |
| Notion | In progress | Not live |
| Loom | In progress | Not live |
| Miro | In progress | Not live |
How this compares to Cerby and Stitchflow
Three vendors take browser automation seriously for the non-SCIM problem. They solve it differently.
The honest read: Cerby is excellent if your problem is specifically a long tail of disconnected, credential-based apps, and you're comfortable with a demo-gated enterprise motion. Stitchflow is a strong fit if you want the work built and managed for you. KINT is for the IT operator who wants browser automation inside one transparent, self-serve lifecycle platform — the same workflow and the same signed evidence whether an app uses SCIM, an API, or the browser.
| KINT | Cerby | Stitchflow | |
|---|---|---|---|
| Core focus | HR-driven JML across the whole stack | Nonstandard / disconnected apps (founded 2020) | SaaS management + last-mile lifecycle |
| Non-SCIM method | Browser automation as one of three routed paths | Credential + access automation for disconnected apps | Headless browser agent that runs locally on an IT machine |
| Public pricing | Yes — $3 / $5 per employee on the site | No (demo required) | No (demo required) |
| Self-serve setup | Yes — OAuth, under 5 minutes | Demo-gated | Demo-gated, managed-leaning |
| Audit evidence | Ed25519-signed, per action, SOC 2 CC6.3 | Platform-managed | Reconciliation + access reviews |
| Best for | A 100–500 IT team that wants to run it themselves | Teams with a heavy long-tail of disconnected apps | Teams that want IT automation built and managed for them |
What to check in any browser automation tool
Whether you evaluate KINT or anyone else, five questions separate a robust implementation from a brittle one:
- Does it capture per-action evidence, or just a completion log? A SOC 2 auditor wants the screenshot, not the word "done."
- Is the evidence signed and tamper-evident? Ask the signature standard. KINT uses Ed25519.
- Is it idempotent and fail-closed? A retry shouldn't double-act, and a UI change shouldn't silently skip a deprovision.
- How are admin credentials stored? Plaintext in a script is a liability; a secrets store is the baseline.
- Does routing happen automatically? If IT has to flag and configure each non-SCIM app by hand, the overhead cancels the benefit.
Pricing
Browser automation is included on the Growth plan and above.
14-day free trial. No card. No automatic conversion. The founding offer is currently open for the first 5 Growth customers: $1.50/employee/month, 12-month price lock, in exchange for case-study collaboration. Three spots remaining as of this writing.
| Plan | Price | Browser automation |
|---|---|---|
| Starter | $3/employee/month | Not included (50+ SCIM + API connectors, JML workflows, SOC 2 CC6 audit trail) |
| Growth | $5/employee/month | Up to 5 non-SCIM apps + access intelligence + all 200+ mapped connectors (50+ live today) |
| Custom | Talk to us | Unlimited browser automation + custom connectors + 99.9% SLA |
The ~40% of your stack that SCIM can't reach is still your responsibility at audit time. Browser automation is how you cover it without paying the enterprise tax on every app.
14-day trial · No card · Live in under an hour
FAQ
What is browser automation for SaaS provisioning?
Browser automation scripts the admin-console actions an IT admin would take by hand — sign in, find the user, remove or deactivate the account, unassign the license — and runs them automatically when a joiner, mover, or leaver event fires. It covers the apps that don't have a SCIM endpoint or a provisioning API, which is roughly 40% of a mid-market stack. KINT runs these flows deterministically and signs the evidence for each action.
Why can't SCIM or an API handle every app?
Two reasons. Many vendors gate SCIM behind an enterprise plan or don't offer it at all — Adobe's Teams plan has no SCIM, Notion's is Enterprise-only. And a large share of apps have no public provisioning API at mid-market tiers. So an IdP-pushes-to-app model only ever reaches the SCIM-supported apps. Browser automation reaches the rest without an enterprise-tier upgrade.
Is browser automation reliable enough for a SOC 2 audit?
Yes, with the right evidence model. The automation must produce a per-action screenshot, signed with a recognised standard (KINT uses Ed25519), timestamped, and tied to the HR event that triggered it. A log entry that says "completed" is not audit evidence; a signed, verifiable record is. KINT maps that record to SOC 2 CC6.3 — the same standard as its SCIM and API paths.
Which apps does KINT support with browser automation today?
Adobe Admin Console is fully live: KINT removes the user from each licensed Adobe product, captures a screenshot per action, and signs the evidence, in about 5 seconds per seat. Figma, Canva, Notion, Loom, and Miro are in progress and should not be treated as live. The current status is always on /connectors.
How is KINT's browser automation different from Cerby or Stitchflow?
Cerby specialises in nonstandard apps and is demo-gated with no public pricing (founded 2020). Stitchflow runs its browser agent locally on an IT machine and leans toward a managed model. KINT runs browser automation as one of three routed execution paths inside the same joiner-mover-leaver workflow, with transparent per-employee pricing and self-serve OAuth setup. The signed evidence standard is identical across SCIM, API, and browser paths.
Does browser automation store admin passwords in plaintext?
It should not, and KINT does not. Credentials live in a secrets store, and the automation runs against the admin console without exposing a plaintext password in a script. Ask any browser-automation vendor how credentials are stored and used before you connect an app.
Can it run multiple non-SCIM apps in parallel?
Yes. A leaver with five non-SCIM apps triggers all five flows concurrently, not one after another. Sequential execution at five apps would stack up; parallel execution keeps the whole leaver workflow inside the same fast window as the API and SCIM steps.