Tech Intelligence.

Google SecOps added two preview SOAR capabilities: case playbooks and reaction triggers. Case playbooks let responders run automation or manual actions at the case-container level instead of per alert, and reaction triggers can fire playbooks on live case/alert updates such as assignee, tags, priority, or entities. The release also notes Google SecOps SOAR 6.3.100 rollout with internal and customer bug fixes.

These features improve incident response workflow automation and reduce repetitive triage actions during active investigations. They can make SOAR playbooks more responsive to evolving cases and help standardize analyst actions across larger incidents.

Evaluate case playbooks and reaction triggers in a non-production SecOps project and map them to your existing IR automation workflows.

Google SecOps SOAR Announcement Release 6.3.99 is now available in all regions. This appears to be a platform release for the SOAR component of Google SecOps, expanding regional availability rather than introducing a specific named control or breaking change.

SOAR platform updates can affect incident response automation, playbook execution, and integrations with SIEM/SOC workflows. Regional availability also matters for data residency and operational consistency across environments.

Check Google SecOps SOAR release 6.3.99 notes for compatibility with existing automations and regional deployment requirements.

Amazon Bedrock Managed Knowledge Base now supports user-managed setup (3LO) for SharePoint, OneDrive, and Confluence data sources. Instead of creating third-party service account or 2LO credentials, users can sign in with their own existing credentials and let Bedrock handle the authentication flow for connecting those sources.

This reduces friction for prototyping retrieval-augmented AI apps and makes data source onboarding faster when admin-level credentials are not available. It also introduces a more user-centric OAuth flow alongside the existing enterprise/service-account option for production use.

Review OAuth consent, data-access scopes, and tenant policies before enabling user-managed setup for enterprise knowledge bases.

Amazon Bedrock Managed Knowledge Bases now supports ServiceNow as a native connector. The connector can crawl ServiceNow knowledge articles and service catalog items, including attachments, and perform incremental sync with scoping controls via sys ID inclusion lists, removing the need for custom ingestion pipelines.

This simplifies RAG data ingestion from a common enterprise system of record and reduces the operational burden of maintaining custom sync jobs. It can also improve freshness and governance of content used by AI assistants by keeping the knowledge base aligned with ServiceNow.

Review whether ServiceNow knowledge content should be ingested into Bedrock and, if so, constrain scopes and credentials tightly before enabling the connector.

GitHub Copilot expanded supported model choices, adding Claude Fable 5.1 for Copilot Pro+, Max, Business, and Enterprise, and rolling out Gemini 3.8 Flash to Pro, Pro+, Max, Business, and Enterprise. More relevant for security workflows, the Copilot app and Copilot CLI now honor content exclusions so sensitive code is kept out of agentic context. In VS Code 1.136, Agent Merge is in public preview to resolve review feedback, failed checks, and merge conflicts, and chat/session management features were added.

Content exclusions reduce the risk of sensitive source code being surfaced to AI tools during automated or agentic workflows. Agent-assisted merge automation can speed delivery, but it also increases the need to validate code, checks, and policy gates before merge.

Review your GitHub Copilot content exclusion settings and validate that Agent Merge still respects branch protection, required reviews, and CI policy gates.

Amazon Bedrock Managed Knowledge Base now supports built-in automatic sync schedules for native data source connectors. You can configure daily, weekly, or monthly refreshes instead of manually triggering syncs or building your own scheduler for RAG data ingestion.

This reduces operational overhead and helps keep retrieval-augmented generation systems aligned with current source content. It also lowers the chance that AI applications answer from stale policy or support data.

Set sync cadences based on source change frequency and review any existing custom scheduling automation for possible replacement.

AWS Security Bulletin 2026-101 reports CVE-2026-85787 in awslabs postgres-mcp-server versions before 1.1.7. The SQL validation logic can miss disallowed inputs, allowing crafted SQL in submitted content to break the intended read-only boundary and potentially modify data when an authenticated user interacts with the MCP server.

