IBM watsonx.ai Audit Logs and the Service ID Gap at the Foundation Model Boundary
IBM watsonx.ai routes foundation model calls through Activity Tracker Event Routing, which records the caller IAM identity, the action, and the outcome in CADF format. Most production callers authenticate as a Service ID rather than a named person, so the event records which credential made the call, not which employee or agent was behind it. This article separates the two and lists what a security review should check.
Every call to a watsonx.ai foundation model, a chat completion, a tokenization request, an embeddings call, generates an event that IBM Cloud Activity Tracker Event Routing can capture. The event carries an action name like pm-20.text-chat.send or pm-20.foundation-model.send, formatted to the Cloud Auditing Data Federation (CADF) JSON standard: an initiator ID, a target resource, an outcome, a timestamp. I want to walk through what that initiator ID actually identifies, because the answer determines whether the record a security team pulls later means what they think it means.
TL;DR
- watsonx.ai foundation model calls are logged through IBM Cloud Activity Tracker Event Routing as CADF-format events with action names such as
pm-20.text-chat.sendandpm-20.foundation-model.send. - Each event's
initiator.idfield records the IAM identity that authenticated the call, which is a person's IAM account only if a person authenticated directly. - Most production watsonx.ai traffic authenticates through a Service ID and API key, so
initiator.idresolves to the service credential, not the employee or agent behind it. - A security review needs a record that ties one foundation model call to an authenticated human or agent, not just to whichever Service ID made the request.
What Activity Tracker actually captures
IBM's watsonx.ai documentation lists the specific action names Activity Tracker Event Routing logs for foundation model activity: pm-20.foundation-model.send for inference calls, pm-20.text-tokenization.send, pm-20.text-chat.send, pm-20.text-embeddings.send, alongside CRUD events for deployments and training jobs. Each event follows the CADF structure IBM Cloud uses across its services: initiator.id for who made the call, target.name and target.id (the resource CRN) for what was acted on, action, outcome, severity, and eventTime.
That structure answers a specific question well. It tells a platform team that a text-chat.send action against a given deployment succeeded at a given minute. It was not built to answer a narrower question a security reviewer asks after the fact: which specific employee, or which specific agent acting on an employee's behalf, sent the prompt that produced that chat completion.
Service IDs authenticate the credential, not the caller
IBM's own guidance for programmatic access to watsonx.ai describes the standard pattern for machine and agent access: create a Service ID in IAM, generate an API key under it, add the Service ID as a project collaborator, and use the resulting key to obtain a bearer token for API calls. That pattern is exactly right for automating access at scale, and it is also why initiator.id in the resulting Activity Tracker event resolves to the Service ID's IAM identity rather than to a person.
A platform team building three internal applications, a claims-review assistant, a policy-drafting tool, and an internal chatbot, on top of one watsonx.ai project typically provisions one Service ID for the integration and shares its API key across all three. Activity Tracker shows that Service ID sending hundreds of text-chat.send events a day. It does not show which of the three applications, or which employee behind them, sent the specific prompt a compliance reviewer is asking about six months later. That gap sits in how Service IDs are meant to work, not in a misconfiguration.
What a review should retrieve
A useful audit pull takes one successful and one failed or denied foundation-model event by timestamp and checks four fields on each: the actual human or agent identity behind the call, the target deployment, the policy or authorization outcome, and the event time. If the only identity field available is a shared Service ID's IAM ID, that is the finding a reviewer should write down, not a detail to work around. IBM's IAM role hierarchy (Platform access roles, Service access roles, and Workspace Collaborator roles at the project and deployment-space level) governs who can provision a Service ID and add it to a project, which is a separate and useful control, but it does not change what the resulting event records once the Service ID is calling the API.
The scope here is the hosted watsonx.ai Runtime endpoint, whether reached over the public internet or through a private-network-only configuration. Models a team downloads and runs on its own infrastructure follow a different path with different logging, and conflating the two produces a review that checks the wrong system. The general version of this identity gap is what I've called the post-authentication gap: the caller authenticated cleanly, and the log still can't say who they were.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits as a stateless proxy between an authenticated user or agent and any HTTP-based LLM endpoint, watsonx.ai's foundation model API included. Before a request reaches the model, DeepInspect evaluates the identity context the calling application supplies, independent of whether that application authenticates to watsonx.ai with a personal IAM account or a shared Service ID.
The resulting audit record is a signed, per-decision entry tied to the actual authenticated principal, structured the way signed audit logs for AI requests should be, giving a security team the identity-bound record that a Service ID's Activity Tracker event was never designed to produce on its own. Activity Tracker Event Routing keeps doing its job for IBM Cloud resource-level auditing. DeepInspect adds the layer that resolves a shared credential back to the person or agent behind a specific request. Book a demo today.