HashiCorp Vault agentic IAM is now generally available. HashiCorp Vault Enterprise advances AI agent security with recent enhancements now generally available. In June, HashiCorp announced the public preview of native AI agent support in HashiCorp Vault. HashiCorp is excited to make these new native agentic IAM capabilities generally available in Vault Enterprise 2.1. These new features enable you to better secure, manage and audit agents across your environments. Enterprises can securely deploy AI workflows and achieve governance over agents. Vault extends its policy-based secrets access and management capabilities to AI agent identities, alongside its existing support for human and non-human identities, so teams can securely scale AI workflows and reduce custom or manual workarounds needed to achieve compliance. This release also contains significant feature enhancements, including per-request access evaluation, deeper integration with existing OAuth and identity infrastructure and enhanced ability to manage agent identities at scale. Vault users can also now access the Agent Registry in the Vault UI, providing centralized visibility and management for agent identities across the organization. Together, these capabilities make it easier to deploy agents securely while benefiting from the governance and audibility that teams already use Vault for today. Agentic workflows have been tested and validated with IBM Verify, Auth0, PingFederate, Microsoft Entra, and Okta. These validated workflows reflect Vault's continued investment in meeting security and identity teams where they are by supporting their preferred identity providers and securing both human and non-human identities. Vault now enables organizations to manage agents with the same granular control, security and auditability as with other identities. A new Agent Registry experience in the UI. For teams that prefer working in the UI, GA introduces the Agent Registry in Vault. The registry brings agent identities, authentication activity, policies, and namespace information into a single view, making it easier to understand how agents are being used and what access they have. Agent identities can be viewed and updated directly from the registry, while agent registration and configuration management also remain available through the API, CLI, and Terraform Vault Provider. Registering an agent and authenticating to Vault. The Agent Registry is the foundation of agent governance in Vault. Before an agent can use an OAuth credential to access Vault, it must be registered in the Agent Registry and mapped to a Vault Identity entity. Separately, administrators configure an OAuth resource server profile that defines how Vault validates JWTs from a trusted issuer. This establishes a governed identity for each registered agent, which enables Vault users to reduce security, compliance and operational risks when agents request access through Vault, while enforcing least privilege and supporting the lifecycle management of agent registrations. Once registered, the agent authenticates with its identity provider and receives a signed OAuth JWT containing an authorization_details claim that defines the requested access. The agent presents that JWT directly to Vault with each request. Vault validates the agent's identity and evaluates the request against the authorization controls. Vault derives token metadata from the JWT; the resulting Vault token exists only for the lifetime of the request and does not persist. With audit devices enabled, Vault audit logs record Agent Registry operations and authenticated Vault API requests and responses, including identity and authorization metadata. This gives security and platform teams an attributable record of requests made through Vault. Enforcing authorization details by default: establishing a secure baseline. Rich Authorization Requests (RAR), defined in IETF RFC 9396, allow OAuth clients to express structured, fine-grained authorization requirements for a task instead of relying solely on broad identity-level permissions. The authorization server carries those requirements in the OAuth JWT's authorization_details claim, which Vault evaluates for each request. By requiring authorization_details by default, Vault establishes a secure baseline for agent-based workflows. Requests that do not include these details are rejected unless explicitly configured otherwise, helping security teams: · Enforce fine-grained, per-request authorization · Reduce reliance on broad, long-lived permissions · Establish clear, auditable authorization scope for each agent action Operators can make this requirement optional for an OAuth resource server profile on an individual agent registration, balancing a secure default with the flexibility to support existing applications as they migrate to RAR. Making the transition gradual, not abrupt. Adopting RAR is not an all-or-nothing decision. Vault requires authorization_details by default but allows the operators to make the claim optional at the OAuth resource server profile or individual agent registration level, enabling teams to migrate incrementally, rather than requiring a wholesale migration. Working with agents that act on behalf of users. Not all agents operate autonomously. Many enterprise workflows require an agent to act on behalf of a user while preserving the user's identity and permissions. In these scenarios, Vault can validate delegated OAuth JWTs that identify the user as the subject and the agent as the actor, including tokens produced through OAuth 2.0 Token Exchange (RFC 8693), and enforce access controls based on both identities. By default, Vault evaluates access for OBO requests using a three-way intersection of user permissions, agent ceiling policies, and the constraints in authorization_details. Access is granted only where all three overlap, ensuring an agent cannot exceed either the user's permissions or its own delegated authority. If authorization_details is configured as optional and the token omits the claim, Vault evaluates the intersection of user permissions and agent ceiling policies. The delegated OAuth JWT identifies both the user and the agent, and Vault includes both identities in the audit metadata. This makes it possible to trace an action back to both the user who initiated it and the agent that executed it. Per-request scoping reduces the risk that an overprovisioned agent will gain unrestricted access. Managing agent identity and configuration with the Terraform Vault Provider. Secure authorization is only part of the problem. Teams also need a consistent way to manage agent identities and authentication configuration across environments at scale. To support infrastructure as code workflows, this GA release adds new resources to the Terraform Vault Provider for managing agent registrations and OAuth resource server configurations declaratively. The vault_agent_registration resource enables teams to register agents through code, associate them with Vault identities, and apply governance controls consistently across environments. The vault_oauth_resource_server_config_profile resource defines how Vault validates OAuth-issued JWTs, including issuer, audience, signing, and identity validation requirements. Together, these resources allow teams to manage agent registrations and OAuth validation settings using the same Terraform workflows they already use to manage Vault infrastructure, reducing operational effort for administrators. Get started. With this GA release, Vault brings agent identity, authentication, and authorization into a single operational model. By combining explicit registration, request-scoped authorization, support for delegated user workflows, and Terraform-based management, Vault helps teams adopt agentic workloads while limiting broad permissions and maintaining visibility into requests made through Vault. Teams can speed AI adoption at scale when agentic identity access management is supported with centralized governance and auditability. Teams do not have to sacrifice development velocity and can still reduce risk with agentic lifecycle management, delegated workflows, and clear accountability for the governed agentic identities. Alongside GA, HashiCorp has expanded Vault's documentation with new how-to guides, deployment patterns, and integration examples. Tutorials for IBM Verify usage with Vault Enterprise Agentic IAM and as with Auth0 are now available. Access these resources to help your teams implement agent registration, OAuth-based authentication, delegated user workflows, and fine-grained authorization in existing environments.

