.svg)
.svg)
A PowerShell script runs under a service account on a domain controller. Is it your automation, or an attacker? To tell the difference, the security team needs to know who or what started the run and whether it matches expected behavior. Accountable automation provides that context: every run and configuration change reaches the security team's SIEM as an attributed event, ready for comparison with the normal behavior that IT Operations defines. This applies across Active Directory, Entra ID, Exchange and Microsoft 365. Without that context, any unexplained run can lead to an investigation.
Why can't your security team tell normal automation from an attack?
Security teams often can't tell the two apart because attackers use the same tools as automation: PowerShell, admin accounts and built-in Windows utilities. In February 2024, CISA, the NSA, the FBI and their Five Eyes partners published a joint guide, Identifying and Mitigating Living Off the Land Techniques.
The guide says that many organizations find it difficult "to discern legitimate behavior from malicious behavior." It identifies one cause: defenders who work in silos, separate from IT teams. Automation is part of the problem. Service accounts that perform management tasks carry out "highly privileged, possibly suspicious actions." Without context, the resulting log events leave analysts to work out which actions are legitimate.
This gap costs time in two ways. First, security teams must investigate privileged runs they cannot explain. Second, poor collaboration with IT slows those investigations. In large organizations, the guide says, investigations "may take several months."
The same lack of shared records complicates audits. When an auditor asks who changed an automation task 3 months ago, an engineer may have to search through logs manually. Connecting the tools that hold these records remains a challenge. For The State of Microsoft Automation 2026 benchmark, ScriptRunner surveyed 180 IT managers and senior system engineers at enterprises with 1,000 or more employees. Only 17% reported full integration across ITSM, monitoring and infrastructure tools.
What does traceable automation look like to both teams?
Closing this gap starts with a clear division of responsibility. The security team owns detection, and IT Operations owns the definition of normal. The CISA-led guidance on living-off-the-land techniques makes this practical: organizations should define the expected behavior of automated tools. Each automated service needs known limits: when it runs, which source and target hosts it uses, and which accounts it can affect.
For example, an onboarding task runs only under its own service account, only against the HR user OU, and only during business hours. IT Operations must document these limits, share them with the security team, and keep them current.
Those limits become useful for detection when analysts can compare them with records of what actually happened. In August 2024, the Australian Signals Directorate and agencies from eight other countries published Best practices for event logging and threat detection. It calls for "detailed tracking of administrative tasks," and its first named audience is senior IT decision makers.
These events go into the SIEM that your security team already operates, avoiding a separate monitoring process. Each run and configuration change identifies the person or system that started it. Together, these records provide a basis for automation governance and compliance for Microsoft IT.
They can also support specific compliance requirements. The NIS2 implementing regulation applies to covered digital service providers, including cloud and managed service providers. Where appropriate, their logs must include privileged access, the activities of administrative accounts and changes to critical configuration. ENISA's NIS2 implementation guidance (June 2025) lists SIEM systems as an example of evidence. It also maps this logging area to ISO/IEC 27001 controls, including A.8.15 and A.8.16.
How should you judge whether the SIEM sees enough of your automation?
Use one test: can an analyst answer these four questions from the SIEM alone, without a call to IT?
- Who or what started this run: a person, a schedule, a ticket or an AI agent?
- Was it an approved task, or an ad hoc script from an admin's laptop?
- Did it stay within its declared limits, including the correct account, hosts and time?
- What changed in the automation itself: the script, the credential or the target?
If the SIEM provides all four answers, the analyst has the context to assess the alert and decide whether to close it. If an answer is missing, further investigation may require an escalation and a call to one of your engineers. The ASD guidance explains why: unusual script execution "could be legitimate behavior," but a defender must investigate to find out. When scripts run from many servers, schedulers and laptops without a shared record, no single source has the answers.
Answering these questions takes attribution, approval records, documented limits and change history. A larger volume of raw logs alone does not provide that context and can add cost for the security team. How the data reaches analysts matters too: does it go to your existing SIEM through an open standard, or does it require another isolated tool?
Where ScriptRunner fits
ScriptRunner provides the execution layer for this approach to Microsoft automation. Your scripts run as governed Actions, and each run creates a report that shows who started it, the target, the parameters, and the result. Help-desk staff and end users start delegated Actions without admin rights on the target systems. ScriptRunner also keeps a change history for Actions, targets, credentials, scripts, and queries.
With the SIEM & Observability license, ScriptRunner sends action executions, configuration changes and access events over OpenTelemetry, an open standard. An OpenTelemetry Collector in your environment forwards them to Microsoft Sentinel, Splunk, Elastic or another compatible platform. The collector can filter the data before forwarding it, so your security team controls what reaches the SIEM while continuing to use its existing tools. This connector was introduced with the ScriptRunner 8.2 SIEM and audit features.
Your security team still builds the detections, using the limits that IT Operations defines. The difference is that sanctioned automation arrives with the context analysts need to identify it, reducing calls to IT and making audit information easier to provide.
So, should automation logs go to the SIEM?
Yes. Send attributed automation events to the SIEM and make their declared limits available for comparison, so the Security team can identify approved automation. Agree on responsibilities before the next late-night alert: the Security team owns detection, and IT Operations owns the definition of normal.
With that shared visibility in place, the next question is whether the accounts running your automation have appropriate access. Service accounts carry most automation, making governing automation credentials to limit risk the next control to examine. The records you collect should also help you answer auditors' questions. To check whether they are sufficient, use the five auditor questions for PowerShell automation. And be sure to visit the SIEM Observability page if you'd like to learn more about the SIEM functionality included in ScriptRunner Enterprise 8.2.