Skip to main content

Boundary 1.0 releases RDP session recording and improved management

Boundary 1.0 releases with support for RDP session recording and a preview ahead towards securing AI agent access in a brave new agentic world.

Today, we are thrilled to announce the release of Boundary 1.0, a milestone that marks the evolution from an initial concept to a fully robust and scalable solution for modern privilege access management (PAM), now proven across many production environments. Like other HashiCorp 1.0 releases, this milestone is not centered on any specific feature but instead represents a significant achievement in terms of user experience, coverage of use cases, architecture maturation, and production deployments in customer environments.  

»RDP session recording 

That said, Boundary 1.0 introduces session recording capabilities for Remote Desktop Protocol (RDP), which allows organizations to meet stringent compliance requirements and helps security and compliance teams to perform deeper security event analysis. With RDP session recording, organizations can capture and replay every interactive user action during each RDP session. Looking forward, we are working hard to expand session recording support for other popular protocols for Kubernetes, databases, and HTTP/HTTPS. 

Demo video:

This demo shows the configuration of session recording, a RDP connection test, and the RDP playback.

»Kubernetes chart 

Boundary has been designed as a distributed system and can run on any runtime, including containers on Kubernetes. However, deploying and maintaining individual components with separate manifest files is not ideal. To address this, we’ve released two Helm charts that can be used to simplify the deployment, management, and upgrades of your Boundary cluster within Kubernetes environments. A controller Helm chart can be used to deploy Boundary controllers onto a Kubernetes cluster. A worker chart can be used to deploy Boundary workers onto a Kubernetes cluster. With the worker chart, Boundary workers can be connected to any Boundary controller, including HCP-managed controllers, self-managed controllers on VMs, or self-managed controllers deployed onto Kubernetes by the controller Helm chart. More detailed information about the Helm charts can be found in this blog. 

boundary helm chart

Caption: This diagram shows an example deployment where the Boundary controller and workers are deployed onto the same Kubernetes cluster. 

»Scoped Aliases

This release introduced aliases for org and project scopes which significantly improves the use of aliases at scale. Aliases make it easy for end users to connect to their targets using a human-readable DNS-like name. However, alias names need to be globally unique within Boundary. That means in a multi-tenancy deployment, different teams cannot use the same alias name. This new feature allows Boundary to automatically append suffixes to an alias for different org and project scopes. This allows aliases to remain unique while also enabling different teams that reside in separate scopes to use similar alias names, like mylinuxhost.rnd.dc-canada and mylinuxhost.rnd.dc-india or mylinuxhost.rnd.dc-canada and mylinuxhost.marketing.dc-canada. As a result, customers can connect to targets using aliases at scale without naming conflicts between teams. To learn more about scoped aliases, click on this latest blog.  

»Enhanced admin UI with guided permission grants 

Lastly, we’ve made it dramatically easier for security professionals and administrators to configure Boundary grants, which determine how users and machine manage or access Boundary resources. Since grants require a specific format and syntax, they can be prone to human error.  

To simplify the process, Boundary’s admin UI now provides a guided experience for visual assistance when configuring grants and permission. This includes a drop-down menu with pre-populated options that administrators can select. The admin UI also provides reusable templates for common roles and access patterns, streamlining the entire process, improving consistency, and reducing the likelihood of misconfigurations.  

boundary guided permission grants

»The road here 

Session recording was first introduced in version 0.13, initially supporting only SSH targets. This primarily benefitted development teams that operated mostly in Linux and Unix environments. Also conducive in this environment was SSH credential injection, which allowed developers to securely connect their development resources without entering credentials  simplifying the workflow while reducing the risk of credential exposure.  

Boundary's agentless architecture further appealed to DevOps and platform teams by simplifying deployment, management, and maintenance in modern and dynamic environments. 

