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

Vault Enterprise 2.2 advances identity security, PKI, and crypto-agility

Organizations are adopting AI agents, cloud-native applications, and automation at an unprecedented pace. As the number of non-human identities grows faster than human users, security teams must govern identities, automate certificate management, and prepare for evolving cryptographic threats without slowing innovation.

Vault 2.2, now generally available, expands identity-based security for AI agents and non-human identities while automating more of the certificate lifecycle and strengthens cryptographic readiness with new post-quantum capabilities. Deeper IBM ecosystem integrations, broader platform support, and usability improvements help organizations reduce risk, simplify operations, and scale security across the autonomous hybrid cloud.

Secure AI agents and non-human identities

AI agents, applications, services, and workloads all depend on identities to access systems and data. Yet many organizations still rely on governance models designed primarily for human users, creating blind spots, identity sprawl, and increased security risk. 

SCIM, available in Vault 2.2, automates user and group lifecycle management across leading identity providers – adding Microsoft Entra to SailPoint and Okta since the SCIM beta, reducing administrative overhead, and helping ensure that access remains aligned with enterprise identity systems. Vault's Agentic IAM enhancements help customers govern identities with confidence by combining verified agent registration, delegated authorization boundaries, and ephemeral per-request authorization. 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's action, and enforces least-privilege access by default. This approach reduces the risk of over-authorization, strengthens accountability, and enables organizations to confidently scale AI agents.

With these enhancements, Vault users extend least-privilege access and auditability to AI agents and non-human identities and reduce identity sprawl to keep every access decision aligned with business and security policy. As a result, organizations gain accountability and confidence to scale AI adoption while simplifying compliance.

An additional way Vault 2.2 helps organizations govern identities with confidence is by eliminating the long-standing Secret Zero challenge for on-prem workloads. With new 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. This strengthens machine identity, reduces the risk of credential theft or reuse, and ensures that only trusted, enrolled workloads can access sensitive resources. By establishing a stronger foundation of trust for workload authentication and integrating with broader identity frameworks such as SPIFFE, Vault 2.2 gives security and platform teams greater confidence in governing, authorizing, and managing machine identities across on-prem environments at scale.

Automate certificate lifecycles and improve crypto-agility 

Security teams face mounting pressure to eliminate manual processes, prevent outages caused by expired credentials and certificates, and prepare for future cryptographic requirements.

Vault 2.2 helps organizations modernize PKI operations and strengthen cryptographic resilience by automating public certificate workflows, improving crypto-agility, and advancing post-quantum readiness. This release delivers capabilities that simplify certificate issuance and governance, such as automated public CA integrations and a UI enhancement that provides better visibility into certificate status and available actions for centralized certificate lifecycle management.

The availability of PQC X.509 certificate support for the PKI Secrets Engine means Vault 2.2 adds support for ML-DSA key generation, signing, key import and key export. This strengthens certificate trust chains and helps protect against certificate forgery and service impersonation in the quantum era. 

Meanwhile, crypto-agility in the Transit secrets engine simplifies future migrations. Vault 2.2 also adopts NIST-approved FF1 format-preserving encryption to strengthen sensitive data protection. Together, these capabilities reduce operational risk, scale certificate management, modernize cryptographic infrastructure, and support future security and compliance requirements.

Drive enterprise scale and adoption 

As organizations expand across cloud, on-premises, and IBM environments, security and engineering teams need solutions that are easy to adopt, efficient to operate, and consistent across diverse infrastructure. Vault 2.2 improves time to value with improvements within the Vault product experience, starting with a redesigned home dashboard. To enhance discoverability and easier onboarding, feature spotlight points the user to what’s new right within the product UI. Improvements to user preferences and the delivery of dark mode add to what makes the Vault experience customizable for users. As well, a new Submit feedback button creates an in-product opportunity to share suggestions and comments to enhance the product feedback loop. A more robust Terraform code generator supplements the Visual Policy Editor released in 2.0.0 that provides code snippets for automated feature adoption. These updates make capabilities easier to discover, reduce friction to adoption, and support ongoing platform modernization.

