Governing AI Agents: a 1.5-hour course that teaches the right foundations but is not enough for production

This course lasts only about 1.5 hours and is rated for beginners. But one lesson in the middle of the syllabus raises the question that agent demos tend to dodge: who is this agent?

Governing AI Agents is a DeepLearning.AI short course, made with Databricks and taught by Amber Roberts, Staff Technical Marketing Manager at Databricks. The course page puts the case briefly: as agents access larger and more sensitive data on their own, governance becomes mandatory.

For an FDE, that is a concern from the first day an agent touches real customer data. The short verdict: take it if you have never put an agent into production, but treat it as the first half of the skill. The other half lies outside the course.

One evening, three labs and one task worth doing properly

The course is built around four pillars: lifecycle management, risk management, security and observability. The syllabus has 11 items, including videos, 3 labs and a graded quiz. The practical work applies governance to a data analysis agent, restricting its access to sensitive data.

The only prerequisite is basic Python, so software engineers looking to move into FDE work can follow it straight away. The course page, updated on 17 July 2026, says the course is free for a limited time during the platform’s beta. That may have changed, so check before you enrol.

You do not need to memorise the names of the four pillars. The value lies in the three ideas below, and in how you carry them back to your work.

First idea: an agent needs its own identity in the permissions system

Lesson 4 is about giving an agent an identity. Picture an HR analytics agent, similar to the kind used in Lab 3, running on a shared service account with read access to the records of 200 employees.

A manager with 12 direct reports asks the agent about their team’s pay. As far as the system is concerned, the agent can still read another 188 records that the person asking is not allowed to see. No model failure is needed for a leak: a differently worded question is enough.

A Databricks blog post on Unity Catalog shows what this idea looks like in production, with a clear rule: if you cannot access a table in Unity Catalog, an agent acting on your behalf cannot access it either.

Apply that rule to the example above and the agent can no longer read those 188 surplus records.

The first thing to do at a customer: ask which account the agent will run under. If the answer is a shared account, calculate the permissions gap as in the example above and put that number on the meeting table.

Second idea: a trace is also evidence

The course defines observability as tracking an agent’s inputs, outputs and decisions, for transparency and for debugging. This is the part engineers find easiest to absorb, because it resembles familiar logging work.

Databricks goes a step further in an article on MLflow tracing: when a trace also records the permission trail that allowed each action, it becomes an audit record and not merely a debugging tool.

The difference shows when someone asks: why did the agent return this data to that person last week?

A trace with only inputs and outputs tells you what happened. A trace that adds identity and permissions also tells you who was allowed to do it. When you design logging for a customer, write out the auditor’s questions in advance, then check whether a trace can answer them.

Third idea: governance is not a checkpoint before go-live

The course presents governance across the whole lifecycle, from defining access controls to monitoring behaviour in operation. This view is worth keeping because it stops governance from becoming a final sign-off step; even the title of Lab 3 combines evaluation and deployment in one exercise.

At a customer, assign each stage an owner and a piece of evidence: who approves permissions before launch, who reviews behaviour after launch, and where both of them look. A table like that often exposes work nobody owns, and that is the risk to deal with first.

What to skip, what to add

If you already run agents in production, you can skim the concept videos and move on to Lab 3, but first check whether that lab needs results from the earlier ones.

Because both the instructor and the partner are Databricks, separate principles from product: per-user permissions and auditable traces are what you can take with you, while tool names depend on the customer’s stack.

The gap worth filling comes after the course. The Unity Catalog blog post describes each agent call being checked against policy before it runs and logged afterwards.

The post also covers registering external MCP servers such as GitHub, Jira or Slack in Unity Catalog and governing them like any other securable, a topic the course does not appear to cover.

A sensible order: take the course first, read the Unity Catalog post straight afterwards, then the MLflow trace article. After that, redo the work yourself on one of your own agents with one external tool, because this seems to be where the course stops and the real work begins.

For your career, do not turn this course into a line on your CV. The line that has value is something you have done, such as a personal project where an agent runs under the user’s permissions and every action can be traced back.

When an FDE job description mentions access control, audit or observability, ask in the interview: has the agent there touched real data yet, and who holds its permissions?

The course teaches you to ask the right questions in 1.5 hours. The next time a customer asks what the agent read and who allowed it, you should have a trace ready to open rather than a promise.