After development of other critical capabilities like HashiCorp Vault integration for dynamic credentials, dynamic host catalog for auto-discovery of virtual machines in AWS, Azure, and GCP, and transparent sessions to further simplify the end-user experience, Boundary capabilities have expanded beyond development teams to include Windows environments that can benefit IT admins, support teams, and business users. In the previous 0.22 release, we announced RDP credential injection, which abstracted the management and handling of credentials from end users. When users connected to an RDP target like a Windows server, Boundary would retrieve credentials and inject them into the session on behalf of the end user, resulting in a passwordless experience. This made the connection experience less cumbersome, while also more secure by preventing credentials from being shared, leaked, or stolen.  

The addition of RDP session recording in today’s release is evidence of our continued effort to further expand security and usability into Windows environments. It adds to the list of existing capabilities and integration points with Microsoft, including: 

  • Auto-discovery of virtual machines in Microsoft Azure 

  • Integration with Microsoft Azure Entra ID for single sign-on (SSO) 

  • Synchronization of Entra ID users and groups for automated RBAC management 

  • Integration with privilege identity management (PIM) for request and approval workflows.  

The Boundary 1.0 release signifies a big step forward, but it is also met by a new era in access management — one that includes AI agents and non-human identities (NHI), which can scale more rapidly than human identities and penetrate much deeper into an organization's most critical systems. Our mission to secure access remains the same, but the identities we manage will evolve. 

»The highway to agentic workflows and beyond 

As we see non-human identities already outnumbering human identities, we need to think about how we can consistently control access across these similar but vastly different identity types. Organizations can no longer rely solely on the model of zero trust to guide how access is enforced. Zero trust is based on the notion that malicious actors already exist within the network, and access to a resource should always require authentication and authorization. This is a solid foundational principle and works well for human identities where access patterns are predicable. However, AI agents and NHI are much less predictable, often requiring different access as it progresses along a workflow to achieve its final objective. The multiple systems it accesses, the humans it’s acting on behalf of, the sub-agents it spawns, and the sequence of commands it executes can vary, even for the same identical objective. This type of pattern requires more than authentication and authorization at initial access, but a continuous re-evaluation of trust, identity, and permissions at every step along its workflow.  

Today's security guardrails were not designed for this. Static credentials give agents persistent access that far outlives the task they were created for. Session-level authorization grants broad permissions at the door and never checks again. And when something goes wrong, security teams are left asking questions that no existing tool can answer: What did this agent actually do, which systems did it touch, and who is accountable for its actions? These are not gaps that can be closed by layering more policy on top of a model built for human users. They require a fundamentally different approach, one where credentials are never held by the agent, authorization is evaluated at each step rather than just at the start, and every interaction is observable from initiation to completion. 

This is the direction Boundary is heading. At the foundational layer, we are introducing authentication and authorization designed specifically for agents and NHIs. Because agents primarily interact with infrastructure over HTTP, we are building HTTP credential injection and session logging so that every API call an agent makes is secured and auditable, extending the same protocol-aware security that Boundary already provides for SSH and RDP. Beyond that, we are working toward:  

  • Ephemeral authorization that moves past the authenticate-once model and toward continuous trust 

  • Narrowly scoped permissions that are re-evaluated at each step 

  • On-behalf-of workflows that tie every agent action back to the human who initiated it 

  • Segmentation that controls which agents can reach which resources 

Together, these capabilities establish a foundation in which every agent identity is verified, every credential is dynamically scoped, and every session is logged from start to finish. Equally important is making this seamless for the teams building and deploying agents. Agents should not require bespoke integration work to connect securely to infrastructure. We are investing in the developer and platform experience so that secure access becomes the path of least resistance, not an obstacle that teams work around. 

Underpinning all of this is an architecture that unifies these capabilities into a single control plane. Boundary, Vault, and the broader IBM ecosystem work together so human and non-human identities are governed through one platform with a shared runtime, giving organizations consistent visibility and control regardless of what type of identity is accessing their infrastructure. 

»Participate in early access 

At IBM, we are continuing to develop and expand our agentic AI security capabilities and looking to get direct feedback from customers. As we roll out new Boundary capabilities, if you would like to be an early adopter and help shape our roadmap, join our Boundary Agentic Security Early Access Program

More posts like this