SonicWall Won't Patch EoL GMS Flaws That Could Expose Files, Alter Database Records

SonicWall has warned of two vulnerabilities impacting end-of-life Global Management System (GMS) systems that it said will not be patched.

Details of the security flaws, which affect SonicWall GMS 9.5.2 and earlier versions, are below -

• CVE-2026-109593 (CVSS score: 9.1) - An unauthenticated file read vulnerability that could allow an attacker with network access to read internal GMS files, potentially exposing sensitive information.
• CVE-2026-109594 (CVSS score: 6.8) - A post-authentication SQL injection vulnerability that could allow an authenticated attacker to access or modify information stored in the GMS database under specific conditions.

"The affected product has reached End-of-life (EoL)," SonicWall said in a Tuesday alert.

"As a result, no remediation or security update will be released for these vulnerabilities. Organizations using the product should be aware of the associated security risks and are strongly encouraged to upgrade to the SonicWall Network Security Manager (NSM)."

The development comes less than a month after SonicWall shipped fixes for CVE-2026-102255 (CVSS score: 10.0), a critical pre-authenticated server-side request forgery (SSRF) flaw that could have allowed an attacker to reach internal functionality and perform unauthorized operations.

The vulnerability has since come under active exploitation in the wild, with telemetry data from Previdian recording 2,541 attack attempts from eight unique IP addresses from Singapore and the U.S. since October 9, 2026. As many as 30 exploitation attempts were registered on November 3, 2026.

from The Hacker News https://ift.tt/wPjNUOx
via IFTTT

Researchers Uncover Prompt Adware Hidden in OpenAI Codex Jailbreak Toolkit

Cybersecurity researchers have disclosed details of an OpenAI Codex jailbreak bundle that's designed to modify an artificial intelligence (AI) agent's trusted instructions to insert advertisements for a third-party AI gateway.

The phenomenon has been codenamed prompt adware by Check Point Research.

Called Haiou (meaning Seagull in Chinese), the jailbreak modifies OpenAI Codex's configuration files to inject advertisements for the jailbreak author's website into subsequent agent responses.

"The advertised service is an opaque, OpenAI-compatible LLM gateway, a middleware between an application and an LLM provider," Check Point Research said in a technical report. "The likely business model is to use the freely distributed jailbreak bundle as an acquisition channel for the paid gateway service."

Adware is a type of software that displays unwanted advertisements, which can appear on users' computers or mobile devices, often in the form of pop-ups or banners. Prompt adware extends this sketchy behavior to AI agents by means of a jailbreak that defeats the model's safety training and content guardrails.

The idea is to persistently modify the agent's global instructions through natural language to influence future responses. This, in turn, causes common greetings or activation words like "Seagull," "hi," "hello," "hey," "yo," and "are you there?" to trigger an advertisement for "zz.aiapi2025[.]top."

Haiou attempts to jailbreak a model by using several prompt injection techniques, such as role-playing and reframing cybersecurity-related requests into a Capture The Flag (CTF) scenario. In addition, it installs security-focused skills devoted to penetration testing, cracking, and reverse engineering.

However, it doesn't stop there. The bundle also injects persistent ads into the global agent instruction file to promote the LLM gateway website. On GitHub, "haiou-codex" is advertised as a "local enhancement configuration package" that adds a "Chinese technical personality and security research workflow to Codex." As of writing, the repository has been forked 77 times and starred 403 times since it was made available on July 10, 2026.

It's worth noting that Codex is not officially available in mainland China, suggesting that the service is likely aimed at individuals or organizations wanting to try out Western AI coding assistants.

What's more, the jailbreak has been bundled within Codex-X, an open-source Chinese visualization tool for configuring Codex through a graphical user interface.

"The behavior is introduced through natural-language instructions and configuration, rather than a traditional executable payload that users and security teams may more readily recognize as software behavior," Pedro Drimel Neto, malware analysis team leader at Check Point, said.

While serving an ad may seem relatively harmless in the larger scheme of things, the findings demonstrate how a bad actor could introduce undesirable behavior through third-party skills or configurations, leading to supply chain attacks.

"As AI agents become part of enterprise environments, the prompts, Skills and third-party components influencing their behavior become part of the trust chain too," Neto said.

from The Hacker News https://ift.tt/Un7aQ5s
via IFTTT

APT29-Linked Hackers Hijack Web Analytics Script to Deliver iOS and Android Exploits

The Russia-linked threat actor known as APT29 is said to be behind a large-scale watering hole campaign targeting iOS and Android users through compromised websites, fake domains, and a supply chain attack involving a Ukrainian web analytics service called Plerdy SEO Tracker.

"The injected JavaScript code collects browser and device attributes," Sekoia researchers Amaury-Jacques Garçon and Félix Aime said in a technical report shared with The Hacker News. "Then, the delivery infrastructure delivers a platform-specific N-day exploit chain targeting either iOS or Android."

The end goal of the attacks is to serve payloads capable of stealing browser cookies, and in some cases, Wi-Fi passwords or full mobile device data. The activity, codenamed Poisoned Source, was discovered by the French cybersecurity company in mid-October 2026.

A defining aspect of the campaign is the use of three infection vectors -

• Compromise of legitimate websites to inject malicious JavaScript
• Lookalike sites masquerading as high-profile websites in the U.S. ("america250[.]holiday"), Ukraine, Czech Republic, and Bulgaria
• Supply chain compromise of Plerdy SEO Tracker between August 27 and September 3, 2026, by injecting malicious code into "a.plerdy[.]com/public/js/click/main.js"

Some of the compromised websites include a major industry trade association representing U.S. companies operating in the chemical industry, a far-right European political party, and a Bulgarian military-related website. It's suspected that the watering hole campaign may have been designed to target specific individuals rather than a broad effort.

"It remains unclear whether the attackers intended to target visitors to specific websites or sought to compromise as many unpatched mobile devices as possible, indiscriminately exfiltrating data before selectively identifying and exploiting information of interest," Sekoia said.

"However, several of these sites are likely to attract high-value or strategically important visitors in the context of the Russia-Ukraine war. This supply chain attack spread through high-value targets, such as army, special forces, and military equipment (ballistic, UAV) websites."

Regardless of the method employed, all roads lead to the same payload: a JavaScript loader that profiles the visitor's device and web browser, and then serves appropriate next-stage malware. For iOS users, it leads to an exploit kit called DarkSword to harvest cookies and full device data.

On Android, the malware is equipped to exfiltrate Chrome data and Wi-Fi passwords without establishing persistence. No less than three different exploits have been identified -

• Class A, which targets iOS devices running iOS 16.7 and exploits CVE-2025-43529 (the same vulnerability exploited by DarkSword) and CVE-2024-27834 to deliver JavaScript malware for cookie theft.
• Class B, which targets iOS devices running iOS 18.5 and exploits the DarkSword exploit chain comprising CVE-2025-43529, CVE-2026-20700, CVE-2025-14174, CVE-2025-43510, and CVE-2025-43520 to deliver JavaScript malware for full device data exfiltration. This includes SMS messages and iMessages; Apple Mail Envelope Index and Protected Index SQLite databases; voicemail; WhatsApp and Telegram databases; iCloud Keychain, Wi-Fi passwords; contacts; call history; Safari browser history and cookies; photos; and data from Apple Health, Calendar, Notes, and iCloud Drive.
• Class C, which targets Android devices running Chrome versions from 139 through 145 (but explicitly excluding version 143 for reasons that remain presently unknown) and exploits CVE-2026-3910 and CVE-2025-27038 to achieve remote code execution, sandbox escape, privilege escalation, and ultimately deliver AndroSnitch to collect Chrome data and Wi-Fi passwords.

In all three cases, the exfiltrated data is sent to the "ad.starx-net[.]com:8881/telemetry/v12" endpoint. The Android attack chain incorporates a check to determine whether the targeted device is a Samsung Galaxy S25 Ultra by examining its model identifier (i.e., SM-S938B). If the device matches, the exploitation activity is terminated.

AndroSnitch derives its name from its similarities to ANDROSNATCH, a Chrome cookie-stealing payload that Google documented in August 2024 in connection with a suspected APT29 watering hole campaign, which targeted Android users visiting a Mongolian government website by leveraging a Chrome exploit chain involving CVE-2024-5274 and CVE-2024-4671.

"This operation also confirms the continued reuse of CSV [Commercial Surveillance Vendors] mobile exploit frameworks, such as DarkSword, by state-sponsored intrusion sets," Sekoia said. "The adoption of packaged N-day exploit chains lowers the cost and technical threshold required to conduct advanced mobile exploitation."

Coruna and DarkSword Kits Evolve

The development comes weeks after iVerify and Report URI detailed the P7 variant of DarkSword being delivered via half-click attacks that leverage ad-based infrastructure. In one case, the exploit is said to have been propagated through a malicious Instagram ad themed around the World Cup and served from "ad-track[.]live."