Improvements to Azure dynamic service principals are part of this release. With automated credential rotation, Vault reduces eventual consistency delays within the Azure Secrets Engine, working around the limitation of having a delay before a newly rotated credential can be used. Automated rotation via Vault’s Rotation Manager now fully handles the lifecycle of static credentials even if Azure Secrets Engine does not support automated rotation. Azure access token vending is another way to handle how a newly created credential can be used, resolving the eventual consistency delay. Applications can now directly access tokens which are immediately consistent. Enhancements to LDAP are also generally available in this release. Credential drift and blind spots - that were previously created by the inability to detect if a managed account has been locked or revoked by the target directory – are now resolved with the ability to unlock accounts from Vault manually or automatically during rotation. Health checks for the LDAP Secrets Engine are now also made possible by configuration validation. Non-disruptive, on-demand configuration validation endpoints for Vault resources are now available, which means Vault customers can proactively discover that Vault has successfully connected and authenticated, with configured external systems instead of only being discovered at rotation failure or when application downtime is reported.   

Finally, Vault 2.2 extends consistent identity and secrets security across IBM and hybrid infrastructure. Support for Vault CLI and Vault Secrets Operator on IBM Power, Azure AKS Workload Identity integration, secret recovery for KV v2 and Secrets Sync enhancements help organizations standardize security practices across cloud-native applications, IBM platforms, Kubernetes environments, and traditional infrastructure. 

Standardizing security practices across cloud, on-premises, IBM, and Kubernetes environments helps organizations reduce operational silos and tool fragmentation. Teams gain more consistent governance, visibility, and control while lowering administrative overhead. This foundation enables the business to scale identity, secrets, certificate, and key management as its technology environment evolves.

Building the foundation for the autonomous hybrid cloud 

As organizations move toward more autonomous and distributed operating models, identity becomes the foundation for securing applications, workloads, infrastructure, AI agents, and cryptographic systems.

Vault 2.2 gives organizations a stronger foundation for securing autonomous and distributed environments. By unifying identity governance, lifecycle automation, cryptographic readiness, and platform improvements, this release helps customers reduce operational risk and scale security with greater consistency.

See how Vault 2.2 can strengthen security across your AI agents, applications, and enterprise workloads. Review the Vault developer documentation to explore the platform, then use the upgrade guidance to plan, test, and begin your move to Vault 2.2.

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

Google Warns LLMjacking Attacks Are Costing Some Enterprises Up to $1 Million in Cloud Charges

Google on Monday warned that threat actors are hijacking enterprise access to Large Language Models (LLMs) to fraudulently leverage expensive computing resources and AI services.

The tactic is called LLMjacking, a form of resource hijacking adapted for the LLM era, where an attacker obtains an API key through phishing, source code leaks, misconfigured environments, or exposed client-side code to gain unauthorized access to an organization's LLM accounts, while the legitimate owner covers the consumption costs.

Such attacks have a wide geographical footprint, with impacted entities located in North America, South America, and Asia Pacific across the financial services, retail, technology, and transportation sectors.

"Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours," Google Threat Intelligence Group and Mandiant said in a report shared with The Hacker News.

"Across individual incidents, we observed fraudulent charges associated with resource consumption exceeding $100,000 USD in a single day, with cumulative charges at some organizations reaching $1 million USD before access was revoked."

On one end of the spectrum are low-level resource theft that involves the manipulation of customer support chatbots to conduct unauthorized tasks like code generation. LLMjacking is on the other end, as they target the backend model resources directly by identifying publicly exposed LLM endpoints or obtaining valid LLM API keys.

The most common initial access vector has been exposed or stolen cloud identity tokens, including IAM credentials, Service Account keys, GitHub Personal Access Tokens (PATs), and active session tokens, which allow an attacker to establish an initial foothold into target organizations' infrastructure.

This includes a threat actor called UNC6993, which is said to have breached a cloud instance through a misconfigured Service Account key and used it to obtain access to an LLM API.

"UNC6993 also hosted a session hijacking page masquerading as an application portal to join a group of LLM users," Google said. "This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend API to bypass password and multi-factor authentication (MFA) controls."

In another case, an unknown attacker has been observed leveraging a stolen Personal Access Token to access private code repositories, following it up with the exploitation of a suspected web application vulnerability in a package running within a containerized cloud environment.

Other initial access routes include the compromise of IAM credentials of corporate users to programmatically generate fresh access keys to bypass MFA safeguards, as well as the use of a hacked cloud Service Account key with broad project permissions and LLM API keys obtained from public GitHub repositories.

Upon successfully gaining a foothold, the threat actors waste no time escalating privileges, burrowing deeper into the network, establishing persistence, and conducting internal reconnaissance to identify targets and further cloud credentials for lateral movement.

