Ekoin Torii

What renews next?

Zoom renews first, on Dec 15, at $38,400 a year.

#it-ops

Mara Ellison 9:41 AM

@Eko how many Figma seats are unused?

Eko APP 9:41 AM

18 of 120 Figma seats haven't been used in the last 30 days.

Claude Code

> What did we spend on AI tools last quarter?

⏺ eko - ask (MCP)

$184,200 across 11 AI tools.

Largest: OpenAI at $71,400.

>

SaaS moved fast, AI accelerates it

For most IT and Procurement teams, SaaS was never a static inventory. New apps arrive through expense reports and free trials. Licenses drift away from what people actually use. Renewals come due on their own schedule, ready or not.

AI adds new layers on top of that. Teams build their own internal apps. Usage is billed in tokens instead of seats. API keys and secrets spread across tools. Integrations link systems that used to stand alone. And AI features now ship inside software you already approved, quietly changing what that software can reach.

None of these is a separate problem. A single new AI tool touches spend, access, security, and vendor risk at once. The work is not only bigger. The decisions are more connected, and each one depends on context from the others.

Management is more than visibility

Torii helps IT and Procurement manage SaaS and AI together, so spend stays optimized and governance stays strong as the stack evolves. Seeing everything in one place is the foundation. As environments get more complex, we believe a management platform should carry more of the load on top of it.

That means interpreting what is happening, pointing out what deserves attention, and helping your team respond. It is the standard behind this update to Eko.

What’s new in Eko

Eko now brings three things together: trusted answers from your own data, the ability to recognize patterns across your environment, and the means to act on what it finds once you approve. Here is what that looks like in practice.

Answers from your own contracts, not general knowledge

Eko reads your contract and gives you the answer. A missed notice window can lock you into another term at the old price, so a fast, accurate answer here translates directly into money.

It reads how your environment actually works

#it-ops

Desmond Vale9:41 AM

@Eko explain what our offboarding workflow does.

EkoAPP9:41 AM

Your Employee offboarding workflow starts when someone's status changes to Terminated in BambooHR. Then it:

1. Waits until their last day of work
2. Removes their access to every app connected through Okta
3. Opens a ticket for each app owner where access has to be removed by hand
4. Transfers their Google Drive files to their manager
5. Posts a summary in #it-ops on Slack

One condition: if the person is a contractor, it skips the file transfer.

Source: Workflows › Employee offboarding (5 actions, 1 condition)

Eko explains the workflow you built, with its real triggers, conditions, and steps, rather than a generic description from the help center. That helps when you inherit a workflow, review one, or need to walk an auditor through it.

It knows where you are

Ekoin Torii

On page: Zoom › Users · 14 selected

What happens if I click Remove users on this page?

Remove users takes the 14 people you selected out of Zoom.

They lose access right away, their licenses go back into your available pool, and each person's manager gets an email from Torii.

Heads up: 3 of the 14 used Zoom this week. You may want to filter by Last used first.

Eko sees the page you are on, so it can tell you what an action will do before you take it. You act with confidence instead of testing in production.

It builds things worth sharing

Ekoin Torii

Build a renewal tracker.

Here are your renewals through March 2027: 6 contracts worth $412,000 a year.

App	Renews	Annual cost
Zoom	Dec 15, 2026	$38,400
Atlassian	Jan 8, 2027	$96,000
Slack	Feb 1, 2027	$74,500
Salesforce	Mar 31, 2027 Notice by Jan 30	$186,000

+ 2 more renewals

Open trackerShare

Eko pulls your upcoming renewals into a tracker you can review, refine, and send to finance or leadership.

It compares the apps you already pay for

#procurement

Peter Kilian9:41 AM

@Eko we pay for ChatGPT and Claude. Which one should we renew?

EkoAPP9:41 AM

Recommendation: renew Claude (high confidence).

Claude has more active users, more assigned licenses, and higher tracked spend, so it's the cleaner renewal case. ChatGPT has fewer active users and messages, and its billing data doesn't line up. If you can keep only one, Claude is the easier renewal to defend.

	Claude	ChatGPT
Active users (30 days)	412	268
Paid seats	450	400
Licenses assigned	438	391
Usage (30 days)	48,900 messages	17,300 messages
Active contract	Yes, renews Jun 2027	Yes, renews May 2027
Tracked spend (12 months)	$198,000	$156,000
New charges	None	$4,800 not on the contract

I wouldn't cancel ChatGPT until its seats and billing are reconciled.

Ask which of two overlapping tools to keep, and Eko weighs them on your own data: active users, paid seats, usage, contracts, and spend. It also tells you when that data doesn’t add up.

It supports decisions before you buy

Ask Eko to compare vendors on pricing and security certifications, and it returns a side-by-side view with sources you can check yourself.

It turns a request into a recurring job

Eko

Elliot Jenson9:41 AM

Check every license has a cost each week, ping the app owners, and send me a report.

EkoAPP9:41 AM

Here's the weekly job I'll set up. It won't run until you approve it.

Weekly license cost check

Every Monday at 9:00 AM

1. Find licenses with no cost attached
2. Message each app owner on Slack to add the cost
3. Email you a report of what got fixed and what's still missing

This week it would flag 23 licenses across 7 apps.

ApproveEdit

One request covers all three parts: Eko finds the pattern (licenses with no cost attached), takes the action (notifying the owners), and reports back, every week, with your sign-off on what it does.

From a single answer to a standing process

A fast answer helps today. The larger payoff comes when a finding becomes something that keeps working after the conversation ends.

When Eko sees the same issue more than once, such as licenses with no cost, apps nobody opens, or renewals that keep arriving late, it points out the policy to tighten or the task worth automating. You review the suggestion and approve it. From then on, it runs as the stack grows, without anyone scheduling an audit.

Ekoin Torii

Policy gap: ownership is inconsistent.

1,240active apps have no owner

185active contracts have no owner

Recommendation: Run a weekly policy that flags missing owners, asks the likely owner to confirm, and prepares updates for approval.

Set up weekly policy

This is the link between everyday assistance and governance at scale. Each question your team asks can leave the environment in better shape than it was before.

What it means for each team

IT

The work you already do goes faster. Eko also points out policies worth tightening and tasks worth automating, then carries them out when you approve. Governance keeps improving between audits, and your team gets time back for the projects that need people.

Procurement

Answers about contracts and renewals arrive in seconds instead of after a search through folders. Patterns like underused apps or renewals that keep landing late surface early. That means better timing on every renewal and a stronger position at the negotiating table.

Leadership

Governance improves continuously, and a person approves every action. The stack stays optimized and within budget as AI adoption grows, without adding risk.

All three teams meet at the same point: governance that keeps up with how fast the stack changes, with people in control.

Your team stays in control

Eko proposes and people decide. Whenever Eko would change something, whether that’s a policy, an automation, or a message to app owners, it waits for your approval first.

That is what lets Eko take on more of the work without asking you to give up oversight. Your team sets the direction, and Eko helps carry it out across a stack that keeps growing.

SaaS and AI will keep compounding. With Eko, your governance can compound too.

Try it today: open Eko on any page in Torii and ask it something about your own stack.

Why this is the right next step

Tal, Uri Nativ, and I started Torii in 2017 with a problem we could not get anyone to care about. Software was piling up inside companies faster than any team could keep track of it, and every tool we looked at covered one slice of the picture. Nobody could answer the basic questions. What do we have? Who uses it? What does it cost? We wanted one piece of software to manage all software. Most of the people we pitched told us that was not a real category, so we built it ourselves.

Others followed, and SaaS management became a category. This year, Torii was named a Leader in the 2026 Gartner® Magic Quadrant™ for SaaS Management Platforms, for the third consecutive year.

Nearly a decade later the problem is bigger, and AI has made it harder. Consumption pricing does not fit the way anyone budgets for software, and most of these tools arrive without IT hearing about them. Fixing that at scale means software management cannot sit in a tool of its own. It has to run inside the systems IT already uses: the service desk where access gets granted and offboarding happens, the CMDB where the rest of the estate is tracked, and the ITAM and ITSM workflows where contracts, renewals, and approvals already live. Software is the layer that has been missing from all of it.