The other pathway is part of a criminal campaign dubbed DeadTag, in which attackers acquire expired domains behind old analytics and advertising tags that are still loaded by thousands of websites. The idea is to serve malicious JavaScript to iPhone visitors and silently do the attacker's bidding.

"It checks who's visiting," Report URI said. "Search engines, security scanners, automated browsers and anything else that looks like a bot gets nothing."

The script then interacts with the attacker's server, which then decides the destination to which each visitor has to be redirected. The iPhone exploit paths that take advantage of DeadTag lead to the Coruna exploit kit for older iPhones running iOS version 13 to 17.2.1 and DarkSword P7 for iOS devices running 18.4 to 18.7.

"These are not phishing pages or fake app downloads, both kits attack the browser itself," Report URI's Scott Helme said. "Simply opening the page is enough for your device to be compromised. There's nothing to tap, you don't need to click any link, nothing to install and no warning. If the iPhone is running a vulnerable version of iOS, the kit breaks out of the browser and installs spyware on the device."

Other schemes lead to decoy Google redirects, betting and casino scam sign-up pages, search advertisements for car deals and dentists, and fake surveys and "you've won" prize pages. More than 660 expired and re-registered domains are part of the DeadTag network.

According to an analysis published by Zimperium zLabs, campaigns distributing Coruna and DarkSword exploit kits have continued to evolve, with 608 domains delivering Coruna-family code as of October 2026.

Although Coruna was initially developed by a nation-state actor for highly targeted operations, its subsequent leak following initial disclosure has made the toolkit widely accessible to multiple threat actors for their own campaigns.

In many cases, the lure sites have been found to explicitly instruct visitors to exit their in-app browser or alternative iOS browser and open the link in Safari so as to trigger the exploit chain depending upon the device operating system.

"Targets running iOS 17.2.1 or earlier receive the legacy Coruna framework (exhibiting byte-identical JavaScript payloads across multiple recovered configurations)," security researcher Santiago Rodriguez said. "Conversely, devices running later iOS builds receive a DarkSword-derived execution chain."

"The analyzed distribution footprint spans dating portals, AI-companion platforms, cryptocurrency promotions, media streaming services, and – in several instances – compromised legitimate sites serving the kit via hidden iframes."

from The Hacker News https://ift.tt/pB4fSQl
via IFTTT

Xen Hypervisor Flaws Let One Malicious VM Read and Write Any Other VM's Memory

Two flaws in the Xen hypervisor allow a malicious guest virtual machine (VM) to read and write the memory of other VMs on the same host, including dom0.

Dom0 is the VM that, by default, has full permissions and manages the others. Patches are out, and there is no known mitigation, the Xen Project said in an advisory on November 3.

All Xen versions from 4.6 onward are vulnerable, while 4.5 and earlier are not. The flaws are tracked as CVE-2026-102703 and CVE-2026-102704, under Xen advisory XSA-523.

The Xen Project credited AI company Anthropic with finding the flaws using its Claude model. Stephan Lipp of Ada Logics then validated the finding, and the CodeAnt AI Security Research Team later independently reported the same issue.

The flaws are in grant copy, the operation Xen uses to copy data between VMs. Each VM tells Xen which of its memory pages other VMs may use, and Xen checks those permissions.

To save time on a batch of copies within the same memory page, Xen reuses checks it has already made. In some cases, it did not check again when it should have. That mistake is what lets a malicious guest read and write memory it does not own.

XCP-ng, an open-source virtualization platform built around Xen, said in its update notes that "a single compromised guest can break out of its isolation and take over the whole host."

Xen's advisory does not mention any attacks that exploit the flaws or specify what access within the VM an attacker needs.

Qubes OS is a security-focused desktop operating system that keeps software in separate Xen-based compartments called qubes. A bulletin said that every supported release and configuration is affected. Its fix is for Qubes 4.3, the only release it still supports.

Because every Xen version from 4.6 on is vulnerable, other products built on those versions are affected until their makers add the XSA-523 patches. As of November 4, Debian's security tracker listed the xen package in its bookworm, trixie, and forky releases as vulnerable, and in sid as fixed.

Fixes and Restarts by Platform

These are the fixes published so far:

• Xen source: the advisory has patches for xen-unstable to Xen 4.19.x, and for Xen 4.18.x to 4.17.x.
• Xen 4.6 to 4.16: the advisory has no patch for these versions. Xen 4.16's security support ended on December 2, 2024.
• XCP-ng 8.3: xen-4.17.7-4.2.xcpng8.3, released November 3. Hosts must be rebooted. Vates, which backs XCP-ng, rates the impact as Critical.
• Qubes OS 4.3: Xen packages 4.19.6-3 in dom0. Dom0 must be restarted, and Anti Evil Maid users must reseal their secret passphrase because the new Xen binaries change PCR18 and PCR19.

Qubes told users on November 3 to keep installing updates as normal. The fixed packages were then in its security-testing repository, due to move to the stable one over the next two weeks after community testing.

XSA-523 is separate from XSA-500, an earlier grant copy flaw that Xen disclosed on July 28, and it has its own patches.

from The Hacker News https://ift.tt/xkaYcLH
via IFTTT

China-Aligned Hackers Hijack Sogou Input Method DNS Requests to Deploy DarkVigil Backdoor

A China-aligned threat actor known as SlippyNunchucks has been attributed to a Domain Name System (DNS) hijacking operation abusing insecure HTTP communications in Windows versions of Sogou Input Method as part of a surveillance campaign designed to deploy an implant called DarkVigil (aka FDMTP).

The campaign, observed starting July 1, 2026, is assessed to have targeted organizations and Chinese-speaking individuals in Hong Kong, Thailand, Japan, Vietnam, Oman, and Sri Lanka, according to ESET.

"DarkVigil implants are typically deployed through popular Chinese applications," ESET researcher Anh Ho said in a report shared with The Hacker News. "By abusing these applications, the SlippyNunchucks threat actor has been able to reach Chinese-speaking users across Asia and Europe."

Some of the applications abused by the adversary include Sogou Input Method, QuickFox, QingTalk, MiYunChat, SoftCam, and tawk.to.

Active since at least September 15, 2023, SlippyNunchucks is known for targeting organizations and Chinese-speaking individuals across South and East Asia. These attacks led to the deployment of a modular .NET framework that includes DarkVigil and a set of over 20 plugins.

Although the use of the backdoor has been previously linked to Mustang Panda, ESET said it found no tactical overlaps between the threat actor and DarkVigil-related activity in its telemetry, prompting it to classify it as a distinct intrusion set.

Earlier this August, Fortinet's FortiGuard Incident Response Team detailed the threat actor's supply chain compromise of the QuickFox VPN and network acceleration tool to deliver DarkVigil.

According to the Slovakian cybersecurity company, the adversary shifted to exploiting Sogou Input Method, a popular Chinese-language input method editor developed by Tencent, as a delivery vector three days after QuickFox released a clean version of its program.

Specifically, the attack involves hijacking the app's branded vocabulary promotion mechanism to serve a malicious configuration, which ultimately paves the way for the deployment of the malware via SGTool.exe, a legitimate Sogou Input Method component that functions as a multi-purpose task dispatcher.

In a clean environment, the executable sends an HTTP request to the "config.pinyin.sogou[.]com/api/brandScd/getBrandScd.php" endpoint to fetch a configuration. But in the attack discovered by ESET, the DNS resolution of the domain is tampered with to resolve it to one of the two staging servers -

The consequence of this DNS hijacking was that HTTP requests to the "getBrandScd.php" endpoint were routed to one of the staging servers, which then responded with a malicious configuration. The configuration, for its part, instructs the binary to download two additional payloads from "sogou-cdn[.]com" and launch the malware via DLL sideloading -

• A legitimate Adobe executable ("biz_helper.exe")
• A rogue DLL ("libcef.dll") containing DarkVigil

DarkVigil is notable for its use of Duplex Message Transport Protocol (DMTP) for command-and-control (C2), allowing the client to execute and orchestrate plugins received from an attacker-controlled server to facilitate persistence or data collection.

Following responsible disclosure, Tencent addressed the vulnerability (CVE-2026-120422) in version 16.10, released on October 29, 2026, by migrating the affected HTTP requests to HTTPS.

SlippyNunchucks is suspected to operate keeping the interests of the Chinese government in mind, with ESET describing it as a nation-state surveillance effort.

"Although SlippyNunchucks targets organizations and individuals across multiple sectors, we discovered significant surveillance activity against an organization operating Chinese-language online betting platforms in Sri Lanka, Hong Kong, and the Philippines," ESET said.

"The targeting of this organization is notable given China's restrictions on gambling, including criminal penalties for operating gambling businesses and organizing Chinese citizens to gamble abroad."

This is not the first time China-nexus threat actors have weaponized the Sogou Input Method as an entry point for malware distribution. In September 2026, Gen Digital said a now-patched vulnerability in the input method editor (CVE-2026-51990) was exploited by UNC3569 to deliver a backdoor dubbed GRAYRABBIT by means of a crafted link.

