Skip to main content
The trustguard-sdk package evaluates model traffic from Python applications. Call it before and after the model request to apply the Input and Output phases of your policy. The application can include context such as the authenticated user, tenant, and source document in each evaluation. The SDK protects only the call sites where you add it. For route-level coverage, use Python middleware. For enforcement across multiple clients, use TrustGate.

Integration capabilities

Your code enforces the verdict. Return or raise on block, and forward transformed_payload when present. Logging the verdict without changing control flow provides monitoring only.

Before you start

Create the policy in Observe mode. Observe records decisions in Activity without enforcing them. Review the results, then switch the policy to Enforce. See Policies.

1. Install

2. Guard the input

Build the client once and reuse it. Call guard() with the payload before sending it to the model, then handle the verdict:
Two parts of the example enforce the verdict:
  • if inbound.is_blocked: stop before calling the model.
  • inbound.transformed_payload or {"input": user_input}: send this value instead of the original. A DLP rule masks by rewriting the payload, and transformed_payload is null when nothing was changed, which is why the fallback is there.
consumer_id routes the request to a per-consumer policy and attributes the finding in Activity. session_id groups the turns in a conversation. Use stable identifiers already available to the application, such as the authenticated user ID and conversation ID.

3. Guard the output

The model’s response is a second evaluation, with direction="output":
Set direction on every call. It selects the detector phase: input before the model and output after it. The field defaults to input, so omitting it from the second call prevents Output-phase rules from running. The payload key remains input on an output call. Wrap the completion in the same {"input": …} shape and set direction="output".
If you stream the completion to the user, tokens have already been delivered when the assembled text becomes available for evaluation. An output-side block cannot prevent delivery. Buffer the stream until a verdict is available if the route requires preventive output enforcement. Input enforcement is unaffected.
Before deployment, handle every status and decide whether requests should proceed when TrustGuard is unreachable. See Configuration.

4. Verify

  1. Send a prompt through a guarded call site with a jailbreak rule in the policy.
  2. Confirm the event in TrustGuard Activity, under the consumer_id you sent.
  3. Reconcile the run with the console using trace_id from the response. It is the same identifier the finding carries in Activity.
In Observe mode, this prints False and the finding appears in Activity. After switching the policy to Enforce, the same call prints True.

Reference

Coverage

Use the SDK when model calls are made in Python and the policy requires application context, such as the authenticated user, tenant, or retrieved document. Use a gateway when enforcement must not depend on each call site being instrumented. ⚠️ Your application enforces the verdict. Blocking and redaction work only when your code handles the returned status and transformed payload. Tool coverage also requires a guard() call with protocol="mcp" around your tool dispatch. Limits. Coverage is per call site. Uninstrumented routes, background jobs, and services are not inspected. To protect the request path by configuration, use Python middleware, or the network with a gateway.

What is evaluated

Only call sites that invoke guard() are evaluated: protocol is also a gate and rule condition, so the same policy can treat model traffic and tool traffic differently. The default is all. payload accepts the minimal {"input": "…"} shape used throughout this page, or a full OpenAI, Anthropic, Gemini, or MCP provider body. For an MCP tools/call payload, tool.name is read from payload.params.name, so gate on that short name.

Configuration

Handle each returned status in application code. is_blocked covers one verdict; the reduced status has five values, most restrictive first: A block verdict still returns HTTP 200. TrustGuard returns a decision but does not control application traffic. The full response carries status, findings, transformed_payload, trace_id and request_id; see Evaluate API for the contract behind the client. Handle evaluation failures explicitly. Define what happens on timeouts, connection errors, and authentication failures:
Fail-closed handling stops the feature when evaluation is unavailable. Fail-open handling lets the request proceed without inspection. Choose the behavior per route and set a timeout that does not hold the application request open indefinitely. Other languages and runtimes: Node.js SDK (@neuraltrust/trustguard-sdk), the Go SDK (github.com/NeuralTrust/trustguard-sdk/go), or REST from any HTTP client. Where available, an SDK provides the client, types, and payload handling.

Attributes

Use these fields for policy routing and correlation: Include application context such as the tenant, plan tier, or role when it is needed for policy routing or conditions.

Troubleshooting