Veeam, Terraform MCP, Django patch critical flaws, led by CVSS 10.0 cross-tenant bug. Swati KhandelwalAug 05, 2026 Vulnerability / Software Security HashiCorp, Veeam, and the Django Software Foundation have patched 11 vulnerabilities across Terraform MCP Server, Veeam Service Provider Console, and Django. The three most serious: * An unauthenticated flaw in Veeam's console that hands over a managed agent's credentials, rated 9.5 * A cross-tenant flaw in HashiCorp's MCP server that lets one user's Terraform token be reused for later users' requests, scored a maximum 10.0 on its CVE record * A flaw in GeoDjango's spatial lookups that can write a file to disk and, on some setups, run code, reachable by a staff user with view permission on a registered model containing a spatial field Each has a fix available now. Operators should update Terraform MCP Server to version 1.1.0 or later, Veeam Service Provider Console to 9.3.0.35057, and Django to 6.0.8 or 5.2.17. Exposure is configuration-dependent: HashiCorp's bugs affect Streamable HTTP rather than stdio, Veeam's flaws affect version 9 builds before 9.3, and Django's documented admin attack path requires a staff account with view permission for a model containing a spatial field. None of the three advisories says the flaws are under active exploitation, and as of August 5, 2026, none of the eleven CVEs appears in CISA's Known Exploited Vulnerabilities catalog, and no public proof-of-concept has surfaced. Impersonate an agent, take its credentials. Veeam Service Provider Console, the multi-tenant console that hosting firms and managed service providers use to run and monitor customer backups, got four fixes in build 9.3.0.35057, detailed in a security bulletin published August 4. Two are critical. Veeam released the build on July 29. * The one to watch is CVE-2026-58073 (CVSS score: 9.5), which lets an unauthenticated attacker impersonate a managed agent and obtain that agent's credentials. Its CVSS vector rates attack complexity as high. * The second critical flaw, CVE-2026-58072 (CVSS score: 9.0), is an arbitrary file write on the management server that can lead to remote code execution and requires a low-privilege account. The 9.5 reads as the worst of the two because it needs no login, but its high attack complexity is the reason the vector is not a straight-line exploit; unauthenticated here does not mean easy. Two high-severity bugs round out the set: CVE-2026-58067, an unauthenticated memory-exhaustion denial of service, and CVE-2026-58071, which exposes the proxied appliance API as Portal Administrator during a short window after an administrator session begins. All four affect VSPC 9.2.1.33875 and every earlier version 9 build. The fix is the upgrade to 9.3.0.35057. This is the second critical patch cycle for the console in roughly three months. In May, Veeam fixed CVE-2026-32998, a 9.4-rated remote code execution bug tied to alarm script execution. One tenant's token, reused for the next. HashiCorp's Terraform MCP server, which connects AI assistants to Terraform over the Model Context Protocol, carries three related flaws in its Streamable HTTP transport, disclosed July 28 and fixed in version 1.1.0. HashiCorp released the fixed build on July 14, followed by version 1.2.0 on August 4. Deployments that run only in stdio mode, the local single-user setup, are unaffected. The bugs live in the multi-user HTTP mode meant for centralized, shared deployments, the configuration HashiCorp promoted when it made the server generally available in June. The most severe is CVE-2026-16498 (CVSS score: 10.0), a cross-tenant credential-reuse bug in stateless HTTP mode. The underlying MCP library does not assign unique session identifiers, and the server's credential cache relied on those identifiers to tell users apart. One user's Terraform token could therefore be reused for later users' requests regardless of the token they supplied. The root is an assumption about the layer beneath the tool: the server used those session identifiers to keep tenants apart, and in stateless mode the MCP library did not provide unique ones. A second flaw, CVE-2026-16496 (CVSS score: 8.9), is the stateful-mode version of the isolation failure. Stateful mode is the default when the server runs centrally. Its cache used the MCP session ID as its sole lookup key, without binding the cached client to the token that created it. That let a user who obtained another user's session ID run tool calls with that user's Terraform client and reach resources allowed by the victim's token. Juan Pablo Martinez Kuhn of Coinspect reported the flaw; HashiCorp found the other two internally. The third, CVE-2026-14869 (CVSS score: 8.6), is a server-side request forgery flaw. Request middleware rejected a client-supplied Terraform address when it arrived as an HTTP header but not when the same value came through a query parameter. An unauthenticated caller able to reach the Streamable HTTP listener could make the server send its configured bearer token to an attacker-controlled endpoint. Two things complicate reading the CVSS numbers as a priority order. They are not on one scale: Veeam scores on CVSS 4.0 and the HashiCorp records on 3.1, so the 9.5 and the 10.0 are not the same measurement. And the two isolation flaws land on different configurations: the 10.0 (CVE-2026-16498) affects stateless mode, which an operator has to enable deliberately, while the 8.9 (CVE-2026-16496) affects the stateful mode that is the default for a central deployment. Which of the two is in reach depends on how the server is configured, not on which carries the higher number. There is a discrepancy in the published affected-version ranges. HashiCorp's umbrella bulletin lists versions 0.2.1 through 1.0.0, while the individual CVE records begin at version 0.3.0. Both sources agree that version 1.1.0 is the first fixed release. The scores come from the CVE records HashiCorp assigned; the advisory itself lists none. Operators who cannot upgrade immediately should restrict network access to the Streamable HTTP listener to trusted users and treat MCP session IDs as sensitive values. Back in GeoDjango's raster path. Django shipped 6.0.8 and 5.2.17 on August 4, with the same fixes applied to the main branch and the Django 6.1 release-candidate branch. The release covers four CVEs. Django rates their severity under its own security policy, and only one is rated high. That flaw, CVE-2026-15307, sits in GeoDjango, the framework's geographic-data layer. Spatial lookups accepted str and dict values and passed them to GDALRaster when they appeared to represent rasters. Depending on the raster driver, that could write a file to disk or make the Django process issue a network request. Writing a file to a location later imported by the application can result in remote code execution. The documented admin path is reachable by staff users with view permission on a registered model containing a spatial field. The fix disallows dict values and strings that are not valid GEOSGeometry values in spatial lookups, a backward-incompatible change. Direct model-field assignments still accept those types. The other three flaws are lower severity: * a moderate stored cross-site scripting bug in the admin where unsafe URLField values could be rendered as links and execute when clicked (CVE-2026-15920); * a moderate denial of service through deeply nested GEOMETRYCOLLECTION objects that could trigger a GEOS segmentation fault (CVE-2026-15830, now limited to 198 collections); and * a low-severity memory-consumption denial of service in check_for_language (CVE-2026-15337, now rejecting language codes longer than 500 characters). Older unsupported branches, including Django 5.1, 5.0, and 4.2, were not evaluated and may also be affected. Django's GIS code has already drawn attacker attention this year. In February, the project patched CVE-2026-1207, a SQL injection flaw in PostGIS raster lookups. CrowdSec reported exploitation in the wild: it released a detection rule on February 18, observed the first attacks on February 26, and subsequently saw steady probing aimed at locating PostGIS-backed Django deployments. That flaw required a PostGIS backend and user-controlled input to a specific lookup. The probing locates the kind of application without opening it. The new flaw's documented route needs a staff account, and fingerprinting a public site does not supply one, so the reconnaissance that found PostGIS-backed Django stops a step short of an actual way in. What carries over is the scrutiny on this code. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Introducing tfctl: The CLI for HCP Terraform and TFE. tfctl is the first dedicated CLI for HCP Terraform and Terraform Enterprise, giving engineers and AI agents full, safe access to the platform API. For years, automating HCP Terraform platform operations meant building and maintaining custom tooling on top of the API. Today, HashiCorp is changing that with tfctl, the first dedicated CLI for HCP Terraform and Terraform Enterprise, now available on GitHub. The missing interface. HCP Terraform and Terraform Enterprise had no official first-party CLI for platform operations. The Terraform CLI handles infrastructure workflows like plan and apply, but it doesn't cover platform operations like canceling runs, creating workspaces, managing variables, or administering organizations. As infrastructure automation becomes more sophisticated, a reliable, first-class interface to the platform isn't a nice-to-have. It's a prerequisite. Introducing tfctl. tfctl gives platform engineers and AI agents a single, discoverable interface to the HCP Terraform and Terraform Enterprise platform API. tfctl handles the platform operations that sit outside of your Terraform code but are central to how your team works day to day. Today's release includes: * Built-in safety guardrails. All commands support -dry-run to preview changes before they take effect. Delete commands require interactive confirmation, making them effectively inoperable by autonomous agents, by design. * Schema discovery. Use tfctl api schema search to find any API operation by keyword and retrieve the precise schema needed to form a request, useful for both humans navigating the API and agents operating autonomously. * Flexible output modes. Every command supports JSON, markdown, and human-readable table output, so whether you're piping into jq, dropping output into a GitHub PR, or reading it at the terminal, tfctl works the way you do. * Full API coverage via OpenAPI foundation. tfctl is built on top of the HCP Terraform OpenAPI spec, giving it access to 100% of the documented API today. As the platform evolves, older versions of tfctl can still access new endpoints without requiring a new release. Getting started. Whether you're automating platform operations from the terminal or pairing tfctl with a coding agent, here's what teams are using it for: * Troubleshooting and incident response: Diagnose a failed run, identify whether the issue is in your code or the platform, and get a proposed fix to review. * Change impact analysis: Before merging, identify likely affected workspaces, read their latest plans, and summarize destroys, replacements, and policy failures. * Lifecycle management: Audit workspaces at scale, rotate variables across environments, upgrade Terraform versions, or scaffold new workspaces. Destructive changes always require human approval. tfctl is available now on GitHub, and HashiCorp'd love to hear what you think. To get started, visit the repository and try it with your HCP Terraform or Terraform Enterprise environment. If you are new to HCP Terraform, you can get started for free and begin managing your infrastructure in any environment. This is the foundation for more to come as HashiCorp continue investing in how platform engineers and AI agents work with HCP Terraform and Terraform Enterprise.