"The vulnerability chains three separate weaknesses into a single, one-click exploit: unvalidated command-line argument injection in the sgbiz: custom protocol handler, unrestricted URL navigation in a CEF-based WebView, and a severely outdated, unsandboxed Chromium browser engine [susceptible to CVE-2021-38003]," Gen Digital said.

from The Hacker News https://ift.tt/M0qSglX
via IFTTT

CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a security flaw in WordPress Core to the Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.

The high-severity vulnerability, tracked as CVE-2026-119977 (CVSS score: 8.1), is a case of Time-of-check Time-of-use (TOCTOU) race condition that could be exploited to achieve arbitrary code execution on affected servers. Patches for the flaw were released late last month.

"WordPress Core contains a time-of-check time-of-use (TOCTOU) race condition vulnerability that could allow unauthenticated attackers to execute code on the server during the upgrade window," CISA said. "This is due to predictable, web-accessible staging paths used during full-package core upgrades."

Details of the flaw emerged last week when Wordfence said exploiting the vulnerability does not require an account on the site. That said, it does require an attacker to exploit a brief window during a complete Core update that could allow unauthenticated code execution.

During the first 21 hours after public disclosure, the WordPress security company said it recorded more than 18,500 requests targeting staged "setup-config.php" installer paths. As of writing, 12,632 attacks attempting to exploit the flaw have been blocked in the last 24 hours.

Telemetry data from Previdian shows that three exploitation attempts have been recorded against its honeypot censors from an IP address geolocated in the U.K. The exploitation events were observed on October 30, 2026.

With exploitation now officially confirmed by CISA, Federal Civilian Executive Branch (FCEB) agencies have time until November 6, 2026, to apply the fixes.

from The Hacker News https://ift.tt/jez0DAG
via IFTTT

1077 - From $2 Trillion to $20 Trillion: What Anthropic Has to Become Beyond Claude

Brian and Brandon debate what Anthropic has to become if its IPO succeeds and, in Brian’s hypothetical, it must grow from a $2 trillion company into a $20 trillion one. Brandon argues the natural next step after Claude Code is rules-based back office work like tax, accounting, and finance, and he floats a free Claude tool that prepares a basic 1040 tax return as a national proof of concept, which raises the question of whether Anthropic wants to take on Intuit directly. Brian sees a Claude version of the ERP as a logical target, given how much customers dislike the consultants and constant data integration that come with those systems, though it would mean entering SAP and Oracle territory. They also weigh whether Anthropic would announce these moves or let them emerge quietly, with Brian pointing to its claim that it could rewrite mainframe code, which he says sent IBM’s stock down, and Brandon predicting most of it will be emergent. The boldest ideas build on Bending Spoons: Brandon proposes “Claude Equity,” where Anthropic buys companies and runs them with a few people and AI, while Brian imagines using IPO money to build cheap replacements that drive down incumbents’ value before buying or swapping them. Brandon cites Anthropic’s new source control work as a possible shot at GitHub, but Brian warns that at the growth investors may expect, replacing GitHub is like a fly on a horse’s back.

 

 

SHOW: 1077

SHOW VIDEO: https://youtu.be/C8MY3IhJtXM

 

 

SHOW SPONSORS:

• Nord Security - NordLayer AI Scout

 

 

SHOW LINKS

• The Enterprise AI Show
• Anthropic’s S-1 filing
• Redesigning source control at Anthropic
• COBOL Modernization with AI: Breaking the Cost Barrier
• Bending Spoons
• Palantir CEO Alex Karp’s CNBC interview
• Bun 1.4 Rewritten In Rust
• Stack Overflow Went From 200,000 Monthly Questions to Nearly Zero

 

 

GUEST BIO

N/A this week

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/li3tNGg
via IFTTT

Strengthen security for agentic AI with new Vault, Verify, Boundary, and Secure Hub capabilities

AI agents are reshaping what enterprises need to secure. They join workloads, applications, machines, and human users in accessing increasingly distributed infrastructure, creating new requirements for identity, authorization, credentials, access, and governance. 

At TechXchange, IBM is introducing new capabilities across Verify, Vault, and Boundary to help enterprises establish trusted identities, enforce appropriate access, strengthen cryptographic security, and govern activity across hybrid environments, creating a stronger foundation for agentic AI and autonomous operations. 

Agent Identity enables trusted AI agents across the enterprise 

AI agents are rapidly becoming active participants in enterprise operations. As agents gain the ability to access systems, invoke tools, orchestrate workflows, and act on behalf of users, organizations need a consistent way to establish agent identity, manage delegated authority, enforce access controls, and maintain accountability throughout the agent lifecycle. Traditional identity systems were not designed to address these new requirements. 

IBM Agent Identity, now generally available, helps organizations secure AI agents as first-class identities through a coordinated identity control plane. It enables enterprises to register agents, establish ownership, preserve delegated authority and context as agents act across systems, enforce task-scoped authorization, protect credentials through integration with HashiCorp Vault, and maintain end-to-end auditability. Together, these capabilities help organizations understand which agents are operating, what they are authorized to do, and how their actions trace back to human or business approvals, establishing the trust and accountability needed to scale agentic AI in production. 

Together with IBM Verify, HashiCorp Vault, and watsonx Orchestrate, IBM Agent Identity provides a foundation for securing the agent lifecycle, helping enterprises accelerate AI adoption while strengthening governance, reducing identity-related risk, and building trust in autonomous operations.  

Vault strengthens identity-based security for the autonomous hybrid cloud 

Organizations adopting AI, cloud-native applications, and automation face a changing security reality: rapidly growing populations of non-human identities, increasing cryptographic risk, and operational complexity across distributed environments. With the general availability of Vault 2.2, IBM helps customers address these challenges through three key outcomes. Govern AI identities with confidence by extending identity governance to AI agents and non-human identities, strengthening least-privilege access, and establishing trusted workload authentication. Eliminating the long-standing Secret Zero challenge for on-prem workloads is another way that Vault 2.2 helps organizations govern identities with confidence. With vTPM support for Linux VMs, workloads can authenticate to Vault using cryptographic proof tied to an enrolled virtual TPM rather than relying on distributed bootstrap secrets, strengthening machine identity. Automate certificate lifecycles and improve crypto agility by modernizing PKI, automating public certificate management, and advancing post-quantum readiness. These capabilities help organizations reduce identity and cryptographic risk while improving resilience as AI-driven operations scale. 

Vault 2.2 also helps customers drive enterprise scale and adoption by deepening IBM ecosystem integration, including Vault on IBM Power, while improving usability, automation, and operational visibility. Together, these investments help organizations reduce fragmentation and standardize identity, secrets, certificate, and key management across IBM and hybrid environments. Vault 2.2 strengthens Vault's evolution beyond secrets management as an identity-based security solution, helping customers securely adopt AI, reduce operational and cryptographic risk, and build the trusted security foundation required for the autonomous hybrid cloud. 

Announcing the public preview of Vault Arc and Secure Hub 

As infrastructure, machine identities, and AI agents expand across hybrid and multi-cloud environments, enterprises need security platforms that can evolve with new requirements while building on the investments they rely on today.  Vault Arc and Secure Hub, now in public preview, expand HashiCorp’s Security Lifecycle Management capabilities to help organizations modernize on their terms, strengthen governance across their security environments, and prepare for the emerging security requirements of agentic AI. 

Secure Hub: Govern Vault at scale 

As Vault adoption expands across teams, regions, and environments, fragmented visibility and reporting make it increasingly difficult to monitor security resources, assess operational health, and maintain consistent governance. 

Secure Hub addresses these challenges by providing centralized visibility, reporting, and governance across distributed Vault environments. The public preview introduces cross-environment insights into operational health, secrets, and certificates, along with a common governance experience spanning Vault Enterprise and Vault Arc. 

Vault Arc:  Expanding Vault for evolving enterprise needs 

Vault Arc expands the Vault portfolio with a new architecture designed for evolving scale, operational, and security requirements. It complements the Vault environments organizations rely on today, giving customers greater flexibility in how they deploy Vault across different workloads and use cases. 

The Vault Arc public preview introduces capabilities designed to simplify operations and developer workflows, strengthen authorization and governance, and support emerging machine and agentic workloads. Its architecture provides a foundation for a new resource and IAM model, scoped and ephemeral authorization, agent and non-human identity governance, and greater cryptographic agility. 

Join the public preview of HashiCorp Vault Arc and Secure Hub to explore the new capabilities, share your feedback, and see how they can extend your organization's security lifecycle management strategy. 

Boundary improves target auto-discovery and introduces an MCP server 

HashiCorp Boundary 1.1 is now available, improving administration for enterprise scale and enhancing external integration. Boundary also introduces an MCP server, currently in public preview, which is used to help reduce administrative tasks and facilitate agentic access.  

Improved integrations with App Tokens  

