Microsoft Defender helps you discover AI agents, monitor risky behavior, and investigate incidents, but it does not make an agent safe to run by itself. For enterprise agents that can change security settings or query sensitive telemetry, you need a permissioned execution layer that enforces policy-as-code, not prompt-only instructions.
Claw EA runs OpenClaw as the baseline agent runtime and adds enforceable controls using WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), CST = scoped token (issued by clawscope), and gateway receipts emitted by clawproxy. Microsoft Defender can be connected via official API with enterprise buildout controls, with write and admin actions gated by WPC approval and least-privilege auth scopes.
Step-by-step runbook
-
Define the “Defender surface” the agent is allowed to touch. Split read-only use cases (incident triage, hunting queries, inventory) from write use cases (tagging, status changes, isolation actions) and treat write as a separate policy tier.
-
Create a WPC that states allowed tools, allowed Microsoft Graph permissions/scopes, and which Defender workloads are in scope (for example Defender for XDR versus Defender for Cloud Apps). Pin the WPC hash for the job so the agent cannot silently switch policies mid-run.
-
Issue a CST from clawscope for the specific job and bind it to the WPC scope hash. Keep the CST TTL short and require a fresh CST for each run that can change state.
-
Implement the Defender connection via official API in an enterprise buildout, using Entra ID OAuth where possible. Require explicit Graph permissions/scopes and avoid broad directory scopes unless the WPC explicitly allows them.
-
Route model calls through clawproxy so you get gateway receipts for every model interaction. Keep “tool execution” and “model reasoning” separated so you can later prove what the model was asked and what was executed.
-
Run the agent in OpenClaw with sandboxing and tight tool policy profiles. Validate the effective sandbox and tool policy with OpenClaw’s own audit and inspector commands before enabling any Defender write actions.
-
Emit a proof bundle for each run and store it in your evidence system or as a Trust Pulse for review. Treat Defender changes as change-managed actions and attach the proof bundle to the ticket.
Threat model
Defender data is high leverage: it can reveal incident timelines, device identities, user behavior, and security configuration. If an agent can query or mutate that data based on prompts alone, prompt injection and mis-scoped credentials turn into real operational impact.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection triggers unintended Defender actions | An attacker embeds instructions in an alert description or ticket so the agent “helpfully” runs a write action, changes a policy, or expands scope. | Permissioned execution: WPC must explicitly allow the write tool, the Graph scopes, and the target resource types. Require separate WPC approval gates for any state-changing action. |
| Over-broad Entra ID app permissions | The agent’s token can access unrelated security data, or it can modify tenant configuration beyond the intended workflow. | Least-privilege Microsoft Graph permissions/scopes, enforced by WPC. Use separate app registrations for read-only and write paths and prefer PIM for human elevation outside the agent path. |
| Credential replay across jobs or environments | A token obtained in one run is reused later, bypassing intended approvals and making incident timelines ambiguous. | Job-scoped CST binding (anti-replay) and short TTL. Pin the policy hash so the CST is only valid for the approved WPC. |
| Misconfigured OpenClaw tools or sandbox escape hatch | The agent gains host-level execution or reads local secrets, then uses Defender APIs with higher impact than planned. | OpenClaw sandboxing and strict tool allow/deny profiles. Avoid elevated tool paths except under a separate WPC tier and only for constrained operations. |
| Disputed audit trail after an incident | You cannot prove whether the model was called with a specific prompt, which policy was active, or which credentials were used when a change occurred. | Gateway receipts for model calls plus a proof bundle that binds receipts, job metadata, CST scope hash, and the WPC hash. Verification becomes a mechanical check, not a narrative. |
Policy-as-code example
This is an example WPC that permits read-only hunting and inventory, while forcing explicit approval for write operations. Treat the snippet as a template; exact Microsoft Graph permissions/scopes depend on your tenant configuration and the Defender workload you are calling via official API.
{
"wpc_version": "1",
"policy_name": "defender-agent-readonly",
"purpose": "Run incident triage and hunting queries via official API; no tenant changes",
"openclaw": {
"tools_profile": "readonly",
"tools_allow": ["http", "defender_api_call", "report_write"],
"tools_deny": ["shell", "filesystem_write", "elevated_exec"],
"sandbox": { "mode": "all", "workspaceAccess": "ro" }
},
"auth": {
"provider": "entra_id",
"token_type": "oauth",
"graph_permissions_scopes_allow": [
"SecurityEvents.Read.All",
"ThreatHunting.Read.All"
],
"graph_permissions_scopes_deny": [
"Directory.ReadWrite.All",
"Policy.ReadWrite.ConditionalAccess"
]
},
"claw_bureau": {
"cst_require": true,
"cst_scope_hash_pin": true,
"wpc_policy_hash_pin": true
},
"approvals": {
"write_actions": { "require": true, "reason": "Any change to Defender state must be approved" }
},
"logging": {
"gateway_receipts": "required",
"proof_bundle": "required"
}
}
For write paths, create a second WPC such as defender-agent-write that allows only specific endpoints and specific Graph scopes, and require an approval gate before issuing the CST. If you rely on Conditional Access or PIM, keep that in the human operator path and do not assume an agent can satisfy interactive requirements without enterprise buildout.
What proof do you get?
Every model call routed through clawproxy produces gateway receipts, which you can later verify to confirm what model was called and under what job context. Those receipts are bundled into a proof bundle along with job metadata, the CST scope hash, and the pinned WPC hash.
Operationally, this gives you two checks during incident response: confirm the run was bound to the approved WPC, and confirm the model traffic matches the job that executed the Defender calls. If you publish it, the proof bundle can be stored and viewed as a Trust Pulse for audit and review workflows.
Rollback posture
Rollback for permissioned agents is mostly about making unsafe actions impossible to repeat, then reverting the affected configuration with a controlled playbook. Do this in layers: revoke credentials first, then disable tools and policies, then remediate Defender-side changes.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop further agent runs | Revoke the CST in clawscope and rotate the underlying Entra ID secret or certificate for the app registration used by the agent. | Proof bundle shows the CST scope hash and issuance context for the run you are investigating. |
| Prevent policy drift | Freeze to a known-good WPC hash and require policy hash pinning for all jobs. Remove any WPC that allows write scopes until reviewed. | WPC hash is recorded in the run metadata and can be compared across runs. |
| Contain tool blast radius | Tighten OpenClaw tool policy and sandbox mode to remove elevated and filesystem-write tools from the agent profile used for security workflows. | OpenClaw audit output plus job configuration snapshots associated with the proof bundle. |
| Undo Defender-side changes | Revert the specific Defender or Graph changes using a human-run procedure with PIM elevation, then re-run the agent in read-only mode to verify state. | Defender audit logs and the agent’s proof bundle together show what was attempted and when. |
FAQ
Is this a native Microsoft Defender connector in Claw EA?
No. Microsoft Defender can be connected via official API with enterprise buildout controls, and you should plan for a scoped integration that matches your tenant’s Entra ID and Graph permission model.
Why is prompt-only control not enough for Defender-capable agents?
Because prompts are not enforceable when the agent sees untrusted text, such as alert descriptions, emails, or tickets. Policy-as-code in a WPC gives you a machine-checked allowlist of tools and scopes, so “the agent promised not to” is not your control.
How do you keep Graph permissions from quietly expanding over time?
Put allowed Microsoft Graph permissions/scopes inside the WPC and require policy hash pinning for the job. Any change to scopes becomes a WPC change, which you can review and sign before issuing a CST.
What do gateway receipts cover versus Defender audit logs?
Defender audit logs show actions inside Microsoft services. Gateway receipts show the model calls used to decide actions, and the proof bundle binds those receipts to the exact WPC and CST that authorized the run.
Can we enforce network egress allowlists for Defender integrations?
It can be implemented as an additional control outside clawproxy, but it is not a shipped default. Most teams start with strict tool policy plus WPC scope pinning, then add egress controls where required.