Native safety profiles for agents and workflows

Status: Current | Last reviewed: 2026-10-13

Llama Guard and NVIDIA NeMo Guardrails extend the existing Agent Logic response guards and tool gates. Workflows use the same evaluator and tenant profiles. Ordinary rules, expressions and general-purpose AI judges retain their behavior. No model weights or inference service are installed by this feature.

Configure and select a policy

A tenant administrator with AIManager:ManageConfiguration creates a profile under Settings → Tenant Settings → Safety profiles. It contains the service URL, served model or NeMo configuration ID, optional bearer token, inference timeout and input-size limit. Saving appends a revision. Tokens use the managed encryption envelope with context tenant:{tenant_id}:guardrail:{profile_id}:{revision}.

Profiles live in tenant_settings under guardrail_profile:{uuid}. No migration is needed. Published agent/workflow configurations contain only a profile UUID, positive revision and optional enforce/observe mode. There is no URL, token or general-judge fallback in a binding. Disabling a profile revokes all its revisions on the next check. An update does not retarget existing bindings. Remote model deployments and NeMo configurations must also use stable names; the platform cannot freeze a server's weights or policy behind a mutable ID.

GET /api/guardrail-profiles returns non-secret selection metadata. Administrative GET/POST /api/settings/guardrails also returns editable connection fields with a masked token. Writes use an optimistic revision check and a transaction lock. Saved tokens are decrypted and re-encrypted for each new revision's context.

Try this policy calls /api/guardrail-profiles/test, which forwards the authenticated tenant to /api/v1/guardrails/test. The latter requires an agents:run token and rejects a mismatched tenant. Configure ai-manager's existing ASYNC_AGENT_URL and ASYNC_AGENT_API_TOKEN for the preview path. The service token must belong to the selected tenant; it does not grant cross-tenant impersonation. Preview checks content only and never executes an agent, workflow or business tool.

Provider contracts

Provider	Request	Accepted result
Llama Guard	OpenAI-compatible POST /v1/chat/completions, configured model, temperature 0, non-streaming, matching model chat template	Exact safe, or unsafe followed by category codes
NeMo	POST /v1/checks with messages, guardrails.config_id and explicit rail_types: ["input"] or ["output"]	PASSED, BLOCKED, or MODIFIED with string content

The NeMo adapter targets the released v0.24.1 checks API and its supported Colang 1.0 input/output rails. The server must have the requested rails configured. It does not invoke chat generation or NeMo tool rails. Tool arguments/results are submitted as content to input/output checks. Llama Guard is a content classifier; prompt-injection detection depends on an appropriately deployed NeMo policy or a separate detector. Neither provider establishes tool permission, customer identity, transaction validity or correctness of a specialist's work.

Primary protocol references:

• NeMo v0.24.1 check API
• NeMo v0.24.1 message checks
• Llama Guard 3 model card

Private HTTP/HTTPS endpoints are supported. Redirects and credentials embedded in URLs are rejected. Provider responses are bounded to 32 KiB. Oversized input is unavailable, never silently truncated and approved. The configured inference deadline is 50–10,000 ms; profile lookup/decryption also fit within a 12-second total deadline. The default inference timeout is 1,500 ms.

Enforcement boundaries

Agent config.logic.response_guards[].check accepts {"kind":"safety","binding":{"profile_id":"…","profile_version":1}}. It uses the existing replacement, redaction, regeneration, interruption and suppression actions. New safety checks default to strict failure handling; legacy guards retain their previous default. Observe mode records the result without applying the action. NeMo modified content is available to the existing Redact action; without sanitized content the normal replacement fallback applies.

Text checks happen per sentence before delivery or separate TTS. Native speech-to-speech keeps its existing transcript audit or bounded first-sentence hold behavior. Audit cannot recall already-played audio; hold does not protect every later sentence and buffer overflow retains existing fail-open behavior. This package does not add a conversational input/audio gate, image scanning or whole-conversation classification. Native response profiles require the linear agent builder. Parallel/swimlane agent builds reject them because those branches do not install this processor; they must not silently omit a required check. Workflow step/tool guards support workflow teaming independently.

Agent config.tool_logic[name].input_guard checks fully bound arguments before dispatch. output_guard checks returned content before variable captures, tool-result hooks or model delivery, including idempotent replay. Enforced unavailable checks block. Existing availability and procedure gates still apply. A withheld output does not assert that an external write failed or was undone.

Workflow settings.guardrails supports:

• input: initial parameters, event/context and iteration/review input before entry.
• output: final node results, variables and communications before graph completion.
• node_input: step-visible business state and registered tool arguments.
• node_output: step and registered-tool results before downstream delivery.

Entry/exit checks are graph nodes, so checkpoint resume does not repeat the initial entry check. Step/tool checks inherit through in-process nested graph calls; LangChain's empty-state tool adapter cannot remove that policy context. A rejection remains fatal even if an inner reasoning loop catches the tool exception. Separately queued child workflows execute their own saved policies. Foreach bodies retain parent guards even when overriding other settings; replacing an inherited profile or mode is rejected. Additional guarded boundaries are allowed.

Failures terminate the graph with a sanitized error. Completed side effects are not rolled back. Final-output checks alone cannot stop actions that occurred earlier. Choose step/tool input checks for pre-execution protection and retain downstream idempotency. These checks are not authorization or a transactional sandbox.

Runtime and validation

The provider implementation is shared in libs/logic-expressions/trueserve_logic/guardrails.py. Each runtime supplies its own database/decryption adapter. Voice checks open and close their database and HTTP connections within the calling event loop. No connection survives into another voice session's loop.

Logs record status, profile/revision, provider, categories, reason and elapsed milliseconds. Audit metadata excludes submitted text, rewritten text, credentials, URLs and provider error bodies. Sandbox evaluation refuses unmocked safety-provider calls; enforced policies therefore report unavailable in those simulations. Use the isolated policy preview to test the connection and policy.

Binding validation runs in authoring/publish and runtime preflight/graph build. The generated agent/workflow JSON schemas include these fields. No existing profile is automatically enabled on an agent or workflow.

Unconfigured boundaries make no database or inference calls. Enabled checks add their lookup and inference time; this package makes no sub-50-ms model latency claim. Workflow startup is still measured at the first useful node, after entry and step-input checks. Keep provider timing separate from request admission.

Verification covers strict classifier parsing, malformed responses, timeouts, disabled/missing revisions, tenant isolation, context-bound token decryption, response actions, tool side-effect/capture prevention, nested error propagation, graph resume and live UI autosave. Browser provider tests use a local protocol fixture, not deployed model weights.

October 13 regression measurements

The existing disposable Postgres/Redis/RabbitMQ benchmark was rerun with safety bindings absent: 200 sequential idle requests and 100 requests while four synthetic background jobs were running. This measures client-send-to-native-handler startup, not Llama Guard/NeMo inference or official ingress.

Run	Idle p95	Mixed-load p95	Mixed-load p99
Earlier startup package	17.762 ms	37.186 ms	69.220 ms
First native-guard regression run	16.299 ms	748.017 ms	1699.940 ms
Repeat after local rebuilds finished	16.357 ms	37.007 ms	38.936 ms

The first regression run overlapped local development activity and had clustered outliers. The repeat supports no observed steady-state penalty for unconfigured safety checks in this workload. Both runs are retained; this is not a hard latency SLA, an inference benchmark or a controlled production capacity comparison.

Raw measurements: first run and repeat. Reproduction: startup benchmark.