The evaluation endpoints
Each endpoint serves a distinct job. They differ on two things: the input shape you send, and what you get back.
The request and response endpoints (
evaluate_request / evaluate_response) are pass-through: you send a provider-native request or response, and you get back a payload in the same provider format to forward in the live serving path. The policy returns the original (possibly redacted) payload when it allows or redacts, or a block message when it blocks. Use them for inline enforcement. An AI gateway or proxy in front of your LLM traffic typically calls these inline endpoints, forwarding the provider-native payloads it already sees.
The interaction endpoint (evaluate_interaction) is different on both axes: you submit an interaction you describe explicitly, an envelope of { metadata, interaction }, and you get back a structured outcome rather than a payload to forward. Use it instead of the inline request and response endpoints when you need:
- the actual verdict (which rules fired, the threat level, and per-message findings) to log or act on, rather than just a payload to forward;
- support for traffic that isn’t one of the supported provider formats, sent as an explicitly described interaction; or
- to evaluate out of band, outside the live request path: monitoring, replay, batch analysis, or an integration submitting a captured turn, rather than enforcing inline.
request-evaluations
Evaluate a raw provider request (input), before the model runs (inline, in the request path). It accepts provider-native request shapes only, which are auto-detected.response-evaluations
Evaluate a raw provider response (output), after the model returns. It accepts provider-native response shapes only, auto-detected. Pair a response with its request by sending the sameHL-Roundtrip-Id on both (see Agentic Sessions).
Inline request and response flow
To enforce on a live turn, wrap your model call between a request evaluation and a response evaluation:- Call
evaluate_request(...)with the provider request. - If the response carries the header
hl-runtime-action: BLOCK, the policy blocked the turn: return the returned payload (a provider response-shaped block message) without calling the model. - Otherwise forward the returned (possibly redacted) request payload to the model, not your original.
- Call
evaluate_response(...)on the model’s response. - Return the returned (possibly redacted) response payload.
hl-runtime-action response header, not by the body or the HTTP status (both endpoints return 200 even on a block). To read that header you call the endpoint through the SDK’s raw-response accessor (with_raw_response, or with_streaming_response); the plain client.runtime.evaluate_request(...) method returns only the parsed body.
Pass the correlation ids so the two evaluations reconstruct into one session: one hl_runtime_session_id for the whole workflow, and one HL-Roundtrip-Id per turn (the same value on the request and its response) via extra_headers. See Agentic Sessions for where these ids come from.
interaction-evaluations
Useinteraction-evaluations when you want to submit an interaction directly and get structured results back, rather than a provider-shaped payload to forward inline. This is the endpoint for:
- logging or acting on the policy action, threat level, detections, and per-message findings;
- evaluating captured traffic out of band, such as monitoring, replay, batch analysis, or an integration submitting a turn;
- evaluating traffic that is not one of the provider-native request or response formats accepted by the inline endpoints.
{ metadata, interaction }. The metadata object identifies the model, provider, requester, and optional external session id. The interaction can be either:
- a supported provider-native payload, such as OpenAI or Anthropic; or
- an explicitly described interaction:
messages[]with roles and typed content parts such astext,tool_use, andtool_result. (This is sometimes called the normalized interaction format in API schemas.)
interaction-evaluations; the request and response endpoints expect provider-native request or response bodies because they return provider-shaped payloads for inline forwarding. Traffic that isn’t one of the supported provider formats can be sent as an explicitly described interaction here.
Its response includes:
outcome.action:NONE,DETECT,REDACT, orBLOCK.outcome.threat_level:NONE,LOW,MEDIUM,HIGH, orCRITICAL.outcome.detections[]: each with arule_nameandrisk_level.outcome.effective_interaction: the payload to forward downstream (with any redactions or substitutions applied).evaluated_interaction.messages[].analysis.signals: the per-message signal findings.
Supported provider formats
Agentic Runtime Security accepts common LLM provider wire formats directly, plus an explicitly described interaction format forinteraction-evaluations. Provider shapes are auto-detected from the JSON body; there is no format field to set.
- OpenAI Chat Completions (request and response)
- OpenAI Responses API (request and response)
- Anthropic Messages (request and response)
interaction-evaluations.
Tool calls and agentic content
Tool calls are supported across all formats:- OpenAI:
tool_callsandrole: toolmessages. - Anthropic:
tool_useandtool_resultcontent blocks. - OpenAI Responses: function/tool calls.
- Explicitly described interaction:
tool_useandtool_resulttyped content parts.
Examples
The inline examples pass the correlation ids (hl_runtime_session_id and a per-turn HL-Roundtrip-Id) so the calls reconstruct into one session. Here session_id is created once for the workflow and roundtrip_id is generated per turn; see Agentic Sessions for details.
request-evaluations: OpenAI Chat Completions request
response-evaluations: OpenAI Chat Completions response
interaction-evaluations: explicitly described interaction
An explicitly described interaction usesmessages[] with typed content parts and no top-level model.
Next
Agentic Sessions
Correlate an agent’s many calls into one replayable session.

