Why We Refuse to Read Your Files.

When we designed the SCOUTz collector architecture, we made a decision that cost us features and I'd make again tomorrow: the platform does not read content. Not documents, not email bodies, not files, not chat messages. Configuration and metadata only. Settings, permissions, policies, usage patterns. Never the words inside anything.

I want to explain why, because the distinction between config and content is the most important line in this entire category, and most vendors hope you won't look at where they've drawn it.

Configuration is the shape of the environment. Which accounts have admin rights. Whether MFA is enforced. What apps hold permissions. Where mail is being forwarded. What licenses sit unused. Everything an MSP needs to assess risk, find waste, and verify insurance answers lives at this layer. Content is the environment's substance: the actual contracts, the actual payroll file, the actual email thread about the merger. Reading configuration tells you whether the vault is locked. Reading content is opening the vault.

The industry has normalized a pattern: a lot of security tooling asks for content permissions it doesn't strictly need, because broad access is easier to build against and because "we could but we promise we won't" has become an accepted answer. It shouldn't be. A promise is a policy, and policies change. They change when a company gets acquired, when a product team finds a monetization angle, when one engineer makes one bad decision. If the permission exists, the client's protection is the vendor's ongoing good behavior, forever.

Architecture doesn't have that problem. When the permission was never granted, there is nothing to behave well about. Our access can be read by anyone, the client's IT counsel, their insurance carrier, their most paranoid board member, and the answer to "can this tool read my documents" is not "they promise not to." It's "they can't." Those are different sentences, and business owners can hear the difference.

This costs us things, and I want to be honest about that. There are findings you can only produce by reading content, and competitors will happily list them as features. We looked at those features and concluded the trade was terrible: marginal findings in exchange for becoming one more vendor the client has to trust with everything. The entire premise of what we've built, of the whole trust-first approach I've been preaching for years, is that MSPs win by being the most trustworthy party in the room. You can't sell that while holding permissions you're asking clients not to think about.

So the fence stays. Config, not content. By design, not by policy. If a tool asks your clients for more than that, ask the vendor the question we made sure nobody ever has to ask us: why do you need it?