So today, we’re sharing our news: Freshworks has entered into a definitive agreement to acquire Torii. Freshservice is already where IT teams across industries and geographies run their day-to-day operations, and Torii extends that same footprint into software and AI spend.

Freshworks has spent years on the hardware and infrastructure side of the estate, and on the service desk that runs on top of it. The piece it has not had is software: which applications are actually in use, who is using them, what the licenses cost, and what AI is quietly running up in consumption charges. That is what we have spent nine years building. Put the two together and IT teams can manage all of it in one place instead of stitching it together across separate tools.

What this means for customers

Between signing and closing, Torii operates as an independent company. Your instance, your integrations, your workflows, your support contacts and your renewal terms are exactly where they were yesterday. The roadmap has not changed, our product teams are working on the same projects they were working on last week, and we are still shipping and still signing new customers.

What changes over time is what stands behind the product. Freshservice already runs inside IT organizations around the world. The software and AI governance you bought from Torii will sit next to the service desk, the CMDB, and the asset management those teams use every day, instead of living in a separate tool somebody has to remember to open. Many of you brought Torii in when this problem was not on anyone’s priority list, and you argued for it internally before it was obvious. That is the reason we are here. Thank you. Once the deal closes, we’ll share more about what we’re building together.

If you have questions, please reach out to your Torii contact.

This post contains forward-looking statements. The transaction is subject to customary closing conditions, and there can be no assurance as to its timing or completion.

For years, a SaaS renewal negotiation went roughly the same way. The vendor sent a quote a few weeks out. Someone checked it against last year’s invoice, asked for a few points off, and signed. The seat count rolled forward because nobody had time to argue with it.

That model is breaking, and Microsoft is the clearest example of why. Its July 2026 price increase is the one on every renewal calendar this winter. But the change that did the most to your bargaining position happened eight months before that, and it came with a lot less noise.

Here’s the uncomfortable part. The vendor walks into the call knowing how many seats you bought and how many people actually log in. Most buyers walk in with last year’s invoice and a spreadsheet called something like licenses_FINAL_v3.

This piece is about closing that gap. It covers what to pull 90 days before a renewal, how to model the tier mix and the metered charges, what to ask for and when, and what to write into the contract. Microsoft is the worked example because it’s the renewal everyone is watching. The method is meant for every renewal on your list.

Microsoft’s 2026 price increase started in November

On November 1, 2025, Microsoft removed its Level B through D volume discounts on Enterprise Agreement and MPSA online-services renewals (Microsoft Licensing). Those tiers used to reward larger customers with a lower per-seat price. The change doesn’t bite on the day it was announced. It takes effect at your next agreement renewal or new purchase, with on-premises and Government/Education excluded.

SoftwareOne estimated the impact on affected EA and MPSA customers at 6 to 12% (SoftwareOne). That’s a third-party estimate, not a Microsoft figure, but it gives you the order of magnitude. And it lands before the July list prices even enter the math.

Then came the headline change. On July 1, 2026, Microsoft’s US commercial list prices moved like this (Microsoft 365 Blog; US Cloud):

• Office 365 E3: $23 to $26 per user per month (13%)
• Microsoft 365 E3: $36 to $39 (8%)
• Microsoft 365 E5: $57 to $60 (5%)
• F3: $8 to $10

Put the two together and the picture changes. If you’re on an EA or MPSA and your renewal falls in the Q4 or January cluster, your quote can carry both increases at once: the lost volume discount and the new list price. A team that budgeted 5% for its E5 renewal because that’s the number in the press coverage is probably budgeting low.

Two caveats before going further. These are US list prices, and very few large customers pay list. And the November change applies only to EA and MPSA (Microsoft Licensing). If you buy through a Cloud Solution Provider or on an MCA-E, your price and discount are set by the partner and aren’t published anywhere, so treat the numbers here as a way to size the change, not a quote.

None of this is secret. Some licensing advisers have written about the November-to-July connection. What your reseller’s renewal email usually won’t do is hand you the numbers you’d need to push back on it. Those numbers come from license tracking, and our comparison of enterprise software license management tools shows which tools track Microsoft agreements and which track SaaS seats.

Pull four numbers 90 days before the renewal

Ninety days gives you time to find the problems, fix some of them, and still have a position before the vendor’s quote arrives. If you’d rather have software start that clock, our comparison of renewal management software scores seven tools on lead time and usage data. Four numbers do most of the work.

Active users vs. licensed seats. How many seats you pay for, and how many people used the product in the last 30 or 90 days. One way I’ve heard the gap put is “owned vs. used vs. assigned,” and it’s a useful split: seats you bought, seats assigned to a person, and seats that person actually uses. Each gap has a different fix.

Last-login distribution. A single average hides the story. You want the spread: how many users logged in this week, this month, this quarter, and not at all. The long tail of people who haven’t logged in for 90 days is where the easy savings sit.

Feature usage by tier. A premium seat is only worth it if the person uses the premium features. For Microsoft, that means knowing who actually touches the capabilities that separate E5 from E3.

Contract value vs. invoiced spend. What the contract says you committed to, against what you were actually billed. Mid-term additions, true-ups and add-ons drift, and the renewal quote usually starts from the higher number.

What does this kind of pull turn up? Our benchmark report puts license non-utilization across a dozen widely deployed enterprise apps between 24% for Slack and 55% for Salesforce (Torii). Read that as seats not earning their keep rather than a precise, defined rate; the report doesn’t publish its method. It also doesn’t include Microsoft, so don’t carry those percentages over to your 365 estate. The same report found about 2.5% of seats in paid apps still assigned to people who had left the company (Torii). That’s roughly 1 in 40, sitting on an invoice, belonging to nobody.

Your numbers won’t match these. But almost nobody’s come back clean.

Match each seat to the tier it needs

Once you know who uses what, you can model the tier mix. This is where Microsoft’s price gaps matter more than the increase itself.

At the new US list prices (Microsoft 365 Blog), Microsoft 365 E5 costs $21 per user per month more than E3, or $252 a year. E3 costs $29 a month more than F3.

Here’s an illustrative example, using list prices. Take a company with 1,000 users, all on E5. The July increase from $57 to $60 adds $36,000 a year to that bill. Now say the usage pull shows 200 of those users never touch an E5-only feature. Moving them to E3 saves 200 × $252, or $50,400 a year.

Right-sizing a fifth of the seats saves more than the entire price increase. That’s the argument for doing the tier work before arguing about the sticker price.

The same logic runs down to F3, Microsoft’s frontline tier. It’s far cheaper and far more limited, so check what each group of users actually does before moving anyone. A blended model, meaning the count of seats on each tier multiplied by its price, is what you take into the call.

One trap sits inside E5. Security Copilot is included with Microsoft 365 E5 and E7 as a monthly capacity allowance: 400 Security Compute Units per 1,000 licensed users, with no rollover (Microsoft Learn). Unused units disappear at the end of the month. That’s worth knowing in both directions. If you cut E5 seats, you also cut the allowance. If your security team leans on Security Copilot heavily, the allowance may run out, which matters for the next section.

Model the metered charges as a range

Seat prices are the easy part to forecast. The harder part is anything billed by consumption.

Microsoft has announced a pay-as-you-go rate of $6 per SCU for Security Copilot usage beyond the included allowance. As of this writing, it isn’t live. Microsoft says it will start “at a future date,” with 30 days’ notice (Microsoft Learn). You’ll see some renewal coverage describe it as an active charge. Microsoft’s own page says otherwise, and it’s worth checking before you budget against it.

So how do you plan for a charge that doesn’t exist yet? As a range, not a number. Your low case assumes you stay inside the allowance. Your high case assumes your heaviest month of use continues after the overage switches on. If the 1,000-seat example above ran 100 SCUs over its 400 in a month, that’s $600 a month at the announced rate. Small on its own; not small once agents and other metered tools stack on top.

That stacking is the bigger pattern. More software is shifting to a seat price plus a usage charge, and the usage part is what surprises finance mid-year. I covered who ends up owning that bill in “FY2027 is the year finance takes over the AI budget,” the previous part of this series. For renewals, the practical step is simpler: give every metered line a floor and a ceiling, and show finance both.