App tokens is a new enhancement that improves the way external applications securely interact with Boundary for CI/CD workflows, infrastructure automation, observability, or any type of integration. Prior to App token, the process for external applications to authentication with Boundary involved multiple steps that were not efficient and was potentially brittle. With App tokens, the administrators can create authorization tokens more easily with customized time-to-live and scope for each external application, improving security and efficiency.  

Higher scale with cross-account target auto-discovery 

Boundary can auto-discover and onboard virtual machines in Amazon Web Services (AWS), Microsoft Azure, and Google Cloud, greatly reducing administrative effort. Boundary’s latest release improves this process even further by making auto-discovery easier across multiple AWS accounts. Prior to the enhancement, customers needed to configure Boundary plugins in each AWS account that needed auto-discovery. Now, customers can configure the Boundary plugin in a single account and Boundary can discover and onboard virtual machines across multiple AWS accounts with minimal additional configuration effort. This enhancement further reduces administrative effort for customers with a large number of AWS accounts. 

Reduce management and facilitate secure agentic AI connections with MCP Server  

Boundary is introducing a Model Context Protocol (MCP) server that simplifies management and troubleshooting for administrators. The MCP server also facilitates AI agent access to infrastructure resources without requiring agents to have custom code or additional Boundary client tools.  

For administrators, the Boundary MCP server relieves a lot of burden by allowing them to interact with Boundary clusters using natural language with common AI assistant clients like Claude, Cursor, and Codex. Administrators can ask questions, perform administrative tasks, and troubleshoot issues without needing to know the exact UI workflow, CLI command, or API call. As a result, administrators spend less time learning Boundary tools and searching through documentation. 

For AI agents that are MCP-compatible, the Boundary MCP server can facilitate session and connections through Boundary to securely access infrastructure resources like SSH and RDP target systems. Agents do not need to have custom Boundary code or Boundary client tools to connect, making it much more scalable to enforce secure guardrails for agentic access within a network. 

See the latest Boundary 1.1 blog for more details on the latest Boundary releases. 

Securing agentic AI requires more than protecting individual credentials or connections. Organizations need coordinated controls that establish trusted identities, define what human, machine, and AI identities are authorized to do, secure how they access resources, and maintain governance across distributed environments. 

The latest capabilities across IBM Agent Identity, Vault, Secure Hub, Vault Arc, and Boundary extend security across this lifecycle. Together, they help organizations strengthen identity and cryptographic security, govern Vault environments at scale, and secure infrastructure access as AI agents take on more autonomous roles across the hybrid cloud.  

To explore how organizations can apply continuous trust across the agentic lifecycle, read the IDC white paper, Secure enterprise agentic AI with continuous trust. For a closer look at the underlying architecture and controls, watch the Securing the agentic runtime technical deep-dive webinar. 

from HashiCorp Blog https://ift.tt/ONZWzrV
via IFTTT

Boundary 1.1 improves target discovery, external app integration, and introduces MCP server

Boundary 1.1 is now available with administrative improvements for enterprise scale and simpler external app integration. A new Model Context Protocol (MCP) server will also be available in public preview that allows administrators and end users to interact with Boundary using natural language through AI-driven interfaces. 

App Tokens 

This release introduces app tokens, which are used to securely integrate external tools with scoped access to Boundary. Prior to this release, when an external machine or application needed access to Boundary for CI/CD workflows, infrastructure automation, observability, or any type of integration, it relied on a shared human credential or an admin-managed static password, which posed a security concern as password accounts are long lived and never expire. In addition, when human password credentials were used, the authorization tokens given to external applications were short-lived and valid for only seven days. This means applications would only be able to perform API calls to Boundary for seven days before the application needed to re-authenticate and request a new token. This was an inefficient process that was brittle and not very secure.  

App tokens now allow administrators to provision tokens with fine-grained permissions for machine-to-machine communication with Boundary. App tokens will have maximum time-to-live (TTL) ceilings of three years to ensure credentials are not long-lived. In addition, each individual app token will have customizable TTL and time-to-stale (TTS) values so new tokens are not required as frequently. For example, administrators can set tokens to expire after one year instead of every seven days. This capability makes it more efficient for administrators to manage the full credential lifecycle, including creating, revoking, and rotating credentials. Comprehensive audit logs also record every API request, helping organizations meet compliance and regulatory requirements. 

Cross-account support for AWS auto-host discovery 

Boundary dynamic host catalog (DHC) automatically discovers, onboards, updates, and off-boards virtual machines (VMs) from Amazon Web Services (AWS), Microsoft Azure, and Google Cloud to keep Boundary’s host inventory current. This automation eliminates manual inventory updates, which are difficult to sustain at scale in environments where VMs are frequently created and removed. 

Before this release, DHC could discover EC2 instances only within the AWS account in which it was configured. Discovering instances across multiple accounts required administrators to configuring a worker separately in each AWS account, increasing setup time and ongoing management. 

Boundary 1.1 adds cross-account discovery for DHC on AWS. Administrators can configure a DHC in one AWS account and use appropriate AWS Identity and Access Management (IAM) roles and permissions to discover EC2 instances in other accounts. This hub-and-spoke model centralizes configuration and reduces administrative effort. 

MCP server (public preview) 

Boundary now offers a Model Context Protocol (MCP) server that simplifies management and troubleshooting on the control plane, while reducing the complexity of integrating AI agents with Boundary for secure infrastructure access on the data plane. 

How this helps administrators 

As organizations adopt new products or tools, the learning curve associated with managing the product can be a challenge. Even simple products may have multiple tools for administrators to learn, including GUIs, CLIs, and APIs. Further, troubleshooting can be more frustrating as administrators interpret unfamiliar error message. Administrators will often need to search through documentation which can also be a daunting. 

The Boundary MCP server now relieves a lot of the burden allowing administrators to interact with Boundary clusters using natural language with common AI assistant clients like Claude, Cursor, and Codex. Administrators can ask questions, perform administrative tasks, and troubleshoot issues without needing to know the exact UI workflow, CLI command, or API call. This reduces the level of effort and time administrators spend learning Boundary tools or searching through documentation. 

How this helps AI agents 

Integrating agents with an infrastructure access platform can traditionally require developers to build custom integrations using APIs or SDKs, or install and invoke CLI tools within the agent’s environment. The Boundary MCP server simplifies this experience by exposing Boundary’s access capabilities, allowing MCP-compatible agents to request infrastructure access without developers having to build and maintain custom Boundary integrations. 

When an agent needs to connect to a resource, the Boundary MCP server can establish the authorized Boundary session and create a local TCP listener that proxies the agent’s connection through Boundary to the target resource. The agent can then connect its existing client or tool to the local listener, while Boundary handles the underlying access session. This means developers do not need to embed Boundary-specific API calls, SDKs, or CLI commands into each agent. Instead, organizations can provide a standardized way for agents to access infrastructure through Boundary while retaining Boundary’s centralized authorization and access controls. 

Conclusion 

Boundary 1.1 helps organizations adopt AI agents and other non-human identities without sacrificing control over infrastructure access. JWT authentication and app tokens provide purpose-built identity and credential controls, while the Boundary MCP server simplifies administration and agent integration. Cross-account AWS host discovery further reduces configuration effort at enterprise scale. Together, these capabilities help teams securely expand automation while maintaining centralized authorization, credential management, session control, and auditing. 

To learn more about the features in this blog:

• Read our AWS cross-account host discovery documentation

• Read our App tokens documentation

• Read our MCP server documentation

For new Boundary users

• Sign up for a free HCP Boundary account

• Download the free Boundary Desktop client

• Go through our tutorial on getting started with HCP Boundary

• To request a Boundary Enterprise trial, contact HashiCorp sales

from HashiCorp Blog https://ift.tt/vipT5x7
via IFTTT

The barriers to autonomous infrastructure

Infrastructure automation has transformed how organizations provision and manage infrastructure. But as agents begin to participate alongside humans in infrastructure operations, automation alone is no longer enough. 

The next challenge is autonomy: How do we give agents the ability to act safely within guardrails? 

Answering that question requires more than giving agents access to infrastructure. They need trusted context to understand the environment and the potential impact of change, governed workflows to translate decisions into action, and continuous governance to maintain trust and control as infrastructure evolves. 

Three fundamental barriers stand in the way. 

Lack of Trusted Infrastructure Context  

Many organizations have adopted Infrastructure as Code to standardize provisioning and improve consistency across hybrid and multi-cloud environments. However, as infrastructure environments grow in scale and complexity, and agents begin participating in infrastructure workflows, provisioning alone is no longer sufficient. Organizations need a trusted understanding of their infrastructure estate to make informed decisions.  

Most organizations lack a complete and trusted view of their infrastructure, including resource relationships, dependencies, governance posture, compliance status, and operational context. Infrastructure data is often fragmented across teams, tools, and environments, making it difficult to understand how infrastructure is configured, how systems are connected, and what impact changes may have. Without shared context, both humans and agents struggle to make informed decisions with confidence.  

