This is the fifth and final part of a five-part series on cybersecurity, AI governance, and the future of biological research. Part 1 laid out the governance gap and its history, Part 2 put documented cases behind it, Part 3 looked at where the technology is headed next, and Part 4 set out the governance a research organization can build today.
Previously in this series: Part 1 introduced the three-layer governance gap, infrastructure, data, and model, and its history. Part 2 documented the cases behind it. Part 3 looked at where the technology is headed next. Part 4 laid out the governance practices a research organization can build today: BDL tiering, toxicology's e-validation discipline, TRiSM and Violet Teaming for agentic AI, and a practical checklist. This closing part gets specific about one platform's role in that picture.
The layer most organizations get wrong first
Part 1 of this series described the connection between cybersecurity and biological research as running three layers deep: the infrastructure, the data, and the model itself. Parts 2 through 4 spent most of their time on the data and model layers, because that is where the more dramatic failures live, biosecurity misuse, re-identification, algorithmic bias, dataset shift. But the infrastructure layer underneath all of it is where most research organizations have the least visibility, and it is the layer this part is about.
Most research organizations have never formally audited their Microsoft 365 tenant for access control. Shared drives accumulate permissions. Service accounts from old integrations retain access long after the projects they supported ended. A read-only scan of a typical research institution's environment will surface gaps that would not survive a clinical data audit, because no one has ever looked. Any model trained on data sitting behind those stale permissions inherits that exposure. If you cannot answer who has access to your training data and when that access was last reviewed, you cannot make a credible claim about the privacy protections wrapped around the model built from it.
This is the specific gap Senserva is built to close. It does not touch the biology. It does not evaluate whether a model learned real biology or a batch effect, and it makes no claim to. What it does is give a research organization a continuous, evidence-based answer to the access and identity questions that Parts 1 and 4 of this series argue have to be answered before any data-layer or model-layer governance claim means anything.
What Senserva actually checks
Senserva is a security posture management platform for the Microsoft 365, Intune, Defender, and Entra ID environment most research organizations already run their science on, email, SharePoint and OneDrive, Teams, device management, and the identity layer that gates access to all of it. It runs several hundred built-in checks organized across identity, privileged access, applications and service principals, endpoint and device compliance, email, logging, and Azure subscription roles.
That means it can answer, continuously rather than as a one-time audit, the exact questions Part 4 of this series lists as the first item on its checklist: which admin accounts don't have MFA enforced, who holds Global Administrator and whether they could reach it through group nesting rather than a direct assignment, which service principals have expired or soon-to-expire credentials, which app registrations and service principals have gone stale, no owner, no recent activity, credentials nobody rotated, and which Conditional Access policies are still sitting in report-only mode instead of actually blocking anything. Those are the stale service accounts and app integrations Part 1 and Part 4 both call out by name as the chain-of-custody gap in the cloud layer.
It also builds an identity graph rather than a flat list of findings, so a research organization can trace a privilege path, for example how a non-employee guest account could reach Exchange administrator rights through a chain of group memberships, rather than only seeing the endpoint of that chain. And because most research collaborations span more than one tenant, whether that is a university and a contract research partner, or a biobank coordinating with several sponsoring institutions, it is built to scan and compare multiple tenants side by side rather than assuming a single-tenant environment.
Turning a finding into a fix, with the audit trail to prove it
A finding by itself does not close a gap. For each check, Senserva provides step-by-step remediation guidance, including validated PowerShell scripts and rollback notes, along with direct links into the relevant Microsoft admin portal. It also maps findings to recognized compliance frameworks, including the Microsoft Cloud Security Benchmark and CISA's SCuBA baselines, with the specific control and the justification for the mapping, and it can walk an organization through a broader compliance review against frameworks like NIST 800-171, CIS, ISO 27001, SOC 2, HIPAA, or PCI-DSS. For a research organization handling patient-linked data, that HIPAA mapping connects directly back to the patient privacy questions raised in Part 2 of this series.
It also keeps a history. Between scans, it tracks what changed, a stale account that got re-activated, a group role that quietly escalated, a service principal whose permissions expanded, a Conditional Access policy that got weakened, rather than only showing a snapshot of current state. That is the same principle behind the toxicology field's "companion agents" described in Part 4 of this series, watching a system's real-world state over time instead of validating it once and assuming it stays put. Part 4 called validation a lifecycle discipline, not a one-time gate. This is what that discipline looks like applied to the identity and access layer specifically.
The same governance question applied to AI agents themselves
Part 3 of this series described the rise of agentic AI as a new attack surface, and Part 4 pointed to sandboxing, least privilege, human-in-the-loop review, and continuous monitoring as the practical countermeasures the agentic AI literature converges on. Senserva has a growing set of checks aimed directly at that problem as it shows up inside the Microsoft 365 and Copilot ecosystem: whether an AI agent's identity has been granted more permissions than its function requires and whether those permissions could be inherited more broadly than intended, whether high-impact AI actions have a human approval gate rather than running unattended, whether an organization is standardized on approved models rather than an unmanaged mix, whether monitoring and detection are actually watching agent behavior, and whether the workflow gets red-teamed on a continuing basis rather than once before launch.
None of that replaces the domain-specific agent governance a research organization still needs for a tool that queries scientific databases or executes lab-relevant code. But it means the identity and permission layer underneath a research agent, the same layer a stale service account exploits, gets the same continuous scrutiny an autonomous agent deserves, rather than a one-time review before it was turned on, which is exactly the failure mode Part 3 warns is showing up faster than most access review cycles can keep pace with.
Practicing the rule it's built on
Part 4 of this series lists "never let AI output substitute for domain-expert review" as a non-negotiable line item, not a nice-to-have. Senserva's own reporting is built around that same rule rather than treating it as someone else's problem. Every AI-generated report or recommendation the platform produces is checked by a rules-engine validator before it ships, and if the validator catches something wrong, it triggers a fix-it pass rather than shipping the flawed output. Every report and every generated remediation script also carries a standing disclaimer stating plainly that automated findings should be validated by a qualified IT or security professional before remediation, and that AI-generated content may contain inaccuracies and does not constitute professional security advice on its own.
That is not a legal footnote. It is the same discipline Part 4 asks every research organization to apply to its own biological AI outputs, applied here to the infrastructure layer's own AI-generated findings and reports.
Where Senserva fits, and where it doesn't
It is worth being precise about scope, because overclaiming here would repeat exactly the mistake this series argues against. Senserva secures and continuously audits the Microsoft 365, Intune, Defender, and Entra ID infrastructure a research organization's data and models sit on top of. It does not perform DNA synthesis screening, it does not validate whether a genomics or oncology model has learned real biology instead of a batch effect, and it does not replace the data-layer and model-layer practices described in Parts 2 through 4 of this series, tiered data governance like BDL, de-identification testing, federated learning, explainability tooling, dataset-shift correction, or domain-expert review of a model's conclusions.
What it does is make sure the layer underneath all of that is not the weakest link. A biologically-constrained model with rigorous explainability tooling, sitting on training data nobody has checked access to in years, is not a governed system. It is a well-documented one running on an ungoverned foundation. Closing the infrastructure layer is not a substitute for the rest of this series. It is what makes the rest of it credible.
A concrete example
Consider the scenario Part 1 of this series opens with: a research organization that has hardened its bench protocols but never formally reviewed its cloud tenant. A service principal set up three years ago for a since-retired data pipeline still holds Microsoft Graph access to a SharePoint site containing genomic sequence data. Nobody remembers it exists. Senserva's stale application and service-principal checks flag it automatically, on the next scan rather than the next time someone happens to look. The finding is mapped to the relevant compliance control, with the justification for that mapping shown alongside it. A validated PowerShell script and rollback plan are generated so the fix can be applied and reversed safely if something breaks. The change is logged, so if that access is ever quietly restored, it shows up in the next history review instead of going unnoticed for another three years.
That is a small, unglamorous fix. It is also exactly the kind of chain-of-custody gap Part 1 of this series named as the reason the connection between clinical rigor and cloud security matters in the first place: not because the fix is dramatic, but because it is the fix nobody was making before anyone looked.
About Senserva: Who We Are and What We Do
Senserva is a Microsoft-focused security posture management company based in St. Paul, Minnesota. Its platform continuously scans an organization's Microsoft 365, Intune, Defender, and Entra ID environment, running several hundred built-in checks across identity, privileged access, applications and service principals, endpoint and device compliance, email, logging, and Azure subscription roles.
For every finding, Senserva provides step-by-step remediation guidance, including validated PowerShell scripts and rollback notes, and maps results to recognized compliance frameworks such as the Microsoft Cloud Security Benchmark, CISA's SCuBA baselines, NIST 800-171, CIS, ISO 27001, SOC 2, HIPAA, and PCI-DSS. Senserva is a member of the Microsoft Intelligent Security Association (MISA) and a Microsoft Security Excellence Awards finalist.
Senserva also offers Three Free Unlimited Audits covering every tenant, user, and patch: one to Find, one to Fix, and one to Prove, using the same 650+ checks described above. Registration takes only a work email, with no cost and no obligation to buy. Request an evaluation key at senserva.com/request-key.html.
Senserva also runs Senserva Watch, a free membership that tracks CVEs and Microsoft patches on an organization's behalf and sends an alert only when something being tracked changes, including a same-day notice when Microsoft's Patch Tuesday updates ship. Signing up needs no tenant connection, agent, or call, just an email address, at senserva.com/senserva-watch.html.
Already a Senserva Watch member, or ready to join? Sign up at senserva.com/when-the-lab-meets-the-cloud.html to get the complete five-part series sent to your inbox, plus everything else membership includes: alerts when a CVE or KB you follow changes, a fresh audit credit every quarter, and 20% off when you buy.
Learn more at senserva.com.
Sources cited in this part
Product capabilities described in this part reflect Senserva's platform documentation and in-product help content as of August 2026.