Run the negotiation in a set order

With the numbers in hand, the sequence matters as much as the asks.

Start with utilization. Open with what you use, not with what you’d like to pay. “We have 1,000 E5 seats and 200 of them don’t use E5 features” is a different conversation from “can you do better on price?” It turns the call from a discount request into a correction of the bill.

Then ask for flexibility, not just a lower rate. Two terms carry most of the value:

• Swap rights, so you can move seats between tiers during the term as usage changes
• True-down rights, so you can reduce seat counts at set points instead of only adding them

A discount helps once. These terms keep helping every time your headcount or usage shifts.

Then time the ask. Vendor sales teams work to quarterly and annual targets, and a deal that closes inside the period counts toward them. For Microsoft, aim to have your position ready well before its fiscal year closes, and before the end of whichever quarter your renewal falls near. Getting your numbers together in the final week of the quarter is too late to be useful.

Write the terms into the contract

A good call is worth nothing if the terms don’t make it onto paper. Four clauses do most of the protecting:

• Price caps on renewal increases, stated as a percentage
• True-down at defined dates, with the minimum seat count spelled out
• Benchmark clauses that let you revisit pricing if the market moves
• Notice periods long enough to run this whole 90-day process before auto-renewal kicks in

Microsoft’s own language shows why term length is a pricing decision. Its FAQ on the 2026 changes says: “Customers on existing multi-year agreements will continue at their current pricing until renewal” (Microsoft Licensing).

Read that from the other side. A multi-year agreement protects you from repricing during the term, and the full weight of every change lands on the day it renews. So the price you lock in this winter is the base for the next cycle too. If the tier mix is wrong at signing, you’re locking in the wrong mix at the new price.

Repeat it for the rest of your top ten

Microsoft is the example, not the whole job. The same four numbers work for any renewal: seats against active users, the login spread, tier fit, and contract value against invoiced spend.

The benchmark range above suggests where to look next. If a widely deployed app can sit anywhere from roughly a quarter to over half non-utilized (Torii), your other large renewals probably deserve the same pull. Rank them by renewal date and contract value, and start the clock 90 days out for each.

The hard part is getting the data together, especially across ten vendors with ten admin consoles. Torii is one way to do that. For Microsoft 365 Copilot specifically, it syncs purchased, assigned, and unassigned seats, plus prompts and active days over 7, 28, 90, and 180-day windows (Torii Product Updates).

So start with one. Find your largest renewal in the next six months, count back 90 days, and put the seat pull on the calendar for that date. If the 90-day mark has already passed, pull the numbers anyway. A late count still tells you which tier mix to ask for, and it’s cheaper to find the wrong mix now than to lock it in for another term.

Torii’s AI Management Platform closes that gap. It pulls AI usage and spend from browser-based tools, developer CLIs, vendor admin APIs, and the integrations you already run. Then it cross-references everything against your HRIS, your identity provider, and your financial data, so you get one live view of who is using what, what it costs, and whether it’s paying off.

The AI Module hit general availability on September 3, 2026, and the updates haven’t slowed down since. Here are 11 ways to put it to work, from the first “wait, we use how many AI tools?” moment all the way to governing the apps your non-engineers are vibe coding.

The 11 at a glance

1. Find every AI tool in the building
2. Put a name and a team on every dollar
3. Break your AI bill into the four ways AI charges you
4. Forecast next quarter’s AI spend before the budget fight
5. Give every department its own AI spend story
6. Learn what your power users know
7. Get full value out of every AI seat
8. Coach adoption instead of just counting it
9. Bring engineering’s AI coding agents into view
10. Go deep on any single AI vendor
11. Bring vibe coding out of the shadows

Part 1: See it, then price it

1. Find every AI tool in the building

You can’t manage what you can’t see, and AI is the fastest-growing blind spot in the stack. Torii’s own data found 694 new AI-native apps in 2025, and 26 of the top 50 shadow apps are pure-play AI. Odds are good some of them are already running in your org.

Source: Torii SaaS Benchmark Annual Report 2026, covering January to December 2025.

Torii maps your AI footprint from four directions at once:

• The Torii AI Lens browser extension picks up SaaS AI platforms like OpenAI, ChatGPT, Claude, Cursor, Lovable, and Base44.
• AI Telemetry tracks developer CLIs like Claude Code, Gemini CLI, and Codex.
• Vendor admin APIs bring in what each vendor actually bills you.
• Integrations you already have do double duty. Microsoft 365, for example, now feeds Copilot adoption data with zero extra setup.

That includes the tools nobody expensed. Torii flags unapproved AI in active use, even when it never touched a corporate card.

Why it matters: your AI inventory stops being a guess. IT, security, and finance all start from the same list.

2. Put a name and a team on every dollar

A big AI invoice raises one question fast: who did this? Torii answers it. Usage and spend are cross-referenced against your HRIS and identity provider, so every token rolls up to a person, a department, a manager, and a cost center.

And for the spend that doesn’t belong to any one person? The Cost Overview now has an Unattributed category. Click it and you get a breakdown by tool that explains why the cost landed there: org-level API usage, service accounts and automations, or credits billed at the workspace level. No more mystery line items.

Why it matters: chargebacks and budget conversations start with facts instead of finger-pointing.

3. Break your AI bill into the four ways AI charges you

AI doesn’t bill like SaaS. One tool charges per seat, another burns credits, a third meters every API call. Torii’s Cost Overview shows your total AI cost and splits it into:

• Subscriptions (the seats you pay for every month)
• On-demand credits (usage that runs past the plan)
• API and platform costs (metered model usage)
• Vibe coding (credits on platforms like Lovable)

Here’s the insight that makes this view so useful: as an AI program matures, spend tends to shift from subscriptions toward API and on-demand usage. Watching that mix over time tells you where your program actually is, not just what it costs.

For Cursor, OpenAI, Claude Platform, and Claude.ai, Torii syncs billed costs straight from the vendor admin APIs, daily, in USD. That’s the real invoice number, not an estimate.

Why it matters: you can explain your AI bill in one slide, and you can see which cost model is growing fastest.

4. Forecast next quarter’s AI spend before the budget fight

Torii tracks your AI spend over time and projects where it’s headed, so you know which numbers you’ll be debating next quarter before the meeting gets booked.

Two recent updates make this a finance team favorite:

• Finance-aligned time periods. Pick “Last month,” “Quarter to date,” or “Last quarter” to line up AI reporting with vendor invoices and your close.
• Export any AI Module table to CSV. Spend tables, adoption dashboards, and connected tool data drop straight into your planning model.

Why it matters: AI spend becomes something you plan for, not something that surprises you.

Part 2: Understand the people behind the usage

5. Give every department its own AI spend story

Every team uses AI differently, and Torii’s department breakdown shows exactly how. Pick a team and see its top AI tools, whether each one is billed on demand or by subscription, and where the money goes.

Take a sales team, for example. You might expect a CRM copilot to top their list. Instead, most of their spend is in Cursor, with a sizable Lovable bill right behind it. That’s not a problem to shut down. It’s a signal that reps are building their own tools, and it’s the start of a much better conversation with the sales leader.

Why it matters: department heads get a clear, specific picture of their AI footprint, and you walk into every budget review with context.

6. Learn what your power users know

Every organization has AI power users. Torii shows you who they are and what they’re actually doing.

Open any individual’s AI profile and you’ll see:

• Total token value, sessions, requests, and tokens used
• Activity over time
• Their model mix compared to the org average, thanks to the new model heatmap

The heatmap works at the team level too. The Adoption Groups view lays out groups against models, so you can spot which teams lean on premium models and click into any cell to see who’s driving it. Filter by provider, and switch between token share, absolute tokens, and value.

Why it matters: your power users are your best playbook. Find what they do well, then spread it.

7. Get full value out of every AI seat

AI seats are expensive, and an idle one is money on fire. Torii’s subscription efficiency metric shows how much value each person gets from their license. Subscriptions hand out tokens at a different rate than API billing, so this number tells you whether a seat is a great deal or a quiet waste.

