Unity Gateway: Govern Coding Agents as a Platform Service

A coding agent is easy to install and harder to govern. Once it can read repositories, call models and invoke tools, its configuration becomes part of your platform’s security boundary — not just a developer preference.

At NexOps, our work includes Unity Catalog governance and self-service data onboarding. Our position is straightforward: making access convenient does not remove the need to define identities, permissions and ownership.

In this post, we’ll turn the recent Unity Gateway updates into a controlled coding-agent onboarding path. We’ll separate central configuration from actual enforcement, establish authentication and spending boundaries, and cover tracing, model retirement and EU data-processing review.

What Changed

The September 2026 updates bring several related capabilities together, but their availability statuses are not interchangeable. They cover shared agent settings, Model Context Protocol (MCP) tools, tracing and usage reporting — each with its own prerequisites.

The central configuration documentation specifies one published configuration per workspace. The CLI checks that configuration at agent launch; changes can take a few minutes, while ug configure refreshes settings and synchronises managed MCP servers and skills.

The coding-agent observability documentation distinguishes gateway traces from activity emitted on a developer’s machine. Its documented client-side tracing setup covers Claude Code and Codex; do not extend that support claim to every agent the CLI can launch.

There is also a lifecycle deadline: the 28 September retirement notice schedules Thinking Machine Labs Inkling for retirement on 30 October 2026, recommending GLM 5.3 and Kimi K3 as replacements. A recommendation is not proof of compatibility with your coding agent.

Why It Matters for Platform Teams

Central configuration gives us a distribution mechanism for an approved setup. It does not, by itself, establish that every request takes the approved path or that an approved tool can only perform safe actions.

We would treat this as a platform service with a named owner, reviewed changes and a support boundary. The useful distinction is between configuring what an agent sees and enforcing what an identity can do.

A shared skill is an instruction, not an authorisation boundary. Similarly, listing a GitHub MCP server does not establish which repositories it can access or whether it can merge changes.

Our opinion: adopt the managed path when several teams need a consistent model and tool catalogue. Do not present it as an end-to-end sandbox or a substitute for repository protections.

Use Case: Coding Assistance in a Public Health Platform

Consider a hypothetical national public health institute with several domain teams, sensitive data classifications and legacy ingestion code. Developers want help maintaining pipelines and onboarding sources, but the institute cannot allow source code, credentials or patient-level extracts to flow through unreviewed tools.

The usual approach is to distribute setup instructions and let each developer connect an agent independently. That creates inconsistent model choices, unclear spending ownership and uncertainty about which credentials a tool uses. Repository access also becomes entangled with production data access.

The managed approach starts in a development workspace with approved models, reviewed skills and narrowly authorised MCP tools. A developer launches the agent through ug; model and gateway-handled MCP requests pass through Unity Gateway, while configured client-side traces add execution context to the selected Unity Catalog trace table. Proposed changes remain on branches, and production deployment stays behind the existing CI/CD approval boundary.

We would measure onboarding failures, configuration adoption, tool-authorisation failures, trace coverage, spend attributable to team owners and the quality of reviewed changes. Commits and lines changed are activity signals, not evidence of safe or useful output. This scenario is hypothetical; our RIVM self-service onboarding reference describes verified delivery, not use of these new coding-agent features.

Implementation

1. Approve the data-processing path before the model

Start with a service-boundary document, not a CLI rollout. Record which repository content, prompts, tool responses and trace attributes can leave the developer’s machine, which services process them and who owns each decision.

For an EU organisation, review the actual deployment and contracts with security, privacy and procurement. Include processing locations, subprocessors, retention, deletion, international transfers, provider terms and whether production data is permitted in prompts or tool results.

The supplied documentation does not establish regional availability or an EU-only processing guarantee. Neither a Unity Catalog resource name nor an Azure workspace location is sufficient evidence for those conclusions.

Apply the same review to MCP tools. A model can receive sensitive information through a tool response even when the repository itself contains no sensitive data.

2. Publish a narrow, version-controlled configuration

Enable the workspace-level Unity Gateway Managed Configuration preview and prepare the model, MCP and skill resources. Grant developers the access they need before publishing; configuration does not replace resource permissions.

Use a static model_services list initially. The documentation recommends this option, and its membership is easier to review than a catalogue location whose available models can change with resources and grants.

Save the following template as coding-agent-config.json. It combines the documented configuration example with the documented tracing setting:

{
  "default_agent": "CODING_AGENT_CLAUDE_CODE",
  "enabled_agents": [
    {
      "agent": "CODING_AGENT_CLAUDE_CODE",
      "config": {
        "models": {
          "model_services": ["system.ai.claude-sonnet-4-6"]
        },
        "default_models": {
          "default_model": "system.ai.claude-sonnet-4-6"
        },
        "tracing": {
          "enabled": true
        }
      }
    }
  ],
  "mcp_servers": {
    "names": ["main.developer_tools.github"]
  },
  "skills": {
    "names": ["main.team_skills.code_review"]
  }
}

These resource names come from the documented example; they are not evidence that the resources exist or are approved in your workspace. Replace them with reviewed resources, and enable tracing only after completing the account-level preview and trace-table setup. The default_agent must also appear in enabled_agents.

Each agent must have exactly one model source in config.models. Compatibility matters: the documentation specifies the Anthropic Messages API for Claude Code, and the Open Responses API or OpenAI Responses API for Codex.

Publish the initial configuration with the Databricks CLI authenticated as a workspace admin:

# Initial creation only, in the intended workspace's admin session.
# Review coding-agent-config.json before publishing it.
databricks api post /api/ai-gateway/v2/coding-agent-configs \
  --json @coding-agent-config.json

Do not use this creation command as an update loop: the workspace supports one published configuration. Keep subsequent changes reviewed in version control, then publish through the documented UI or update API.

For DTAP, separate configuration rollout from permission rollout. Development, test, acceptance and production should each have explicit release criteria:

Because configuration is workspace-scoped, plan where these stages live before rollout. We recommend separate workspaces where configuration isolation is required, rather than assuming one workspace supports several simultaneously published policies.

3. Standardise developer onboarding

The official quickstart provides the installation and launch commands below. Use a clean managed-device test before distributing them.

# Prerequisites: Python 3.12 or later, uv, and approved model access.
uv tool install git+https://github.com/databricks/unity-gateway

# Record the installed version in the onboarding evidence.
ug --version

# Apply the published configuration, including managed tools and skills.
ug configure

# Run from the intended project directory.
# First use prompts for workspace selection and sign-in.
ug claude

The CLI handles the agent-specific connection settings; developers do not need bespoke endpoint-editing instructions. These are the documented installation commands, not a reproducible software-supply-chain policy: separately approve how CLI updates enter your managed-device estate.

Test a subsequent configuration change as well as first installation. Confirm normal launch picks it up, then test ug configure for immediate refresh.

4. Make authentication boundaries explicit

Document four separate boundaries: the developer signing into Unity Gateway, access to model resources, the identity used by each MCP tool, and credentials available to local agent execution. Do not assume that successful gateway sign-in establishes safe permissions everywhere else.

For each tool, record whether it uses delegated user access or a service identity, where its credential is stored and which downstream operations it permits. Prefer separate, narrowly scoped identities over reusing a deployment credential.

Run negative tests: an unauthorised developer cannot use the model; a repository tool cannot access an unapproved repository; an agent cannot merge a protected branch or deploy directly to production. Keep delivery authority in the existing pipeline, as described in our Databricks Asset Bundles CI/CD guide.

Human approval belongs before consequential actions, not merely after reviewing the final response. Require reviewed changes and deployment approvals even when an agent produces convincing explanations.

5. Establish tracing and spend ownership

An account admin first enables the Enhanced Unity Gateway preview. A metastore admin then opens Unity Gateway, selects Govern, then Traces, and sets up the trace table in the chosen catalog and schema.

The table owner must grant query access. Keep that audience narrow until you have reviewed what the collected payloads contain and established retention and incident-access procedures.

Gateway trace collection starts when unified tracing is enabled. Client-side execution details require the tracing setting and a supported launch through ug claude or ug codex; test both layers rather than assuming one proves the other works.

For spending, assign a budget owner and a process for approved exceptions. Developer visibility through ug usage requires more than installing the CLI: link the supplied budget ID through top-level smart_defaults.budget_id, enable Enhanced Unity Gateway, and use a budget with a per-user threshold and Block usage enabled. Smart defaults are Beta.

# Run after the managed configuration contains the qualifying budget.
ug configure
ug usage

This checks the developer-visible spending path, not just whether an administrator can see a dashboard. Include it in onboarding acceptance tests.

Use the Coding Agents tab in the Usage Dashboard for consumption and cost investigation, then inspect requests and traces. The usage metadata announcement adds session metadata, invocation source, token details for the 5-minute and 1-hour prompt caches, and file and web search counts. Verify the current table schema and access requirements before building queries or durable reporting dependencies.

6. Treat model retirement as a release

Inventory model lists, defaults, provider-service configurations, catalogue-based sources and any routing configuration in use. If Inkling appears in the approved model estate, assign an owner and a migration plan before 30 October 2026.

Evaluate GLM 5.3 and Kimi K3 against the affected workload, not just the retirement notice. Check agent API compatibility, tool behaviour, data-processing approval and performance on representative repository tasks.

Promote the replacement through DTAP and verify that developers receive the new configuration. Keep a separately approved alternative for failed migration tests; rolling back to a retired model is not a recovery strategy.

Pitfalls and When Not to Use It

A default is not a prohibition. Test whether developers can take unmanaged paths through local configuration, direct provider credentials or separately installed tools. Device policy and credential controls must address those paths where your risk assessment requires enforcement.

Beta observability is not complete audit evidence by assumption. Review the documented limitations, test collection failures and check what happens when an agent is not launched through the supported path. Do not grant broad trace access merely to make troubleshooting convenient.

An approved tool can still be overpowered. A centrally listed MCP server with broad downstream credentials is a concentrated risk. Review authorisation at the service receiving the action, not only at the gateway.

We would defer broad adoption where processing terms remain unresolved, required tool permissions cannot be narrowed, or mandatory audit controls depend on unverified Beta behaviour. In those cases, constrain the pilot to non-sensitive repositories and synthetic data — or keep agents disconnected from organisational tools.

Key Takeaways

1. Treat coding-agent onboarding as a platform service with reviewed configuration, ownership and a support boundary.
2. Start with explicit model lists and verify each agent’s API compatibility; configuration is not authorisation.
3. Separate developer, model, tool and deployment identities, then test denied actions.
4. Validate gateway and client-side tracing independently, and restrict access to collected payloads.
5. Complete the EU data-processing review and budget setup before granting broad access.
6. Handle Inkling’s 30 October 2026 retirement through a tested model migration, not a last-minute default change.