Unify Logo Footer.svg
AI Governance
Logo
OpenAI Agent SDK

OpenAI Agent SDK

Logo

3 mins READ

Introduction

Registering an OpenAI Agent SDK agent brings its runs under governance the same way any other framework does. What is worth understanding first is the distinction this integration forces you to be precise about: the agent you are governing and the models it calls are separate records, and confusing them produces double-counted cost and misplaced policies.

Where to find it

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

Note: Two similarly named entries exist and they do different things. OpenAI Agent SDK registers an agent you built. OpenAI in Discovery is a connection that finds models served through your OpenAI account. One is a thing you wrote; the other is infrastructure you consume. See the OpenAI provider page.

The flow

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

  2. Follow the Setup tab — It shows "Connect <platform>" — "Instrument the agent to bring its traces in." — with a Waiting for traces… pill and numbered steps: install dependencies, point the agent at your UnifyApps endpoint (UNIFYAPPS_COLLECTOR_ENDPOINT, UNIFYAPPS_API_KEY), add credentials, initialise tracing, group traces into a session, and run the example.

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

  4. Point a policy at it — Instrumentation gives you observation. Governance needs a policy covering the asset — see Apply a Policy to Assets.

Agent and model are two records, and the difference matters

The agent record

The model record

Is

The thing you built

The thing it calls

Measured in

Traces

Spans

Owned by

Your team

Often nobody in particular

Arrives by

Registration

Import or discovery

The same spend appears against both. That is by design — two lenses on one pool of money — and it is why you must never add an agent total to a model total. See Agent View vs Model View.

What to govern on an agent like this

An SDK-built agent typically has tools, and tools are where the consequential risks live. In rough order of what earns its keep first:

  1. Blocked tools on Tool name — Deterministic and costs nothing per request. On an enforced connection it prevents the call; on an advisory one it records every attempt — see Connection Type & Control Mode.

  2. Secrets and PII on Tool input — This is the exfiltration surface — data leaving your boundary in a tool argument.

  3. Prompt injection on Tool output — Instructions hidden in content the agent fetched. Harder to think of than the user-typed variety and more likely to succeed.

  4. Output checks last — Useful, and the most expensive place to catch something, because the work is already done and paid for.

"Instrumenting an agent tells you what it did. It does not stop it doing anything. Those are two separate pieces of work and only one of them is on the Setup tab."

One limit to be clear about

You choose the tier at registration: Observe · Advisory (controls evaluate and record; only Flag takes effect) or Control · Enforced. Choose Control · Enforced only if the agent routes its calls through UnifyApps.

So prevention lives inside the agent. Do not give it a tool it must never call. See Governing Vendors Without a Control API.

If something looks wrong

Symptom

Most likely cause

Stuck on Setup Pending

The agent has not run since instrumentation, or the exporter cannot reach the endpoint from where it runs

Traces appear, cost does not

The provider did not report token usage, or no rate exists for that model. See How Cost & Tokens Are Calculated

Model calls captured, tool calls missing

Only the LLM client is instrumented. Tool spans need the SDK's own tracing

Controls never fire

Check the agent's Policies tab. An observed agent with no policy is fully instrumented and entirely ungoverned