This is a security boundary failure in an AI/MCP integration layer, which can turn a read-only assistant or automation into a write-capable path. If exploited, it could lead to unauthorized database changes and integrity loss in environments that rely on MCP tooling for controlled access.

Upgrade awslabs postgres-mcp-server to version 1.1.7 or later and review any workflows that expose it to untrusted content.

AWS published CVE-2026-85654 for awslabs.dynamodb-mcp-server, affecting the CDK generator component in versions 2.0.10 through 2.1.5. Crafted table, index, or attribute names in a data model file can trigger template injection and lead to arbitrary code execution on the machine generating/deploying the CDK application.

This is a local code-execution issue in an AI-assisted infrastructure generation tool, so it can compromise the build or deployment host and any credentials or cloud access available there. Because it affects generated infrastructure, the blast radius can extend into AWS accounts, CI/CD runners, and IaC pipelines.

Upgrade awslabs.dynamodb-mcp-server to a fixed version immediately and inspect any pipelines or hosts that processed untrusted data model files.

Amazon EC2 now lets AMI owners attach compatibility rules that explicitly allow or deny instance types for an AMI. If a launch request uses a non-permitted instance type, EC2 blocks it before launch; existing AMIs are unchanged unless owners opt in to the restriction.

This adds a new control point for preventing invalid or unintended compute launches, which can reduce deployment failures and help enforce standardization across fleets. It is also useful for image governance in environments with mixed instance families or strict platform baselines.

Review your AMI publishing pipeline and decide whether to enforce instance-type compatibility on golden images used in production.

AWS Security Bulletin 2026-100 reports CVE-2026-85786 in Amazon ion-java, where highly compressed input can trigger memory-amplification denial of service during auto-decompression. The previous mitigation in ion-java 1.12.0 for CVE-2026-75936 was incomplete, and the fix requires upgrading to 1.12.1 or later.

If your services parse Amazon Ion payloads, an attacker could cause excessive memory usage and destabilize JVM workloads. This is a security and availability issue that can affect ingestion pipelines, event processing, or any AWS-integrated Java service using ion-java.

Inventory ion-java usage and upgrade all affected deployments to version 1.12.1 or later immediately.

Microsoft Security Blog explains how Edge AI changes the trust model when inference, model assets, credentials, and data run in customer-owned environments instead of a provider-controlled cloud. The article recommends attestation-based runtime verification, provenance for AI artifacts, and deterministic mediation of model actions before releasing sensitive assets like weights, keys, or data. It also highlights that disconnected deployments cannot depend on live cloud policy updates or revocation, so local verification and enforcement become necessary.

This is a shift from cloud-centric AI trust assumptions to customer-operated security controls, which raises the bar for supply chain integrity, runtime attestation, and access gating. It is especially relevant where AI systems can affect physical systems or handle sensitive data in environments with limited connectivity.

Review any edge or on-prem AI deployments for attestation, signed artifact provenance, and conditional release controls for secrets and sensitive data.

AWS disclosed CVE-2026-85781 in the Amazon EFS CSI Driver affecting versions <=3.4.0. When the controller is run with the non-default --delete-access-point-root-dir=true flag, it may delete directories from an EFS file system that does not match the access point in the PersistentVolume handle because the driver failed to verify ownership between the access point and file system.

This is a Kubernetes storage-controller authorization flaw that can lead to unintended data deletion across EFS file systems, even though Amazon EFS itself is not vulnerable. It matters for clusters that use the EFS CSI driver with privileged storage provisioning workflows because a user with PV creation rights could abuse it for destructive actions.

Upgrade the Amazon EFS CSI Driver to a patched version and disable --delete-access-point-root-dir=true unless strictly required, then review PersistentVolume creation permissions.

GitHub Copilot now generally supports OpenAI's GPT-6 Astra across IDEs, the Copilot CLI, the coding agent, the web app, mobile, and multiple desktop IDE integrations. Enterprise and Business admins can control access through Copilot model policy, and the model is billed via usage-based pricing at provider list rates.

