Monte Carlo’s Enterprise Platform Updates: Coverage and Control Below the Agent Layer
Our enterprise customers are shipping agents in production at scale, and that raises the bar on everything underneath them. An agent is only as reliable as the data it reads and the guardrails on what it’s allowed to do with it. That’s why we continue to strengthen and expand the capabilities of our platform.
Read on to learn about what we shipped this past quarter, from extending the coverage of the Monte Carlo Trust Platform, to expanding the level of control and admin flexibility teams can work with.
Coverage: what your agents read
An agent reasoning over your data estate inherits every gap in it. A pipeline we can’t observe, a table we can’t reach, a run history that only records failures — each one is a place where the agent’s picture stops matching reality. These three updates close gaps of exactly that kind.
AI-first integrations for ETL and orchestration
What’s new: Our AI-first integration framework, proven on warehouses, now covers ETL and orchestration — the largest integration category by demand. When Monte Carlo doesn’t natively cover your orchestrator, you no longer wait for a connector. A customer, a partner, or Claude can build one.
Why it matters: A job running in a tool we can’t see puts a hole in the chain from an output back to its source data, and root cause analysis stops at the edge of what we know. Lineage completeness is a function of integration coverage.
There are two ways in, and they’re not rival products. The Push Ingest API is the direct path: you, or Claude, build a small collector that posts run and metadata events from anywhere a REST call can originate. No agent is required, and you own the hosting and schedule. A custom connector is the batteries-included way to use that same API — a guided conversation with Claude scaffolds it, packages it, and registers it as a first-class connection, with Monte Carlo running the collection schedule for you.
Because both paths resolve into one model of jobs, tasks, and runs, a third mode works too: collect natively for some capabilities and top up with Push for the rest, whether that’s a slice of lineage the native path can’t reach or a run signal it doesn’t emit. Everything your existing integration does keeps working, and the pushed data layers on top.
Four new integrations:
- Snowflake Tasks brings task graphs to the same footing as Airflow DAGs — run history, task-level detail, and failure alerts, with an optional near-real-time path that fires the moment a task fails.
- GCP Dataform surfaces lineage, run history, and workflow failure alerts from your repositories, alongside your warehouse-native lineage.
- Matillion joins the same product surface as the rest — jobs, tasks, run history, lineage, and alerting.
- Mulesoft brings table-to-table lineage from the SQL operations inside your Mule applications, shown next to your warehouse lineage. Lineage-focused to start.
Claude is how these integrations get built, but nothing about that changes where they run or what they can reach. A generated connector runs on the Generic Agent in your own environment, using your credentials, making outbound calls only — the same posture as a connector we build ourselves, with no privileges native collection doesn’t have. It works behind forward proxies, TLS inspection, and private connectivity, and deploys on-prem or in any cloud. Integrations that lean entirely on Push need no agent at all. And if you’d rather not hand the build to an AI, every step has a documented manual path.
Databricks foreign catalog support
What’s new: Databricks foreign catalog tables now show up as first-class assets with full schema and cataloging. Everything you can do on a native external table works on them, monitoring and in-warehouse lineage included. It runs on your existing Databricks connection, as long as we have access to the catalog.
Why it matters: For customers running multiple warehouses side by side, parts of the estate often live in foreign catalogs that were invisible to us until now. Which means any agent reading those tables was reading an unmonitored surface, and had no way to know it.
Coming next: Linking a foreign table back to the real asset it points to. When a Snowflake table is projected into Databricks, we’ll connect the two and draw a cross-warehouse lineage edge. The intent is to build it generically, so the same mechanism extends to other integrations.
Monitor runs data export
What’s new: A new monitor runs export gives you the value observed on each monitor run and the threshold it was checked against — including the runs that stayed healthy and never alerted. It’s available via the Snowflake data share, the CLI, and the API.
Why it matters: Exports previously centered on incidents and breaches, which is the right shape for a postmortem but close to useless for the question that actually predicts the next one: has this been drifting toward its threshold for six weeks without ever crossing it? Healthy-state history is what baselines are made of, and what lets you bring Monte Carlo’s run data into your own reporting alongside every other quality signal you track.
Control: what’s allowed to act
Coverage tells you what an agent can see. The other half is what it — or anyone else holding programmatic access — is permitted to do. These three updates put that in admins’ hands.
Granular permissions for the Troubleshooting and Triage agents
What’s new: Dedicated permissions for the Troubleshooting and Triage agents, usable in custom roles, replacing the previous all-or-nothing access. A subset of your team can run the agents while everyone else keeps read access to what the agents found.
Why it matters: The path from human-guided to autonomous isn’t a switch, and it isn’t uniform across an organization either. A platform team may be ready to let an agent triage incidents unsupervised while the same company’s analytics org wants a human reading every recommendation. Both positions are correct for the team holding them, and access control is how that gradient gets expressed — team by team, at whatever pace each one is ready for.
That’s the core value of custom roles in general. Built-in roles rarely match how an org actually works, and each new permission like this one makes them more useful.
OAuth 2.0 for the API, SDK, and CLI
What’s new: The API now supports OAuth 2.0 client-credentials (machine-to-machine) authentication alongside existing key-based auth, end to end across the API, SDK, and CLI.
Personal OAuth clients act as you, for usage tied to your own user. Service clients are scoped by authorization groups rather than a single person — the right shape for anything running unattended, and revocable without touching whoever created it.
Each client can hold up to two secrets, so rotation is a built-in operation: generate a new one, roll every integration over, delete the old one, no downtime. A new OAuth and API keys tab lists every credential with created and expiry dates, one-click revoke, and a Revoke all option. Maximum expiration is now capped at one year for all non-service key types; service credentials stay flexible for long-lived production use.
Why it matters: OAuth client-credentials is the standard for machine-to-machine API access, and it matches how most enterprises already run programmatic access. Clients mint short-lived, auto-expiring tokens, rotation doesn’t require a maintenance window, and access maps to an identity you can scope and revoke centrally rather than a personal key tied to whoever happened to set the integration up. As more of what calls Monte Carlo runs on a schedule rather than at a keyboard, that distinction stops being a formality.
SSO lockout recovery
What’s new: SSO admins now have a self-service way back in when an SSO change locks their org out. When enabling or editing SSO, an admin generates single-use recovery codes as a required step of saving the config. If the org gets locked out later, a user with the Edit-SSO permission redeems a code at the sign-in page, which arms a password reset link sent to their on-file email. Getting back in means proving you hold a code and control the mailbox, with no Monte Carlo intervention.
There’s also a grace window on SSO updates: when an admin edits a live config, password login stays open for just that admin, so a misconfiguration can’t instantly lock everyone out. Guardrails run throughout: email verification as a second factor, a rate-limited redeem endpoint, and an optional per-account IP allowlist in front of it.
Why it matters: Once SSO is enforced, password login is disabled. A wrong cert, an IdP switch, or a bad attribute mapping could lock an entire org out with no self-service path back. Customers now hold their own recovery path.
Coming next
Cross-warehouse lineage is the near-term priority: linking foreign tables back to the assets they point at, so a projection into Databricks resolves to the Snowflake table behind it. We’re also extending the integration framework past ETL, using the same building blocks that opened up orchestration.
Several capabilities above are in private preview. Reach out to your Monte Carlo account team to get an account enabled.