From there, right-sizing gets easy:

• Spot the extremes. Surface inactive licenses, users on the wrong tier, and people ready for an upgrade.
• Catch idle seats early. Developer CLI tracking flags seats with no activity after 30 days. Microsoft 365 Copilot tracking flags seats unused for 90+ days, along with purchased, assigned, and unassigned counts.
• Take action automatically. Revoke, reassign, or notify without a ticket queue. With the new ChatGPT Enterprise integration, Torii workflows can invite, remove, change roles for, and manage group membership of ChatGPT members.
• Keep seat data fresh. Claude.ai Enterprise members, seat tiers, spend limits, and pending invites now sync nightly through Anthropic’s Admin API.

Why it matters: you pay for the AI people use, and the savings show up at renewal.

8. Coach adoption instead of just counting it

AI adoption isn’t a straight line. Some people can’t wait to try every new model. Others hold back, because of their role or just how they approach new tech. Both groups need attention, and the earlier you talk to them, the better.

Torii gives you three views to work from:

• The Usage dashboard shows company-wide token value, active users, sessions, tokens, daily model use, and an auto-generated AI summary.
• The Adoption dashboard breaks adoption down by department or org hierarchy and calls out the biggest movers.
• The AI Pulse dashboard is the live view: active users right now, AI calls per minute, token value rate, and a projection for the day, all over a continuously refreshing window of roughly the last five minutes. It even includes a map of where active users are and a “Model Pulse” that shows which models are busiest.

The aggregate view also highlights the people making the most efficient use of their tokens. Those are your champions for the rest of the company.

Why it matters: you can run an AI enablement program on data. Find the champions, find the stragglers, and help both.

Part 3: Go deeper where AI moves fastest

9. Bring engineering’s AI coding agents into view

Some of your heaviest AI usage never shows up in a browser. It runs in the terminal. Torii tracks LLM token usage from developer CLIs, including Claude Code, Gemini CLI, Codex CLI, and GitHub Copilot Chat in VS Code, across macOS, Linux, and Windows.

For each session, Torii captures the user, the model, input and output tokens, and errors. For Claude Code, it also records which tools and MCP servers ran, so security can see what agents are actually doing. The Productivity dashboard adds engineering signals like commits and code changes.

And it’s built to earn developer trust. Prompt contents are off by default, model responses are never captured, and there’s no keystroke logging, screen capture, or shell history collection. Roll it out however suits your team: through MDM (Jamf, Kandji, Intune, JumpCloud, and more), through an existing OpenTelemetry collector, or with a one-liner install for a quick pilot.

Why it matters: engineering AI spend gets the same attribution and governance as everything else, without slowing anyone down.

10. Go deep on any single AI vendor

Sometimes you need to zoom all the way in. Open any AI application in Torii and get the full picture for that vendor.

Open OpenAI, for example, and you’ll see how many members you have, projects ranked by spend, your daily spend rate, the last 30 days of spend, and recent billing history. Claude Platform costs break down by model and workspace. Microsoft 365 Copilot shows prompts and active days over 7, 28, 90, and 180 days, plus usage across Teams, Outlook, and the rest of Office.

Torii also keeps the data honest. If an AI source stops collecting, it shows a Failed status so you can fix the gap fast. If a custom OpenAI key expires or hits a rate limit, AI Settings tells you exactly what went wrong.

Why it matters: vendor reviews and renewals come with real usage behind them, not a sales rep’s slide.

11. Bring vibe coding out of the shadows

This is where things get exciting. Vibe coding gave non-engineers a superpower: anyone can build a working app in an afternoon. Until now, most organizations had no idea what those apps were, who used them, or what they connected to.

Torii changes that. For platforms like Lovable, you can see your credits, your spend, and a breakdown of your published apps. Then it goes a level deeper. The Integrations tab maps every internal app to the systems it connects to. One app might touch GitHub, Gong, and Segment. Another might reach into AWS, Gong, and Slack. Flip the view around to see every internal app connected to a single system, like GitHub.

Connect Lovable or Base44 to Torii and each internal app becomes a regular Torii app. You see who has access and how many users it has, user lists stay in sync automatically, and the apps flow into your existing offboarding, access reviews, and reports.

Why it matters: security knows exactly where to start, IT can set policy it can measure against, and your builders keep building.

One platform, every AI question answered

Those 11 use cases add up to one shift: AI goes from something that happens to your company to something you actively run. IT gets the inventory. Finance gets numbers that match the invoice. Security gets a map. And leadership finally gets a straight answer to “is this AI spend worth it?”

Bonus: you don’t even need to open a dashboard to get answers. The Torii MCP Server is now an official connector in Claude’s connector directory, so you can bring Torii data right into your AI conversations.

Ready to see your whole AI footprint in one place? Book a demo and find out what’s really running in your company.

A year ago, those same conversations would have been a mix of offboarding, license use monitoring, and NHI detection. But today, it’s all AI.

One CTO said that tracking their monthly LLM costs was like “open brain surgery.” Another put it more simply: they had been early adopters of AI, and now those bills were becoming a massive liability.

AI is not a feature, it’s a utility

AI consumption is the only number that matters, and it’s also the only number nobody can see.

Software used to be a fixed cost. You negotiated it once a year, signed, and the number sat still until renewal. You bought 500 seats, used 180, and argued about the difference twelve months later. Painful, but predictable. The decision that set the bill was made at signature.

A utility doesn’t work that way. You don’t buy it, you draw on it. It meters by consumption, it scales with usage rather than headcount, and it runs whether or not anyone is watching. The bill isn’t decided at signature. It’s decided every day, by behaviour, by thousands of small choices nobody logged.

That’s the shift. The buying unit used to be seats. Now it’s tokens. And the control point moved with it: procurement governed software, but metering is the only thing that governs a utility. You cannot negotiate your way out of a consumption curve.

Which is the problem, because a monthly bill for tokens tells you almost nothing. You don’t know who the heavy users are. You don’t know which teams or use cases are driving it. You don’t know whether the spend was worth it. You don’t even know what next month looks like. You just know the bill is growing.

The steam engine was never the expensive part

Nobody remembers what a steam engine cost. Ask an industrialist in 1870 about the price of the engine and you’d get a shrug. The engine was a one-time line item that stopped mattering the day it was installed. The fight that decided who won was over coal. Priced per ton, burned forever.

And the operators who pulled ahead weren’t the ones who negotiated the cheapest ton. They were the ones who learned to read what a ton of coal actually produced, output per ton, before their competitors could read it, and before the instruments that measured it were standard equipment.

That’s the part worth borrowing. Not “tokens are the new coal,” which is a fine line and a taken one. Palantir’s Shyam Sankar said it almost verbatim on the Q1 2026 earnings call, and every FinOps vendor has said it since. The narrower lesson is the one that mattered in 1870: the price of the input is the easy half, and the operators who win are the ones who read the output half first.

Tokens are further along that curve than coal ever was on day one, which is exactly the trap. The input meter is already precise. You can look up published list rates to the million tokens, Claude Sonnet 5 at $2 in and $10 out, Opus 5 at $5 in and $25 out. Compared to the old seat math, a per-token price reads clean. It reads like the problem got simpler.

It didn’t. It moved.

The input meter is nearly built. The output meter isn’t.

Two questions get blurred together, and the difference between them is the whole thing.

The first is what did we spend and who spent it. That’s cost attribution, and it’s getting solved. Not finished, but close enough that you can see the finish line from here. FinOps Foundation’s State of FinOps 2026 found that 98% of practitioners now manage AI spend, up from 31% two years ago. The same report names granular AI-spend monitoring, tokens and requests and GPU, as the top-cited missing capability.

Read that carefully, because it’s easy to misuse. The gap they’re describing is finer metering on the cost side. Even the input meter isn’t fully installed yet. That tells you the easy half is nearly done, not that the hard half has started.

The second question is what did the spend buy. And that one has no meter at all.

It shows up the moment the CFO question changes, which it already has. It used to be “what are we spending on AI.” Now it’s “what did we get for it,” and the answer is mostly silence: only about 7% of senior leaders report established AI ROI. Ninety-three out of a hundred can increasingly tell you the bill and cannot tell you the return.

