TL;DR: Only about 10% of the CIS Microsoft 365 benchmark was covered by Microsoft Graph alone, so meaningful Microsoft 365 auditing had to combine Graph with controlled PowerShell sessions, according to Prowler. The practical lesson is that security visibility often depends on the least elegant integration path, especially when identity, authentication state, and command safety all matter.
At a glance
What this is: Prowler shows that Microsoft 365 audit coverage cannot rely on Microsoft Graph alone because large parts of CIS-aligned checking still require controlled PowerShell access.
Why it matters: For IAM and security teams, the practical issue is not the API preference but whether audit tooling can preserve session state, constrain command execution, and reach the controls that matter for governance evidence.
Context
Microsoft 365 audit coverage depends on more than a single management interface. When a platform exposes only part of the control surface through an API, security teams are forced to balance convenience against completeness, and that gap becomes a governance problem as much as a tooling problem.
This article sits at the intersection of SaaS security, identity-controlled access, and operational auditability. The key issue is whether programmatic access preserves authentication state, limits command risk, and still reaches the checks needed for defensible compliance evidence. That makes the topic relevant to identity and access governance even though the underlying problem is broader than IAM.
Key questions
Q: What breaks when Microsoft 365 auditing depends on Graph alone?
A: Graph-only collection breaks coverage when important Microsoft 365 settings are exposed only through PowerShell or portal-backed administrative paths. The result is not just fewer findings, but a weaker control assertion because the audit tool cannot see the full benchmark surface. Practitioners should map each control to its real source of truth before treating coverage as complete.
Q: Why do persistent PowerShell sessions matter for Microsoft 365 checks?
A: Persistent sessions matter because many Microsoft 365 modules expect one authenticated context to survive across multiple commands. If every command starts a new process, the authentication state disappears and multi-step checks fail or become unreliable. For governance work, the session is part of the control path, not just an execution detail.
Q: What are the main failure modes when embedding PowerShell in Python automation?
A: The main failure modes are command injection, orphaned or long-running processes, and broken response handling between stdout and stderr. Those risks are operational, but they also affect evidence quality because a collector that hangs or misreads output cannot be trusted for compliance checks. Teams need validation and timeouts as baseline controls.
Q: When should teams choose a hybrid API and shell approach for SaaS audits?
A: Teams should choose a hybrid approach when the supported API covers only part of the required benchmark and the remaining controls live in a governed administrative shell. The decision is justified when completeness matters more than architectural purity, provided the shell path is tightly constrained and continuously tested for abuse.
Technical breakdown
Why Microsoft Graph alone leaves audit blind spots
Microsoft Graph is the supported programmatic interface for many Microsoft 365 services, but it does not expose every configuration and security control that auditors need. In practice, that means a tool can be standards-aligned in intent yet still miss large portions of the control surface. The issue is not whether Graph is valid, but whether it is sufficient for continuous audit coverage. When a benchmark spans portal-only settings, the tool must either accept blind spots or introduce a second, tightly governed execution path.
Practical implication: treat API coverage as incomplete until you map every required control to an accessible interface.
How persistent PowerShell sessions preserve authentication state
Independent subprocess calls create a state problem because each invocation starts a fresh process, which means authentication can disappear between commands. A persistent PowerShell session solves that by keeping one authenticated process alive and sending multiple commands through stdin while the process stays open. Background readers collect stdout and stderr, and delimiters mark the end of each command response. This design is less about convenience than control: it preserves session continuity while keeping execution bounded and observable.
Practical implication: if a control requires session continuity, design around authenticated session reuse rather than one-shot command execution.
Why command safety becomes a security control in embedded shells
Running PowerShell from Python creates an attack surface that looks like automation but behaves like command execution. Input sanitization, validation, execution timeouts, and constrained session handling become the practical controls that separate a managed integration from a shell injection risk. The article’s internal testing also showed a denial-of-service path when malformed queries could keep a process alive indefinitely. That matters because audit tooling often touches privileged data flows, so the integration layer itself must be treated as security-relevant infrastructure.
Practical implication: validate every command path and enforce hard timeouts wherever shell execution is embedded into automation.
Threat narrative
Attacker objective: Disrupt the audit integration by keeping the PowerShell process alive indefinitely and preventing reliable control collection.
- Entry occurs through malformed query input sent into a persistent PowerShell session, rather than through a classic external exploit path.
- The attacker or tester can force the process into an indefinite execution state by abusing command handling and response delimiting.
- The practical impact is denial of service against the audit workflow, reducing visibility and interrupting controlled Microsoft 365 data collection.
Breaches seen in the wild
- Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hybrid audit paths are now a control-design issue, not an implementation quirk. If Microsoft 365 governance evidence exists partly in Graph and partly in PowerShell, then tooling strategy must follow the control surface rather than the developer’s preferred interface. The real decision is whether the organisation wants partial visibility with simple integration or complete coverage with tighter execution governance. Practitioners should design for the full control map, not the easiest API.
Session persistence is the hidden requirement in many SaaS audit workflows. Authentication state that survives across commands is not a convenience feature, it is what makes multi-step collection possible. In identity terms, the session itself becomes the governed object because losing state breaks the control chain and can distort audit evidence. Teams should treat authenticated session continuity as part of the control architecture.
Command execution safety belongs in the same governance conversation as audit coverage. Once automation invokes an embedded shell, input validation, timeout enforcement, and response framing become evidence-integrity controls. This article shows why security teams cannot separate coverage from containment: the path that expands visibility also expands the need for operational guardrails. The practitioner takeaway is to govern the integration layer with the same seriousness as the data it retrieves.
PowerShell-assisted collection exposes a broader pattern in SaaS governance. Many enterprise controls remain split between modern APIs and legacy administrative surfaces, and no single interface always captures the full policy state. That creates an audit gap whenever teams assume the official API is the whole system. Practitioners should expect hybrid collection patterns to persist wherever platforms evolve unevenly.
Control-surface completeness should become a named design goal for Microsoft 365 programmes. The article’s central lesson is that coverage gaps are not just missing checks, they are missing governance visibility. When a benchmark depends on multiple administrative planes, the programme must define which plane is authoritative for each control and how collection is safely executed. Security teams should explicitly plan for this control-surface split.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Regulatory and Audit Perspectives
What this signals
Control-surface completeness: Microsoft 365 programmes increasingly need a deliberate split between API-driven checks and governed shell-driven checks. If teams assume one interface is enough, they will keep finding audit blind spots after the fact rather than designing them out up front.
The practical signal for security leaders is that integration safety now sits beside coverage as a first-order requirement. Persistent sessions, timeout enforcement, and input validation are not engineering polish, they are what make the audit path reliable enough to trust.
For practitioners
- Define the Microsoft 365 control surface Map each CIS-relevant Microsoft 365 requirement to Graph, PowerShell, or another administrative plane before implementing checks.
- Use persistent sessions for multi-step checks Keep one authenticated PowerShell session alive for the duration of a service collection run so authentication state is preserved across queries.
- Enforce strict command validation Sanitise every input, reject characters that can alter shell parsing, and validate all parameters before they reach the PowerShell process.
- Set hard execution timeouts Terminate any PowerShell session that exceeds its allowed runtime so malformed queries cannot trap the collector in an endless loop.
- Test the integration like an attacker would Run abuse tests against the Python-to-PowerShell path to confirm that malformed input cannot inject commands or create denial-of-service conditions.
Key takeaways
- Microsoft 365 audit tooling can look modern and still miss large parts of the control surface if it relies on Graph alone.
- Persistent PowerShell sessions are necessary when controls require authenticated continuity across multiple commands.
- Audit completeness and command safety have to be governed together because the collection path itself can become a failure point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Graph-only auditing misses part of the Microsoft 365 control surface. |
| Recommendation — Inventory every Microsoft 365 control path and map each check to the interface that actually exposes it. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on governed administrative access to audit-relevant M365 settings. |
| Recommendation — Review permissions for the collection account and limit each check to the minimum required scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | Persistent session handling and service access depend on disciplined account control. |
| Recommendation — Constrain and review the accounts used for Microsoft 365 collection and automation. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Malformed query abuse can disrupt the collector and interfere with authenticated sessions. |
| Recommendation — Map shell-abuse scenarios to credential and impact tactics when testing the audit path. | ||
| SOC 2 (AICPA) | CC6.1 — Logical Access Security Software | The article is about access-controlled automation used for security evidence collection. |
| Recommendation — Document how session handling and command safeguards support logical access controls in automated checks. | ||
Key terms
- Hybrid audit path: A hybrid audit path is a collection model that uses more than one administrative interface to reach the full control set for a platform. In Microsoft 365, that often means combining modern APIs with shell-based administration so coverage does not stop where the API stops.
- Persistent PowerShell Session: A long-lived PowerShell process that keeps authentication state active across multiple commands. In audit automation, it acts like a controlled runtime session rather than a one-shot script, which makes lifecycle management, timeout enforcement, and input validation essential security controls.
- Control-surface completeness: Control-surface completeness means the audit tool can observe every place a required control is actually enforced or configured. It is not the same as feature coverage, because a platform may expose some controls through APIs and others only through administrative shells or portals.
- Command injection: Command injection occurs when attacker-controlled data is inserted into a shell command and changes what the process executes. In AI tooling, that often happens through wrappers, plugins, or installation flows that turn paths or prompts into shell strings. The impact is privilege abuse through the process’s inherited authority.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your role requires stronger governance over machine access, sessions, and secrets across modern environments.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org