Weekly Security Roundup: Agent Governance, CI Secrets, Data Egress

by TechHub

Welcome to this week's Security roundup, where agent governance moved from design guidance to concrete tooling across Kubernetes, developer IDEs, and Microsoft Security. We look at kars and AGT patterns for isolating and auditing agent behavior, plus new mitigations for MCP risks like tool metadata poisoning and untrusted server connections. On the platform side, GitHub tightened CI and audit controls (read-only cache tokens, reduced PAT use, Copilot session streaming) and expanded secret scanning into a more operational model. We also cover integrity and egress controls in Azure and Fabric, and why resilience drills and a faster post-quantum timeline mean security planning needs to start earlier.

This Week's Overview

Agent governance and MCP hardening moves from theory to tooling

kars brings Kubernetes-native isolation and policy to AI agents

Building on last week's focus on making agent behavior governable (with enforceable policies, deterministic workflows, and explicit isolation), kars landed as an open-source “agent reference stack” for running AI agents on Azure Kubernetes Service (AKS), and it treats isolation and governance as first-class runtime concerns. It combines per-agent sandboxes (via AKS Pod Sandboxing), CRD-based governance using the Microsoft Agent Governance Toolkit (AGT), and an end-to-end encrypted inter-agent mesh (“AgentMesh”) so agent-to-agent traffic is protected by default.

For teams experimenting with agentic workloads, the practical shift is that you can model agent policy the same way you model cluster policy: as Kubernetes resources that can be audited, versioned, and rolled out with GitOps. The runtime focus on per-agent boundaries is also a reminder that “one agent per pod” is not enough if tools, memory, and cross-agent communication are left unconstrained.

Microsoft Security expands coverage for local agents and MCP servers

After last week's AutoJack deep dive reinforced that localhost MCP endpoints still need authentication, monitoring, and explicit mediation, Microsoft's June 2026 security update included several agent-related items that start to close the gap between “agents as apps” and “agents as security-managed endpoints.” Highlights included codename MDASH (agentic vulnerability scanning, private preview), plus preview protections oriented toward local AI agents and Model Context Protocol (MCP) servers.

That matters because more organizations are running agent stacks partly outside centralized control planes (developer laptops, self-hosted runners, local MCP servers), where traditional cloud posture tools see less. If your security model assumes the agent is “just another app,” these updates are a signal to start treating tool servers, agent runtimes, and agent permissions as auditable assets.

MCP supply chain risks get concrete: tool metadata poisoning and mitigations

Following last week's theme that MCP tool surfaces behave like privileged APIs (and need governance controls like allowlists and audit trails), a separate Microsoft Security analysis dug into a specific agentic risk: MCP tool metadata poisoning, where an attacker manipulates tool descriptions or metadata so an agent takes unsafe actions or exfiltrates data. The guidance mapped mitigations onto Microsoft controls such as Prompt Shields, Microsoft Purview DLP, Microsoft Entra Agent ID, Defender, and Sentinel, emphasizing that “tooling” becomes part of your supply chain when agents can act.

For developers building MCP-driven workflows, the practical takeaway is to treat tool descriptors and tool registries like code: constrain who can publish them, validate what an agent is allowed to call, and log tool calls with enough context to investigate. This also lines up with Visual Studio's new trust validation for MCP servers (below), which starts pushing MCP trust decisions closer to the developer workflow where these tools are configured.

Visual Studio adds MCP server trust checks and better Copilot usage visibility

With last week's MCP governance discussion pointing toward “approved tools only” patterns (often enforced via gateways like APIM), the Visual Studio June update focused on two developer-facing security levers: improved Copilot usage tracking and MCP server trust validation. The Copilot Usage window now tracks usage in token terms and supports alerts, which is useful for spotting unexpected spikes that can indicate misconfiguration, runaway prompts, or an agent looping on tool calls.

The MCP trust validation is the more directly security-relevant change: it helps teams reduce the chance that developers accidentally point Copilot or other tooling at an untrusted MCP server. If you're adopting MCP internally, this is a nudge to document “approved servers,” pin endpoints, and review what tools they expose before enabling them in shared dev environments.

Auditing agent behavior in .NET with AGT + OpenTelemetry

This picks up where last week's governance thread left off (deterministic agent workflows and gateway-enforced controls) by showing how to capture the evidence you need for incident response: a .NET-focused tutorial showed how to add auditing and telemetry to Microsoft’s Agent Governance Toolkit (AGT) sample, writing governance events into Azure Blob Storage using Append Blob and exporting metrics/traces via OpenTelemetry to Application Insights. It included policy examples with direct allow/deny evaluation, plus KQL queries and guidance on sanitizing sensitive data in audit logs.

This is the kind of plumbing teams will need if agents are allowed to do anything privileged (create tickets, query internal systems, modify infra), because “what did the agent do and why?” becomes a standard incident response question. If you already have OpenTelemetry pipelines and Application Insights dashboards, this approach helps you keep agent auditing aligned with existing observability rather than inventing a parallel system.