That gap isn’t a pricing problem. It’s a measurement problem, and the instrument for it hasn’t been built.

The spend moves fast enough to matter

Look at the spread rather than the average. Ramp’s 2026 business spend data puts median monthly AI spend at $2,246 and average monthly AI spend at $140,842.

Sit with that for a second. The median company spends about the price of a decent laptop each month. The mean is dragged two orders of magnitude higher by companies running orchestrated, agentic workloads. That spread is the entire risk profile of the category. One unchecked agentic workflow is how you travel from the median to the mean without anyone filing a purchase order.

The mix underneath it is moving the same direction. On the same Ramp data, premium models account for 45.8% of tokens but 55.9% of AI cost, up from a rounding error a year earlier. And the cost of a single interaction has climbed with the shape of the work: roughly $0.04 for a single 2023 linear call, roughly $1.20 for a 2026 orchestrated agentic task. About 30x.

The mechanism isn’t exotic. Output tokens cost exactly five times input tokens across the entire Claude lineup, and an agentic task consumes 5 to 30 times the tokens of a single chatbot turn. A tool that talks back and forth to itself twenty times before answering is not twenty questions. It’s one question with a bill that fans out.

Gartner has put a stake in the ground on where this heads. In June 2026 it predicted AI coding token costs will surpass the average developer’s salary by 2028. Two months later it went further, predicting AI inference costs per agentic workflow will rise more than fivefold through 2028, with a warning worth keeping in one line: product leaders cannot rely on more efficient token economics to rationalise AI costs.

The cheap tokens get cheaper. The expensive work gets more expensive and less predictable. The average hides both.

Two instruments, one wall

The input meter reads price times volume. It’s nearly finished, it’s improving, and it’s the half every vendor is racing to perfect.

The output meter reads what the spend produced. Per token, per user, per project, across every AI tool actually in use. That instrument doesn’t exist as a product yet.

And the place it’s darkest is the place IT never approved. The AI tools people adopted on their own, the shadow AI stack, where the spend is real and the attribution is nothing.

That’s the ground worth naming, because it’s the ground the current tools don’t cover. Cloud FinOps platforms like CloudZero and Vantage do genuinely deep token attribution, but they face engineering and infrastructure and stop at the infrastructure layer rather than spanning the application layer or the tools nobody filed a ticket for. SaaS management peers work the other side of the house, the procurement and approved-spend layer. Zylo’s AI Consumption Cost Management shipped in 2026, alongside Vertice and Productiv. Flexera calls itself the only complete AI cost management platform, and it’s infrastructure-first.

Line them up and the coverage map has a hole in the exact shape of the question buyers are walking in with: token and user and project, across many AI tools, including the ones nobody approved, read from an IT or ITAM seat. That’s where an output meter would have to live, and it’s where none of them live yet.

So what did the token buy?

Nobody can tell you yet. That’s the point.

Every AI tool can already tell you what a token cost. None of them can tell you what it bought, and the second number is the only one that was ever worth having.

The industrial analogy makes one more prediction, and I don’t have the answer to it. Coal got its output metrics eventually. Thermal efficiency, cost per horsepower-hour, all of it became standard, and the edge that came from reading output first went away once everyone could read it.

So the real question isn’t whether someone builds the output meter for tokens across the whole stack, shadow AI included. Someone will. It’s whether the years before they do are long enough, and the edge wide enough, that reading output first is worth as much now as it was for the operators who learned to read a ton of coal before their rivals could.

I don’t know. But the people who dropped everything else to ask are betting it is.

For most IT teams, Patch Tuesday was a monthly chore with a familiar shape. Microsoft published its fixes, security sorted them by severity, and ops pushed them through testing and out to machines. The volume shifted, but it stayed within a range you could plan staffing around.

That model is breaking. Microsoft’s September release fixed at least 974 flaws in one day, and its year-to-date count has already passed the previous annual record, with a full quarter to go. The industry-wide numbers are climbing too.

Microsoft shipped 974 fixes in one day

On September 8, Microsoft patched at least 974 vulnerabilities, 113 of them rated critical, its largest Patch Tuesday on record, according to Krebs on Security. Two were zero-days already under attack: CVE-2026-81963 and CVE-2026-85880, both Windows privilege-escalation flaws (Krebs on Security).

That’s the headline most outlets ran. The more useful number is what came before it.

Four months of releases show a trend

Here are Microsoft’s monthly counts this summer, all from Krebs: roughly 200 in June, 570 in July, 398 in August and 974 in September.

The line isn’t smooth. August came in below July, so this isn’t a curve bending steadily upward. But the direction over four months is hard to miss.

The running total makes the point more plainly. Microsoft has patched more than 2,600 CVEs so far in 2026, more than double the 1,245 it patched in 2020, the previous record year (Krebs on Security). Krebs calls this the worst year on record, and October, November and December haven’t happened yet.

For a team that sized its patch process around 2020, that means more than twice the work flowing through what’s likely the same testing windows, and probably the same people.

Microsoft blames AI, and FIRST’s forecast points the same way

Microsoft’s explanation for the surge is AI-aided vulnerability discovery: better tooling finding more flaws in its code (Krebs on Security). That’s Microsoft’s account of Microsoft’s numbers, and nobody outside the company has verified it. It’s also a slightly awkward thing to announce. The good news is the bug-finding got much faster; the bad news is whose bugs they are.

The second signal comes from somewhere else entirely. In June, FIRST, the forum of incident response and security teams, published a mid-year forecast covering every vendor, not only Microsoft (FIRST.org). It contains two numbers that are easy to blur together, so here they are separately.

• The forecast moved up. FIRST now expects about 66,000 CVEs across the industry in 2026, up from the 59,427 it forecast in February. That’s a revision of roughly 11%.
• Reality is ahead of the old forecast. Actual CVE disclosures were running 46.3% ahead of what the February forecast projected for that point in the year.

The second figure is the one I’d pay attention to. It compares what actually got disclosed against the path FIRST itself expected, and the gap is wide. Both are mid-year figures, and they’re the most recent FIRST has published.

Keep the two signals apart. FIRST’s forecast says nothing about Microsoft, and Microsoft’s explanation says nothing about the industry. Neither explains the other. They’re two independent readings pointing the same direction: a lot more vulnerabilities are being found and published.

Volume is climbing faster than FIRST’s risk-filtered tally

But here’s the catch. The same FIRST release filters the pile down to vulnerabilities with real-world risk signals. That means entries in CISA’s Known Exploited Vulnerabilities catalog or an EPSS score above 10% (FIRST’s threshold for “likely to matter” in real-world context). On that filtered view, FIRST says the patching burden “has not materially increased, despite the surge in raw volume” (FIRST.org).

EPSS, the Exploit Prediction Scoring System, estimates a probability of exploitation; it isn’t a record of attacks, and FIRST’s counts date from May. What FIRST is saying is that the slice of vulnerabilities flagged as most likely to matter hasn’t grown in step with the total. But the dangerous fraction is shrinking relative to volume, which makes it harder to find, not easier to manage.

September’s two exploited zero-days might seem to contradict this, but they don’t. Two actively exploited flaws inside a release of 974 fits the pattern FIRST’s numbers imply: a small number of dangerous vulnerabilities sitting inside a much larger pile of ones that carry little near-term risk on their own. A flat aggregate doesn’t mean no month contains live exploits. It means the dangerous fraction is shrinking relative to everything around it, which makes it harder to find.

FIRST’s own people frame it the same way. Éireann Leverett, FIRST’s liaison, put it this way: “The challenge for defenders is no longer the discovery of vulnerabilities; it’s the capacity to verify, coordinate, and prioritize them at a scale the industry has never seen before” (FIRST.org). Jerry Gamblin, a co-author of EPSS, was blunter: “In 2026, the rain doesn’t stop. The job is no longer counting the drops. It’s knowing which ones will overrun the levee” (FIRST.org).

So the planning problem is a search problem. Finding the exploitable few gets harder as the pile grows, and that search starts with knowing what you’re running.

Microsoft is one software provider in a stack of hundreds

