Zoho has launched Catalyst 3.0 with a developer workflow built around AI coding agents that can move beyond code generation and operate cloud infrastructure directly. The platform adds a live MCP server, agent skills, a non-interactive CLI, and integrations for tools including Claude, Cursor, Codex and Gemini. The important change is not another assistant integration. Catalyst is giving agents a supported path to create tables, configure authentication, provision services and deploy applications inside the same production platform developers use.
That changes the risk model. Once an agent can mutate infrastructure, the question is no longer only whether its code is correct. Teams also need to know which identity the agent used, what it was allowed to change, which tools it called, and whether a bad action can be reconstructed or reversed. Catalyst 3.0 makes those controls part of the same agent workflow rather than leaving them entirely to an external harness.
From generated code to infrastructure changes
Catalyst says its live MCP server lets supported agents connect directly to its infrastructure and perform actions such as creating tables, wiring authentication and deploying applications. The official Cursor plugin shows the same design at a lower level: it bundles service-specific skills, project context, MCP routing and access to operations for data stores, cache, buckets and other platform services.
This is a meaningful step beyond the common pattern where an agent edits a repository and a separate CI/CD system owns deployment. Here, the agent-facing interface reaches into cloud resources. That can reduce the translation work between code generation and platform operations, but it also expands the blast radius of an agent mistake.
Identity and permissions become part of the agent architecture
Zoho documents a scoped collaborator model in which an agent authenticates with its own configurable permission set. It also says destructive commands are disabled in non-interactive mode. That distinction matters because a coding agent running unattended should not inherit the same authority as the developer who launched it.
The practical architectural implication is that agent identity should be reviewed like a service account, not like a chat-session preference. Teams adopting this pattern should define least-privilege roles for agent tasks, separate development and production authority, and decide which infrastructure mutations must remain behind human or pipeline approval. The MCP connection is therefore not just an interoperability layer; it becomes part of the authorization boundary.
Auditability is now a delivery requirement
Catalyst 3.0 exposes application logs, platform logs and MCP tool-call logs, and Zoho says post-launch changes are versioned, attributable and reversible. Those properties make it possible to ask a useful operational question after an incident: which agent invoked which tool, under which identity, and what changed as a result?
That does not prove that every agent action is safe. It does make the execution trail inspectable, which is a prerequisite for debugging, governance and incident response. For engineering leaders, the relevant comparison between agent-ready platforms is therefore shifting from model support alone to the quality of identity, permission, logging and rollback controls around tool execution.
Vendor benchmark claims need separation from shipped controls
Zoho reports large improvements in task completion when its Agent Skills and MCP context are enabled, including results in the 90–95% range for the models it tested. Those numbers are vendor-produced and should not be treated as independently established performance.
The shipped workflow is easier to verify than the benchmark. The product page documents the MCP server, scoped permissions, tool-call logs and versioned changes, while the official repository exposes the Cursor integration and service-specific skills. A team can evaluate those capabilities directly without accepting the performance claims at face value.
The bigger decision is where agent authority should live
Catalyst 3.0 illustrates a broader design shift in agentic software engineering: infrastructure providers are beginning to expose production operations directly to coding agents while also adding the controls needed to constrain them.
That creates a new architecture choice. Teams can keep agent authority in an external harness that calls a cloud platform through conventional automation, or they can use a platform-native agent interface where permissions and audit trails are integrated with the infrastructure itself. The second path can simplify execution, but it also increases dependency on the platform's control model. Before adopting it, teams should evaluate portability of the agent workflow separately from portability of the application.