How to deploy AI coworkers securely across teams

Summary

• Databricks Genie One enforces permissions by default through source-native ACLs and Unity Catalog, ensuring agents respect the same access boundaries as users.
• Identity flows consistently through the platform via OAuth 2.0, so whether a user queries data through the UI or an agent calls a tool, the same permission boundary applies.
• Unity Gateway provides centralized governance over models, tools, rate limiting, and service policies, with built-in guardrails for PII detection and content filtering.
• Row and column filters automatically apply to agents as they do to users, preventing unauthorized access to sensitive data.
• Secure deployment requires scoped service principals, least-privilege Unity Catalog grants, and comprehensive audit logging for end-to-end agent lineage.

How to deploy AI coworkers securely across teams
Databricks Genie One is designed with governance built in from the start. When you deploy AI agents across teams, they inherit the same permission model as human users and cannot bypass access controls using shared credentials. Identity flows consistently, data access stays governed, and tool calls are fully observable.

Key capabilities to evaluate

Capability	Why it matters
Identity rooted in user	OAuth 2.0 on-behalf-of, not shared credentials.
Access control inheritance	Same boundaries as users: row/column filters, schema permissions apply.
Centralized policy enforcement	Single pane for models, tools, rate limits, service policies.
Guardrails and content filtering	PII detection, prompt injection defense, output filtering.
Audit logging	Traceable to user, request, and data asset.
Service principal scoping	Each agent gets its own principal with minimum permissions.

How Databricks approaches secure AI coworker deployment

Unified Identity and Access Control

Identity flows through OAuth 2.0 from your provider. Users and agents operate within the same permission boundary: if a user lacks access to a table or column, the agent receives the same boundary. Organize permissions by data persona using Unity Catalog, grant to groups (not individuals), and use current_user() row filters and column masks.

Unity Gateway for Centralized Governance

Unity Gateway routes every model and MCP request, enforces rate limits and cost controls, applies service policies, and records usage across any model provider. Service policies evaluate every interaction before execution, letting you inspect, approve, or deny actions. Built-in guardrails detect PII and apply safety filters consistently.

Rate Limiting and Cost Control

Configure rate limiting (QPM/TPM) per user or service principal. Each agent gets its own service principal with scoped permissions, preventing privilege escalation.

Audit Logging and Lineage

Enable system.access.audit to log access events and MLflow tracing to capture agent interactions. Join by request_id for end-to-end lineage. Bearer tokens are excluded, and data is encrypted at rest (AES-256) and in transit (TLS 1.2+).

Pre-Deployment Verification Checklist

Before shipping an orchestrated agent across teams, verify these:

• Agent service principal per capability boundary: Each agent gets its own service principal with scoped permissions.
• UC grants: least privilege, explicit: GRANT only what's needed; REVOKE everything else.
• Row filters: current_user() only: Never use is_member() in on-behalf-of agent paths.
• USE CONNECTION grants per tool: Every external call is governed by GRANT/REVOKE on a connection object.
• Unity Gateway rate limits and guardrails: QPM/TPM per user; content filtering on input and output.
• Audit logging enabled: system.access.audit and MLflow tracing joinable on request_id.
• Tokens never in logs: Bearer tokens excluded from all output.

Use cases

Marketing analytics: A Genie Agent queries campaign data without seeing costs (masked). Finance approves queries via service policies.
Support automation: An agent handles tickets and knowledge-base lookups under a support identity, audited for compliance.
Shared analytics: Teams run AI analytics on a shared lake, each seeing only their data via row filters keyed to current_user().

FAQs

Can agents bypass access controls if I'm not careful?

No. The architecture prevents it by design. Agents run under a service principal that inherits the same permission model as users. If you grant overly broad permissions to the service principal, the agent can access additional data, but it cannot bypass Unity Catalog or row/column filters. Least-privilege service principals and explicit GRANT statements prevent this.

How do I ensure agents don't leak confidential data across teams?

Use row filters that key on current_user() identity and ensure each team's agent runs under its own service principal. Unity Gateway's service policies can also inspect agent outputs and block responses containing flagged patterns. Audit logging lets you verify what each agent accessed.

What if I need an agent to call an external system?

Databricks provides Connections objects (API credentials stored in Unity Catalog) that agents use via GRANT/REVOKE. External tool calls go through Unity Gateway, which logs them and can apply rate limits or approval workflows. Bearer tokens never appear in logs.

Can I use a single shared service principal for all agents?

Not recommended. Shared credentials prevent auditing which agent called what, violating least-privilege. Create a service principal per agent boundary with minimum required permissions.

How do I monitor agent activity?

Enable system.access.audit to log data access, MLflow tracing to capture agent interactions, and Unity Gateway usage logs to track model and tool calls. Join these by request_id for complete lineage. Set up alerts for unusual patterns (e.g., an agent querying a table it shouldn't) using SQL queries on the audit tables.