Everything above is about Microsoft or the industry total. Your exposure depends on your own stack, and Microsoft is one entry in it.

Our 2026 SaaS Benchmark report found the average organization runs 831 discovered applications (median 680), and the average enterprise with 4,000 or more employees runs 2,191. Those counts cover the whole discovered inventory: sanctioned apps, shadow IT, and apps that are blocked or still under review.

Most of those apps will never ask you to patch anything. A typical SaaS tool gets fixed by its provider on its own servers, and the customer never sees an update. So I’m not arguing that patch work scales with app count. It shouldn’t.

The obligation sits in a smaller, harder-to-see group: on-prem components, self-hosted instances, agents installed on endpoints, browser extensions. Those are the places where a vendor’s fix does nothing until someone on your side applies it.

Which raises the question the benchmark can’t answer. With hundreds or thousands of discovered apps in a typical stack, how many teams could actually name which ones carry a Microsoft-style patch obligation? Our report counts apps, not how each one is hosted, so it doesn’t measure how big that group is. My guess is that most teams couldn’t answer quickly, because the people who own the patch queue and the people who own the app inventory are often different teams, and the shadow part of the inventory frequently has no owner at all.

That’s why this lands well outside the security team. Security can triage a list of CVEs, but it can’t triage an app nobody knows is installed. The IT or ITAM lead owns the list that says what’s there. And the finance lead pays for all of it in hours, because every fix that needs testing and deploying is somebody’s time, and Microsoft’s volume alone has more than doubled.

An application discovery tool is one way to build the first half of that answer. Torii, for example, maintains an inventory of discovered applications across sanctioned and shadow IT, which is where the benchmark figures above come from. It doesn’t scan for vulnerabilities, track patch status or classify apps by hosting type, so it tells you what’s there, and someone still has to work out which of those apps need patching on your side.

A quarter is left in a year that has already doubled the record

Three Patch Tuesdays remain in 2026. Even three quiet months would leave it as Microsoft’s biggest year by a wide margin, since the total is already more than double 2020’s.

The standard advice this cycle, which Tenable’s Satnam Narang also gave in Krebs’s coverage, is to prioritize remediation by risk context rather than volume. That’s right as far as it goes, but prioritizing assumes you already have the list.

FIRST’s numbers say the risky slice is holding roughly steady. Microsoft says the pile around it keeps growing. Next year, will vulnerability management budgets go to patching faster, or to finding out what there is to patch in the first place?

Not a coordinated announcement. Not one big FinOps push. A steady drip of native cost controls, one vendor after another, all landing between June and August. Once you notice the rhythm, the rhythm is the story.

Who’s building the meter?

The people who sell the tokens.

Count the native spend controls across the major model-and-cloud vendor surfaces this summer, one per surface, and you get five. OpenAI added them to ChatGPT Enterprise on Jun 18. Anthropic shipped an Enterprise Spend Limits API for Claude on Jul 2. OpenAI brought hard project and org limits back to its API on Jul 22. AWS added cost controls to Bedrock AgentCore on Aug 6. Google shipped hard monthly spend caps to Gemini Enterprise on Aug 26.

Five, from Jun 18 to Aug 26. About ten weeks. Same season, same handful.

The exact count is soft, and I’ll say so. The inclusion rule is strict: one native spend control per major model-or-cloud vendor surface. Loosen it and the number goes up, not down. Anthropic shipped a session-budget control too. GitHub Copilot added budgets. Cloudflare’s AI Gateway has spend controls of its own. Count those and the cadence gets faster, never slower.

So the ordinal is a footnote. The cadence is the fact: the companies whose revenue is the meter running spent the summer building the switch to cap it.

Are these even the same kind of control?

No. There are two philosophies.

Anthropic and AWS bound a run. The limit sits on a session or a per-agent execution, and it fires when a single agent burns through its budget mid-task. OpenAI and Google bound a billing period. The limit is a monthly cap on the project or org, and it fires when the bill for the month crosses a line.

Bound-the-run versus bound-the-billing-period. Same anxiety, an agent doing something expensive when nobody’s watching, and two bets on where to put the brake. One vendor thinks the danger is a single runaway execution. The other thinks it’s the slow accumulation over thirty days.

What both bets share: each brake stops at the vendor’s own wall. AWS can cap a Bedrock run because AWS can see the Bedrock run. It cannot see the Gemini one. Google can cap a Gemini project because Google bills it, and has no idea what that same team spends on Claude.

Did all five vendors freshly build these?

Not quite. At least two are re-ships.

This is the tell worth slowing down on. OpenAI’s Jul 22 API control isn’t new. OpenAI had hard API spend caps, removed them earlier in 2026, and brought them back on Jul 22. Its Jun 18 ChatGPT Enterprise control isn’t net-new either. It’s a migration of an existing weekly limit to a monthly one. Anthropic, AWS, and Google are genuinely net-new to those surfaces. OpenAI, on two of the five, is adjusting a meter it already had.

That’s the part a pundit reading only the August release notes can’t write. Picture OpenAI shipping the hard cap, quietly removing it earlier in 2026, then reinstalling it in July and taking a bow for the new safety feature. A seller that can pull a hard spend cap and put it back whenever it suits the billing is telling you something plain: the meter isn’t a fixed customer-protection feature. It’s a dial the seller turns toward its own billing interest, on its own schedule. Which is exactly why a seller-built meter can’t be the buyer’s number. The buyer doesn’t control when it exists.

So the meter-builders are marginal players you can ignore?

The opposite. They’re already everywhere.

The same handful shipping these caps already sit in nearly every stack we see. OpenAI and Anthropic each show up in about 96% of those stacks, Gemini in about 82%, detected via SSO, finance, and browser extension, so read those as detection floors, not exact usage.

One clause of daylight, because it matters. That presence is of the brand. We detect that OpenAI, Anthropic, and Google are in the building. We are not detecting use of the specific agent or API surface each cap governs, the Bedrock AgentCore workload, the Vertex or Gemini Enterprise project, the raw OpenAI API. Presence is not proof the cap already binds anything. It establishes the one thing the argument needs: the vendors writing the meters are not niche. They’re the default.

And when the top work surface joins the cadence, the signal is loudest. Google Workspace is already the #2 app in our Adoption Index, ahead of Slack, Atlassian, and Microsoft 365, and that’s behavioral adoption, where work happens, not a spend ranking. So when that vendor ships a spend cap, it’s the surface most of your people already live on adding a meter.

What’s the actual problem with five good meters?

They’re bounded. Every one of them.

This is the whole thing, and it’s an argument from how the controls are scoped, not a number we measured. Each of the five caps is scoped to something the vendor bills: a project, a billing account, an API key, an org. That’s correct engineering. A cloud vendor should let you cap a project. Nobody built a bad meter here.

But name the dichotomy the scoping creates. Per-vendor wall versus cross-vendor question. Every shipped control is bounded by one vendor’s billing surface. The buyer’s real question crosses all of them and lands on a person: what does this employee cost across OpenAI, Claude, and Gemini, added up. None of the five meters can answer that. None can see the other two, and none was built to join spend to a named human.

I’ll concede the near miss, because it’s real. Cross-vendor cost aggregation already exists. CloudZero, Vantage, and Finout roll up multi-vendor spend, typically drawing on the vendors’ own Cost APIs. What none of those produce, and what the key-, project-, and account-scoped meters structurally can’t produce, is the join to the individual: what one named person costs across every model they touch. The aggregators sum accounts. The meters cap projects. The gap is specifically the human.

And a buyer went looking in exactly that gap. One prospective buyer deprioritized the entire SaaS-governance category to ask us a single thing: what does each employee cost in OpenAI, Claude, and Gemini tokens, across all three. Five vendors spent the summer shipping per-vendor meters. A buyer walked in asking for the number that lives between them.

So who wins?

Genuinely unresolved.

Two candidate units of account, and I don’t know which one takes over. There’s the vendor’s per-project billing meter: native, scoped, shipping fast, five deep in one summer. And there’s a cross-vendor, per-employee view of what each person costs across every model they touch, which nobody ships natively and which the buyer keeps asking for.

