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 SDKregisters an agent you built.OpenAIin 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
Register the agent — Platform, name, owner. It arrives as
Setup Pending.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.Run the agent — Status flips to
Activeon the first trace.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:
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.
Secrets and PII on Tool input — This is the exfiltration surface — data leaving your boundary in a tool argument.
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.
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 | 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 |