Cursor shipped v3.4 on May 13, 2026, turning Cloud Agent Environments into the first industrial-grade agent runtime in the coding category. The release adds multi-repo support inside a single environment, Dockerfile-based configuration with build-scoped secrets, 70% faster rebuilds through layer caching, agent-led credential prompting, and a governance layer covering audit logging, environment-scoped secrets, and version rollback. According to the official Cursor changelog, the explicit framing is that teams can now "run fleets of parallelized agents that handle tasks from end-to-end, inside development environments you fully control." That language is a direct positioning move against Devin's "fleet of agents" marketing — and the timing, two weeks before Devin's expected mid-2026 product update cycle, is not coincidence.
We have been tracking the coding-agent platform race across every major release since Q4 2025, and v3.4 is the clearest signal yet that Anysphere — Cursor's parent — is industrializing the agent runtime rather than refining the editor. The company's reported $9.9 billion valuation and $500 million+ ARR run-rate from recent reporting on the category give it the operating capacity to invest in infrastructure most coding agents still treat as version-2 work. With v3.4, the infrastructure becomes the product. The IDE chrome is the wrapper around what is now a managed agent compute layer with first-class multi-repo, Docker, secrets, and governance primitives. For procurement teams evaluating Cursor against Devin, Windsurf, Claude Code, and OpenAI Codex, the comparison set just shifted from feature parity to platform completeness.
What shipped on May 13, 2026
The v3.4 changelog entry, published on cursor.com/changelog and timestamped May 13, 2026, lists six structural changes to the Cloud Agent Environment runtime. Multi-repo environments allow a single agent session to operate across multiple repositories with configuration reused across sessions. Dockerfile-based configuration replaces the previous setup model, with support for build secrets that allow secure access to private package registries directly from the build step. Build secrets are scoped to the build phase and are not exposed to the running agent's runtime environment. Layer caching reduces rebuild time by 70% when only updated layers need to rebuild. Agent-led setup means the system asks questions, flags missing credentials, and validates the environment configuration before the agent begins work. Governance adds version history per environment with rollback, an audit log capturing every team action on environments, and per-environment secret scoping such that secrets configured for one environment are not accessible from any other.
Each of those six lines describes a discrete capability that maps directly to a procurement requirement enterprise platform teams have been articulating for the past nine months. Multi-repo answers the monorepo-or-polyrepo conversation: regardless of repo architecture, the agent can operate across the full surface. Dockerfile config answers the reproducibility requirement: build steps are now codified rather than declarative. Build-scoped secrets answer the security review: secrets live in the build phase and never reach the runtime, which closes the most common audit finding from internal security teams reviewing agent platforms. Layer caching answers the developer-experience requirement: agent iteration speed is now bounded by the speed of the changed layer rather than the speed of the full environment rebuild. Agent-led setup answers the onboarding-friction problem. Governance answers the compliance and incident-response requirements.
Multi-repo is the most structurally important change
Of the six features in v3.4, multi-repo is the one that shifts the most enterprise procurement conversations. Until this release, Cursor Cloud Agents operated against a single repository per environment, which forced developers into one of two unattractive workarounds. Either consolidate cross-cutting work into a monorepo to keep the agent in scope, which collides with most enterprise polyrepo architectures, or run multiple parallel agents against multiple environments, which fragments context and breaks the cross-repo refactor pattern that complex enterprise codebases require. The v3.4 multi-repo capability resolves both workarounds in a single primitive.
The "configuration reuse across sessions" language in the changelog is the operational hook. In practice, this means a team configures the agent environment once — Dockerfile, secrets, build steps, governance — and the same configuration applies to every multi-repo session the team initiates. The economic implication is that the per-session setup cost approaches zero after the initial environment definition, which is the precondition for running large fleets of parallel agents at enterprise scale. The Devin "fleet of agents" framing makes the same promise; the difference is that Cursor's framing is supported by a published configuration mechanism rather than by a roadmap commitment. For procurement teams running paid pilots, that difference is the line between vendor demo and operational deployment.
The cross-repo refactor case is the highest-leverage use of the multi-repo capability. Enterprise codebases routinely span 50 to 200 repositories with API contracts, shared libraries, and deployment surfaces distributed across the repo set. A schema change in a central library repository propagates through dozens of dependent service repositories — work that is mechanically tractable but tedious enough that it consumes meaningful senior-engineer time. With v3.4, the agent can be assigned the schema-update task across the dependent repo set in a single environment, with the propagation work parallelized across the agent fleet. That use case is the single most common scenario in enterprise codebase modernization, and it is the one where the agent runtime delivers a documented productivity multiplier rather than a marketing claim.
Dockerfile config and the build-scoped secrets pattern
The Dockerfile-based environment configuration is the second major architecture shift. Previous Cursor Cloud Agent environments used a declarative configuration surface — a YAML or JSON manifest — that worked for simple cases but became friction for enterprise environments with custom toolchains, private package registries, or non-standard build steps. Moving the configuration to Dockerfile semantics gives platform teams the same primitive they already use for production container images, with the same toolchain knowledge already in the team's hands. The migration cost from existing CI/CD container configurations to Cursor Cloud Agent configurations is now approximately zero for teams already operating on a Docker-native deployment surface.
The build-scoped secrets pattern is the security architecture that makes the Dockerfile approach enterprise-viable. Standard Docker build arguments are notoriously poor at handling secrets — secrets leak into image layers, persist in build caches, and become discoverable through layer inspection. The v3.4 build secrets capability follows the Docker BuildKit secret-mount pattern: secrets are made available to the build step but are not written to any image layer and are not accessible from the running container. The changelog language — "scoped to the build step and aren't passed to the running agent's environment" — is the precise security architecture that enterprise security review teams have been asking for. The most common scenario is private NPM, PyPI, or Maven registry credentials needed at build time but not at runtime. Build-scoped secrets handle that case cleanly.
The audit-trail implication of the Dockerfile approach is also material. Because the build configuration is now expressed in a Dockerfile rather than in a vendor-specific manifest, the configuration itself can be version-controlled in the team's existing repository alongside the application code. Security review, change approval, and rollback all operate on the same tooling the team uses for application code, rather than requiring a parallel review process for vendor manifests. For enterprises with strict change-management discipline, this collapses the agent-platform compliance overhead into the existing development workflow.
70% faster rebuilds: the layer cache economics
The 70% rebuild speedup is the developer-experience headline of v3.4 and the operational economics that makes large agent fleets cost-feasible. The cited figure is specific: "builds that hit the cache run 70% faster" when only updated layers need to rebuild. The mechanism is standard Docker layer-cache reuse applied at the Cloud Agent Environment level — when a developer triggers an agent task against an environment whose lower layers (base image, system packages, language runtime, dependency installation) are unchanged, only the upper layers (application code changes, configuration deltas) are rebuilt. For a typical Node, Python, or Go service with a multi-megabyte dependency tree, the layer cache reduces the full-environment rebuild from minutes to seconds.
The economic translation is meaningful. Cloud Agent compute time is the variable cost in the v3.4 model — the agent runs on managed infrastructure billed against the customer account. A 70% reduction in rebuild time directly reduces the dominant compute cost component of each agent invocation. For a team running 100 agent tasks per developer per day across 50 developers, that translates to a compute-cost reduction in the meaningful single-digit percent of total platform spend, which is the gating economic factor in scaling agent usage past pilot deployments.
The developer-experience translation is more important than the cost translation. Agent iteration speed is the binding constraint on agent productivity. A developer who has to wait 60 to 120 seconds for an environment to rebuild between agent invocations will run a small number of agent iterations per task. A developer whose rebuild completes in 15 to 30 seconds will run many more iterations, increasing the probability that the agent produces a useful result and reducing the human-in-the-loop overhead that limits the productivity multiplier. The 70% rebuild speedup is the difference between a tool developers reach for occasionally and a tool developers reach for routinely.
Agent-led credential prompting: the onboarding unlock
The agent-led setup capability — "will ask you questions, flag missing credentials, and validate that your environment is set up properly" — is the lowest-profile feature in v3.4 and one of the highest-leverage in practice. Environment configuration is the friction point that has historically caused agent platform pilots to stall at the second or third user. The classic failure pattern is that the platform-engineering team builds a reference environment, the first developer onboards smoothly, the second developer hits an undocumented credential prerequisite, the platform team gets pulled into a one-off support cycle, and the third developer never gets onboarded.
Agent-led credential prompting moves the onboarding burden from the platform team to the agent itself. When a developer connects to an environment, the agent inspects the configuration, identifies missing credentials, and prompts the developer to provide them — with the validation that the credentials are correctly formatted and authoritative before the agent begins work. The platform team writes the configuration once; the agent handles the per-developer onboarding loop. For enterprises rolling out coding agents to 100 to 1000+ developers, this single feature is the difference between a successful platform rollout and a stalled pilot.
The validation step deserves separate attention. The changelog language is "validate that your environment is set up properly" — implying that the agent does not just collect credentials, it tests them. For environments with credentials to private registries, cloud accounts, or internal APIs, this validation closes the most common day-one failure mode: the developer enters credentials that look correct but fail at first use, leading to a debugging cycle that consumes the agent's first task. By front-loading the validation, the agent's first task starts in a known-good state.
The governance layer: audit, rollback, and secret isolation
The governance capabilities in v3.4 are the enterprise-readiness signal. Three specific mechanisms ship: every development environment has its own version history with rollback, an audit log captures every action team members take on environments, and secrets configured for one environment are not accessible from any other environment. Each of those three lines maps to a specific enterprise compliance requirement that has historically blocked agent platform adoption in regulated industries.
Version history and rollback address change management. Enterprise platform teams operate against change-control policies that require the ability to revert any environment configuration to a known-good prior state. The previous Cloud Agent model required platform teams to manage configuration versioning externally — typically through a separate Git repository synced to the agent platform — which created drift between the source of truth and the deployed configuration. Native per-environment version history with rollback collapses that into a single managed surface.
Audit logging addresses compliance attestation. Regulated industries — financial services, healthcare, government, defense — require demonstrable audit trails for any developer action against production-adjacent systems. The v3.4 audit log captures team-member actions on environments at a granularity sufficient for SOC 2, ISO 27001, and equivalent compliance attestations. Without this capability, deploying Cursor Cloud Agents in regulated industries required compensating controls — typically external SIEM ingestion of agent-platform telemetry — that introduced their own cost and operational overhead. Native audit logging eliminates that compensating-control requirement.
Per-environment secret isolation addresses the lateral-movement risk. The most common security finding on multi-tenant agent platforms is that secrets configured for one environment can be discovered or exfiltrated from another environment, creating a lateral-movement path that an attacker could exploit. The v3.4 isolation guarantee — "secrets configured for one environment aren't accessible from any other" — closes that finding at the platform level. For enterprises with strict separation-of-duties requirements between development environments — production vs. staging vs. development — this isolation is the precondition for deployment.
How v3.4 positions against Devin and Windsurf
The "fleet of agents" language is a direct, intentional reference to Devin's positioning. Devin's market entry in 2024 framed the autonomous coding agent category around the fleet metaphor — multiple agents working in parallel, each handling end-to-end tasks. The framing was strong enough that subsequent entrants — including Cursor's own earlier Cloud Agent positioning — implicitly competed against the Devin narrative. With v3.4, Cursor adopts the same framing and builds the platform primitives — multi-repo, Dockerfile config, governance — that make the fleet metaphor operationally viable for enterprise deployment.
The strategic read is that Cursor is no longer competing as a better IDE with agent features. Cursor is competing as a managed agent platform that happens to ship with an IDE. The product surface area has expanded from editor → editor + agent feature → editor + managed agent runtime. Each expansion increases the procurement complexity (more features to evaluate) but also increases the platform stickiness (more configuration sunk costs). For Devin, the implication is that Cursor has matched the fleet positioning with a more credible platform substrate. For Windsurf and other agent-forward editors, the implication is that the platform-completeness bar has moved up — competing on agent features alone is no longer sufficient.
The published Cursor vs. Windsurf comparison we maintain has been updated to reflect the v3.4 capabilities; the Devin vs. Manus comparison remains the structural framing for the autonomous-agent end of the category. Readers evaluating the platform-completeness dimension of the agent race should also see the Cursor vs. Zed comparison for the lightweight-editor counterposition, and the Claude Code vs. Cursor 2026 comparison for the CLI-first counterposition. Each of those four comparisons captures a different vector on which the v3.4 platform expansion will be tested in the next three to six months.
The Anysphere financial context
The release lands in the context of Anysphere's reported financial trajectory. Recent industry reporting places the company's most recent valuation at approximately $9.9 billion and the ARR run-rate at $500 million or higher. Those numbers, if accurate, place Anysphere among the fastest-growing AI infrastructure companies of the 2025-2026 cycle and give it the operating capacity to invest in platform infrastructure most coding agents still defer to a future release.
The financial context matters because the v3.4 feature set is not the work of a single sprint. Multi-repo coordination, Dockerfile-native configuration, build-scoped secret handling, layer-cache architecture, and full governance with audit trails represent a multi-quarter engineering investment that requires sustained capital deployment. The $500 million ARR run-rate is the revenue base that funds the engineering capacity, and the $9.9 billion valuation is the equity surface that recruits the engineering talent. Without that financial substrate, the platform expansion in v3.4 would not be possible at the speed it landed.
The strategic implication for the category is that financial substrate is now a competitive variable. Earlier in the coding-agent cycle, the competition was on raw model capability and editor ergonomics. With v3.4, the competition is also on the engineering capacity to build managed-platform infrastructure at production quality. Vendors without comparable financial substrate — and without the engineering depth that the substrate funds — will have a harder time matching the platform-completeness bar that Cursor has set. The category compresses toward the vendors with both the model access and the platform-engineering capacity.
Enterprise procurement implications
For procurement teams currently in active evaluation of coding-agent platforms, the v3.4 release changes the evaluation rubric in four specific ways. First, the multi-repo capability becomes table stakes for any platform claiming enterprise readiness. Vendors that still operate on a single-repo-per-environment model now have an explicit gap that the procurement team can use as a leverage point in negotiation or as a basis for downselection. Second, Dockerfile-based configuration becomes the expected primitive for environment setup. Vendors offering proprietary configuration schemas — YAML, JSON, custom DSL — now face an additional friction conversation with platform teams that prefer Docker-native semantics.
Third, build-scoped secrets become the expected security model. Vendors whose secret-handling architecture does not separate build-time and runtime contexts now have a documented inferior posture against an industry-standard pattern. Fourth, governance — version history, audit logging, secret isolation — moves from optional differentiator to required capability. Vendors without those three governance primitives now face an extended security-review cycle in any regulated-industry deployment, with the burden of evidence on the vendor to demonstrate equivalent capability through external tooling or compensating controls.
The downstream implication for the broader category is that v3.4 sets the floor for what an enterprise-ready agent platform looks like in mid-2026. Vendors above the floor compete on differentiation. Vendors below the floor compete on roadmap promises. The procurement team's job is to identify which vendors are above the floor today versus which vendors are claiming they will be above the floor by Q4 2026. That distinction is the most important filter in the current evaluation cycle.
What could still go wrong
The release is structurally strong but operationally untested at scale. Three risk vectors are worth tracking in the months ahead. First, multi-repo coordination at fleet scale. The v3.4 changelog describes the capability but does not document the upper bounds — how many repositories can a single environment span, what is the agent context window when operating across a large repo set, and how does the agent handle conflicting state across repos. These are operational questions that will surface only as enterprise customers push the capability to its limits. Early reports from large customers in Q3 2026 will define what the practical multi-repo ceiling actually is.
Second, the Dockerfile configuration migration. Existing Cursor Cloud Agent customers operating on the prior declarative configuration model will need to migrate to Dockerfile semantics. The migration path, the support window for the legacy configuration, and the migration tooling are not addressed in the changelog. Customer experience during migration will determine whether v3.4 is perceived as a smooth platform evolution or as a forced migration that imposes operational cost. Cursor's communication and support cadence in the next 30 to 60 days will set the tone.
Third, the governance feature operational depth. Audit logging is straightforward in concept and complex in execution. Questions like retention duration, query interface, integration with enterprise SIEM systems, and access controls on the audit log itself are the operational details that determine whether the audit log is a compliance checkbox or a usable operational tool. The v3.4 release ships the primitive; the v3.5 and v3.6 releases will determine whether the primitive matures into the operational tooling that regulated-industry deployments require.
The 2026 coding war positioning shift
The coding-agent category is now in its fourth distinct competitive phase. Phase one (2023) was the editor-with-completion phase, defined by GitHub Copilot. Phase two (2024) was the agent-feature-in-editor phase, defined by Cursor's early Tab and Composer releases alongside Windsurf's Cascade. Phase three (2025) was the autonomous-agent phase, defined by Devin, OpenAI Codex, and the parallel rise of CLI-native agents including Claude Code. Phase four (mid-2026) is the managed-agent-platform phase, defined by v3.4 and whatever Devin, Windsurf, and Codex ship in response over the next two quarters.
The phase-four characteristic is platform completeness rather than feature differentiation. The competitive question is no longer "which agent writes better code" — the frontier model differentiation has narrowed to the point where most enterprise customers can use any of three to four model lines effectively. The competitive question is "which agent platform integrates cleanly with the enterprise's existing development, security, and compliance infrastructure." That is a different competitive surface and a harder one to compete on, because platform-engineering investment compounds and the leader is hard to dislodge once enterprise customers have configured against the platform's primitives.
Cursor's bet with v3.4 is that platform-engineering investment compounds and that the first vendor to industrialize the agent stack captures the enterprise procurement cycle that opens in mid-2026 and closes by year-end 2026. The bet may or may not be correct — Devin, Windsurf, and Codex will respond, and the response cadence will determine whether Cursor consolidates the platform lead or whether the category remains fragmented. But the bet is well-funded, well-engineered, and timed precisely against the enterprise procurement cycle. For procurement teams, the implication is that the platform decision made between now and Q4 2026 will likely be the platform decision that sticks through 2027 and 2028.
Strategic bottom line
v3.4 is the inflection point where Cursor stops being a better IDE and becomes a managed agent platform. The six features that shipped on May 13, 2026 — multi-repo, Dockerfile config, build-scoped secrets, 70% faster rebuilds, agent-led setup, and governance — are individually useful and collectively transformative. Each one closes a specific enterprise procurement gap, and the combination sets the floor for what an enterprise-ready agent platform looks like for the rest of 2026.
The strategic framing — Cursor industrializes the agent stack while Anysphere's $9.9 billion valuation and $500 million+ ARR run-rate fund the platform-engineering investment — captures both the product reality and the financial substrate that makes the product reality possible. The category-level implication is that the coding-agent race compresses toward vendors with both the model access and the platform-engineering capacity, and v3.4 is the clearest signal yet of which vendor occupies that position. Devin, Windsurf, OpenAI Codex, and Claude Code will respond, and the response cadence over the next two quarters will define whether Cursor consolidates the platform lead or whether the category remains structurally competitive.
For enterprise procurement teams, the next 90 days are the highest-leverage evaluation window of the cycle. The platform floor has moved up, the leading platform is documented and shipping, and the procurement decision made in this window will compound across 2027 and 2028. The exercise is now on the buyer.
Frequently Asked Questions
What is Cursor Cloud Agent Environments v3.4 and when did it ship?
Cursor Cloud Agent Environments v3.4 is the May 13, 2026 release that turns Cursor's Cloud Agent runtime into an industrial-grade managed agent platform. The release adds multi-repo support, Dockerfile-based environment configuration, build-scoped secrets, 70% faster rebuilds through layer caching, agent-led credential prompting, and a governance layer with audit logging, version rollback, and per-environment secret isolation. The release was published on the official cursor.com/changelog on May 13, 2026.
What does multi-repo support mean in Cursor v3.4?
Multi-repo support means a single Cloud Agent session can operate across multiple repositories in a single environment, with configuration reuse across sessions. Before v3.4, a Cloud Agent environment was scoped to a single repository, which forced developers to either consolidate work into a monorepo or run multiple parallel agents across separate environments. With v3.4, the cross-repo refactor pattern — a schema change in a central library that propagates through dozens of dependent service repositories — becomes a single agent task rather than a fleet-coordination problem.
How does the new Dockerfile-based configuration work?
Cursor v3.4 replaces the previous declarative environment configuration with Dockerfile semantics. Platform teams define the environment using a Dockerfile, which is the same primitive teams already use for production container images. The Dockerfile can be version-controlled in the team's existing repository alongside application code, which collapses agent-platform configuration into the existing development workflow. The migration cost from existing CI/CD container configurations to v3.4 environment configurations is approximately zero for teams already operating on a Docker-native deployment surface.
What are build-scoped secrets and why do they matter for enterprise security?
Build-scoped secrets are credentials made available during the Dockerfile build step but not exposed to the running agent's runtime environment. The pattern follows Docker BuildKit secret-mount semantics: secrets are accessible during build but are not written to any image layer and are not accessible from the running container. The most common use case is private NPM, PyPI, or Maven registry credentials needed at build time. The architecture closes the most common enterprise security audit finding on agent platforms — that secrets used at build time leak into runtime contexts where they can be discovered or exfiltrated.
How does the 70% faster rebuild speedup work?
The speedup uses standard Docker layer caching applied at the Cloud Agent Environment level. When a developer triggers an agent task against an environment whose lower layers — base image, system packages, language runtime, dependency installation — are unchanged, only the upper layers — application code changes, configuration deltas — are rebuilt. For typical Node, Python, or Go services with multi-megabyte dependency trees, the layer cache reduces the full-environment rebuild from minutes to seconds, making agent iteration speed bounded by changed-layer rebuild time rather than full-environment rebuild time.
What is agent-led credential prompting?
Agent-led credential prompting means the Cursor agent inspects the environment configuration, identifies missing credentials, prompts the developer to provide them, and validates that the provided credentials are correctly formatted and authoritative before the agent begins work. The capability moves the per-developer onboarding burden from the platform-engineering team to the agent itself. For enterprises rolling out coding agents to 100 to 1000+ developers, this single feature is the difference between a successful platform rollout and a stalled pilot at the second or third user.
What governance features does Cursor v3.4 ship?
Three governance primitives ship in v3.4: every development environment has its own version history with rollback, an audit log captures every action team members take on environments, and secrets configured for one environment are not accessible from any other environment. The three capabilities map to enterprise change management, compliance attestation (SOC 2, ISO 27001), and separation-of-duties requirements that have historically blocked agent platform adoption in regulated industries including financial services, healthcare, government, and defense.
How does Cursor v3.4 position against Devin's fleet of agents pitch?
The v3.4 changelog explicitly frames the release as letting teams "run fleets of parallelized agents that handle tasks from end-to-end, inside development environments you fully control." The language is a direct reference to Devin's fleet-of-agents market positioning from 2024. The strategic positioning is that Cursor now offers the same fleet metaphor backed by published platform primitives — multi-repo, Dockerfile config, governance — that make the fleet metaphor operationally viable for enterprise deployment. For procurement teams running paid pilots, the published platform primitives are the difference between vendor demo and operational deployment.
What is Anysphere's reported valuation and ARR?
Anysphere, the company behind Cursor, has been reported at approximately a $9.9 billion valuation with an ARR run-rate of $500 million or higher in recent industry reporting on the coding-agent category. The financial substrate is the engineering capacity that funds the v3.4 platform expansion — multi-repo coordination, Dockerfile-native configuration, build-scoped secret handling, layer-cache architecture, and full governance with audit trails represent a multi-quarter engineering investment that the $500 million ARR base funds and the $9.9 billion valuation surface recruits.
How does Cursor v3.4 affect enterprise procurement evaluations?
The release changes the evaluation rubric in four specific ways. Multi-repo capability becomes table stakes for enterprise-readiness claims. Dockerfile-based configuration becomes the expected environment-setup primitive. Build-scoped secrets become the expected security model. Governance — version history, audit logging, secret isolation — moves from optional differentiator to required capability. Vendors without those four capabilities face extended security-review cycles in regulated-industry deployments, with the burden of evidence on the vendor to demonstrate equivalent capability through external tooling or compensating controls.
What competitive phase is the coding-agent category now in?
The category is in its fourth competitive phase. Phase one (2023) was editor-with-completion, defined by GitHub Copilot. Phase two (2024) was agent-feature-in-editor, defined by Cursor's early Tab and Composer releases. Phase three (2025) was autonomous-agent, defined by Devin, OpenAI Codex, and CLI-native agents including Claude Code. Phase four (mid-2026) is managed-agent-platform, defined by Cursor v3.4 and whatever Devin, Windsurf, and Codex ship in response. The phase-four competitive surface is platform completeness rather than feature differentiation.
What are the biggest operational risks in Cursor v3.4?
Three risks worth tracking. First, multi-repo coordination at fleet scale — the changelog does not document upper bounds on repository count per environment or agent context behavior across large repo sets, and early enterprise customer reports in Q3 2026 will define the practical ceiling. Second, the Dockerfile configuration migration path for existing Cloud Agent customers, with the migration tooling and legacy-configuration support window not documented in the v3.4 release. Third, governance feature operational depth — audit log retention duration, query interface, SIEM integration, and access controls on the audit log itself are details that determine whether governance is a compliance checkbox or a usable operational tool.
