The redacted notebook problem
Somewhere in the world right now, a scientist is taking a photograph of a paper lab notebook, uploading the image to SharePoint, and using an image editor to manually draw black boxes over the parts of the page they don't want a CRO to see.
(Sending best wishes to that scientist).
At the core, this is an IP problem. Biotech is, by economic value, almost entirely IP. The system most companies use to control who sees that IP, once the work involves anyone outside the four walls of the company, is SharePoint, which is essentially a system that knows the names of files but nothing about what's in them. It can tell you that a folder has been shared with a CRO. It cannot tell you whether the folder should have been, because it doesn't know what's in the folder beyond a filename and a file type.
The reasoning about what's actually safe to share has nowhere to live inside the tool, so it ends up living in the head of the scientist with the image editor.
File systems are bad at handling biotech permissions
Unlike most other fields, the unit of collaboration in biotech isn't a file. A given experiment lives inside a project, which connects to a set of compounds, which connect to other experiments on the same compounds. The data model that captures all of this, for any team actually tracking R&D in a structured way, looks more like a graph than a folder tree. The access question is therefore not "can this person open this file" but "given that this person can see this node, what else can they reach from there, and is any of it something we don't want them to see."
That's not a question SharePoint is built to answer. It’s not really a question any file-level access system is built to answer.
The collaboration patterns make it worse. A typical biotech doesn't have one or two clearly trusted counterparties. It has a CRO in one country running an in vivo study, a different CRO somewhere else running a screening assay, a Pharma partner whose co-development deal covers part of the pipeline but not other parts, an academic collaborator on a separate program. Each of those relationships has a trust profile that isn't binary. You trust the CRO to run the assay competently and report the results honestly, and you don't trust them (as a matter of policy and not as a matter of the relationship) to have a complete view of the rest of your work. The tooling has to be able to express that kind of partial, scoped, context-aware trust.
Why has nobody solved this?
Most software tools started single-player, with sharing added later as a feature. A lab notebook that began as a place where one scientist writes notes ends up with a permissions model shaped by that origin, where the basic question is who can edit and who can comment. That doesn't get you a system where a CRO sees the existence of an experiment and the structured deliverable they're meant to produce without seeing the underlying data the company doesn't want them. That requires permissions to be part of the data model rather than wrapped around it.
The second reason this hasn’t been solved is that the customers who would benefit most from permissions don't have a clear mental model of what's possible, so they don't ask for it. When we tell enterprise customers our permission system can express almost any rule they want, the reaction is often a confused pause, because they've spent their careers working around the limits of file-level access and don't have the vocabulary for what they'd do if those limits weren't there. We've actually had to simplify what we expose by default, because the full surface area turns out to be too much to navigate cold. The demand is real, but it's latent in a way that's hard to surface through a survey or a feature request
Advanced permissions for humans and agents
What you get from a permissions system that understands the work, rather than just the files, is the ability to share what you wanted to share without also having to share everything connected to it.
A scientist shares a project tree with a CRO, so the CRO sees the deliverables and timing and structured tasks, while the underlying experimental data stays internal until it's been reviewed. A Pharma partner gets visibility into work on the targets covered by the co-development agreement without being able to traverse the graph to the targets they don't have rights to. None of this requires the human at the center to do anything unusual. It requires the system to know enough about the work to enforce the rules they would have enforced manually if they'd had the time, which is most of what tooling is for.
When we launched advanced permissions in Kaleidoscope, we were also building for the future. A biotech company in 2026 doesn't only collaborate with CROs and Pharma partners and academic labs. It collaborates with AI agents that read from its data and write back into it. Those agents need access too, and they need it scoped the same way a CRO's access is scoped to the specific work they're doing and nothing else. Our permissions system doesn't care whether the collaborator on the other side is a contract chemist or a model. It enforces the same rules either way.
Overall, advanced permissions is one of our favorite features at Kaleidoscope. It's the part of the platform we think is going to matter most in five years.
Kaleidoscope is a software platform for Life Science teams to robustly manage their R&D operations. With Kaleidoscope, teams can plan, monitor, and de-risk their programs with confidence, ensuring that they hit key milestones on time and on budget. By connecting teams, projects, decisions, and underlying data in one spot, Kaleidoscope enables R&D teams to save months each year in their path to market.