This expands the set of available coding models for agentic and long-horizon development workflows, which can affect productivity, cost, and governance. Admin-controlled model enablement also matters for organizations that need to manage AI tool adoption and data/usage policy.

Review Copilot Enterprise/Business model policies and usage-based billing impact before enabling GPT-6 Astra for your org.

Kubernetes v1.37 moves the KubeletInUserNamespace feature gate to beta, allowing the kubelet, CRI/OCI runtimes, CNI plugins, and kube-proxy to run as a non-root user on the host inside a Linux user namespace. The update clarifies this is separate from pod user namespaces (hostUsers: false), and highlights that rootless node components reduce the blast radius of container-breakout bugs by preventing host-root compromise.

This is a significant hardening option for cluster nodes because it reduces the impact of runtime and kubelet escape vulnerabilities. It is especially relevant for environments where clusters are run on shared hosts, laptops, or as nested/ephemeral clusters.

Evaluate rootless node component support in your cluster build and hardening standards, and test compatibility with your CNI, runtime, and kube-proxy stack.

Amazon ECS added Early Success Criteria for rolling service deployments. You can now mark a deployment successful once a configurable percentage of desired tasks on the new revision are healthy, while remaining tasks continue launching outside the deployment lifecycle; ECS also adds BLOCKING vs DEFERRED cleanup behavior for source revision tasks.

This changes deployment semantics for ECS by decoupling rollout success from full task replacement, which can shorten CI/CD wait times and reduce deployment bottlenecks. It is especially relevant for workloads with slow or constrained capacity, long-lived connections, or scale-in protection.

Review your ECS deployment configuration and IaC to decide whether Early Success Criteria and DEFERRED cleanup match your rollback and availability requirements.

GitHub added a new REST API endpoint for star history that returns historical star counts with timestamps while avoiding exposure of individual stargazer identities. This is positioned as a privacy-safe replacement for earlier stargazer listing behavior, which was restricted to admins and collaborators earlier this year.

This changes how teams can measure repository popularity and growth without collecting personally identifiable user-level stargazer data. It preserves analytics use cases while aligning with tighter privacy controls in the GitHub API.

Update any GitHub analytics or reporting integrations to use the new star history endpoint and remove dependencies on stargazer identity data.

AWS MCP Server added a serverless diagnostic capability focused on AWS Lambda. AI coding agents can now inspect a Lambda function and its connected services (API Gateway, EventBridge, S3, DynamoDB, SNS, SQS, Step Functions) in one workflow to pull deployed configuration, recent change timelines, recurring errors, baseline deviations, and latency signals.

This makes AI-assisted troubleshooting for serverless workloads faster and more context-rich, especially when failures span multiple AWS services. It also centralizes access through the MCP Server, which can reduce manual console/API hopping during incident response and debugging.

Evaluate the AWS MCP Server in a non-production account and review the access scope, logging, and least-privilege controls before adoption.

Amazon EC2 C8g instances powered by AWS Graviton4 are now available in AWS Asia Pacific (Taipei, New Zealand) and AWS GovCloud (US-East). The new sizes include bare metal options, higher vCPU/memory ceilings than Graviton3-based C7g, and higher networking/EBS bandwidth, with AWS Nitro providing the underlying isolation and offload architecture.

This expands the footprint for Arm-based compute in regulated and latency-sensitive regions, which can improve cost/performance for security tooling, batch jobs, and platform services. The GovCloud availability is especially relevant for workloads needing stricter compliance boundaries.

Evaluate Graviton4 migration candidates in GovCloud/APAC and validate AMI, container, and Terraform compatibility before rollout.

AWS Transfer Family SFTP Connectors now support authenticating against an ordered list of AWS Secrets Manager version stages, such as current and previous, instead of a single fixed secret version. This lets ongoing SFTP file transfers continue during credential rotation without updating the connector or suffering transfer failures during the rotation window.