Maybe the per-project meter is enough. For a lot of orgs it might be, and the cross-vendor per-employee view stays a nice-to-have that never becomes the unit anyone budgets against. Or maybe the number that decides headcount and tooling is the one that crosses every wall and lands on a person, and the vendor meters end up as five inputs to a join none of them will ever make.

The vendors have placed their bet: the meter they own, scoped to the surface they bill. The open question is whether that’s the unit the buyer ends up managing by. And if it isn’t, who ends up owning the number that crosses all five walls.

An engineer leaves. IT does what it always does: disables the account in Okta, pulls the SSO grants, reclaims the laptop. On paper, the person is gone.

In practice, the Slack bot they wired to a shared channel is still posting. The Zapier connection they authorized still moves data between two apps every night. The AI agent they handed a service account to still has its access, and nobody remembers it exists.

None of those were tied to their SSO login. They were separate credentials, OAuth grants, integration tokens, an agent’s key, created directly against the apps. Deprovisioning a person doesn’t touch them. So the tokens sit there. No owner, no review, no expiry. Live.

That is the gap offboarding misses. You can revoke a person cleanly and still leave a trail of working machine identities behind them. The customers we hear from already have names for what that produces:

“orphaned after projects end,”

“service account sprawl,”

“invisible, ungoverned, and overprivileged”.

How bad is the sprawl, really?

Bad, and worse than anyone can agree on.

Non-human identities now outnumber human ones by a wide margin, and the count is climbing fast. But the exact ratio depends entirely on what you measure, and where. Different vendors offer widely different counts on how many NHIs are running through your org:

So the number is contested. Different vendors measure different environments with different methods, and the spread, 17:1 to 144:1 depending on the study, reflects that, not sloppiness. What none of them argue about is the direction. The non-human surface is now the larger one, AI agents are its fastest-growing slice, and it is compounding. Read 144:1 as the ceiling of a range, not a consensus.

So why can’t your SSO see any of it?

Because it was built to find people, and none of these are people.

Your SSO and IdP are built around people. They govern who a human is, what groups they belong to, what they can log into. Most identity tooling does that work, and does it well. That part is genuinely hard.

Here’s where it gets uncomfortable. It’s a human-identity model in a world that has gone non-human. When CyberArk surveyed the field, 88% of organizations defined only human users as privileged. The machine identities, the OAuth grant one SaaS app holds against another, the integration token, the Slack bot, the MCP server an agent runs through, never touch the IdP at all. They were provisioned directly, app to app. So when the IdP deprovisions a person, it reaches everything that person logged into and nothing they authorized on the side.

The industry conversation points the wrong way, too. Most writing about machine identity is cloud- and infrastructure-first: workload identity, Active Directory service accounts, secrets in a CI pipeline. That matters. But it steps right past the SaaS-app layer, the OAuth grants, integration tokens, bot tokens, and agents that live between the apps your company actually runs on. That layer is where a departing employee’s leftovers pile up. It is also the one nobody has claimed.

What does governing these things at the app layer actually take?

The same three things you already give a human account.

None of this needs another vault or another scanner. Treat every token and agent at the SaaS-app layer the way you already treat a person: give it an owner, watch it for staleness, wire it into offboarding.

Owner. The first question about any machine identity is the one nobody can usually answer: who created this, and who is accountable for it now? A token with no owner is a “decommission candidate,” in a customer’s own words. Attach a human owner to each grant and agent, and an anonymous credential becomes something you can review.

Staleness. Is it still doing anything? “Hasn’t authenticated in six months but still has privileged access” is how one practitioner named the exact failure. Last-use data sorts the tokens that earn their access from the ones that are pure standing risk.

Offboarding trigger. When a person leaves, their machine identities should surface as part of the same offboarding, the bot they built, the token they authorized, the agent they stood up. Then those credentials get a decision, instead of defaulting to “left running.”

This is where Torii sits. Our SaaS discovery already maps the app-to-app graph; it can see the OAuth grants and integration tokens between apps and attach a human owner and an offboarding trigger to each one. Visibility, ownership, and a trigger at the point of offboarding.

The data itself is not sitting in cold storage somewhere. Productiv’s site states that “all production systems, data stores, and backups have been permanently and securely destroyed. No customer data has been retained.” Productiv has never given a business reason for the shutdown.

One clarification, since the situation has been described loosely elsewhere: this was not a conventional bankruptcy. The public record shows that, effective June 25, 2026, Productiv, Inc. made a General Assignment for the Benefit of Creditors to PFS Productiv Liquidation LLC under California law, a state-law wind-down handled outside bankruptcy court in which a company’s assets pass to an assignee who liquidates them for creditors. Claims are being administered by Stretto, Inc. at cases.stretto.com/Productiv, with a filing deadline of December 22, 2026. If you think you have a claim, that deadline is the one to calendar. Source: the Stretto case page, which lists the assignor, assignee, effective date, governing law, and claims bar date.

Worth saying plainly: this was a hard week for the people who built Productiv, not just the people who bought it. A team lost their jobs, and a lot of admins lost a tool they genuinely liked and had staked internal credibility on.

If you’re one of those admins, the export advice everyone published in the first week — including ours — is now useless to you. So here is the version that still works: what’s actually gone, what you can rebuild, and how to get most of it back in 30 days.

What you lost versus what you can rebuild

Be precise about this before you promise anything to your VP, because the two halves have very different timelines.

Gone for good. Historical engagement and utilization trends — the multi-year record of who logged into what, how often, and how that curve moved. In-platform notes, tags, saved views, and workflow configuration. Your license-optimization baselines: the “we reclaimed 340 seats last year” numbers that justified the tool. Any benchmark data that was Productiv’s own, not yours. None of this exists anywhere. There is no backup, no escrow, no partner copy.

Recoverable. Your application inventory. Your annual and monthly software spend. Contract terms, renewal dates, and notice periods. App owners and business sponsors. Purchased license counts. Vendor contacts. All of it lives in systems you still control — your identity provider, your finance stack, your contract repository, your endpoints. Productiv aggregated that data; it did not originate it.

That distinction matters commercially, too. If a vendor offers to “restore” or “recover” your Productiv usage history, they are selling you something that cannot be delivered. The honest offer is help reconstructing the recoverable half faster, and starting a new engagement baseline today.

The four sources that get you to ~90% coverage

This is the core of the work. Four pulls, done in parallel by whoever owns each system, will reconstruct most of a mid-market or enterprise SaaS estate. Assign owners before you start — this stalls when one person tries to do all four.

1. Your identity provider. Okta’s System Log, Entra ID sign-in logs, or the Google Workspace audit log will give you every app users authenticated into, with unique user counts and last-sign-in dates. In Okta, export the app list with assignment counts and pair it with 90 days of sign-in events; in Entra, pull the enterprise applications list plus sign-in logs. This is your fastest path to the sanctioned app list and often takes an afternoon. What it misses: anything not behind SSO. Departmental tools bought on a card, free tiers, tools with local logins, and most of the AI apps that arrived in the last 18 months. Shadow IT is defined by its absence from this list.
2. Your finance systems. Pull 24 months of vendor-level spend from the AP ledger (NetSuite, Coupa, or your ERP) plus corporate card and expense feeds (Ramp, Brex, Expensify). Filter on software and subscription GL codes, but also scan uncoded vendors — that’s where the surprises are. This is your only real source for spend, and your best source for apps IT never knew existed. The obstacle is vendor naming: card descriptors like ADOBE *ACROPRO, resellers and marketplaces (AWS Marketplace, SHI, Insight) that mask the actual product, and parent-brand line items that cover several apps at once. Budget real time for normalization; it’s the least glamorous and most valuable hour of this project.
3. Contracts and email. Your contract repository, DocuSign’s completed-envelope list, and the procurement and AP inboxes together reconstruct renewal dates, term lengths, auto-renewal notice windows, and purchased seat counts. Search the shared drive and inboxes for “order form,” “auto-renew,” “renewal notice,” and “MSA.” What it misses: month-to-month and click-through agreements, which usually have no paper at all and show up only in the finance pull.
4. Endpoint and browser signals. OAuth grants (Google Workspace third-party apps, Entra enterprise app consents), browser extension inventories from your MDM, and installed-application reports from Intune, Jamf, or Kandji. This is the layer that catches free and freemium tools — the AI assistants, the note-takers, the design tools — that never touch finance or SSO. It’s noisy and needs filtering, but it’s the only source that sees them.

