标签：#sessionrecording

The 1.0 lands with session recording attached HashiCorp announced Boundary 1.0 on June 25. The operational headline is RDP session recording, and the version number is a distant second. Boundary is HashiCorp's privileged-access proxy, and until this release it did not record Remote Desktop sessions on its own. Teams that route Windows-side deploys through the proxy now have a first-party audit trail that ships with the product itself. The announcement bundles two other things on top of the RDP work. "Improved management" is HashiCorp's phrasing. Boundary 1.0 also previews work aimed at securing access for AI agents, which HashiCorp positions as a same-chokepoint answer for a new class of caller. What actually changes on the CD side For most teams the practical read is narrower than "1.0 shipped". Two things move. RDP sessions get recorded through the proxy. Windows targets have historically been the awkward part of a privileged-access story. SSH session recording and TLS-terminating proxies have been standard for years on Linux. RDP has been thinner. A CD pipeline that lands on a Windows host for a hotfix, an artifact promotion, or a release-time config change now has the same after-the-fact video that Linux jumpboxes have had for a long time. The AI-agent preview signals where Boundary wants to sit next. If CD tooling is starting to hand a shell to an agent, that agent needs a credential of some kind. HashiCorp is telling operators the plan is for Boundary to mediate that call the way it mediates a human on-caller today. This is a preview. Read it as a roadmap. Why the audit line matters for release engineering The audit case for session recording is easy to state and hard to argue with. When a bad change lands on a production Windows host at 2am, the post-incident question is always the same: what did the person on the console actually do, and can it be replayed? Without recording, on-call gets shell history if it is lucky and a change-management ticket if it is n