Difficulty translating decisions into governed actions 

Even when organizations have the information needed to make infrastructure decisions, translating those decisions into safe and governed actions consistently remains difficult. Governance controls, policy enforcement, operational procedures, approvals, and execution workflows are frequently distributed across disconnected tools and teams.  

As infrastructure delivery accelerates and agents become active participants in development and operational workflows, organizations must ensure actions are executed within approved guardrails and organizational standards. Existing operational models were largely designed for human-driven processes and manual coordination, creating friction between decision-making and execution while increasing operational risk at scale.  

Failing to Continuously Govern and Operate at Scale  

After infrastructure is deployed, many organizations struggle to maintain consistent governance, visibility, optimization, and lifecycle control across their environment. Compliance assessments, operational audits, policy enforcement, and lifecycle management are often performed through separate processes that provide only point-in-time visibility rather than continuous oversight.  

As infrastructure estates continue to grow and operational velocity increases, maintaining trust, consistency, and control becomes increasingly difficult. Organizations need the ability to continuously govern, optimize, audit, and operate infrastructure across hybrid and multi-cloud environments without introducing additional operational complexity. 

From infrastructure automation to autonomous infrastructure 

Autonomous infrastructure isn't simply about giving agents greater access or automating more tasks. It requires a foundation that gives agents the context to understand infrastructure, the guardrails to act safely, and the continuous governance needed to maintain trust as environments change. 

This is where infrastructure lifecycle management must evolve for the agentic era. With Terraform, organizations can establish a trusted infrastructure foundation that brings together shared context, governed workflows, and lifecycle controls, helping humans and agents operate with greater autonomy without sacrificing control. 

The measure of autonomous infrastructure won't be how much organizations can automate. It will be how confidently they can enable agents to act. 

Learn how Terraform helps build the foundation for autonomous infrastructure 

 

 

from HashiCorp Blog https://ift.tt/nQLIlsP
via IFTTT

Bring cloud cost insights to Terraform with IBM Cloudability

Cost estimates and FinOps policies often sit outside the Terraform workflow, making cost optimization a slow and complicated process. For example, teams must switch between a Terraform plan and separate financial or policy results, then match those findings back to the planned resources. Without a single view of the proposed infrastructure and its cost implications, teams may discover a concern only after completing their initial review. Addressing it means revisiting the configuration and reviewing the change again.

We are excited to introduce a new integration between HCP Terraform and IBM Cloudability, helping customers optimize cloud spending with market-leading FinOps intelligence. Customers using HCP Terraform Standard or Premium, and Terraform Enterprise 2.1 or later, together with IBM Cloudability can access this streamlined, integrated experience.

Built directly into the HCP Terraform run workflow, the Cloudability native task brings cost estimates based on IBM Cloudability data, FinOps policy checks, and recommendations into HCP Terraform runs. Teams can assess financial impact, enforce policies, and consider recommendations before applying infrastructure changes.  

Add cost context to Terraform plan reviews

Terraform plans let teams review proposed resource changes before applying them. The Cloudability native task adds financial context to that review by showing the estimated monthly cost before and after a proposed change, plus the difference between them. Teams can assess the infrastructure and its estimated cost together before deciding whether to apply or revise the configuration.

Per-resource estimates connect Cloudability cost data to the resources represented in the Terraform plan. Teams can assess those estimates against the workload’s requirements and budget, without waiting for a separate cost review. The estimates can account for custom and usage-based pricing where applicable, using Cloudability data available to the organization.

This makes the Terraform plan review a shared decision point for infrastructure and FinOps teams. Both teams can discuss the proposed resources and their estimated cost using the same plan, rather than assembling that information through a separate handoff.

Apply FinOps policies consistently

FinOps policies have more practical value when teams see their results where infrastructure decisions happen. Cloudability policy checks evaluate planned changes against configured FinOps policies and present the results within Terraform run. FinOps teams manage their policies in Cloudability, while infrastructure teams see the results in Terraform. Teams can identify concerns before apply and decide which configuration changes need attention without reconciling a separate policy report.

Within Terraform, advisory checks report findings and allow the run to continue. Mandatory checks can stop a run when their conditions are not met to prevent non-compliant changes. Teams can choose enforcement that treats a finding as guidance or makes it a condition of proceeding. Showing policy results beside estimated costs also keeps the financial implications visible when a failed check prompts further discussion.

Terraform gives teams flexible scoping, so the same FinOps checks apply consistently across an organization or a specific project without configuring each workspace separately.

Evaluate Cloudability resource recommendations before apply

IBM Cloudability can identify a lower-cost alternative for an eligible resource in a Terraform plan. The recommendation compares the planned resource configuration with a suggested alternative, giving teams more information before they provision the infrastructure.

HCP Terraform displays the recommendation alongside the plan, where teams can evaluate whether the alternative meets the workload’s operational and financial requirements. The recommendation informs the decision but does not modify the Terraform configuration. Teams decide whether to update the configuration or proceed with the original plan.

Get started

Explore the documentation to learn how the Terraform integration with IBM Cloudability helps you optimize cloud costs by comparing monthly cost estimates, checking policies, and reviewing recommendations before applying infrastructure changes.

New to Terraform? Sign up for an HCP account to get started today and check out our tutorials. HCP Terraform includes a $500 credit that allows users to quickly get started using features from any plan, including HCP Terraform Premium. Contact our sales team if you’re interested in trying our self-managed offering: Terraform Enterprise.

Visit the IBM Cloudability website to learn how to unlock cloud and AI value with FinOps.

from HashiCorp Blog https://ift.tt/gTXLaSl
via IFTTT

Drive adoption and operations across hybrid environments with Vault

Security teams face mounting pressure to secure more applications, identities, and infrastructure across increasingly diverse environments. Yet many organizations continue to struggle with operational complexity, fragmented tooling, and inconsistent security practices that slow adoption and create management overhead.

Vault 2.2 introduces enhancements that make Vault easier to adopt, simpler to operate, and more scalable across enterprise environments. From onboarding and usability improvements within Vault to expanded automation and deeper IBM ecosystem support, these capabilities help organizations accelerate adoption while standardizing security across hybrid infrastructure.

Accelerate time-to-value with a better Vault experience

Successful security platforms are not only powerful, but they must also be approachable for administrators, platform engineers, and application teams who interact with them every day. As Vault deployments expand across organizations, reducing friction becomes essential to broader adoption. In Vault 2.2, in-product adoption and onboarding features become generally available to improve the overall Vault user experience.

Reduce risk and disruption with the Upgrade Analyzer

Organizations that stay current on software releases can adopt innovations faster, standardize operations more effectively, and respond more quickly to evolving business and security requirements. Up to date platforms  mean teams can readily access and benefit from ongoing product enhancements, fixes, and security patches. However, deploying platform or product upgrades can be challenging while trying to maintain high standards of day-to-day operations, especially when they are perceived to be disruptive to business as usual. To help teams operate Vault more easily, Vault 2.2 introduces the Upgrade Analyzer, a tool built to provide transparency around upgrades. It supports Vault operators in planning which release to target and how to account for recommended prerequisites and known issues. The goal is to reduce the number of post-upgrade risks and make teams feel more secure in the Vault upgrade process by providing in-product information. 

Delight users with a more personalized Vault experience

Security practitioners spend long hours working within the tools that protect their organization. Small usability improvements can have an outsized impact on productivity, satisfaction, and long-term adoption. That's why Vault 2.2 introduces a series of user experience enhancements designed to make everyday interactions with Vault more intuitive, informative, and enjoyable.

Feature Spotlight cards on the Vault home dashboard help users quickly discover recently released capabilities and product updates without leaving the platform. These cards make it easy to understand the newly available features and enable customers to take full advantage of the upgrade, by making these announcements easily viewable within the product. By surfacing relevant innovations directly within the UI, teams can more easily stay informed and take advantage of new functionality as it becomes available.

Dark mode has been a top ask from users. Vault delivers it with support from preferences, but it will default to the system values upon release.  Preferences give individuals greater control over how they interact with the product. In 2.2.0, Preferences will support dark mode, in-product personas, and opting in to UI analytics. 

Submit feedback right from Vault

A new Submit Feedback button enables Vault users to provide input from the UI. We are grateful for and welcome feedback on how to improve features, other features that would be beneficial, or comments on what improvements you find most valuable. 

As an example, Vault users could provide feedback on other features that might benefit from the customizability of preferences. While this button creates a venue for in-product contact, it’s also intended to enhance engagement with account teams or support. The feedback provided via the button will be monitored by the Vault Product Management team and contributes to the data that influence roadmap decisions.  

Reduce operational complexity through security automation

As organizations scale, manual security processes quickly become unsustainable. Managing secrets, credentials, and service accounts across multiple environments can create significant operational overhead and increase the risk of human error.

