How can I let developers choose their coding agent while maintaining governance?

Summary

• Decouple the tool from the policy. Let developers pick whichever coding agent they like, then require all of them to reach models through one governed gateway. Choice lives at the developer's desk; control lives at the gateway.
• Hold credentials centrally, not on laptops. Register each model provider once so the gateway injects the key at request time. Developers never handle raw API keys, and rotation or offboarding is one change instead of a scavenger hunt.
• Every request runs as the developer. A one-time sign-in ties each call to the person who made it, and access is granted with the same Unity Catalog permissions you already use for data.
• Switch models without rewiring. Agents address models by catalog name and the gateway routes to Databricks-hosted or external providers, so a team can change models or providers without touching governance.
• On Databricks, Unity Gateway is that gateway (generally available): usage tracking, cost attribution, and rate limits are GA, and guardrails plus contextual service policies add per-request screening. Confirm the current status of specific policy controls in the docs.

How can I let developers choose their coding agent while maintaining governance?

Separate the choice of tool from the enforcement of policy. Let each developer keep the coding agent they work fastest in, then require every one of those agents to reach models through a single governed gateway. The tool is a preference; the gateway is the control point. Once model and tool calls funnel through one path, identity, permissions, safety checks, rate limits, and cost tracking apply the same way no matter which agent made the call. Forcing everyone onto one tool trades away productivity; wiring each agent to its own provider key trades away control. Governing at the gateway keeps both.

Why tool choice and governance seem to conflict

Coding agents don't just answer questions, they act: they call models, invoke tools, run code, and read data on a developer's behalf. That's why a locked-down single-tool mandate frustrates engineers, while a free-for-all of personal API keys and unmanaged assistants leaks secrets and creates access no one can audit. The way out is to move the controls off the individual tools and onto the shared path all of them use, so a new agent inherits the rules instead of reopening the debate.

What to look for

Capability	Why it matters
Provider-agnostic routing	Developers point any agent at one endpoint and address models by name, so switching model or provider doesn't change the governance around it.
Central credential custody	The platform holds provider keys and injects them per request, so keys never live on laptops and rotation or offboarding is a single change.
Caller identity on every request	Each call runs as the developer who made it, not a shared service account, so access and audit map to a real person.
Permissions you already run	Granting access to a model or tool with the same catalog privileges you use for data means no parallel entitlement system.
Per-request safety checks	Screening for sensitive data, unsafe content, and prompt injection covers every agent, not the subset someone remembered to configure.

How Databricks approaches this with Unity Gateway

Unity Gateway is a governed control plane for AI traffic, generally available and built on Unity Catalog. Developers keep their own coding agent, whether a command-line tool or an IDE assistant, and point it at the gateway; every request then follows one path: resolve the caller, check authorization, apply policy and guardrails, route to a model, and log the result. See govern a coding agent's model access.

• Any provider, one endpoint. External providers are registered as model provider services, Unity Catalog securables that hold each provider's connection details and encrypted credentials. The gateway supplies the credential at request time, so a coding agent never handles a raw key, and it routes to Databricks-hosted models or external providers, including custom endpoints that expose a standard API. See model provider services and connect a coding agent.
• The developer's identity, your permissions. A one-time browser sign-in establishes the developer's identity rather than a shared API key, and to use a model or tool the caller must hold EXECUTE on that service, granted with the same Unity Catalog privileges you apply to tables and volumes. See set up AI governance.
• Runtime controls on every call. Rate limits cap token and request rates per user, endpoint, or key. Built-in guardrails screen for sensitive data, unsafe content, and jailbreak attempts, and contextual service policies can allow, deny, or require approval based on the user, agent, model, or content. These policy controls are evolving, so confirm the current availability of a specific control in the docs.
• One log for cost and audit. Usage tracking records every request in Unity Catalog system tables, so you attribute usage and cost by user, team, or application across every agent. For the wider design, see governing AI agents at scale.

Use cases

• Mixed toolchain, one policy. Different teams prefer different assistants; routing all of them through the gateway keeps one permission model and one audit trail.
• Clean offboarding. When a developer leaves, revoking their access and rotating a central credential takes effect everywhere at once, with no personal keys left behind.

FAQs

Do developers have to standardize on one coding agent?

No. Each developer can keep the agent they prefer. Governance lives at the gateway, so access rules, guardrails, rate limits, and logging apply to every agent that routes through it, whatever the vendor or harness.

How do developers avoid handling raw API keys?

External providers are registered as model provider services that hold the credentials centrally. The gateway injects the key at request time, so the agent authenticates with the developer's identity and never sees the provider secret.

Can they use non-Databricks models?

Yes. The gateway routes to Databricks-hosted and external providers alike, including custom endpoints that expose a standard API, and the same permissions, limits, guardrails, and logging apply regardless of the model a coding agent targets.