Integration capabilities
Before you start
Start with the policy in Observe mode. Findings appear in Activity without
affecting traffic. Switch to Enforce after reviewing the results. See
Policies.
direction
value differs between the two calls:
1. Build the evaluate request
Use AssignMessage to construct the body. Includeprotocol, direction,
payload, consumer_id, session_id, and, optionally, attributes. Do not add
other top-level fields.
/v1/evaluate decodes strictly and rejects unknown top-level fields with 400:
payload accepts either a minimal { "input": "…" } object or a complete
OpenAI, Anthropic, or Gemini provider body. Preserve the provider body where
possible.
2. Call evaluate
Use ServiceCallout toPOST the body to {TRUSTGUARD_URL}/v1/evaluate with
the collector key as a bearer token:
3. Raise a fault on block
Use RaiseFault to return 403 whenstatus == "block". On the request
path this happens before the backend is called, so the prompt never leaves. On
the response path the completion is discarded and the caller gets the fault
instead.
/v1/evaluate returns 200 for every successful evaluation, including a block
verdict. Branch on status in the response body, not the HTTP status code.
4. Handle transform verdicts
This integration does not support redaction. Atransform verdict is recorded,
but the Shared Flow forwards the original message. Use Block rules for
enforcement rather than forwarding transformed_payload, which is not a
provider-specific request or response body.
5. Attach the Shared Flow
Attach it twice, once per direction:
With only the request attachment, completions are not inspected and Output-phase
rules do not run.
Then choose the scope:
For a limited rollout, start with a FlowCallout on one proxy. Use an environment
flow hook when you are ready to cover the environment.
6. Verify
Confirm the collector answers, using the same body the flow builds:"status": "block" and a
trace_id. Then:
- Send the same prompt through the proxy. Expect 403 from RaiseFault.
- Confirm the finding in TrustGuard Activity, under the
consumer_idyour AssignMessage set. - Match the
trace_idfrom the callout response to the one on the finding.
Reference
Coverage
The flow evaluates request and response bodies, but not streamed completions or
individual tool calls. Redaction is unsupported. With both attachments, a turn
adds two evaluation round trips.
What is evaluated
Every call is
POST /v1/evaluate with the collector
tgk_… key, and the policy’s detectors decide
the verdict. direction selects which detector phase runs, so the flow must send
it on both paths.
Verdict handling
Configuration
The evaluate body, built by AssignMessage:
Configure attachment scope with a FlowCallout for each proxy or an environment
flow hook for all proxies. The Shared Flow contains the remaining integration
configuration.
Decide what a failed callout does. If the ServiceCallout times out or errors
and the flow does not fault, the request continues without evaluation. Configure
the flow to fail open or fail closed, and monitor callout failures in either
case.
Attributes
consumer_idis the value supplied by the flow. Use the developer app or verifiedclient_idthat Apigee resolved so Activity can group events by caller.session_idgroups the turns of one conversation. Send a stable, verified value instead of an empty string.trace_idandrequest_idcome back on every evaluate response.trace_idis the join key to Activity. Log it from the flow.
consumer.id for per-caller policy, and use per-consumer policy
overrides on the collector to send different developer apps to different
policies.
Troubleshooting
Related
- Evaluate API: request and response contract for the endpoint the callout uses
- Policies: Observe and Enforce modes, including gate configuration
- Collectors: collector keys and policy resolution
- Apigee shared flows: Google reference for shared flows and flow hooks