Vault 2.2 expands automation across credential and secret lifecycle management to help teams implement consistent security practices with less manual effort.

Vault 2.2 strengthens Azure Secrets Engine with automated rotation and immediately consistent Azure access tokens to resolve eventual consistency delay and reduce credential delays and drift. For LDAP Secrets Engine, account unlocking improves credential management within Vault and not in the configured external system, while proactive configuration validation with the LDAP Health Check identifies connectivity issues before failures occur, improving operational resilience.

Secret Recovery for KV v2 provides a safeguard against accidental secret deletion, helping teams recover critical information when mistakes occur. Usage Attribution offers deeper visibility into Vault consumption patterns, enabling administrators to better understand adoption, governance, and utilization across teams and environments.

By automating repetitive security tasks and improving operational visibility, organizations can reduce complexity, strengthen governance, and scale security programs more effectively.

Extend consistent security controls across IBM and hybrid infrastructure

Enterprise infrastructure continues to evolve beyond a single platform or cloud provider. Many organizations operate a mix of IBM Power systems, Kubernetes environments, public clouds, and traditional datacenters. Securing these disparate environments often requires multiple tools and inconsistent operational processes that increase complexity and slow adoption.

Vault 2.2 helps organizations establish a consistent approach to secrets and identity security across their infrastructure footprint.

The Vault Client on IBM Power, now available in beta, enables teams running mission-critical workloads on IBM Power to leverage the same Vault workflows and operational model used elsewhere in the enterprise. This is planned to be made generally available in a follow-up patch release this year. Vault Secrets Operator (VSO) on IBM Power extends Kubernetes-native secrets and certificate management capabilities to IBM Power environments, helping platform teams standardize security practices across both modern and traditional infrastructure.

Vault 2.2 further strengthens cloud-native integrations with support for Azure AKS Workload Identity, enabling secure workload authentication without relying on long-lived credentials. This helps organizations simplify identity management while improving security across Kubernetes deployments.

Secrets Sync with Vault’s DB secrets engine enables organizations to maintain control over secrets, while making them available through external secrets stores, including cloud service providers and other destinations. Vault 2.2 now sources secrets from Vault’s database secrets engines, including instant updates for rotating database secrets, and enables encryption of those secrets in AWS and GCP.  With these updates, rotating secrets across a distributed hybrid deployment is a simple API call.  

These capabilities allow organizations to extend consistent security controls across diverse environments, helping reduce operational silos while simplifying security management across hybrid infrastructure.

Standardize security and scale with confidence

As organizations expand across cloud, on-premises, and IBM environments, security success increasingly depends on the ability to simplify operations while maintaining consistent controls.

Vault 2.2 delivers improvements that help organizations achieve both. Enhanced onboarding and usability features accelerate adoption, expanded automation reduces operational overhead, and deeper IBM and hybrid cloud integrations help standardize security practices across the enterprise.

The result is a platform that enables organizations to reduce complexity, eliminate tool fragmentation, and scale modern security practices wherever applications and workloads run.

Drive adoption and simplify Vault operations

Vault 2.2 delivers new capabilities that make Vault easier to adopt, simpler to operate, and more consistent across hybrid environments. To take advantage of these enhancements, we encourage existing customers to upgrade to the latest version and begin benefiting from the latest usability improvements, automation capabilities, and platform integrations.

Before the next GA, use the Upgrade Analyzer to assess your environment, identify potential upgrade blockers early, and plan your migration with greater confidence. By proactively evaluating your environment, you can reduce risk, minimize disruption, and accelerate access to the latest Vault innovations.

from HashiCorp Blog https://ift.tt/UW1bJRu
via IFTTT

Eliminate Secret Zero for on-prem workloads with Vault 2.2

Your application starts on a virtual machine. Its database password is safely stored in Vault. Access policies are in place. Everything is ready—except the application needs a credential before Vault will let it retrieve anything. Someone has to get that first credential to the right machine. Then protect it, limit its use, and replace it when necessary. Repeat that across a fleet, and the first connection becomes a security risk of its own. This is the Secret Zero problem. And for teams running applications on on-premise VMs, it can stand between adopting centralized secrets management and relying on yet another system to distribute secrets.

Vault 2.2 introduces TPM Support for Vault Enterprise. Linux VMs can authenticate using keys bound to an enrolled virtual Trusted Platform Module (vTPM), removing the need to deliver a reusable bootstrap secret to each VM for this authentication flow. For platform teams, that means a new way to establish trust in the applications running on infrastructure they already operate. For security teams, it means stronger protection against credentials being copied from one machine and reused on another.

Bring infrastructure-based authentication to on-prem VMs

Cloud identity services give workloads a way to authenticate without teams distributing their own bootstrap secrets. Where those services are configured, Vault can use the platform's identity as a basis for trust. On-prem VM environments often lack an equivalent identity service that Vault can consume directly. Teams fill the gap with AppRole SecretIDs, client certificates and private keys, or tokens delivered through provisioning systems. These approaches can be secured, but the delivery process remains part of the trust chain.

TPM Support gives teams another path. A vTPM provides cryptographic operations using protected keys inside a virtual machine. Once the vTPM is enrolled with Vault, the VM can prove possession of a key bound to it. Vault can verify that proof before granting access. The operator decides which VM to trust and what it can access. The VM supplies the cryptographic proof when it authenticates. There is no reusable bootstrap secret to hand over to the VM. The initial release focuses on Linux VMs with vTPMs in Vault Enterprise. Windows and physical TPMs on bare-metal servers are outside this release's scope.

Enroll, attest, authenticate

TPM Support brings the attestation and authentication workflow into Vault:

1. Enroll the VM. An authorized operator or provisioning system registers the vTPM's public Endorsement Key with Vault and configures the roles and policies it may use. Enrollment establishes which machine is trusted and the access it is eligible to receive.

2. Attest the key. The VM completes an attestation exchange with Vault. Vault verifies that the application key is bound to the enrolled vTPM and issues a client certificate for that key.

3. Authenticate to Vault. The VM uses the certificate and its vTPM-protected key to authenticate. Vault issues a token with the configured policies, which the application uses to retrieve its secrets.

The application still gets a Vault token and accesses secrets through Vault's policy controls. What changes is how it earns that token in the first place. A public certificate and protected key blobs can remain on disk. Copying those files alone does not provide the usable private key needed to authenticate from another machine with a different vTPM. That binding is the core security benefit: access depends on using the enrolled vTPM's key, rather than possessing a bootstrap secret copied from the VM.

Replace secret delivery with managed enrolment

For platform teams, TPM Support changes the work involved in bringing a VM into service. Instead of delivering a reusable bootstrap secret, the provisioning process registers the VM's public vTPM identity and associates it with the right access in Vault. That creates an opportunity to make enrollment part of VM provisioning. A new VM is enrolled as it comes into service, receives access appropriate to its role, and can subsequently authenticate using its vTPM-bound key.

Enrollment remains a trust decision. The provisioning system needs permission to register machines, and teams need procedures for vTPM replacement, VM retirement, and failed attestation. Certificates and Vault tokens also retain their own lifecycles. The operational benefit is removing bootstrap secret delivery from that process, while keeping authorization in Vault.

The same benefit applies whether the VM runs an established application, a new service, or an AI agent. Each needs to authenticate before it can retrieve secrets. TPM Support addresses that shared foundation without requiring the application to move to a cloud platform first.

Connect on-prem authentication to SPIFFE identity

Vault already provides capabilities for minting SPIFFE identities. TPM Support strengthens the first step for on-prem VMs: authenticating to Vault before requesting an identity. An application can use its enrolled vTPM to authenticate to Vault, then request a SPIFFE identity through Vault's existing issuance capabilities, subject to the configured access policies. This connects authentication rooted in the VM's vTPM with a standard identity that can be used beyond Vault.

For platform teams, the two capabilities address complementary needs: TPM Support establishes the basis for the initial authentication, while SPIFFE gives the workload an identity that other systems can verify. Those systems must support the relevant SPIFFE identity format and be configured to trust its issuer. Together, these capabilities give teams a path from on-prem VM authentication to broader workload identity, with Vault at the center of issuance and access policy.

Eliminate the Secret Zero problem with TPM Support in Vault

Start with a Linux VM workload that currently depends on a distributed bootstrap credential. Identify how its vTPM can be provisioned, who will enroll it, and which Vault policies it needs. Use that workflow to evaluate TPM Support before extending enrollment across a larger fleet.

With Vault 2.2, teams gain a new way to secure the first connection for on-prem workloads and remove one more secret from the provisioning process, eliminating the Secret Zero problem. Talk to your IBM representative about adopting TPM Support in Vault Enterprise 2.2 for your on-prem VM environment.

from HashiCorp Blog https://ift.tt/GN279jk
via IFTTT

Introducing Provider Sets: Bring more Terraform modules to no-code provisioning

Provider Sets separate provider configuration from module code, making it easier for platform teams to reuse existing Terraform modules across no-code provisioning and self-service workflows. 