GitHub security controls tighten up around CI, secrets, and auditability

Read-only Actions cache tokens reduce cache poisoning risk right now

GitHub Actions changed cache behavior for untrusted triggers: when the cache scope comes from the default-branch SHA, GitHub now issues read-only cache tokens for those untrusted runs. This specifically targets cache poisoning and privilege escalation patterns where an attacker influences cache contents in a PR context and later gets that cache consumed by trusted workflows.

If your workflows currently both restore and save caches in PR runs, you may need to move cache “save” steps to a trusted trigger like push while keeping restore steps in PR workflows. The security win is least privilege by default, but it will surface as a performance/behavior change if you were relying on PR runs to populate caches.

Copilot CLI in Actions can use GITHUB_TOKEN instead of PATs

GitHub Copilot CLI no longer requires a personal access token (PAT) when running inside GitHub Actions, and can instead use the built-in GITHUB_TOKEN. That directly reduces long-lived secret sprawl and the operational burden of rotating PATs across repos, environments, and runner pools.

Teams still need to align on Copilot policy/permissions and understand how org billing and spend controls apply to AI credits. Practically, this makes it easier to standardize “AI-assisted” workflow steps (like generating changelog drafts or refactoring suggestions) without introducing a new category of high-value secrets into CI.

Enterprise visibility increases with Copilot agent session streaming

In the same spirit as last week's push for agent audit trails (not just policy), GitHub also introduced Copilot agent session streaming in public preview for GitHub Enterprise Cloud, allowing enterprises to stream or query usage records (prompts, responses, and tool calls) across Copilot clients. You can route the data to a SIEM/event collector via audit log streaming, with Microsoft Purview supported as a streaming endpoint, or pull it via a REST API for the last 48 hours.

For security and compliance teams, this provides a much clearer path to “prove what happened” when agents are involved in code changes or operational actions. For developers, the implication is that Copilot activity can become part of standard audit trails, so teams should document acceptable use, redaction practices, and where prompts should not include sensitive material.

Secret scanning grows up: public monitoring, more validators, and operational playbooks

GitHub shipped two secret scanning expansions: public monitoring (public preview) for enterprises with GitHub Secret Protection, and new validity-check validators for Asana, IBM, and MessageBird. Public monitoring targets leaked secrets across public github.com content and attributes findings back to an enterprise using membership and verified-domain signals, which helps teams respond even when the leak is outside their private repos.

A related case study showed how GitHub itself got from 20,000+ secret scanning alerts to “inbox zero” by enforcing secret scanning and push protection, bulk-triaging low-risk findings, validating whether credentials were live, and building scalable ownership/remediation workflows. Taken together, the theme is shifting secret scanning from “lots of alerts” to “continuous monitoring plus predictable remediation,” with validity checks helping teams prioritize what is actually exploitable.

Repo hardening and supply chain governance continue to converge

GitHub published a practical checklist of six repo settings maintainers can enable quickly (SECURITY.md, private vulnerability reporting, secret scanning with push protection, Dependabot with dependency review, CodeQL scanning, and default-branch protection rules). In parallel, GitHub's Advisory Database team explained why review times have increased due to record vulnerability volume and complexity, and shared concrete submission guidance (package naming, version ranges, CVSS vectors, and CWE classification) to improve throughput while keeping reviewed advisories human-validated.

On the governance side, open source license compliance entered public preview for GitHub Enterprise Cloud, with enterprise-wide license policies enforced via rulesets and a required compliance check before merging dependency changes. GitHub also described how its OSPO uses the feature (evaluate/active modes, exceptions handling) to roll out enforcement without stopping delivery, which is useful if you want to introduce license controls gradually.

GitHub deprecations and retention changes: plan for API and alert-history impacts

Two platform changes need planning work. GitHub is restricting public REST API endpoints and UI views that expose stargazer and watcher lists, limiting access to admins/collaborators and deprecating the user subscriptions endpoint (returning empty responses during the deprecation window), which could break analytics and community tooling that assumed public visibility.

Separately, GitHub is introducing a cloud data retention policy for Dependabot security alerts: starting August 25, 2026, closed alerts older than two years move to archival storage and disappear from the UI and API, although admins/security managers can still export CSV. If you rely on long-term alert history for compliance evidence or trend reporting, you should build an export/archive process before the cutoff.

Azure and Fabric harden data paths with integrity, egress controls, and governed sharing

Azure Blob Storage adds end-to-end integrity checks (CRC64-NVME) in GA

Azure Blob Storage reached GA for client-side, end-to-end data integrity protections using CRC64-NVME checksums integrated into the latest Azure Blob SDKs. Instead of relying on legacy MD5 patterns, the SDK can perform transactional checksum verification so clients can detect corruption or unexpected mutation across the full path.

