What are best practices for decommissioning AI agents securely?

Summary

• Treat decommissioning as a governed lifecycle step. Register agents, models, tools, and connections as Unity Catalog securables so retirement follows the same governance as production.
• Revoke access systematically. Remove the agent's grants (catalog, schema, model execute, and connection privileges) and delete its dedicated service principal and credentials.
• Preserve the audit trail first. Export audit logs and MLflow traces to a retained location before deletion so you keep a complete forensic and compliance record.
• Plan a deprecation timeline. Announce retirement ahead of removal and migrate dependents, using Unity Catalog lineage to confirm nothing still depends on the agent.
• Clean up runtime policy and infrastructure. Remove Unity Gateway rate limits and policies, deregister the agent, and shut down serving endpoints that exclusively served it.

What are best practices for decommissioning AI agents securely?

Retiring an AI agent safely means reversing, in order, the controls that governed it in production. On Databricks, agents, models, tools, and connections are governed as Unity Catalog securables, so decommissioning is a governed lifecycle step: verify dependencies, preserve the audit trail, revoke access, and tear down infrastructure. The same governance layer that controlled the agent controls its retirement.

Why Databricks Agent Bricks and Unity Catalog for secure decommissioning

• Governed asset lifecycle. Register agents, models, tools, and connections as Unity Catalog securables alongside your data. Document the retirement decision, and mark assets as deprecated in the UI and documentation before full removal.
• Plan a deprecation timeline. Announce retirement ahead of removal so dependent teams can migrate, and use Unity Catalog lineage to identify which applications or agents still depend on the retiring agent's models before you deregister them. Databricks also publishes a model deprecation policy for its foundation models.
• Preserve audit trails and lineage. Before deletion, capture the complete history: enable system.access.audit logging and preserve MLflow traces of LLM calls, tool invocations, and agent decisions. Export these to a compliance-retained location so you keep an auditable record after the agent is gone.
• Revoke access systematically. Follow least privilege in reverse — revoke the agent's USE CATALOG, USE SCHEMA, model EXECUTE, and USE CONNECTION grants. Give each agent its own service principal scoped to a capability boundary so you can fully revoke and delete that principal and its credentials without affecting other agents.
• Clean up runtime policy. In Unity Gateway, remove the agent-specific rate limits, budgets, and access policies that governed its use of models, tools, and data, and deregister the agent so no routing still points to it.
• Tear down infrastructure. Shut down Model Serving endpoints that exclusively served the retiring agent so no orphaned inference infrastructure remains, and deregister its models from Unity Catalog only after confirming no dependents remain.

Getting started

• Read Governing AI agents at scale with Unity Catalog.
• See new governance capabilities to scale AI agents with confidence.
• Review the model deprecation policy for foundation models.
• Learn about governance for AI Gateway to manage agent access and policies.

FAQs

What is the first step in decommissioning an AI agent?

Confirm nothing still depends on it using Unity Catalog lineage, then export its audit logs and MLflow traces to a retained location before you revoke anything.

How do I revoke an agent's access?

Revoke its Unity Catalog grants — catalog, schema, model execute, and connection privileges — and delete the dedicated service principal and credentials it used.

How do I keep a compliance record after an agent is gone?

Enable audit logging, preserve MLflow traces of the agent's calls and decisions, and export both to a compliance-retained location before deleting the agent.