Some of the observed tactics are listed below -

• Enumerate cloud services, code repositories, and data stores for sensitive credentials.
• Perform internal reconnaissance across multiple cloud regions to map available services and identity policies.
• Clone sensitive codebases to search for hard-coded secrets, configuration variables, and developer credentials.
• Scan access logs to identify credentials for secondary cloud environments.
• Run targeted database queries to harvest additional credentials.
• Abuse cloud identity permissions and virtual machine configurations to escalate privileges and maintain persistent access.
• Exploit token-creation privileges associated with service accounts to generate temporary credentials for high-privilege service accounts and exfiltrate infrastructure credentials, internal database passwords, and third-party API keys from cloud secret managers.
• Create unauthorized IAM and service accounts and inject SSH keys into compute instances for persistence.
• Create backdoor service accounts disguised as internal billing optimization utilities.
• Exploit vulnerabilities targeting LLM routing software, such as CVE-2026-40217 in LiteLLM, to escalate privileges.

"The ultimate objective of LLMJacking is the monetization and resource-hijacking of foundation models, which actors achieve through token proxying, automated model streaming, and GPU hardware provisioning," Google said. "Threat actors also leveraged their access to host their own proxy endpoints and agentic workloads."

UNC6993, for instance, has created additional API keys to scale their operations within victim cloud projects, racking up over $100,000 USD in billing charges. Some threat actors attempt to bypass rate limits by adopting a "burn and rotate" strategy that involves continuously creating and deleting short-lived service accounts

The maturation of the LLMjacking ecosystem has also paved the way for the emergence of a new category of actors called LLM Mixers, highlighting a division of labor between attackers who establish initial access and those who manage downstream monetization infrastructure.

LLM Mixers function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to other criminal actors via underground storefronts. One such service is Jet Night ("jet-night[.]com"), which offers an unlimited token plan with alleged access to a frontier model for approximately $60 per month.

By fueling an illicit resale marketplace, it permits bad actors to siphon enterprise quotas while passing the billing costs to victims before compromises are detected.

Jet Night is far from the only token routing offering. According to a report published by Broadcom-owned Symantec and Carbon Black last week, there exists a grey market relay service that installs the genuine OpenAI Codex and Anthropic Claude Code CLIs on enterprise systems, only to reconfigure them to route every request through third-party infrastructure instead of the vendors' own servers.

The service is assessed to be active since at least early 2026, primarily impacting a dozen organizations located in Mainland China, along with multi-national subsidiaries based in South Korea, Taiwan, and Malaysia. Targeted sectors include industrial automation, electronics manufacturing, semiconductors, pharmaceuticals, shipping, tire manufacturing, petrochemicals, and data center services.

"Rather than building its own client software, the service repurposes the genuine CLI tools," Symantec said. "It installs them normally, then rewrites their configuration to switch sandboxing off, in Codex's case by setting it to 'danger-full-access,' and routes every request through its own servers instead of OpenAI's or Anthropic's."

The service appears to mainly target markets where Anthropic and OpenAI do not operate, with the installation driven by an employee attempting to try out a Western AI coding assistant by turning to an unauthorized reseller.

Notably, the service does not distribute a modified or trojanized client. Shortly after the legitimate install of the Codex or Claude Code CLI through npm, users are likely instructed to run a one-line command to fetch fileless PowerShell or bash setup script from a lookalike domain ("vibe.aiok[.]me") that's used to override the configuration.

The reconfiguration, which targets "~/.codex/config.toml" for Codex or "~/.claude/settings.json" for Claude Code, disables the CLI's execution sandbox, enables network access for the write sandbox, replaces the user's real API credentials with relay-issued tokens, and disables telemetry and error reporting.

The script also checks the Windows locale setting to confirm it's running on a system in the region it serves before the setup is completed. It's suspected that the operators behind the service are not only circumventing regional restrictions imposed by Western AI vendors, but are also reselling capacity below market rates similar to Jet Night.

Although there is no evidence to suggest that the service is abusing its position to harvest prompts entered by employees or fabricate or alter responses, the findings demonstrate the security risks associated with using such tools.

"Threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking, driven by the immediate, high-margin monetization enabled by emerging underground LLM Mixers," Google said.

