Unify Logo Footer.svg
AI Governance
Logo
LiveKit

LiveKit

Logo

3 mins READ

Introduction

Registering a LiveKit agent brings its runs under governance like any other framework: register, instrument, and its traces are collected from that point on. Everything downstream — policies, controls, incidents, cost, evaluation — then works exactly as it does for any other asset.

Where to find it

AI Governance > Agent Registry > Register Agent > LiveKit. Instrumentation instructions appear on the agent's Setup tab afterwards.

There is no discovery connection for this platform — LiveKit is not in + Add Application. Agents arrive by registration, not by sweep.

The flow

  1. Register the agent — Platform, name, owner. It arrives as Setup Pending.

  2. Follow the Setup tab — LiveKit setup is Python only and uses the plain OpenTelemetry SDK, with no API key. Follow the numbered steps the panel shows.

  3. Run the agent once — Status flips to Active on the first trace.

  4. Point a policy at it — Instrumentation gives observation, not governance.

Note: Register at the granularity you want to govern. A single application often runs more than one distinct agent. The registry record is simultaneously the unit of ownership, of policy coverage and of cost attribution — so if two parts of your application need different owners, different rules, or separated cost, they are two records.

What to think about for a real-time agent

Agents that operate in a live session rather than a request-response exchange raise two governance questions worth deciding before you instrument:

  1. What counts as one run? — Session, trace and span are three zoom levels, and how your instrumentation divides a live interaction determines what every downstream number means. An entire conversation as a single trace makes cost per trace and latency close to meaningless. See Sessions, Traces & Spans.

  2. Which surfaces carry the content you care about? — Controls read five points — user input, agent output, tool input, tool output and tool name. What reaches those points depends entirely on what your instrumentation emits.

Emit tool calls, not just model calls

This is the decision that determines how much governance is available to you at all. An agent reporting only its model calls produces complete-looking traces in which no tool-surface control can ever fire — and nothing warns you, because the dashboard looks healthy.

If you emit

You get

Model calls only

Cost, latency, volume. No tool governance at all

Model calls + tool calls

The full picture, including every tool-surface control

Tool results as well

Prompt-injection detection on retrieved content

One limit to be clear about

An agent registered this way is on an advisory footing: controls evaluate and record, and actions other than Flag need an enforcement point the platform provides. Prevention therefore lives inside the agent — most reliably by not giving it a tool it must never call. See Governing Vendors Without a Control API.

Troubleshooting

Symptom

Check

Stuck on Setup Pending

Has the agent run since instrumentation? Exporters fail silently, so a misconfigured deployment looks identical to an idle one

One enormous trace per conversation

An instrumentation choice, not a fault — but it flattens every per-run number. Consider a finer boundary

Traces arrive, cost does not

Token usage is not on the spans, or no rate exists for that model

Tool-surface controls never fire

Tool spans are not being emitted