OpenAI Agent Builder Audit Logs: The Admin API Records the Org, Not the Agent Run
OpenAI exposes an Audit Logs API that lists recent user actions and configuration changes for an organization, reached with an admin credential carrying the Audit Logs read scope. The documented surface is administrative: credential creation, user and role changes, login attempts, project modifications. Agent Builder workflows execute inside that organization, and the runs themselves sit outside the event list the Admin API publishes.
OpenAI's Admin API and its Audit Logs endpoint are built around the organization as the unit of record. The Admin APIs documentation describes automating "organization management workflows such as user invitations, audit log review, project administration, API key management, spend limits and alerts, data retention, and rate limit operations," and the audit logs endpoint exists to "list recent user actions and configuration changes for the organization." I want to walk through what that covers for a team running Agent Builder, and what a security review is left asking for.
TL;DR
- The OpenAI Audit Logs API requires an admin credential with the Audit Logs scope set to Read, and returns organization-level user actions and configuration changes.
- The documented event surface is administrative: API credential creation, user and membership changes, login attempts, project modifications, and role assignments.
- Agent Builder is in beta for API, ChatGPT Enterprise, and Edu customers, with a Global Admin Console that covers domains and SSO across multiple API organizations.
- Individual agent runs and the model calls inside them are not part of the organization audit event list, so per-run identity evidence has to come from somewhere else.
Getting at the audit log
Access runs through a scoped admin credential. OpenAI's guidance is that you create one with the Audit Logs scope set to Read and use it against the Audit Logs API, which gives security teams an immutable record of administrative activity in API Platform organizations, useful for identifying security and compliance issues, along with gaps in operational procedures.
Scoping the read credential separately from the write-capable one is the right design and it means a SIEM collector can be given exactly one permission. That is a detail worth copying in any internal tooling that pulls these logs on a schedule.
The events themselves are organizational: API credential creation, user changes, login attempts, project modifications, and role assignments. Read against an incident, the shape becomes clear. A project key was created on the 3rd, a member's role changed on the 11th, and that key was deleted on the 24th. Between those points, the organization ran production traffic that the event list does not describe.
Agent Builder sits inside that organization
Agent Builder shipped as part of AgentKit, available in beta for API, ChatGPT Enterprise, and Edu customers, with a Global Admin Console where Global Owners manage domains and SSO across multiple API organizations. The admin control panel provides access controls and audit logs at that organizational level, along with credential management.
A visual workflow builder changes who can create an agent, and it does not change what an agent is on the wire. A published Agent Builder workflow is a sequence of model calls and tool invocations, each evaluated against guardrails, executing under a project's credentials inside an organization. When that workflow fires, the organization's audit event list gains nothing, because no administrative action occurred.
The gap is not an oversight in the product. An organization audit log and a request-level authorization record are different artifacts serving different questions, and OpenAI's documentation is accurate about which one it provides. The problem arrives when a compliance program treats the first as if it were the second.
What a workflow run leaves behind
Trace a support agent built in Agent Builder. A customer message arrives through an application. The application authenticates the customer, then invokes the published workflow with a project credential. The workflow retrieves the customer's account history through a tool call, assembles a prompt, calls a model, evaluates a guardrail, and returns a response. On the wire that is a POST to the responses path on api.openai.com, with an Authorization header carrying a project-scoped bearer token and an OpenAI-Organization header naming the organization.
The project key is the only identity in that request. Nothing in it names the customer whose record entered the prompt, or the support representative who may have triggered a follow-up turn. Every execution of the workflow, for every customer, presents the same credential.
Traces in the OpenAI dashboard show the workflow's internal steps, which is genuinely useful for debugging a tool call that returned the wrong branch. A trace is developer observability tied to the run rather than to a verified principal, so it answers what the agent did and stays silent on who it did it for. This is the post-authentication gap expressed in an agent framework, and the same shape appears in OpenAI enterprise security controls more broadly.
Usage data is not audit data either
The other artifact teams reach for is the usage and costs surface, which reports token consumption by project and model. Aggregate consumption is the right tool for chargeback and capacity planning.
An aggregate cannot be decomposed into the request that carried a customer's identifiers into a prompt, because the aggregation destroyed the per-request detail by design. A spike in a project's token count on a Thursday raises a question and holds none of the evidence needed to answer it.
The record format that does answer it is described in AI audit log schema design.
Agent chains multiply the identity question
A single-turn chat application has one human per request, and an application-asserted user field is at least a plausible approximation. An agent workflow breaks that assumption. One human message triggers a chain of model calls, each shaped by the output of the previous one, several of them consuming content that arrived from an external tool.
Which of those calls is the human accountable for? All of them, if the agent was acting on their instruction. That accountability needs a record binding each call in the chain to the principal that authorized the chain, with the classification of what each call carried. Agent frameworks do not produce that record because the framework runs inside the trust boundary rather than at its edge. The tool-side risk in the same chain is covered in indirect prompt injection defense, and the data controls in OpenAI Agent Builder DLP.
DeepInspect
This is the gap DeepInspect closes. DeepInspect runs inline as a stateless proxy in front of HTTP LLM endpoints, so every call an Agent Builder workflow makes passes through a point that verifies the authenticated principal against the identity provider before the request reaches the model.
Each call in an agent chain produces a signed record carrying the named principal the chain is acting for, the role that principal holds, the classification of the content in that specific prompt, the policy version in force, and the allow-or-block decision, exportable into the same SIEM already collecting the organization audit stream. OpenAI's Audit Logs API keeps doing what it does well, giving security teams an immutable record of who changed a credential or a role. DeepInspect records what those credentials did on every request they made. Book a technical deep dive at deepinspect.ai.