"As enterprises integrate higher-tier models and agentic workflows into production environments, cybercriminals will likely refine automated reconnaissance to target exposed API tokens and exploit vulnerabilities in model routing middleware."

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

cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

On November 2, an attacker broke into cPGuard's update system and pushed a malicious script to Linux web servers running the security tool.

The script installed a backdoor and collected password hashes and other sensitive files from servers that ran it, cPGuard maker OPSSHIELD said in an advisory. The attacker has since taken some of that data.

cPGuard 5.88.25 and later versions remove the backdoor and the files the script left. Credentials the script copied may still work after the update, so any server that may have run the script also needs new passwords and keys.

At 02:06 UTC, the attacker, who has not been identified, used compromised credentials to get into cPGuard's update system. The script went out in cPGuard versions 5.88.12 through 5.88.19.

The attack was detected within 12 hours of those versions going out, according to OPSSHIELD. The company has cleared its infrastructure credentials and stopped the script from reaching more servers. It is still investigating how the attacker got the credentials.

OPSSHIELD has not said how many servers installed one of these versions. Servers check for updates at intervals, so some may not have run the script.

Admins can check whether a server installed an affected version by searching its update log:

grep 'Successfully updated' /opt/cpguard/logs/install_log

An entry for any version from 5.88.12 through 5.88.19 means the server installed an affected update. The entry alone does not show that the script ran or that data left the server. The server should still be treated as potentially compromised, even if it now runs 5.88.25 or later.

A server with no matching entries, or with a missing or incomplete log, may still have run the script. Admins who are unsure can contact OPSSHIELD Support.

The script collected these kinds of data, OPSSHIELD found: /etc/shadow and /etc/passwd, root's MariaDB or MySQL configuration (my.cnf), root's shell history, and the SSH authorization and known-hosts files for root. It may not have collected every file from every server, and the company is still working out what left each one.

The /etc/shadow file stores one-way password hashes. Weak, common or previously leaked passwords can be recovered from those hashes by testing guesses offline, and even strong ones still need resetting. Secrets that may sit in the database configuration or shell history have no such hashing to protect them.

The script uploaded what it collected to a licensing server run by OPSSHIELD itself, using a compromised account, so the attacker could pick it up later. OPSSHIELD has since secured that account.

The attacker took 32 files from that server, each tied to one customer server, OPSSHIELD estimated late on November 2 UTC. The count covers only files known to have been taken, and it may change. It does not show how many servers may be involved in total.

Beyond the data collection and the backdoor, OPSSHIELD has found no other malicious activity so far, a finding it says is not final.

What cPGuard Admins Should Do Now

OPSSHIELD asks admins to update every cPGuard server now and confirm the version:

1. Run cpgcli update --start on each server.
2. Run cpgcli --version and check that it reports 5.88.25 or later. If the update fails or the version is lower, contact OPSSHIELD Support.

Admins should also take these steps for any server where the script ran or may have run:

1. From a trusted recovery environment, reset the passwords for root and every other local Linux account that uses a password.
2. From a trusted device, change any of those passwords that are also used on other systems.
3. Rotate the server's database passwords, S3 access keys, DigitalOcean tokens and any secrets recorded in root's shell history.
4. Replace the SSH private keys stored under /root/.ssh, and remove the matching old public keys from every system that trusts them.

OPSSHIELD is not recommending a full reset or operating system rebuild as a routine step, and says that view could change as the investigation continues. Admins who find other signs of compromise, or cannot confirm a server is clean, should ask OPSSHIELD Support for a case-by-case review, which may lead to a rebuild.

Separately, OPSSHIELD is releasing another update, as a precaution, that removes its support-access keys from cPGuard servers where they were added earlier.

Support access is a cPGuard feature customers use to let OPSSHIELD staff into a server for troubleshooting. Granting it adds an SSH public key belonging to OPSSHIELD to the authorized_keys file for root, according to the company's documentation.

OPSSHIELD has not said whether the private key that matches its support-access key was exposed in the attack.

Files the Script Left Behind

OPSSHIELD published these file names. The update removes the backdoor shell and the collection directory, so their absence after updating proves nothing about whether the script ran.

• File: cpguard-v58812-i91511.sh (the malicious script)
• File: /var/tmp/.cpg91511_sh (backdoor shell)
• Directory: /var/tmp/.cpg91511 (where the script gathered files)
• File: /var/tmp/.cpg91511/loot.tgz (archive the script prepared)

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