For developers moving large data sets or operating in environments where integrity is part of compliance, this gives a more modern integrity mechanism with clear SDK requirements and migration guidance away from MD5. The practical work this week is checking minimum supported SDK versions in your services and deciding whether to enforce checksum validation on reads, writes, or both based on performance trade-offs.

Fabric Real-Time Intelligence gets Workspace Outbound Access Protection (OAP)

In line with last week's agent hardening theme of adding explicit mediation at trust boundaries (instead of assuming “local” or “internal” is safe), Microsoft Fabric introduced Workspace Outbound Access Protection (OAP) in preview for Real-Time Intelligence experiences, with clear routing rules about what outbound routes are allowed or blocked for Eventstream, Eventhouse, KQL QuerySet, Real-Time Dashboard, Activator, and Fabric/Azure Events. A related preview specifically covered securing Azure and Fabric event flows in the Real-Time hub, where cross-workspace event consumption is blocked by default unless you allow the Real-Time Events connector via data connection rules.

If you're building near-real-time pipelines across workspaces (or across teams), OAP changes the default posture from “it might work” to “it will be blocked until explicitly allowed.” That is a good security baseline, but it means architects need to treat cross-workspace connectivity as governed infrastructure, with documented allowlists and ownership for the data connection rules.

Delegated OneLake Shortcuts preview targets scalable, governed data sharing

Microsoft Fabric announced Delegated OneLake Shortcuts (preview), adding delegated-identity authentication as an alternative to pass-through for scaling governed OneLake data sharing within and across tenants. A deeper dive on OneLake security and shortcuts explained how permissions evaluate differently between passthrough and delegated shortcuts, including intersection-based permissions behavior that can surprise teams expecting a simple “source OR target” rule.

For platform teams, the core design choice becomes: do you want access decisions to be enforced at the source (passthrough), or mediated via a delegated identity designed for distribution scenarios (delegated)? If you're doing cross-tenant sharing or mixing OneLake with external storage, you will want to test real permission intersections with table- and column-level security before rolling shortcuts out broadly.

Resilience and crypto timelines push security conversations earlier

Chaos Studio Workspaces adds scenario-based resilience drills (and agent integrations)

Azure Chaos Studio introduced Chaos Studio Workspaces in public preview, positioning chaos engineering as a scenario-driven workflow rather than a collection of ad hoc experiments. Workspaces recommend and run curated outage drills across Azure resources, then produce structured scenario reports correlated with Azure Monitor signals, which helps teams tie “what we broke” to “what we observed” in telemetry.

The post also highlighted integrations that matter for teams adopting agents: a GitHub Copilot Skill and an MCP server that let AI assistants drive Chaos Studio. The example Microsoft Entra ID outage scenario is a useful reminder that identity dependencies are often the real failure domain, so having a catalog of drills that include Entra failure modes helps teams prove resilience beyond pure compute/storage outages.

Microsoft accelerates its quantum-safe target to 2029 and asks customers to prepare now

Microsoft announced an accelerated Quantum Safe Program timeline, targeting a transition of critical products and services to post-quantum cryptography (PQC) by 2029. The guidance for customers was practical: modernize network protocols (including TLS 1.3), build crypto-agility for data at rest, and update trust chains for signing and certificates.

For engineering teams, the work starts with inventory: where do you terminate TLS, what libraries and certificate chains do you rely on, and where are signing keys embedded in build systems. Treat PQC readiness like a multi-year migration program, not a one-off “swap the algorithm” change.

Other Security News

Git (libcurl) removing NTLM in September 2026 is a breaking change that can stop HTTPS Git operations against Azure DevOps Server in environments relying on NTLM (often through SPNEGO fallback). The guidance is actionable: detect the dependency using warnings, klist, or GIT_TRACE_CURL, then move to Kerberos or SSH to avoid a last-minute outage.

Microsoft Defender research documented a malicious Manifest V3 Chromium extension impersonating Perplexity AI branding to hijack browser search by capturing Omnibox queries and redirecting via attacker infrastructure, and included IOCs plus Defender Advanced Hunting queries. Meanwhile, Microsoft also described improvements to security across the Cloud Solution Provider (CSP) partner ecosystem, emphasizing partner vetting, mandatory tenant security requirements, least-privilege delegated access via GDAP, and expanded monitoring/incident response.

Finally, a few items landed that security-minded developers will want on their radar: Dependabot will stop inferring .npmrc and instead expects a registry scope setting in dependabot.yml for private registries, GitHub previewed “medium depth” Copilot code reviews for more thorough PR feedback on complex/security-sensitive changes, and John Savill's Azure Update called out additional security-relevant platform changes (including quantum-safe and PII-related notes). If you're managing external access and identity, there's also a solid guide on enabling Microsoft Entra ID B2B guest access for Dataverse-backed Power Apps with the right environment access, licensing, and Dataverse roles.