Then de-duplicate, and expect it to take longer than you think. The same app will appear in three sources under three names. Normalize on the vendor’s root domain rather than the display name, decide up front whether a suite counts as one app or several, and keep a single alias column so Atlassian, Jira, and JIRA SOFTWARE-ANNUAL collapse to one row. Do this once, deliberately, or you’ll ship an inventory with a 15% inflation rate and lose the room’s trust on the first review.

This four-source pull is what automated discovery does continuously rather than once.

Triage renewals before you finish the inventory

Do not wait for a complete estate map. A renewal inside the next 90 days is money leaving the building while you build a spreadsheet.

As soon as the finance and contract pulls are underway, build a single triage list sorted by next renewal date, with known or estimated annual value in the second column. Work only the next 90 days. For each line, do three things:

Confirm the owner. Not the person who signed it two years ago — the person who will defend the spend this quarter. Unowned renewals auto-renew by default, every time.

Find the notice deadline, not the renewal date. Most enterprise agreements auto-renew unless you give 30, 60, or 90 days’ written notice. The notice date is your real deadline, and for anything renewing in the next 60 days it may already have passed. Check this first; it changes what’s negotiable.

Make the call: renew, renegotiate, or kill. You’ve lost your utilization data, so you can’t argue seat reduction from a Productiv report anymore. You can still argue from purchased-seat counts versus IdP-assigned users, from headcount changes since the last renewal, and from department owners telling you plainly whether their team uses the thing. That’s weaker evidence than you had two weeks ago, and it’s enough to hold a renegotiation.

Two practical notes. Ask each vendor for their own usage numbers — most account teams will share seat activity on request, and for your largest apps that partially backfills what you lost. And if a renewal is genuinely un-triageable in time, a short-term extension at the current rate is almost always available and beats renewing blind for another year.

This list is also the artifact Finance actually wants. Send it to them at the end of week one, unfinished, with the coverage gaps labeled.

Rebuilding an engagement baseline

Your usage history is gone, which means the new clock starts today. Every day you delay instrumentation is a day missing from the dataset you’ll need at the next renewal cycle.

Set this up in week one, not week four. Confirm your IdP is retaining sign-in logs long enough to be useful and export them somewhere durable — default retention in most tenants is far shorter than a renewal cycle, and you will not get those days back. Connect directly to your ten largest apps by spend via API for last-active dates, license tiers, and seat assignments; those ten usually carry most of the negotiating leverage. Turn on SCIM where you can, so provisioning and deprovisioning generate a record instead of a ticket. Keep the endpoint and OAuth telemetry flowing rather than treating it as a one-time pull.

Do that and you’ll have 90 days of real utilization data by mid-November, and a full renewal cycle’s worth by next summer.

This is also the argument against solving the problem with a spreadsheet. A hand-built inventory is accurate on the day you finish it and starts decaying immediately — new tools appear, seats change, someone renews without telling you. Worse, a static inventory can’t produce a utilization trend at all, because trends require continuous collection. The rebuild is a one-time project. The baseline is only worth having if something keeps collecting after the project ends.

Doing this in Torii

Everything above can be done by hand. If you would rather not, here is what the same rebuild looks like in Torii, kept short because the method is the same.

Two connections start it. Connect your identity provider and your finance system. Discovery runs immediately against both, and the contract and endpoint sources layer in as you connect them. You are building workflows the same day instead of maintaining the spreadsheet you built last week.

Renewals come back first. Torii rebuilds the renewal calendar before the inventory is complete: current owner, the notice deadline rather than just the renewal date, and a renew, renegotiate, or short-extension decision for each line. That is the 90-day triage list from the section above, generated rather than typed.

What comes back. App inventory from the identity provider, software spend from AP and cards, contracts and renewal dates, app owners and sponsors, purchased license counts, and shadow SaaS and AI tools from browser and endpoint signals. What does not come back is the same for everyone: Productiv’s historical utilization trends, in-platform notes, saved views, and workflow configuration were destroyed, and no vendor can restore them.

Who does the work. You make the two connections. A Torii specialist validates discovery and builds your workflows alongside you. There are no agents to deploy, no services engagement, and no implementation fee.

If we ever part ways. You can export your inventory, spend, contract, owner, and license data by API or CSV at any time, on your own schedule. That is the data egress test from the next section, and you should run it while you are a happy customer.

Torii was named a Leader in the 2026 Gartner® Magic Quadrant™ for SaaS Management Platforms. The Productiv replacement page maps each Productiv capability to what Torii does.

What this changed about vendor selection

The obvious lesson is “pick a bigger vendor,” and it’s the wrong one. Company size is a weak predictor, and anyone using this moment to sell you their headcount is selling you a feeling.

The real lesson is narrower and more useful: ask about data egress before you sign, and test it while you’re a happy customer. Three questions belong in every SaaS evaluation from now on:

• Is there a documented, self-serve export of all my objects — inventory, spend, contracts, usage history — not a CSV of the current view?
• Is continued data availability for some defined window after termination a contractual commitment, or a support-ticket favor?
• Can I pull all of it via API on a schedule I control?

Then actually run that export quarterly and put the file somewhere you own. That habit, not vendor selection, is what would have made last week survivable.

We’ll publish the full vendor continuity questionnaire as a follow-up. In the meantime, the thing worth internalizing is that any promise of permanence — including ours — is worth exactly as much as your ability to walk away with your data.

Still comparing platforms? Our Productiv alternatives roundup covers the field, and the Productiv replacement page maps each capability to Torii.

Most of the new customers we onboard are coming off a spreadsheet.

To be fair, this isn’t new, it’s the normal. But it still struck me as important.

This came up on a recent call at Torii: a batch of new customers had just signed, and someone noticed that most of them were coming from a SaaS management process that relied entirely on one person updating a spreadsheet.

Is this a critical mass moment?

We’ve seen some recent consolidation in the SMP market with vendors like Productiv shutting down. And yet, the SMP landscape is only growing.

In 2025, Gartner claimed that “Through 2028, over 70% of organizations will centralize SaaS application management using a SaaS management platform (SMP), an increase from less than 30% in 2025.”

Adoption of SMPs is growing, and in 2026, it’s actually accelerating as more and more companies struggle to manage AI alongside SaaS.

So why has it taken so long?

Nobody owns the problem.

If most teams have not bought a tool for this, the question worth asking is why not. It is not that the tools are bad or that nobody cares. It is that the SaaS stack belongs to no single person.

Think about who touches it. IT, finance, security, procurement, and department heads each hold a piece of it. multiple owners, multiple priorities, and no one whose job title says “the software estate is mine.” A problem nobody clearly owns is a purchase nobody is clearly assigned to make.

Everything else about the slow adoption hangs off that. The spreadsheet is free, it is already open, and it mostly works right up until the renewal nobody caught. That renewal will not send a calendar invite, and the sheet is not going to volunteer that a seat quietly renewed for another year. When our offboarding conversations turn to the manual state, the way people put it is plain: “the list is only as good as the last time someone updated it”. That is not a complaint about a tool. It is the honest ceiling of a shared sheet that four teams half-maintain.

“SaaS management” is also young enough that most teams do not yet expect it as a budget line or a slot on the org chart.

So no, you’re not late to SaaS management… yet

If you’re still updating that spreadsheet by hand; bless you.

You’re keeping things on track, trying to monitor adoption, track spend, inventory the un-inventoriable, and anticipate the new surprise renewal. It’s not just hard work, it’s impossible in the modern workplace.

We say it all the time, but SaaS Management requires cross team collaboration. Not a single hero, but a structured effort that comes from the top. Now, in a world of shadow IT and rampant AI adoption, that effort of managing your software is more important than ever. When the effort turns into a search for a platform, our SaaS management platform buyer’s guide lays out how to run it.