This reduces operational risk for managed file transfer workflows that depend on external SFTP endpoints. It also improves secret rotation hygiene by allowing credential rollover without interrupting data movement.

Review any AWS Transfer Family SFTP Connectors you operate and update them to use version-stage-based Secrets Manager credential lookup during the next maintenance cycle.

Amazon SageMaker AI Batch Transform now supports EC2 G6e GPU instances for offline inference jobs reading data from S3. The update adds support for ml.g6e instance types in the CreateTransformJob API, AWS SDKs, and CLI across five regions, targeting GPU-heavy workloads such as LLMs and diffusion models.

This is primarily a compute/performance update for batch inference rather than a security or governance change. It can affect cost, capacity planning, and regional availability for teams running large offline ML workloads.

No action needed unless you operate SageMaker Batch Transform workloads, in which case review cost, quota, and region support for ml.g6e.

Google Cloud Billing added a new Incentives page that replaces the Spend-based Milestones tab for tracking conditional incentives such as spend-based credits and RaMP discounts. Cloud SQL added C4 machine series support for MySQL, PostgreSQL, and SQL Server Enterprise Plus in multiple regions, plus in-place upgrades/downgrades for edition, machine type, storage type, and database version. Cloud SQL for SQL Server also now supports write endpoints through the Cloud SQL Auth Proxy and language connectors, enabling automatic redirect to the new primary during failover or switchover.

The billing UI change affects cost governance workflows for committed spend and incentive tracking, while the Cloud SQL updates improve operational flexibility and failover handling. In-place reconfiguration reduces migration risk, and write endpoint support lowers application failover complexity for managed databases.

Verify any billing dashboards/processes that depended on the old Credits tab and assess whether your Cloud SQL automation should use write endpoints and in-place updates.

AWS has launched EC2 C9g and C9gd instance types in the Asia Pacific (Tokyo) region, both based on Graviton5 and the sixth-generation Nitro System. The update also introduces Nitro Isolation Engine, which AWS says uses formal verification to provide mathematical assurance of isolation between customer workloads and AWS operators. C9gd adds local NVMe SSD storage for low-latency scratch and cache use cases.

This expands the set of high-performance ARM-based compute options in Tokyo and may improve cost/performance for compute-heavy workloads. The Nitro Isolation Engine claim is notable from a cloud security perspective because it highlights stronger isolation guarantees at the hardware/virtualization layer.

Assess whether any Tokyo-based EC2 workloads can be moved or tested on C9g/C9gd and compare security/performance posture against existing Graviton4 instances.

Amazon ECS Managed Daemons now allow you to mark a daemon as non-critical for ECS Managed Instances. If the daemon fails, stops, or becomes unhealthy, ECS will keep the container instance active and will not churn or block placement of application tasks; the daemon can be created or updated by setting critical=false via Console, CLI, CloudFormation, or SDKs. ECS also emits EventBridge events and service action logs for daemon start failures, covering both critical and non-critical daemon health.

This reduces operational blast radius for supporting agents such as logging, metrics, or compliance daemons so they do not destabilize production workloads. It also improves observability and incident response by surfacing daemon start failures through EventBridge and logs.

Review your ECS managed daemons and mark only truly auxiliary agents as non-critical, then add EventBridge alerting for daemon start failures.

AWS expanded EC2 M9g and M9gd availability to four additional regions: Europe (Ireland) and Asia Pacific (Singapore, Sydney, Tokyo). These Graviton5-based instance families are positioned for memory-intensive workloads and include Nitro System sixth-generation hardware with the new Nitro Isolation Engine, which AWS says provides mathematically verified isolation between customer workloads and AWS operators.

This expands deployment options for Graviton-based fleets and may improve performance-per-dollar for memory-heavy services. The Nitro Isolation Engine language is relevant from a cloud security perspective because it signals stronger hardware-backed isolation assurances, though it does not change customer IAM or policy controls.

Evaluate M9g/M9gd for eligible workloads in the newly added regions and compare performance and cost against current Graviton4 or x86 deployments.