Terraform modules help platform teams standardize and reuse infrastructure. But using those same modules with no-code provisioning has historically come with an important constraint: provider configuration needs to be included directly in the module code. 

This means modules designed for traditional Terraform workflows may need to be modified or duplicated before they can be offered through no-code provisioning. 

Today, we're changing that with Provider Sets, which allow platform teams to define provider configuration separately and reuse it across projects and workspaces. 

The provider configuration challenge 

Consider a platform team that maintains a standard AWS RDS module. 

The module defines what infrastructure should be created, while the provider configuration may intentionally live outside the module. That's common in traditional Terraform workflows. But no-code provisioning also needs enough information to configure the provider when Terraform creates and runs the workspace. 

Historically, this meant modules intended for no-code provisioning needed to include their provider configuration directly in the module. 

For organizations operating across multiple accounts, regions, or projects, this can lead to duplicated modules and provider configuration and limit which existing modules can be offered through self-service. 

Introducing Provider Sets 

Provider Sets allow platform teams to define provider configuration centrally in HCP Terraform and reuse it across projects and workspaces. 

For example, a platform team could define an AWS Provider Set: 

provider "aws" { 
  region  = var.aws_region 
  profile = var.aws_profile 
} 

When Terraform creates a workspace through a no-code workflow, the assigned Provider Set is automatically applied. The module remains focused on what infrastructure should be created, while the Provider Set determines how Terraform configures the provider. 

Provider Sets include: 

• Reusable provider configuration: Define provider configuration once and reuse it across multiple modules and workspaces. 

• Flexible scoping: Apply Provider Sets globally across an organization or scope them to specific projects and workspaces. 

• Variable interpolation: Reference Terraform variables so the same Provider Set can adapt across accounts, regions, and environments. 

• Workspace overrides: Use project-level provider configuration as a default while allowing workspace-level configuration to override it when needed. 

For example, the same Provider Set could reference: 

provider "aws" { 
  region = var.aws_region 
} 

A project might define: 

aws_region = "us-east-2" 

while a particular workspace defines: 

aws_region = "eu-central-1" 

Terraform resolves the value through the existing variable hierarchy, allowing the same Provider Set to adapt across projects and workspaces without duplicating the provider configuration. 

Platform teams can also create different Provider Sets for different needs, such as aws-production, aws-development, azure-production, or gcp-development. 

Bring existing modules to no-code provisioning 

By separating provider configuration from module code, modules no longer need an embedded provider block simply to participate in a no-code workflow. 

Platform teams can take existing Terraform modules, pair them with the appropriate Provider Sets, and make them available through no-code provisioning without maintaining separate self-service-specific copies. 

For application developers, the provider complexity remains behind the platform boundary. Developers select the infrastructure they need and provide the inputs exposed by the platform team, while Terraform handles the provider configuration required to provision it. 

Provider Sets are also designed to preserve existing workflows. Modules that already contain provider configuration can continue to work without modification, allowing organizations to adopt Provider Sets incrementally rather than migrating their entire module catalog at once. 

Use Provider Sets with Terraform Developer Portal self-service and agentic workflows 

Provider Sets extend the same separation of concerns to self-service workflows in the Terraform Developer Platform (TDP). 

TDP allows platform teams to define reusable infrastructure patterns that developers can discover and provision through self-service workflows. Provider Sets allow platform teams to manage the provider configuration needed by those workflows separately, keeping provider complexity behind the platform boundary. 

For example, a platform team could make an approved AWS module available through TDP while using Provider Sets to manage the provider configuration needed across different accounts, projects, or environments. Developers can focus on the infrastructure they need and the inputs relevant to their application, without needing to understand or construct the underlying provider configuration. 

This creates a clear platform boundary: platform teams define how infrastructure connects to providers, while developers choose what infrastructure they need. 

The same model also extends to automated and agent-driven self-service. 

Provider Sets are accessible through the HCP Terraform API and can be managed through tfctl, allowing automation and coding agents to discover and work with platform-defined provider configuration rather than constructing provider blocks themselves. 

For example: 

tfctl api /organizations/{organization}/provider-sets \ 
  -a name=my-aws-provider-set \ 
  -a description="Shared AWS provider config" \ 
  -a "provider-source=registry.terraform.io/hashicorp/aws" \ 
  -a global=true \ 
  -a priority=false \ 
  -a 'configuration-hcl=provider "aws" {\n  region = var.region\n}' 

Because tfctl exposes the documented HCP Terraform API through its OpenAPI foundation, these workflows can work across different coding agents and automation environments without requiring a custom integration for each one. 

An agent could help a platform engineer discover existing Provider Sets, create or update one, or use the appropriate platform-defined configuration as part of a TDP self-service workflow. The agent helps execute the workflow, while HCP Terraform remains the source of truth for provider configuration and governance. 

This allows TDP self-service to extend across human and agent-driven workflows, without requiring developers or agents to recreate provider configuration themselves. 

A more reusable foundation for Terraform self-service 

Provider Sets solve a provider configuration problem, but the impact extends to self-service. 

By separating what infrastructure a module creates from how its provider is configured, platform teams can reuse more of the Terraform modules they already maintain across no-code provisioning and emerging self-service workflows. 

Provider Sets make existing Terraform modules more reusable as self-service building blocks while keeping provider configuration centrally managed by platform teams. 

Ready to get started? Explore the Provider Sets documentation to learn how to configure and reuse provider configurations across your Terraform no-code provisioning workflows. 

from HashiCorp Blog https://ift.tt/cipZUjH
via IFTTT

Modernize PKI, improve crypto-agility and prepare for post-quantum readiness

As enterprises scale AI-driven workloads, expand hybrid cloud environments, and navigate evolving cryptographic requirements, security teams are under increasing pressure to automate certificate lifecycle management, maintain cryptographic compliance, and prepare for post-quantum threats without adding operational complexity. In this blog, we'll highlight capabilities that advance public certificate automation, PKI modernization, post-quantum readiness, and crypto agility, helping organizations build a more resilient and future-ready security foundation for the autonomous hybrid cloud. 

Shorter certificate lifecycles require automated process for scale 

Today, security and platform teams manage a growing volume of public certificates that secure critical applications and services. Without centralized visibility and automated processes for issuance, renewal, rotation, and revocation, organizations risk expired certificates, service outages, audit failures, and security gaps. Changes in certificate operational periods as outlined by the Certificate Authority Browser Forum have set phased reductions in certificate lifetimes from 398 days max for certificates issued before March 14, 2026 to 47 days for certificates issued after March 15, 2029. As certificate lifetimes shrink, manual processes cannot scale. Organizations need a secure, automated way to manage and renew external CA-issued certificates, helping teams maintain trust, reduce operational risk, and safeguard critical services. 

Automate public certificate workflows with Vault 

Vault 2.2 adds native orchestration for public CA workflows, extending the PKI secrets engine’s private CA capabilities to publicly trusted certificates. Direct integrations, centralized policies, and automated issuance, renewal, rotation, and revocation reduce manual handoffs and help teams maintain continuous trust across applications and environments. 

Application developers need a fast, reliable way to request certificates for themselves, their applications, or their systems so they can access resources or provide services that use certificate-based authentication. When public CA enrollment depends on manual approvals, certificate signing requests, and domain validation, developers may face release delays, inconsistent processes, and certificate-related outages. Automated, self-service issuance and renewal reduce this friction while helping developers deploy trusted applications securely and at scale. 

Validate certificates consistently and at scale 

Vault 2.2 delivers the HTTP and DNS-based validation methods to obtain and renew public certificates. Previously, these processes required manual coordination across security, networking, application, and platform teams, an approach that was manageable when certificate volumes were lower. As internet-facing applications, machine identities, and renewal activity grow, organizations can depend on Vault to validate domain ownership consistently, maintain visibility, and prevent issuance failures. The result is operational efficiency, reduced risk of certificate related outages due to incomplete validation and the ability to scale across hybrid cloud environments.   

Centralize certificate visibility and governance 

With the latest release, Vault users can, within the Vault UI, request and issue public certificates from their organization’s public certificate authority. Vault automates issuance and deployment while providing visibility into certificate orders, status, validity, and the external Certificate Authority, as well as controls for managing DNS and HTTP challenges.  

Supported DNS challenge partner integrations include AWS, GCP, Azure, NS1, Infoblox, Akamai, BlueCat, Cloudflare, DigitalOcean, and GoDaddy. This centralized view of the certificate lifecycle improves visibility, governance, and operational efficiency while simplifying audit and compliance tracking. 

Build post-quantum cryptography readiness 

The shift to post-quantum cryptography is urgent because quantum threats put both confidentiality and trust at risk. In a Harvest Now, Decrypt Later attack, adversaries collect encrypted data today with the expectation that future quantum computers will decrypt it, exposing information that must remain confidential for years. In a Trust Now, Forge Later attack, quantum computers could break vulnerable digital-signature algorithms, enabling attackers to forge certificates, software signatures, identities, or transactions that appear legitimate. Legacy infrastructure, hard-coded algorithms, fragmented certificate workflows, and format-dependent data protections make the transition to quantum-resistant cryptography slow, costly, and disruptive.  

