Hello, monitored OpenAI

The smallest possible monitored OpenAI call. You point the OpenAI SDK at Sentisec; everything else stays as it was.

You need: a Sentisec workspace, an API key, and an OpenAI key stored under Settings → Providers, in Provider keys.

The call

curl https://api.sentisec.ch/ws/<your-workspace-id>/v1/chat/completions \
  -H "Authorization: Bearer $SENTISEC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-terra",
    "messages": [{"role": "user", "content": "Write a haiku about uptime."}]
  }'

Your Sentisec key goes in the Authorization header; your OpenAI key stays in your workspace and never enters this process.

gpt-4o, gpt-4o-mini, gpt-4-turbo, o1, and o1-mini work here too. GET /ws/<your-workspace-id>/v1/models lists what your workspace can reach.

What comes back

The response body is OpenAI's own, unchanged. A plain text completion makes no tool call, so there is no action to adjudicate:

See it in the dashboard

Open your workspace → Gateway → Requests. The request is there, and opening it shows the request and response pair. The run itself is under Sessions.

The dashboard is where verdicts live. Sentisec does not signal a block through a response header — when it stops a tool call, what changes is the tool call inside the 200 response body. The next section is how you see that.

Add a tool to see the engine work

Give the model a tool and call it again. Every tool call the model proposes is scored before it reaches you. A stopped one is withheld: it leaves tool_calls, and the message content explains why:

{
  "finish_reason": "stop",
  "message": {
    "role": "assistant",
    "content": "[Sentisec blocked tool_use: Sentisec policy blocked this tool call. …]"
  }
}

The run ends with that explanation. To let the model re-plan instead, see what happens when a tool call is blocked.

Next