Connecting evidence, business context, and bounded authority with Microsoft Security Copilot and Sentinel
An AI agent can explain why a PowerShell command looks suspicious. That is not the same as knowing whether it belongs on your production server.
Who owns the server? Which business service depends on it? Was the activity part of an approved change? Does what happened match that change? Who can authorize containment?
Those are the questions the investigation turns on, and a generic explanation cannot answer any of them. An environment-aware agent helps answer them.
That takes more than model intelligence. It takes access to the right evidence, dependable organizational context, and clear boundaries around what the agent may decide and do. This article is for the security architects and SOC leads who have to make those three things true. It follows one investigation from specification to production, with Security Copilot and Sentinel as the enablers, so you finish knowing what to build first and how to tell whether it worked.
Ground the Agent in the Context That Matters
Start with grounding, not custom model training. Give the agent the information it needs during the investigation, through approved tools and integrations.
Three kinds of context matter, and each answers a different question.
Security evidence helps establish what happened: process execution, sign-ins, network connections, configuration changes, related alerts.
Business context establishes why it matters: asset ownership, service dependencies, criticality, approved changes.
Operating guidance establishes how to proceed: procedures, escalation criteria, approved exceptions, response authority.
For the production server, endpoint telemetry describes the activity, the asset inventory explains the server's importance, the change-management system supplies the approved work, and the response procedure identifies who can authorize isolation. None of these should silently substitute for another.
The goal is not to place every policy, runbook, and log into the prompt. Retrieve what the specific investigation needs, with enough detail to judge its relevance and its limits.
Define One Investigation and Its Intended Result
"Investigate security alerts" is not a specification. "Investigate suspicious administrative activity on production servers and prepare an evidence-backed recommendation for analyst review" is something you can build and evaluate.
Define the input: an alert identifier, the affected asset, a bounded investigation window. Define the evidence required and the questions the agent must answer. Define an output that separates observations, supported conclusions, unresolved questions, and recommended next steps.
Then make the result concrete.
The PowerShell alert falls within an approved maintenance window. The change record authorizes a backup script running under a designated service account. But the observed execution uses a different identity and contacts a destination outside the documented scope.
An approved change window is context, not proof of legitimacy.
The agent compares the process events with the approved work, identifies the discrepancies, and reports that the change does not adequately explain the activity. It attaches the supporting events and the change record, states what remains unresolved, and recommends further investigation. The case workflow routes that package to the responsible analyst. The agent neither declares the activity benign nor isolates the server.
The analyst receives a specific discrepancy to run down, not another generic explanation of suspicious PowerShell.
This is also where agents and automation divide the work. A playbook follows predefined investigation and decision logic. An agent can select its next investigative step based on what it has found, within the tools and boundaries you give it. In the PowerShell case, a mismatch with the approved change might lead the agent to examine the executing identity, process lineage, or network destination. That adaptability is useful when the next step is not predetermined. It does not replace the workflow that controls approvals and execution.
A predefined workflow retrieves the alert, validates inputs, and routes the finished investigation. The agent interprets intermediate findings and selects investigative tools within its permitted scope. Existing response workflows keep approvals and execution. Use reasoning where interpretation is required; keep deterministic processing where the required behavior is already known.
Connect the Evidence and Make It Dependable
Sentinel's MCP data exploration tools can find relevant tables, return schemas, run KQL, and identify workspaces. That reduces the need to hard-code every table and field into the agent's design. It does not make every newly ingested source discoverable or correctly interpreted, and it does not put every source into one schema. ASIM normalizes what its supported schemas and parsers cover. Either way, you still have to prove that the intended queries return the evidence this investigation needs.
MCP reduces integration coupling. It does not eliminate data engineering.
For the PowerShell investigation, validate the joins: alert to device identifier, device to asset record, asset to change record. Confirm that timestamps and investigation windows line up. Confirm that the telemetry carries enough detail to compare observed execution with approved work.
Business context needs an owner as well as a connection. Identify the authoritative source for asset ownership, service criticality, and operational exceptions, and the team responsible for keeping it current. Decide how stale or conflicting records affect the investigation.
You do not need to rebuild the asset inventory first. You do need dependable context for the one workflow you are introducing. When essential knowledge lives only in someone's head, record that as a gap rather than expecting the agent to reconstruct organizational intent.
Bound the Tools and the Authority
Give the agent tools designed for the investigation, not access to every system that might contain relevant information.
A change-management lookup that accepts an asset identifier and time range and returns approval status, authorized activities, and affected systems is more useful than unrestricted access to the change platform, and far safer. Security Copilot supports KQL, API, and MCP tool integrations, and Sentinel can expose saved KQL queries as custom MCP tools, so established investigative queries become reusable, bounded capabilities. Design each tool with explicit inputs, structured outputs, and narrow scope.
Then trace the authority behind the tools. The agent's execution identity, the credentials each integration uses, and the permissions downstream systems enforce may all differ. What matters is whether the agent's effective access matches its assigned work, not simply whether it has an identity. Today a custom agent can easily inherit far more permission than its job requires (see the implementation notes below).
For the production-server investigator, reading endpoint evidence and approved changes does not require authority to isolate the server. Keep investigative access separate from response authority. Enforce containment approval in the execution workflow and the underlying permissions, with no alternate tool path around the gate.
A prompt describing an authorization boundary is not the boundary itself.
Require Evidence, Not Confidence
A displayed confidence score does not establish that a conclusion is correct.
Define the evidence and policy conditions each recommendation requires. Recommending a benign disposition for the PowerShell alert should take more than a matching maintenance window: alignment across affected asset, executing identity, approved activity, and observed behavior, with no unresolved contradictory evidence. These conditions set a minimum basis. They do not make the recommendation infallible.
Handle missing evidence explicitly. A successful query that returns nothing is different from unavailable telemetry, an expired retention window, or a failed tool call. An unreachable change-management system does not establish that no approved change exists. The agent's output should make those distinctions and adjust its recommendation accordingly. When required evidence is missing, the agent may produce an interim report or escalate. It should not recommend benign closure. Define those evidence requirements before deployment, along with limits on retries, query scope, execution time, and resource consumption.
In the illustrative case, the discrepancy supports further investigation. It does not prove compromise. The recommendation should preserve that distinction so the analyst understands both the concern and the limits of the evidence.
Test the Workflow, Not Just the Agent
Whether you build through a form, a conversation, or a YAML definition, you still configure inputs, tools, permissions, and execution behavior. The authoring method should serve the investigation. It does not decide whether the investigation is well specified.
Test cases for the PowerShell investigator should include malicious execution, legitimate administration, incomplete change records, missing telemetry, permission failures, and conflicting evidence. Include cases where an approved change explains the activity and cases where it does not.
Historical replay needs care. Restrict the evidence to what existed at investigation time. Do not let the agent see resolution notes, later discoveries, or updated records the original investigator could not have seen. Keep some reviewed cases apart from those used to refine the instructions. Repeat important scenarios to understand run-to-run variation. Examine tool selection, retrieved evidence, and recommended outcomes, not only the final narrative.
Compare the agent-assisted workflow with the existing analyst or playbook process on the same reviewed cases. When a test fails, find the cause. It may be an instruction, but it may also be a missing source, a bad entity match, an unreliable tool, or an unsuitable decision criterion.
Go live with limited authority and analyst review. Re-run the relevant tests whenever instructions, tools, schemas, or permissions change.
Govern It as a Production System
A security agent investigates content an adversary may have created. Emails, documents, URLs, and retrieved text can carry instructions meant to redirect the agent or misuse its tools. Treat that material as evidence to analyze, not authority to obey.
Put adversarial cases in the test set. Could a crafted document cause the agent to dismiss suspicious activity? Could a malicious tool response steer it toward unrelated data? Could it send findings to an unapproved destination? Review plugins, MCP servers, authorization paths, and permitted outputs as parts of the security boundary.
Production governance also needs an accountable owner, reviewed changes, a tested way to stop execution, a rollback procedure, and defined conditions for reassessment or retirement.
For observability, record the input, agent version, execution identity, tool calls, evidence used, decision rationale, approvals, and resulting actions, and protect that record. Security Copilot's activity views help inspect a run, but they are a high-level view, not an exhaustive record of every operation. Keep your audit requirements distinct from what a native visualization happens to display.
A fluent explanation is not an audit trail.
The record should let an operator reconstruct what the system did and judge whether the evidence justified its recommendation.
Integrate the Work and Measure the Difference
An investigation is useful when it reaches the person responsible for acting on it, in a form that reduces their work. For the production-server investigator, that means placing the evidence package in the existing case, routing it to the right analyst, and preserving the established approval process. Failed and incomplete runs need destinations too. They should not vanish into a separate agent dashboard.
Azure Logic Apps can invoke configured Security Copilot agents and combine their results with other workflow actions. Design those handoffs explicitly: what each stage accepts, what it returns, who owns the next step, and what happens on failure.
The technical integration is usually the easier half. The harder half is process: the runbook has to say which cases the agent handles and which go straight to a person, what the analyst is expected to do with an agent-prepared package, and how an escalation the agent cannot resolve gets picked up. Analysts also need time to learn where the agent is reliable and where it is not before they are asked to trust it. Plan for that adjustment as part of the rollout rather than treating it as resistance.
Then measure three things.
Quality. Did the investigation gather the required evidence and support its conclusion? Track malicious activity recommended as benign separately from legitimate activity unnecessarily escalated, along with reversals and reopened cases. Analyst agreement is useful feedback, not proof of correctness. Review disagreements and sample the accepted results.
Efficiency. Did the complete workflow reduce analyst handling time against the existing process? Count review, correction, failed runs, and evidence reconstruction, not just how quickly the agent produced an answer. Track latency and cost per completed investigation.
Control. Did the agent stay within scope? Track missing evidence, tool failures, human fallback, and attempted or executed out-of-policy actions. Confirm that approval requirements held when tested.
These measures tell you whether the agent improves the work or only produces more output.
Start With One Investigation
Choose one frequent, well-understood workflow with accessible evidence and evaluable outcomes. Rule out the two ends of the range first. If the steps are already fixed and the decision is a lookup, that is a playbook, and an agent adds cost without adding judgment. When a wrong decision could cause severe, hard-to-reverse harm, keep final decision authority with an authorized person. The agent can still assemble evidence, assess discrepancies, and recommend next steps. The candidates worth building sit between those ends: structured enough to specify, variable enough to need reasoning.
Build the narrowest useful agent. Introduce it with review. Measure its contribution. Use the results to decide whether to improve its context, adjust its tools, expand its scope, or leave part of the work deterministic.
The objective is one better-supported investigation with less unnecessary effort and clear accountability, not a library of agents.
In the PowerShell example, success is not that the agent recognizes suspicious syntax. It is that the analyst receives a documented mismatch between observed activity and approved work, understands what remains unknown, and retains control of the response.
A security agent becomes an operating capability when you can identify the evidence it used, assess whether that evidence supports its conclusion, and control what happens next. That is how you build security agents that actually know your environment and deserve a place in it.
This is the shape of the work Lockbase does with SOC teams: one scoped investigation, built inside Security Copilot and Sentinel, with the evidence checks, bounded tools, test set, and measurement in place before it touches production.
Implementation notes, as of September 2026
Platform details change quickly. Confirm each of these in the intended tenant before relying on it.
Authoring paths. Security Copilot supports Agent Builder, YAML-based definitions, and MCP-assisted development for native agents. Natural-language creation is listed as private preview. These are authoring paths into Security Copilot, not the same undertaking as building and operating a separate agent runtime.
Agent identity. The current Security Copilot setup experience offers dedicated Agent ID creation only for Microsoft-built agents. The existing-user-account option inherits that account's permissions. This is a limit of the setup experience, not of Entra Agent ID itself. The practical consequence: check what identity your custom agent actually runs under and what that identity can reach.
Logic Apps. The Security Copilot connector runs the agent under its configured identity, which is distinct from the connector's sign-in identity. Workspace and plugin-sharing prerequisites need to be checked for the intended deployment.
Sentinel MCP. The data exploration collection's search_tables tool accepts natural-language input and returns relevant supported tables with schema information. Custom MCP tools can be built from saved KQL queries.