Enterprises must assess their post-quantum readiness now and establish a phased migration plan for modernizing PKI, replacing vulnerable algorithms, and building crypto-agility into key workflows. 

Operationalize post-quantum protection at scale 

Platform engineers must turn post-quantum requirements into production-ready services without disrupting applications or infrastructure. NIST finalized its first post-quantum standards in August 2024, including FIPS 204 for ML-DSA digital signatures, and recommends that organizations begin migrating now before it removes quantum-vulnerable algorithms from its standards by 2035. Yet fragmented tools and algorithm dependencies make it difficult to modernize cryptography safely and at scale. 

PKI migration is especially difficult because replacing quantum-vulnerable roots, certificate authorities, and downstream certificates can disrupt services, while operating traditional and post-quantum PKI together adds complexity. Vault 2.2 brings ML-DSA support to X.509 certificates in the PKI Secrets Engine with workflows designed to lower operational and security risk. Platform engineers can issue post-quantum X.509 certificates and build a more resilient root of trust by leveraging these automations in certificate lifecycle management and executing PKI modernization. 

Vault 2.2 builds crypto-agility into Transit 

When enterprises tie cryptographic workloads to specific algorithms, they accumulate technical debt and face security risk when standards bodies deprecate those algorithms or attackers compromise them. Rotating a key does not solve the problem because the original algorithm still restricts teams. Moving to modern standards, including post-quantum algorithms, can therefore break stable key references or require manual, error-prone application code changes. 

Vault 2.2 separates the logical key use from the cryptographic algorithm behind each version, so teams can modernize without changing stable key references. Users can add a new Key Version with a different algorithm, for example, moving from ECDSA to ML-DSA  within the same parent key. The Transit service automatically selects the appropriate key material and algorithm based on the version ID, abstracting cryptographic complexity from applications and enabling crypto-agility at scale. This allows organizations to continuously evolve their cryptographic posture, adopt stronger and post-quantum standards without disrupting business operations, and rapidly reduce risk by phasing out vulnerable algorithms as new threats and compliance requirements emerge. 

Secure data with NIST-approved FF1 

Vault 2.2 helps organizations strengthen format-preserving encryption by moving ADP Transform FPW algorithms from FF3-1 to FF1. After researchers identified security concerns with FF3 and FF3-1, NIST retained FF1 in its latest SP 800-38G Revision 1 draft. Vault uses FF1 as the standard for new encryption and limits FF3-1 to decrypting existing data during the transition. A new rewrap process will let teams convert legacy data to FF1 without changing its format or compromising data integrity, supporting a smoother and more secure migration. 

Start your PKI modernization and improve crypto agility

Explore the Vault developer documentation to learn more about these capabilities and plan your next steps. Talk with an IBM representative about your PKI modernization and post-quantum readiness priorities, and where supported, upgrade to Vault 2.2 to begin putting these into practice for improved crypto agility. 

from HashiCorp Blog https://ift.tt/jzQVFcE
via IFTTT

Securely govern human and agentic identities with Vault

As organizations embrace AI agents alongside applications, services, and other machine identities, many are struggling to maintain visibility, control, and accountability across a rapidly expanding identity landscape. Unmanaged AI agents, non-human identity sprawl, and inconsistent access governance can increase security risk and make it difficult to determine who or what has access to critical systems and data. Vault 2.2 advances identity-centric security through the general availability of SCIM integration and new enhancements for non-human identities and agentic IAM. Together, these capabilities help organizations automate identity lifecycle management, govern AI agents and machine identities with the same rigor as human users, enforce least-privilege access, and improve auditability across their environments, all from a centralized identity foundation. 

Prevent identity sprawl and achieve trusted access with SCIM GA  

Manual identity administration across identity providers and Vault can be difficult to scale, creating operational overhead and increasing the risk of access drift, misconfigurations, and outages. SCIM for Vault helps eliminate this challenge by automatically synchronizing human identities, ensuring access to Vault and protected resources remains aligned with authoritative identity data. As organizations move toward autonomous cloud operations, identity becomes the foundation of security and automation becomes essential for operating safely at scale. By automating human identity provisioning and lifecycle management, teams can reduce manual effort, strengthen governance, and focus on securing the growing number of machine and AI identities across their environment. 

SCIM also strengthens delegated and agent-driven workflows by ensuring that human identities are consistently established and maintained before access is granted. This prevents identity drift between Vault and the identity provider, helping ensure that only authorized users, and the agents acting on their behalf, can access Vault-protected resources. The result is stronger governance, reduced operational risk, and greater confidence in identity-based security across both human and autonomous workflows. 

Streamline Vault entity and group adoption through precise updates  

Previously, SCIM clients could only manage users and groups they had created themselves. With GA, SCIM clients can now adopt and manage pre-existing Vault entities and groups, not just the ones initially provisioned through SCIM. This closes a major gap for organizations with established Vault deployments who want to bring their existing identity footprint under SCIM-based lifecycle management without recreating entities from scratch. Teams migrating from manual provisioning to SCIM can now do so incrementally, without disruptive rip-and-replace migrations. 

Teams can now also take advantage of more precise, less disruptive updates. SCIM now supports partial, targeted updates to identities in Vault rather than replacing the full record every time something changes, reducing the chance of accidental overwrites during routine updates. 

Validate integrations with leading identity providers 

SCIM GA expands validated interoperability with Microsoft Entra ID alongside SailPoint and Okta, rounding out support for three of the most widely used enterprise identity providers. Each integration has been tested against Vault's SCIM implementation to confirm compatibility with real-world provisioning workflows, giving teams confidence to deploy SCIM with the IdP they already rely on and leverage their existing identity infrastructure.  

Expand Vault's identity governance and access controls for AI agents 

Since our generally available release in September, we’ve continued enhancing HashiCorp Vault's capabilities for securing and governing AI agents. 

As organizations adopt AI agents alongside applications and other machine identities, many are discovering that their existing identity and access management processes were designed primarily for human identities. Vault's agentic security enhancements help customers govern identities with confidence by combining verified agent registration, delegated authorization boundaries, and ephemeral per-request authorization.  

 Vault extends its core identity model to support the unique security requirements of AI agents. While human users and machine workloads are governed through established identity and access controls, AI agents require additional safeguards because they can interpret intent and execute dynamic, non-deterministic workflows. To address this, Vault introduces a purpose-built governance model that combines three layers of control:  

1. Human baseline policy - the permissions of the human user on whose behalf an agent operates,  

2. Agent ceiling policy - strict agent-specific permission boundaries that define the maximum privileges an agent can ever receive,  

3. Rich Authorization Requests (RAR) - ephemeral authorization scoped to a specific task or request. 

Every agent is tied to a trusted identity, governed by defined ceiling policies that establish maximum permissions, and authorized based on the specific task being requested rather than broad, long-lived access rights. By requiring rich authorization details for each request, Vault evaluates authorization in context, creates a clear and auditable record of every agent action, and enforces least-privilege access by default. This layered approach gives organizations the confidence to deploy and scale AI agents while maintaining strong governance, accountability, and control over autonomous actions. 

Vault's agentic IAM is designed to work alongside the identity providers organizations already use, and it fits into the same infrastructure-as-code workflows teams use to manage the rest of their environment.  

Control every agent interaction with confidence 

Vault gives organizations layered controls for governing how AI agents act and access resources. In delegated workflows, agents can act on behalf of users while remaining constrained by both the user’s permissions and the agent’s own authorization boundaries, helping keep every action within approved limits. When risk arises, security teams can revoke an agent’s active tokens and sessions on demand, removing access immediately rather than waiting for credentials to expire. At the same time, centralized visibility gives security and platform teams a single view of every registered agent, including its access, and activity, making oversight and audits simpler. 

These controls fit into the identity ecosystem organizations already use. Vault’s agent identity workflows have been tested with Auth0, IBM Verify, Microsoft Entra ID, and Okta, helping teams extend governance to AI agents without introducing a separate identity system. 

Getting started  

SCIM for Vault is now generally available for Vault Enterprise and Vault Dedicated customers. Teams that are already running SailPoint, Okta, or Microsoft Entra ID can connect existing provisioning workflows to Vault and start extending governance to both new and existing identities. 

For detailed instructions on connecting an identity provider to Vault via SCIM, read the Vault developer documentation. 

Agentic IAM is available now to Vault Enterprise customers. Teams should start by identifying their existing identity provider, whether that's Auth0, IBM Verify, Microsoft Entra, or Okta, and following Vault tutorials to begin governing agent access from day one. Visit the Vault documentation for detailed setup guides and deployment patterns. 

from HashiCorp Blog https://ift.tt/KYnjHMy
via IFTTT