# Nyraxis documentation
Practical SDK, API, policy, testing and deployment documentation. Python SDK 1.3.2; Node SDK 1.2.9.
A completed check, measured detector accuracy, and application enforcement are separate requirements. Recipes are not a certification of every provider or framework. See the support matrix for live verification scope.
## About Nyraxis
Nyraxis helps teams monitor connected AI agent activity, evaluate policies, investigate findings, export review evidence, and retest changes.
- **AI agent red teaming**: Run selected adversarial probes against an authorized agent endpoint and inspect completed, failed, and incomplete outcomes. [Documentation](https://nyraxis.io/docs/guides/agent-testing)
- **Policy evaluation**: Evaluate text against configured checks. The application must handle completion, failure behavior, and the returned decision. [Documentation](https://nyraxis.io/docs/guides/policies)
- **Agent traces**: Inspect recorded spans and policy findings. Uninstrumented operations are outside the recorded evidence. [Documentation](https://nyraxis.io/docs/guides/traces-and-findings)
- **Regression tests and CI**: Save a specific assertion, run it against a connected agent after a change, and distinguish passed, failed, and incomplete results. [Documentation](https://nyraxis.io/docs/guides/regressions)
- **Safeguard templates**: Configure safeguard bundles for GDPR, the EU AI Act, HIPAA and SOC 2 reviews. Templates support selected technical checks and do not establish compliance or certification. [Documentation](https://nyraxis.io/docs/compliance)
- **Evidence reports**: Export PDF or CSV evidence of configured policies, recorded findings and selected audit activity. Coverage depends on recorded activity and completed checks. [Documentation](https://nyraxis.io/docs/guides/reports-and-audit)
## Scope and evidence
- Configured policy checks and passing examples do not prove general safety or compliance.
- Detector availability and integration coverage depend on the deployment and supported operations.
- Metadata-only storage does not mean evaluation text stays in the application; review processing destinations.
- The homepage examples are synthetic illustrations, not live scan results or accuracy benchmarks.
## Product resources
- [Product and hosted pricing](https://nyraxis.io/): Who Nyraxis is for, product capabilities, hosted pricing, and deployment options.
- [Quickstart](https://nyraxis.io/docs/quickstart): Connect the Python or Node client and inspect one policy decision.
- [Verified integration scope](https://nyraxis.io/docs/support-matrix): Supported operations, tested versions, and remaining integration limits.
- [Data handling](https://nyraxis.io/docs/guides/data-handling): Processing destinations, capture settings, and retention boundaries.
- [Private deployment](https://nyraxis.io/docs/guides/enterprise): Installation-specific identity, storage, model endpoints, and operating responsibilities.
- [Sample red-team report](https://nyraxis.io/sample-redteam-report.pdf): A downloadable example of scoped assessment evidence.
- [Engineering articles](https://nyraxis.io/blog): Practical guides to agent security testing, governance, and audit evidence.
- [Book a demo](https://nyraxis.io/demo): Review a synthetic workflow and discuss a scoped integration.
- [Trust center](https://nyraxis.io/trust): Privacy, security, provider integrations and processing requirements.
- [Privacy choices](https://nyraxis.io/cookies): Control optional analytics and review browser storage.
- [Legal documents](https://nyraxis.io/legal): Separate terms, privacy, cookies, acceptable use, cancellation and processing documents.
---
# Evaluation API
Source: https://nyraxis.io/docs/api-reference
Authenticate a request, submit text, and interpret the decision and completion diagnostics.
## Base URL and authentication
Send requests to your **backend API origin**, such as `https://api.nyraxis.io` or `http://127.0.0.1:8000` for local development. The frontend's `/docs` route is this documentation site, not the evaluation API.
Use an issued `ingest` key in the `X-API-Key` header. `full` also permits ingestion; `read` and `test` keys do not authorize evaluation. Dashboard session authentication is a separate path. See [keys and access](/docs/guides/api-keys).
## POST /api/v1/evaluate
```bash title="Terminal"
curl --fail-with-body "$NYRAXIS_BASE_URL/api/v1/evaluate" \
-H "X-API-Key: $NYRAXIS_API_KEY" \
-H "Content-Type: application/json" \
--data '{"input":"Demo-only internal password is DEMO-ONLY-NEVER-USE.","agent_name":"quickstart-support","capture_mode":"metadata"}'
```
Use this synthetic credential marker only. Configure the applicable Secrets Detection policy before running the request. The policy decision normally returns HTTP **200**, including `allowed: false`.
| Field | Type / default | Meaning |
| --- | --- | --- |
| `input` | Required non-empty string | Text to evaluate; required even when `output` is supplied. |
| `output` | Optional string | Proposed generated text or tool result to check before release. |
| `agent_name` | String; `"default"` when omitted | Agent identity within the key's organization. An unknown name can provision an agent, subject to quota. |
| `policies` | Optional string array | Explicit detector-type selection. Normally omit to use enabled scoped policies. |
| `mode` | `"thorough"` | `"fast"` or `"thorough"`; see [depth semantics](/docs/concepts#evaluation-depth). |
| `capture_mode` | Optional `"metadata"` or `"full"` | May reduce the organization's permitted capture level, never widen it. |
| `no_trace` | Boolean; `false` | Skip evaluation trace/span recording. Evaluation still processes submitted text. |
| `metadata` | Optional object | API-level metadata; retention is subject to the capture policy. Not all SDK methods expose this field. |
An explicit non-empty `policies` list requests those detector types with their default configuration and blocking behavior. It does **not** select configured policy IDs, inherit custom thresholds, or preserve their warning mode. Prefer omitting the field for a normal application integration. `policy_versions` can be empty for explicit ad-hoc checks.
## Interpret the response
Illustrative response shape; IDs, timings, descriptions, and versions vary:
```json title="Example response"
{
"allowed": false,
"violations": [{
"policy_type": "secrets_detection",
"severity": "critical",
"description": "Secret/credential detected in input: PASSWORD",
"details": {"location": "input", "secret_types": ["PASSWORD"]}
}],
"latency_ms": 12.4,
"mode": "thorough",
"policies_evaluated": 1,
"trace_id": "11111111-1111-4111-8111-111111111111",
"provisioned": false,
"provisioned_message": null,
"evaluation_status": "complete",
"errors": [],
"policy_versions": {"22222222-2222-4222-8222-222222222222": 1},
"capture_mode": "metadata"
}
```
For a required check, permit the next operation only when all four conditions hold:
1. `allowed` is true.
2. `evaluation_status` is `complete`.
3. `errors` is empty.
4. `policies_evaluated` is greater than zero.
A warning policy can return findings while allowing the request. A failed blocking detector can deny the request without a normal finding. Incomplete states are `degraded`, `unavailable`, and `not_configured`.
The API response is not the same as retained evidence. Metadata-only stored traces can withhold descriptions and content. Treat response diagnostics as potentially sensitive and avoid printing them wholesale.
## Errors and retry
| Status | Action |
| --- | --- |
| `401` | Check key value, revocation, and backend destination. |
| `403` | Check key scope or access; do not turn an access denial into an allow. |
| `409` | A related resource conflicts; inspect the operation before retrying. |
| `422` | Correct the request fields. |
| `429` | Respect rate limits or workspace quota; apply bounded backoff. |
| `5xx` or timeout | A required check did not authorize the operation. Return a controlled unavailable response. |
Evaluation can record evidence and consume quota. A retry may produce another trace; it is not a general exactly-once operation. Keep the protected model/tool operation outside automatic request retries.
## Telemetry ingestion
`POST /api/v1/ingest/otel` accepts OTLP/HTTP protobuf from a configured exporter using an `ingest` or `full` key. `/api/v1/ingest/otlp` is the legacy JSON ingestion path. Do not send OTLP protobuf to the JSON route. See [tracing](/docs/sdk/tracing).
## Other interfaces
| Purpose | Interface |
| --- | --- |
| Liveness | `GET /health` |
| Dependency readiness | `GET /ready` |
| Deployment-specific OpenAPI schema | Backend `/openapi.json` and `/docs`, when exposed by the operator |
| Saved Test Lab suite in CI | `POST /api/v1/testing/ci/suites/{suite_id}/run` |
| Connected-agent regression in CI | `POST /api/v1/testing/ci/regressions/{case_id}/run` |
CI uses a separate `test` key and returns a queued job receipt. See [regressions and CI](/docs/guides/regressions). UI management endpoints use authenticated, organization-scoped sessions; a read key is not a universal dashboard API credential.
---
# Policy templates and compliance scope
Source: https://nyraxis.io/docs/compliance
Reviewed safeguard bundles, required setup, and the evidence they can support.
Nyraxis provides six policy starting points. Apply a bundle from **Security Policies → Templates**, review its scope, and test its enabled checks. Reapplying a bundle reuses its existing rules for that scope and preserves your edits. Configuration-dependent tool, topic, competitor and grounded-output rules start disabled.
| Bundle | Supporting checks | Separate requirements |
| --- | --- | --- |
| GDPR safeguards | Personal-data, credential and prompt checks | Lawful basis, rights handling, DPIA, transfers, retention and processing agreements |
| HIPAA safeguards | Health-data detector option, prompt/credential checks, configurable tool access | BAA, risk analysis, access review, safeguards and verified PHI coverage |
| SOC 2 security safeguards | Runtime security checks and policy/activity evidence | Independent assurance, control design and operating-effectiveness evidence |
| EU AI Act safeguards | Runtime risk, bias signals, grounded output, prompt/credential checks | Classification, applicable obligations, data governance, documentation, oversight and assessment |
| AI Safety | Content and prompt checks | Representative safety benchmarks and source context |
| Enterprise Chatbot | Content, data and configurable domain checks | Topic/competitor configuration, source context and integration verification |
Templates do not establish compliance, certification, clinical safety or a complete legal control system. A detector error is an incomplete check. A passed probe describes only its tested scope. Model availability and measured accuracy are separate questions.
## What the templates actually establish
The bundle names describe the review they can support. They are not complete,
article-by-article implementations of the named laws or assurance frameworks.
For example, toxicity and bias checks in the GDPR bundle are optional application
safeguards; GDPR does not prescribe those detectors or their thresholds.
The current PII implementation does not use a generic `entities` list as an
entity filter. Templates use supported settings; verify languages, identifier
types, false positives and missed cases with representative permitted data.
Grounded-output template rules require approved policy `sources` and an `output`
before they can complete. Configure and test them before enabling them. The new
template default sets `require_sources: true`; it does not automatically treat a
user's question as factual evidence. Known source/output truncation is reported
as incomplete. See [grounded-output scope](/docs/providers/hallucination).
Template revision **2026-10-19.1** changes newly created rules. Existing policies
are not silently rewritten. Review existing source-dependent rules separately;
reapplying a bundle preserves their settings and enabled state.
## Reports and organizational obligations
The PDF/CSV export is a shared operational evidence report. It is not a complete
GDPR assessment, a SOC 2 auditor's report, a HIPAA approval or an EU AI Act
conformity assessment. Selected or bounded audit records are not complete
statutory logging. Your review must also cover contracts, access, processing
destinations, retention, rights handling, incident procedures and any applicable
organizational obligations.
Having these templates does not establish that Nyraxis itself is GDPR compliant.
Review the actual service agreement, provider schedule and deployment evidence
through the [trust center](/trust).
## Reviewed sources
- [GDPR Articles 5, 25 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng): data principles, protection by design, and processing security.
- [HHS HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html): administrative, physical and technical safeguards.
- [AICPA Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022): assessment framework for relevant controls.
- [EU AI Act consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727): review Articles 9–15 alongside system classification and your applicable role. Metadata-only records are not a complete statutory logging solution.
Sources and implementation scope reviewed on 19 October 2026. The mappings are engineering interpretations for supporting controls. Applicability requires a separate assessment.
Read [the evidence guide](/docs/guides/compliance) and [integration support](/docs/support-matrix) before using real workload data.
---
# Core concepts
Source: https://nyraxis.io/docs/concepts
Understand agents, policies, decisions, traces, and the limits of enforcement.
## Agents and organizations
An organization owns its agents, policies, API keys, and evidence. Select the correct workspace before configuring a key or policy. An agent represents an application or service; its name is unique within that organization.
Use the same agent name in your SDK configuration and policy scope. SDK ingestion can discover an agent, but registering it first makes the intended scope clear. Agent creation is subject to workspace limits.
## Policies
A policy combines a detector type, configuration, an enabled state, and a scope. It applies to all agents in the organization or a selected set.
| Mode | When a finding or a failed required check occurs |
| --- | --- |
| `warning` | Evaluation can allow the operation while returning findings or diagnostics. |
| `blocking` | Evaluation denies the operation. The application or supported interceptor must stop it. |
A policy edit creates a version. Record the versions returned by evaluation when comparing a retest. The `policies` request field is a list of detector **types**, not policy IDs; omit it for normal configured-policy evaluation. The [API reference](/docs/api-reference) explains the explicit-selection behavior.
## Decisions and completion are separate
```text
Request → applicable policies → detectors → allowed + violations + completion
↓
your application decides what to release
```
| `evaluation_status` | Meaning |
| --- | --- |
| `complete` | The selected evaluations completed. Inspect findings and the decision. |
| `degraded` | Some coverage is reduced or incomplete. Inspect `errors`. |
| `unavailable` | A selected check could not run. |
| `not_configured` | No applicable check ran. Enable and scope a policy. |
For a required check, release content only when `allowed` is true, status is `complete`, `errors` is empty, and `policies_evaluated` is greater than zero. An allowed warning decision can still contain findings.
## Evaluation depth
The API accepts `mode: "thorough"` or `"fast"`. This field is distinct from policy warning/blocking and Node's wrapper behavior. The current direct-evaluation route uses the same policy selection for both depth values; `fast` is not a documented shortcut that skips required checks or guarantees lower latency. Prompt Injection also has its own `config.detection_mode` setting.
## Traces and spans
A trace groups an interaction. Spans describe model, tool, retrieval, and other work within it. Direct evaluation normally records an evaluation trace; `no_trace` disables that recording. Supported pre-call SDK checks use `no_trace` and need separately configured instrumentation for model-call traces.
A parent `trace()` groups instrumented work; it does not instrument every operation automatically. Model token counts and other attributes depend on the instrumentor. [Tracing](/docs/sdk/tracing) covers export, privacy, and shutdown.
## What enforcement can stop
A supported input check happens before a model request. To stop unsafe generated content, evaluate a buffered answer before returning it. To stop a side-effecting tool, authorize it before execution. Checking a recorded tool span or a tool's result happens too late to prevent that tool from running.
See [enforcement](/docs/guides/auto-enforce), [streaming](/docs/sdk/tracing#streaming), and [data handling](/docs/guides/data-handling).
---
# Test a connected agent
Source: https://nyraxis.io/docs/guides/agent-testing
Configure an HTTP target, run a bounded assessment, and inspect the evidence.
## Two kinds of test
**Direct evaluation** checks text submitted to Nyraxis. **Connected-agent testing** calls your configured agent endpoint and records how that target responds to probes. Use the second path when you want to test the agent's actual model, tools, prompts, and runtime guards together.
Use an owned development target and synthetic records. A scan can invoke the target repeatedly and consume model or tool resources. Set a bounded probe scope and avoid tools with uncontrolled side effects.
## Connect the target
Open **Agents**, select the agent, and open **Connection**. Choose a preset or configure the request manually:
| Setting | Purpose |
| --- | --- |
| Endpoint URL | The target's chat/request endpoint. |
| Connection mode | Stateless, session-based, or conversation ID, according to your target's contract. |
| Authentication | The target's own authorization method; separate from the Nyraxis ingest key. |
| Body template | Maps test input into the target's request body. |
| Response path | Extracts the text response from the target's JSON. |
A stateless body template for a target accepting an `input` string is:
```json title="Body template"
{"input": "replace-with-test-input"}
```
In the connection editor, replace that value with the editor's `{{input}}` placeholder **without JSON quotes**: `{"input": {{input}}}`. Template substitution JSON-encodes the input. For a JSON response `{"output":"reply"}`, set the response path to `output`.
Run the connection test. Confirm the target is reachable from the **worker network**, not only from your browser. Private-network and loopback access is deployment-controlled; the local QA fixture's network allowance is not a general cloud feature.
## Run an assessment
Open **Security → Red Team**, select the connected agent, choose an assessment mode and bounded probe configuration, then submit. A queue receipt means the job was accepted, not that the target passed.
Inspect queued, running, completed, failed, cancelled, or incomplete states. A failed target call or unavailable judge must not be interpreted as a safe response. Some strategies use model-backed generation or judging and require separate configured provider access.
## Read findings
Review the target, probe, response evidence available under capture policy, severity, and assessment scope. Counts describe the probes run in that assessment. A safe-response rate is not a general security score, and an interrupted run can contain only partial evidence.
Save an accepted finding as an agent regression, make a change, and rerun it. The [regression guide](/docs/guides/regressions) explains assertions and CI.
## Share evidence
Use the scan history and available report download. Verify the compared target/probe configuration, policy versions, incomplete checks, and retained content before sharing. Synthetic fixture results demonstrate that fixture; they are not a certification of another agent or production deployment.
---
# API keys and access
Source: https://nyraxis.io/docs/guides/api-keys
Create the right key for evaluation, telemetry, or CI without exposing credentials.
## Create an application key
Select the intended organization in the dashboard, then open **API Keys → Create API Key**. Choose a name that identifies the application and environment. For SDK evaluation and OTLP export, use **ingest** scope.
The full value is shown at creation. Copy it to your deployment's secret store. Do not paste it into docs examples, source control, frontend environment variables, screenshots, or logs.
## Scope boundaries
| Scope | Intended access |
| --- | --- |
| `ingest` | Evaluation and supported ingestion; also accepted by explicitly API-key-readable read endpoints. |
| `test` | CI submission and polling for saved Test Lab suites and connected-agent regressions. |
| `read` | Read endpoints that explicitly support API keys; does not authorize evaluation or ingestion. |
| `full` | All API-key capability groups; reserve for applications that actually need them. |
Keys belong to an organization. An ingest key is not restricted to one agent just because a client sets `agent_name`. Agent-specific policy scope is a separate setting. Dashboard management remains session- and role-controlled.
## Configure the server
```bash title="Environment variable names"
export NYRAXIS_API_KEY="your-issued-ingest-key"
export NYRAXIS_BASE_URL="https://api.nyraxis.io"
```
Use the actual backend origin for self-hosted deployments. Never prefix the key with `NEXT_PUBLIC_` or send it to a browser. The model provider's key is a separate credential.
## Rotate a key
1. Create a replacement with the required scope.
2. Update the application's secret store and restart or reload its client configuration.
3. Verify an evaluation and telemetry receipt from that application.
4. Revoke the old key in the dashboard.
5. Verify the revoked value is rejected. Remove it from active configuration.
Use separate development and production keys. Keep CI test keys separate from agent ingest keys. Revoking a key does not remove existing traces.
## Diagnose access failures
A `401` can indicate a missing, invalid, or revoked key. A `403` can indicate insufficient scope. Confirm that you are contacting the backend attached to the organization in which the key was issued. Do not retry a denied operation with fail-open behavior.
Continue with the [quickstart](/docs/quickstart) or [evaluation API](/docs/api-reference).
---
# Enforcement
Source: https://nyraxis.io/docs/guides/auto-enforce
Choose failure behavior and understand exactly where an SDK check can stop a call.
Pre-call enforcement evaluates extracted input before a supported model method makes its provider request. It does not authorize arbitrary tools or inspect every generated token. Configure and test each boundary deliberately.
## Python setup
```python title="Application startup"
import os
import nyraxis_sdk
nyraxis_sdk.init(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
agent_name="support-agent",
enforce=True,
enforce_fail_open=False,
enforce_require_complete=True,
enforce_timeout_s=15,
enforce_cache_ttl_s=0,
)
```
Call `shutdown()` when synchronous application work ends, or await `shutdown_async()` in an asynchronous lifecycle. Choose the timeout from your actual backend latency; 15 seconds above is a configuration example, not a response-time guarantee.
## Supported methods
| Package | Implemented input interception |
| --- | --- |
| Python `openai` | Supported Chat Completions, legacy Completions, and Responses create paths, including covered async variants. |
| Python `anthropic` | Supported Messages create methods, including covered async variants. |
| Python LangChain | Supported `BaseChatModel.invoke` / `ainvoke` text extraction; verify your concrete provider and streaming path. |
| Node OpenAI | `enforce(client, options)` wraps supported OpenAI Chat Completions, Completions, and Responses create paths. |
| Other providers/frameworks | Use explicit evaluation at the application boundary. Native interception is not implied. |
These are implementation boundaries, not a claim that every SDK version, modality, structured tool message, or method is covered. [Integration coverage](/docs/support-matrix) identifies the live verified subset. System/developer prompts and unsupported image/audio content are not automatically covered by the text extractors.
## Handle outcomes
```python title="Gate a supported model call"
from openai import OpenAI
import nyraxis_sdk
model = OpenAI()
def reply(message: str) -> str:
try:
response = model.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": message}],
)
return response.choices[0].message.content or ""
except nyraxis_sdk.NyraxisBlockedError:
return "This request was blocked by the configured policy."
```
This function assumes the startup configuration above has already run. Network, invalid-response, and incomplete-check errors must be handled by your service's unavailable path; they must not continue to a second unguarded model call.
## Fail-open and completion settings
| Configuration | Effect |
| --- | --- |
| `enforce_fail_open=True` | Genuine evaluator transport failures may let the provider call proceed. This is the Python compatibility default. |
| `enforce_fail_open=False` | Transport failure propagates and stops the intercepted call. |
| `enforce_require_complete=True` | An allowed result with incomplete status or errors is rejected. |
| `enforce_cache_ttl_s=0` | Always get a fresh decision; useful for policy-edit retests. |
Fail-closed transport behavior alone does not require a complete detector result. Set both options for required checks. A malformed decision or explicit access denial is not a transport fail-open decision.
## Warning versus monitoring
A configured warning policy can report a finding and allow the request. A blocking policy denies it. Node additionally has wrapper `behavior: "monitor"`, which does not enforce the returned decision; keep that separate from backend policy mode and API depth. Python tracing without `enforce=True` observes calls but does not install input enforcement.
## Tool and output boundaries
The [LangGraph example](/docs/integrations/langgraph) explicitly checks a read-only tool's result before feeding it back to the model. That check cannot prevent the lookup itself. Authorize a side-effecting tool before execution.
To prevent disclosure in a generated answer, buffer it, call `evaluate(input=..., output=...)`, validate completion, and return it only if allowed. Checking after streaming has sent tokens is observation, not prevention.
## Measure and test
Count actual provider calls for allowed, blocked, incomplete, unavailable, cached, and malformed-response cases. Repeat after a policy change with caching disabled. Measure warm and cold latency with your network and selected detectors; there is no universal overhead figure for all deployments.
---
# Local SDK rehearsal
Source: https://nyraxis.io/docs/guides/candidate-pilot
Run the repository’s synthetic SDK lifecycle rehearsal without treating it as a live-model benchmark.
The backend repository includes a self-contained Python support rehearsal at `sdk/python/examples/support_pilot`. It exercises decisions, error handling, streaming lifecycle, and an owned local telemetry receiver. Its model and evaluator are scripted fixtures; use the separate [LangGraph guide](/docs/integrations/langgraph) for a real model/tool integration.
## Get the example
Check out the backend revision that matches the SDK release and read `sdk/python/examples/support_pilot/README.md`. The scripts are shipped in that repository; no privately supplied release-owner file or historical development wheel is required by this guide.
Use Nyraxis Python SDK **1.3.2**, not a similarly named package. The SDK reference version is 1.3.2; use a supported Python interpreter such as Python 3.12. Create a dedicated virtual environment and install the example's documented dependencies. For approved offline use, prepare a complete compatible wheelhouse and verify release artifact hashes against your release process.
## What it verifies
The runner uses synthetic support records and local HTTP fixtures. It checks complete allows, blocks, incomplete and malformed decisions, access denial, model failure, early stream closure, and sync/async cleanup. The configured OpenTelemetry receiver checks actual exported parent/child spans.
Read the runner's emitted result and exit code. The recorded rehearsal's expected 14 scenarios and six mock model operations are fixture acceptance criteria, not a customer accuracy or performance benchmark.
## Move to a live integration
1. Create a real organization-scoped ingest key and an enabled agent-scoped Secrets policy.
2. Run the [quickstart](/docs/quickstart) against your actual backend.
3. Use the live LangGraph example with your model-provider key.
4. Count provider operations in warning, blocking, unavailable, and input-block cases.
5. Inspect actual stored traces and capture behavior.
The published SDK's availability does not certify every provider, framework, operating system, or deployment. See [coverage](/docs/support-matrix).
---
# Policies and compliance evidence
Source: https://nyraxis.io/docs/guides/compliance
Use scoped policy results as evidence for your team's review.
Nyraxis can help your team inspect AI-agent behavior and record policy findings. A template, scan or private deployment does not establish regulatory compliance or provide a SOC 2 assurance report.
## Start with a specific control
Choose the behavior you want to inspect, identify where enforcement happens, and test it with safe and unsafe synthetic examples.
| Starting point | What to verify | Limit |
|---|---|---|
| PII detection | A literal synthetic identifier triggers the expected policy, and safe text behaves as expected | Detection depends on the configured recognizers, language and entity types |
| Prompt injection | Your selected probes exercise the relevant input boundary | A passing probe set cannot prove resistance to all attacks |
| Tool authorization | The application checks the decision before invoking a restricted tool | Recording a tool span after execution cannot prevent that execution |
| Warning versus blocking | The application implements the intended action for both modes | An allowed decision may still include warnings or incomplete checks |
Use [the quickstart](/docs/quickstart) to configure a blocking Secrets detection policy. Review [integration scope](/docs/support-matrix) before extending it to your framework.
## Explain the data boundary
Evaluation processes submitted text at the configured Nyraxis API. Model-backed detectors and judges may process it at separately configured endpoints. Storage settings do not change those evaluation destinations.
Current capture settings support metadata-only storage by default. Organization administrators control the permitted capture level; individual requests may reduce capture. Check your deployed version and workspace settings before using real workload data.
Metadata-only traces do not retain the original prompt for replay. Resubmit the prompt for a retest, or explicitly permit capture. Content that was stored by an older release needs its own reviewed retention and migration process.
## Prepare useful evidence
Record the tested agent and target, probe set, policy scope and version, detector/model versions, test time, findings and any incomplete or excluded checks. Review the actual contents of each exported report before sharing it.
Traces cover the calls your integration records. Current audit-log records must not be described as immutable without a verified tamper-resistance mechanism. A finding is a reason to investigate; a clean result describes the checks that completed.
## Compliance and private deployment
SOC assurance involves an assessment and report from an appropriate CPA firm. Product settings and generated reports are supporting material, not that assurance. See the [AICPA SOC overview](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services).
Private deployment lets a customer define data location, access and approved endpoints. Its network-egress and operating controls must be verified in that deployment. AWS documents the division of cloud security responsibilities in its [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).
For a pilot, agree the workflow, permitted data, supported integration, control owner, evidence requirements and review date. Evaluate any GDPR, HIPAA, ISO 27001 or other obligations with the people responsible for that assessment; this guide does not map product features to legal compliance.
---
# Workspace and agents
Source: https://nyraxis.io/docs/guides/dashboard
Create an organization, register an agent, and follow its activity through the dashboard.
## Enter the right workspace
Sign in, create or select an organization, and confirm the organization switcher before creating resources. Agents, policies, keys and evidence belong to that organization. Use **Settings → Organization** to manage the workspace, members and invitations according to your role.
Public documentation and the marketing playground do not require the dashboard session. Application management does. A public SDK ingest key is not a substitute for your dashboard login.
## Register an agent
Open **Agents**, create a named agent and record its framework and intended purpose. Use the same name in your SDK client. Unknown names can be auto-provisioned by evaluation, but registering deliberately makes policy scope and ownership easier to review.
The agent detail page contains **Overview**, **Connection**, **Scans** and **Traces**. A connection is needed when Nyraxis must call your agent for assessment. It is separate from an SDK that sends evaluations or spans to Nyraxis.
## Connect the workflow
1. [Create an ingest key](/docs/guides/api-keys).
2. [Configure one scoped policy](/docs/guides/policies).
3. [Run the first evaluation](/docs/quickstart).
4. [Inspect traces and findings](/docs/guides/traces-and-findings).
5. [Connect and assess the actual agent](/docs/guides/agent-testing).
6. [Save and repeat a regression](/docs/guides/regressions).
## Read the overview carefully
The dashboard summarizes recorded activity, agents and findings in the selected workspace. Empty activity can mean no data arrived; a loading or service error is different from an empty workspace. Verify an individual evaluation and trace before relying on a summary count.
Use separate development and production organizations or a reviewed equivalent separation. Confirm a resource’s scope before deleting it or changing a shared policy. Administrative writes depend on the current organization role; inability to edit is not fixed by exposing an API key in the browser.
---
# Data handling
Source: https://nyraxis.io/docs/guides/data-handling
Understand evaluation destinations, telemetry content, capture settings, and retained evidence.
## Processing and storage are different
Evaluation sends the submitted input and optional output to the configured Nyraxis API. A detector or judge may process that content at another configured model endpoint. A metadata-only storage setting does not remove these processing steps or promise zero network egress.
Keep synthetic data in initial tests. Review your evaluator, model, telemetry, alert, and export destinations before using workload content.
## Capture settings
Organization settings establish the capture ceiling. Requests may restrict capture further; they cannot opt into full content when the organization permits only metadata.
| Setting | What it controls |
| --- | --- |
| Organization `capture_mode: "metadata"` | Retains allowed technical evidence while withholding workload content fields. |
| Organization `capture_mode: "full"` | Permits retained content for applicable records; individual requests can still reduce it. |
| Request `capture_mode: "metadata"` | Restricts that evaluation's stored content. |
| Request `no_trace: true` | Suppresses that evaluation's trace recording, while evaluation and other operational accounting still occur. |
| Python `instrument_capture_content=False` | Requests suppression of prompt/completion attributes in supported instrumentation. |
These controls have different purposes. For example, instrumentation suppression does not stop direct evaluation from sending text, and `no_trace` is not a promise that no operational record exists anywhere.
## What a metadata-only trace can show
Depending on the operation and instrumentor, evidence can include agent and trace IDs, timings, status, model identity, token counts, findings counts, and policy versions. Names derived from prompts may become generic operation labels. Retained violation descriptions and details can be withheld or reduced.
Do not expect the original prompt or tool arguments to be recoverable from metadata-only records. A retest needs new input or a deliberately retained regression payload under the application's data policy.
## Reports and alerts
Review an exported report before sharing it. Export behavior follows current capture rules, and older stored content may need a separate retention or remediation process. Policy mode changes do not retroactively change old evaluation outcomes.
For webhook or Slack delivery, review the recipient, configuration, and actual delivered fields. Retention, alert delivery, storage capture, and external processor destinations are independent operational controls.
## Rollout checklist
- Record approved API, model/judge, OTLP, alert, and report destinations.
- Confirm capture mode and which roles can change it.
- Inspect actual traces and exports for content fields using synthetic markers.
- Establish retention and deletion procedures for current and historical records.
- Verify the integration's error logging does not print prompts, credentials, or raw API error bodies.
See [self-hosted operations](/docs/guides/enterprise) and [compliance evidence](/docs/guides/compliance) for related scope.
---
# Self-hosted operations
Source: https://nyraxis.io/docs/guides/enterprise
Agree hosting, access, processing destinations, operating responsibilities and acceptance for a private deployment.
## Deployment components
A private installation includes application access, evaluation processing, data storage and background work. Agree the architecture and approved processing destinations with the deployment team. Version-specific infrastructure, model provisioning and migration instructions belong in the operator deployment package.
A private deployment defines where services run; it does not by itself guarantee zero egress, unlimited capacity, certification, or a particular availability level.
## Configure deliberately
| Concern | Operational requirement |
| --- | --- |
| Database | Define data ownership, authenticated access, encrypted connections and capacity. |
| Frontend/backend | Set the public app origin and backend origin consistently. Route authenticated management calls to the correct API. |
| Secrets | Keep auth/encryption secrets stable and inject service credentials through an approved secret store. |
| Background work | Verify queued evaluations, recovery, cancellation and operator responsibilities. |
| Migrations | Use the version-specific operator procedure and rehearse backup, migration and rollback. |
| Detectors | Install required models/dependencies or configure approved provider endpoints before declaring readiness. |
| Licenses/limits | Verify the deployment's actual entitlement, quotas, and any enabled license controls. |
Obtain the maintained operator package for your release before installation. Public SDK documentation is not a complete infrastructure runbook.
## Verify the environment
Check `/health` and `/ready`, then run a scoped SDK evaluation, exporter receipt check, queued Test Lab case, and connected-target regression. Inspect failure and recovery paths, including detector unavailability and worker restart.
A green Secrets check is not broad detector readiness. A response from the frontend is not proof that queued work can execute. OAuth/SSO and billing require their own configuration and acceptance tests.
## Egress and retention
Inventory all model, judge, telemetry, alert, authentication, and payment destinations. Self-hosting does not automatically disable external services. Review capture settings, retention, backup access, report sharing, and historical content. See [data handling](/docs/guides/data-handling).
## Latency and capacity
Measure the actual deployed regions, database round-trip time, cold connections, detector startup, concurrency, and model calls. Reuse connection pools and inspect query plans. Local benchmarks and controlled added-delay tests cannot certify a remote database deployment.
## Release acceptance
Agree the supported integration/version, permitted data, target network access, failure policy, operator responsibilities, backup/recovery procedure, and acceptance criteria. Policy templates support engineering review; they do not establish regulatory certification. [Compliance evidence](/docs/guides/compliance) explains that boundary.
For deployment planning, [contact the team](/demo).
---
# Build and operate
Source: https://nyraxis.io/docs/guides
Take an agent from its first key to repeatable tests and operational evidence.
Start with [workspace and agents](/docs/guides/dashboard) for the full dashboard journey.
## Connect and protect
1. [Create and rotate an API key](/docs/guides/api-keys).
2. [Configure a scoped policy](/docs/guides/policies).
3. [Choose explicit enforcement behavior](/docs/guides/auto-enforce).
4. [Review processing and capture settings](/docs/guides/data-handling).
## Test and retest
Connect your own reachable agent in [Agent Testing](/docs/guides/agent-testing), turn a finding into a [regression](/docs/guides/regressions), and run the supported CI workflow. Use the [SDK pilot](/docs/guides/candidate-pilot) to rehearse package lifecycle behavior separately from real-provider testing.
## Operate and review
Use [troubleshooting](/docs/guides/troubleshooting) to distinguish slow requests, missing traces and incomplete detectors. The [self-hosting guide](/docs/guides/enterprise) describes deployment dependencies and readiness. [Compliance evidence](/docs/guides/compliance) explains what results can support; [policy templates](/docs/compliance) describe each starting bundle’s boundaries.
## Inspect and administer
- [Playground evaluation](/docs/guides/playground)
- [Traces and findings](/docs/guides/traces-and-findings)
- [Reports and audit evidence](/docs/guides/reports-and-audit)
- [Settings, alerts and retention](/docs/guides/workspace-settings)
---
# Playground evaluation
Source: https://nyraxis.io/docs/guides/playground
Inspect a direct policy decision before connecting a complete agent.
## Choose the playground
The public website playground is a bounded demonstration. **Dashboard → Playground** evaluates submitted input and optional output using the selected organization agent. Neither path runs your complete agent automatically.
For application acceptance, use the authenticated playground first, then repeat through the real SDK/API and [connected-agent tests](/docs/guides/agent-testing).
## Evaluate synthetic text
1. Register an agent and configure an enabled scoped policy.
2. Open **Playground** and select that agent.
3. Enter a safe synthetic input. Optionally supply the proposed model output.
4. Submit and inspect the decision, completion state, policy count, findings, latency and trace link when available.
5. Replace the input with `Demo-only internal password is DEMO-ONLY-NEVER-USE.` under a Secrets detection policy, then compare warning and blocking behavior.
The built-in example buttons populate text; they do not download required detector models or certify their readiness. An incomplete evaluation must remain distinct from a completed allowed result.
## Interpret the boundary
A blocking playground decision does not prove that your deployed application stops its provider or tool call. Add [an application gate](/docs/guides/auto-enforce) and verify actual call counts. When testing output, the `input` field remains required.
The reported evaluation latency is not the browser’s full loading time, and it excludes unrelated model generation by your application. Use [latency troubleshooting](/docs/guides/troubleshooting#slow-dashboard-or-evaluation-requests) when measuring the complete journey.
Use synthetic data. Processing destinations and retained evidence depend on [data-handling settings](/docs/guides/data-handling), even when text was entered manually in a browser.
---
# Configure policies
Source: https://nyraxis.io/docs/guides/policies
Choose a detector, scope it to an agent, and verify warning and blocking behavior.
## Start with one measurable check
Use **Security → Policies** to create an enabled policy. For a model-independent first test, select **Secrets Detection**. Give it a recognizable name, choose its agent scope, and select Warning or Blocking.
Avoid beginning with every detector enabled. Model-backed checks can be unavailable, and an unrelated blocking policy can prevent a request while you are testing another rule.
## Scope and configuration
A policy applies either to the selected agents or to all agents in its organization. Make sure the application's `agent_name` resolves to the intended agent. Each provider guide lists the actual configuration keys; adding an unknown JSON field does not establish that the detector honors it.
[Browse all 16 policy types](/docs/providers). Configuration-dependent template policies may start disabled until topics, competitors, tool access, or other prerequisites are supplied.
## Warning to blocking
1. Evaluate a safe synthetic message and confirm a complete evaluation.
2. Evaluate `Demo-only internal password is DEMO-ONLY-NEVER-USE.` with the scoped Secrets policy in Warning mode.
3. Inspect the finding. A warning decision can still be `allowed: true`.
4. Edit the same policy to Blocking and save the new version.
5. Repeat with SDK decision caching disabled. Confirm `allowed: false` and verify the application stops the protected operation.
The same text alone is not a complete acceptance test. Include your own benign and adversarial examples and inspect incomplete checks separately.
## Versioned evidence
Keep the returned `policy_versions` with your test record. A new policy version affects future evaluations; historical traces still describe their original execution. Explicit ad-hoc `policies` requests do not provide the same configured-policy version relationship.
## Templates
Templates are starting configurations, not certifications. Review each rule and agent scope before applying. Reapplying a template preserves existing scoped policy edits rather than silently replacing them. See [template scope](/docs/compliance).
## Roll out deliberately
Choose the integration's transport failure behavior, required completion behavior, and output/tool boundaries before enabling blocking in a production workflow. A dashboard policy is effective only where your integration enforces its returned decision.
---
# Regressions and CI
Source: https://nyraxis.io/docs/guides/regressions
Save a finding as a repeatable check and keep failed or incomplete runs out of a release gate.
## Agent regression versus Test Lab
A **connected-agent regression** sends an input to a configured agent target and checks the returned result against an assertion. A **Test Lab suite** evaluates its saved policy cases. Choose the path that matches the behavior you need to retest.
A passing policy case does not prove a deployed agent enforced that decision. A passing agent regression proves only its saved assertion against the executed target/configuration.
## Save and retest a finding
1. Inspect a finding from a completed assessment.
2. Choose **Save as agent regression** and name the behavior.
3. Review the saved input and explicit assertion, such as text that must not appear in the response.
4. Run it against the connected target and inspect the result.
5. Change the policy or application, save the new version, and rerun the same case.
For a synthetic password disclosure, assert that `DEMO-ONLY-NEVER-USE` must not appear. A controlled refusal can satisfy that specific assertion; it does not prove that every tool was authorized or that all output is safe.
Metadata-only trace storage is not a recoverable prompt archive. Review what the regression creation flow deliberately retains, and supply missing input when needed.
## Read run status
| State | Interpretation |
| --- | --- |
| Queued / running | Work has not produced a final assertion result. |
| Passed | The completed run satisfied the saved assertion. |
| Failed assertion | The target ran, but the assertion was not satisfied. |
| Incomplete / failed job | The target, detector, worker, or assertion evaluation could not complete. |
Never treat a missing run, empty suite, timeout, or unavailable detector as a passing release gate.
## Run from CI
Create a separate **test**-scoped key. The backend repository includes `scripts/nyraxis_ci.py`, which submits a saved suite or regression, polls the durable job, and emits a metadata-only summary.
```bash title="From the backend repository"
python -m pip install httpx
python scripts/nyraxis_ci.py --help
```
Use `--suite-id` or `--regression-id` with the saved UUID and `--base-url` with your backend origin. Set `NYRAXIS_API_KEY` through CI secret injection. Confirm the exact available options with `--help` for the checkout you deploy.
| CLI exit code | Meaning |
| --- | --- |
| `0` | Completed passing run. |
| `1` | Completed assertion failures or regressions. |
| `2` | Incomplete run, invalid receipt, service/access error, or timeout. |
The CI API lives under `/api/v1/testing/ci`. Suite and regression submission use different paths, and each has its own job-polling endpoint. Do not use a dashboard session endpoint with the test key.
## Retries and workers
Submission supports a bounded `Idempotency-Key`. Reuse the same request identifier when recovering the same submission; use a new identifier for an intentional new run. A receipt identifies a job, never a clean evaluation result. Inspect history after an uncertain response before triggering more target operations.
Keep the workload worker, dispatcher, scheduler, database, and Redis healthy. See [operations](/docs/guides/enterprise) and [troubleshooting](/docs/guides/troubleshooting).
---
# Reports and audit evidence
Source: https://nyraxis.io/docs/guides/reports-and-audit
Export a defined scope and explain exactly what the records demonstrate.
## Generate an evidence report
Open **Reports**, select the report period, and request **PDF** or **CSV**. The UI offers 7, 30, 90 and 365-day periods. The report covers available agent inventory, configured policies, recorded violations, scan findings and selected administrative audit records.
If generation fails, preserve the selected period and retry the download. The **Recent download requests** list describes requests in that page session, not a durable proof that a recipient received or reviewed a file. Times are displayed in UTC.
## Review before sharing
Check the organization, selected period, tested target, detector readiness, policy versions and any incomplete or excluded checks. Inspect the actual file for sensitive content and capture-policy behavior. A report documents available recorded scope; it does not establish a certification, independent assurance or exhaustive coverage of your application.
Scan-specific evidence is also available from the assessment workflow. [Connected-agent testing](/docs/guides/agent-testing) explains the difference between a queue receipt, completed scan and finding.
## Use the audit log
Open **Audit Log** to inspect recorded organization actions, resource types, resource IDs and timestamps. The CSV action exports the rows currently loaded in the page; paginate when reviewing additional records. Do not describe the page’s current-row download as a complete organization archive.
Audit records are administrative evidence. Their presence does not establish immutability, tamper resistance or a complete history of every external tool operation. Define any additional audit retention/export controls in your deployment.
## Keep a useful review package
Keep the report, its period and generation time, the relevant trace/scan/regression IDs, policy versions and a short statement of tested boundaries. Retention and capture settings can limit what historical content remains. See [compliance evidence](/docs/guides/compliance), [policy templates](/docs/compliance) and [data handling](/docs/guides/data-handling).
---
# Traces and findings
Source: https://nyraxis.io/docs/guides/traces-and-findings
Inspect recorded execution, distinguish completion from safety, and triage a violation.
## Find a trace
Open **Traces** in the correct organization. Use the available agent, time and status filters, refresh if necessary, and select a trace. A trace list can contain direct evaluations and instrumented application activity; they represent different execution boundaries.
The detail view shows retained execution metadata, span relationships and findings. Input/output may be absent by design under metadata-only capture. A model span is useful evidence of an instrumented call; an evaluation trace alone does not prove a provider request happened.
## Check completion before interpreting the decision
Inspect the evaluation completion status, errors and applicable policy count. **Unknown**, **degraded**, **unavailable** or **not configured** must not be relabelled as safe. An allowed warning can still contain a violation, while an unavailable blocking detector can deny without a normal positive finding.
Use trace comparison for the same tested behavior after a change. Check target, input availability, policy versions, timestamps and integration version so that the comparison has a meaningful common scope.
## Triage a finding
Open **Violations**, filter the relevant policy/severity/status and inspect the associated trace. The workflow supports **open**, **acknowledged**, **resolved** and **false positive** states. Record an appropriate resolution note without adding customer secrets to the record.
Acknowledging or resolving a violation changes its triage state. It does not change the policy, rerun the application or establish remediation. Reproduce the behavior, make the change, and run a saved [regression](/docs/guides/regressions) before treating the issue as fixed.
## Export and retain
The trace list offers JSON/CSV export for its selected filters. Inspect exported scope and fields before sharing; a filtered export is not an unlimited archive. Metadata-only exports should not be expected to contain replayable prompt text.
Use [reports and audit evidence](/docs/guides/reports-and-audit) for a broader workspace review. For missing records, check [instrumentation and receipt](/docs/sdk/tracing) and [processing/capture limits](/docs/guides/data-handling).
---
# Troubleshooting
Source: https://nyraxis.io/docs/guides/troubleshooting
Diagnose access errors, incomplete evaluations, missing traces, and slow loading.
## Start with the result, not only the status code
A successful HTTP response can still describe a blocked, degraded, unavailable, or unconfigured evaluation. Inspect `allowed`, `evaluation_status`, `errors`, and `policies_evaluated` together.
| Symptom | Check | Next action |
| --- | --- | --- |
| `not_configured` | Enabled policies and agent scope | Create or enable the intended policy; repeat with the same agent name. |
| `allowed: true` with findings | Policy Warning mode or wrapper monitoring | Confirm intended behavior before switching to blocking. |
| Denied with no normal finding | Failed blocking detector | Inspect `errors`; restore the missing detector dependency. |
| `401` / `403` | Key destination, validity, revocation, scope | Use an ingest key for evaluation; a test key is for CI. |
| `429` | Request limits and organization quota | Back off within a bounded retry budget or adjust the entitled capacity. |
| Missing trace | `no_trace`, instrumentor, exporter, capture mode | Verify actual backend receipt after flushing. |
| Generic span names or no prompt | Metadata-only capture | Expected when content retention is disabled; resubmit input for a retest. |
| SDK timeout | Cold detector/model load, network, database | Measure each layer; configure a timeout that matches the required failure behavior. |
## Liveness and readiness
```bash title="Health checks"
curl --fail-with-body "$NYRAXIS_BASE_URL/health"
curl --fail-with-body "$NYRAXIS_BASE_URL/ready"
```
`/health` indicates that the API process responds. `/ready` checks deployment dependencies and can return **503** when broad detector readiness is unavailable, even if storage, background processing and Secrets Detection are usable. Inspect the returned checks; do not substitute liveness for readiness.
## Model-backed detectors
Check installed dependencies, model files, approved download access, configured remote endpoints, and provider credentials. A limited check does not establish complete contextual coverage. A healthy provider status is also not an accuracy benchmark.
Use Secrets Detection for a deterministic synthetic first evaluation. Enable additional detectors one at a time, then measure them with representative safe and unsafe examples.
## Slow dashboard or evaluation requests
Separate browser rendering, frontend authentication/proxy time, backend authorization and audit writes, database queries, model loading, and actual provider execution. Measure cold and warm requests and inspect a percentile distribution under bounded concurrency.
Place the application and database in appropriate nearby regions, reuse connection pools, verify TLS, and inspect PostgreSQL query plans before changing indexes. Never remove current membership checks, weaken TLS, or turn an evaluator failure into an allow to improve a timing result.
The workspace's local and injected-delay measurements are engineering evidence for those conditions, not a promise for your cloud database or network.
## Scans remain queued
Confirm workload and dispatcher workers consume their configured queues, the scheduler is running, and lease/recovery tasks can reach the database and Redis. The target must be reachable from that worker network. Inspect the persisted job before retrying; an uncertain external call may already have reached the target.
## Search or documentation problems
Use the docs search button or Ctrl/⌘ K. If search is unavailable, retry or use the sidebar. Code blocks and wide tables scroll within their own panels on a narrow screen. The [plain-text documentation](/llms.txt) provides another navigation entry point.
## Report a useful issue
Record the app/SDK version, operation, timestamp, trace/job ID, selected policy versions, status, and sanitized error code. Exclude API keys, cookies, request bodies, credentials, and real customer content. A synthetic reproducer is preferable.
---
# Settings, alerts and retention
Source: https://nyraxis.io/docs/guides/workspace-settings
Understand account, organization and platform configuration boundaries.
## Choose the correct settings scope
| Section | Purpose |
| --- | --- |
| Account | Your profile and account lifecycle. |
| Security | Supported enterprise SSO configuration. |
| Organization | Workspace details, members, invitations and organization selection. |
| Platform | Alert settings, delivery history and trace-retention configuration. |
| Billing | Subscription and payment-provider workflows when configured. |
| Licenses | Deployment licensing and entitlement information. |
Organization writes depend on your current membership role. Review the active organization before saving shared configuration. Account deletion, member removal and resource deletion have different consequences; do not use them as a troubleshooting reset.
## Configure alert delivery
Use **Settings → Platform** to review alert settings and delivery history. Configure only destinations your team controls. Generate a bounded synthetic event and inspect its actual delivery status. Saving a destination is not proof that network delivery succeeded or that a message was read.
Review alert payloads for sensitive fields and confirm what your capture settings permit. Failed delivery and an absent delivery record must not be treated as a successful notification. Self-hosted workers need approved network access to configured destinations.
## Set retention deliberately
The **Data Retention** panel accepts a retention period in days. A saved retention value is configuration; actual cleanup depends on the deployment’s retention worker/scheduler and operator settings. Verify cleanup in the running deployment before promising a deletion schedule.
Changing capture or retention settings does not retroactively prove that older records or external exports were removed. Agree what happens to existing evidence and backups separately. See [data handling](/docs/guides/data-handling).
## Identity, billing and licensing
SSO requires an actual identity-provider registration, valid issuer/client configuration and a complete redirect/login test. Payment flows require the deployed payment provider, webhook processing and the intended entitlement result. License settings require the operator’s configured licensing service or process.
The local documentation/browser checks do not certify those external integrations. Verify each against the identity, billing and licensing environments you intend to ship. Use [deployment guidance](/docs/guides/enterprise) for operational prerequisites and [API-key rotation](/docs/guides/api-keys) for application credentials.
---
# Build security into your agent
Source: https://nyraxis.io/docs
Connect your application, evaluate a policy, and turn findings into repeatable tests.
Nyraxis gives engineering teams a place to check agent inputs and outputs, investigate traces, and retest a change. Start with one policy and a synthetic record. Expand coverage after you can explain the result.
## The engineering workflow
**Connect → evaluate → inspect → change → retest.**
1. Register an agent and choose its policies.
2. Evaluate synthetic safe and unsafe examples before a model call or before releasing its output.
3. Inspect the decision, completion status, policy versions, and any recorded trace.
4. Adjust the policy or application behavior.
5. Run the same example again. For connected agents, save an accepted finding as a regression.
A completed check describes the content and policies tested. It does not prove resistance to every attack. An unavailable detector is an incomplete check, even if no finding was returned.
## Choose your integration
| Your application | Start here |
| --- | --- |
| Python service | [Python SDK](/docs/sdk/python) |
| Node.js or TypeScript service | [Node.js SDK](/docs/sdk/node) |
| LangGraph or LangChain agent | [LangGraph](/docs/integrations/langgraph) · [LangChain](/docs/integrations/langchain) |
| Any service with HTTP access | [Evaluation API](/docs/api-reference) |
| Existing deployed agent endpoint | [Agent testing](/docs/guides/agent-testing) |
See [integration coverage](/docs/support-matrix) for verified paths and recipe-only integrations. The reference versions are Python **1.3.2** and Node.js **1.2.9**.
## Know where the boundary is
- **Evaluation** returns a decision. Your application must act on it.
- **Pre-call enforcement** can stop supported model methods before the provider request.
- **Observation** records operations through telemetry. It cannot undo an operation that already ran.
- **Storage** determines what is retained. Metadata-only storage still sends the submitted text to the evaluator.
Continue with [core concepts](/docs/concepts), [data handling](/docs/guides/data-handling), or the [policy reference](/docs/providers).
---
# Anthropic
Source: https://nyraxis.io/docs/integrations/anthropic
Evaluate input before Anthropic runs and buffer output for a second decision.
Recipe: the native Anthropic call in this page has not been certified against a live Anthropic account. Choose a model available to your account.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 anthropic
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Anthropic
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from anthropic import Anthropic
from nyraxis_gate import guarded_text_call
model = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
def generate(prompt):
response = model.messages.create(
model=os.environ["ANTHROPIC_MODEL"], max_tokens=256,
messages=[{"role": "user", "content": prompt}],
)
return "\n".join(block.text for block in response.content if block.type == "text")
print(guarded_text_call("What are your support hours?", generate))
```
The provider API follows its [upstream documentation](https://github.com/anthropics/anthropic-sdk-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# AutoGen
Source: https://nyraxis.io/docs/integrations/autogen
Evaluate input before AutoGen runs and buffer output for a second decision.
Recipe: targets the AgentChat package family, not legacy pyautogen APIs. The synchronous wrapper runs in a CLI without an existing event loop. For async servers use an async evaluation boundary; do not call asyncio.run inside an active loop.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 autogen-agentchat autogen-ext[openai]
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect AutoGen
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import asyncio
import os
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient
from nyraxis_gate import guarded_text_call
async def run_agent(prompt):
model = OpenAIChatCompletionClient(model=os.environ["OPENAI_MODEL"])
try:
agent = AssistantAgent("support", model_client=model)
result = await agent.run(task=prompt)
text = result.messages[-1].content
if not isinstance(text, str):
raise TypeError("Expected a final text message")
return text
finally:
await model.close()
def generate(prompt):
return asyncio.run(run_agent(prompt))
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://microsoft.github.io/autogen/stable/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# AWS Bedrock
Source: https://nyraxis.io/docs/integrations/aws-bedrock
Evaluate input before AWS Bedrock runs and buffer output for a second decision.
Recipe for Converse-compatible models. Configure AWS credentials through the normal boto3 chain and grant the required model permission. IAM authorization and AWS guardrails are separate from this Nyraxis text gate.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 boto3
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect AWS Bedrock
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
import boto3
from nyraxis_gate import guarded_text_call
model = boto3.client("bedrock-runtime", region_name=os.environ["AWS_REGION"])
def generate(prompt):
result = model.converse(modelId=os.environ["BEDROCK_MODEL_ID"], messages=[{"role": "user", "content": [{"text": prompt}]}])
return "\n".join(block["text"] for block in result["output"]["message"]["content"] if "text" in block)
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/bedrock-runtime/client/converse.html). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Azure OpenAI
Source: https://nyraxis.io/docs/integrations/azure-openai
Evaluate input before Azure OpenAI runs and buffer output for a second decision.
Recipe: use your deployment name and an API version supported by that deployment. The public OpenAI live test does not certify Azure networking, identity or model deployment settings.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Azure OpenAI
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from openai import AzureOpenAI
from nyraxis_gate import guarded_text_call
model = AzureOpenAI(api_key=os.environ["AZURE_OPENAI_API_KEY"], azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"], api_version=os.environ["AZURE_OPENAI_API_VERSION"])
def generate(prompt):
result = model.chat.completions.create(model=os.environ["AZURE_OPENAI_DEPLOYMENT"], messages=[{"role": "user", "content": prompt}])
return result.choices[0].message.content or ""
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Cohere
Source: https://nyraxis.io/docs/integrations/cohere
Evaluate input before Cohere runs and buffer output for a second decision.
Recipe for Cohere’s V2 chat API. It does not claim coverage of legacy generate APIs, rerank, embeddings or tool calls.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 cohere
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Cohere
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
import cohere
from nyraxis_gate import guarded_text_call
model = cohere.ClientV2(api_key=os.environ["COHERE_API_KEY"])
def generate(prompt):
result = model.chat(model=os.environ["COHERE_MODEL"], messages=[{"role": "user", "content": prompt}])
return "\n".join(block.text for block in result.message.content if block.type == "text")
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://github.com/cohere-ai/cohere-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# CrewAI
Source: https://nyraxis.io/docs/integrations/crewai
Evaluate input before CrewAI runs and buffer output for a second decision.
Recipe: configure CrewAI’s model credentials and pin a supported framework version. This wraps the complete crew run; delegation, memory and tool side effects inside the crew need independent permissions and gates.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 crewai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect CrewAI
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
from crewai import Agent, Crew, Task
from nyraxis_gate import guarded_text_call
agent = Agent(role="Support writer", goal="Answer the supplied support question", backstory="You write short answers.", allow_delegation=False)
def generate(prompt):
task = Task(description=prompt, expected_output="A short support answer", agent=agent)
result = Crew(agents=[agent], tasks=[task]).kickoff()
return result.raw
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://docs.crewai.com/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Django
Source: https://nyraxis.io/docs/integrations/django
Gate an application-owned request and buffered model response in Django.
This is a server integration recipe. Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis_gate.py](/examples/nyraxis_gate.py) in your application’s import path.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai Django
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL` and `OPENAI_API_KEY` on the server. Put this view in your Django application, map `/chat` to `chat`, and send requests with your application’s normal session and CSRF protections. Do not disable CSRF to make the example work. Configure upstream body limits as well as Django request limits.
```python
import json
from django.http import JsonResponse
from django.views.decorators.http import require_POST
from openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI()
def generate(prompt):
result = model.chat.completions.create(model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}])
return result.choices[0].message.content or ""
@require_POST
def chat(request):
if len(request.body) > 16 * 1024:
return JsonResponse({"error": "Request too large"}, status=413)
try:
body = json.loads(request.body)
except (ValueError, UnicodeDecodeError):
return JsonResponse({"error": "Invalid JSON"}, status=400)
text = body.get("input") if isinstance(body, dict) else None
if not isinstance(text, str) or not text.strip() or len(text) > 4000:
return JsonResponse({"error": "Provide 1–4000 characters"}, status=400)
try:
return JsonResponse({"output": guarded_text_call(text, generate)})
except PermissionError:
return JsonResponse({"error": "Policy blocked this request"}, status=403)
except Exception:
return JsonResponse({"error": "Required check or model unavailable"}, status=503)
```
## Verify and deploy
The helper requires a complete applicable evaluation, checks input before the provider call, and checks buffered output before release. Test malformed requests, a safe request, synthetic Secrets detection input/output, and an unavailable Nyraxis API. Verify that blocked input makes no provider request.
Keep authentication, authorization, rate limits, upstream request limits and production timeouts in your application. Returning a public error must not log raw prompts or credentials. Review the [framework documentation](https://docs.djangoproject.com/) for deployment and [data handling](/docs/guides/data-handling) for processing/capture settings.
---
# DSPy
Source: https://nyraxis.io/docs/integrations/dspy
Evaluate input before DSPy runs and buffer output for a second decision.
Recipe: set DSPY_MODEL to a model identifier supported by your DSPy provider (for example an OpenAI model identifier). Optimizers may create additional model calls and training records; this final boundary does not govern those automatically.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 dspy
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect DSPy
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
import dspy
from nyraxis_gate import guarded_text_call
dspy.configure(lm=dspy.LM(os.environ["DSPY_MODEL"], api_key=os.environ["OPENAI_API_KEY"]))
predict = dspy.Predict("question -> answer")
def generate(prompt):
return str(predict(question=prompt).answer)
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://dspy.ai/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Express
Source: https://nyraxis.io/docs/integrations/express
Validate a server request, evaluate input, and gate a buffered OpenAI response.
This server recipe uses Node SDK 1.2.9 and Express. Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis-gate.mjs](/examples/nyraxis-gate.mjs) beside `server.mjs`.
```bash
npm install express openai @nyraxis/sdk@1.2.9
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL` and `OPENAI_API_KEY`. Run the following with `node server.mjs`.
```javascript
import express from "express";
import OpenAI from "openai";
import { requireAllowed } from "./nyraxis-gate.mjs";
const app = express();
const model = new OpenAI();
app.use(express.json({ limit: "16kb" }));
app.post("/chat", async (req, res) => {
const input = req.body?.input;
if (typeof input !== "string" || !input.trim() || input.length > 4000) {
return res.status(400).json({ error: "Provide 1–4000 characters" });
}
try {
await requireAllowed({ input });
const answer = await model.chat.completions.create({
model: process.env.OPENAI_MODEL || "gpt-4o-mini",
messages: [{ role: "user", content: input }],
});
const output = answer.choices[0].message.content || "";
await requireAllowed({ input, output });
return res.json({ output });
} catch (error) {
return res.status(error.name === "PolicyBlocked" ? 403 : 503)
.json({ error: error.name === "PolicyBlocked" ? "Policy blocked this request" : "Required check or model unavailable" });
}
});
app.listen(8080, "127.0.0.1");
```
Test malformed input, safe text, synthetic blocked input, blocked output and Nyraxis failure. Confirm blocked input causes zero provider requests. This is a localhost recipe; add application authentication, authorization, rate limits and deployment logging before exposing it publicly. Do not log secrets or raw workload text in error handlers.
See [Node SDK](/docs/sdk/node), [upstream Express docs](https://expressjs.com/) and [capture settings](/docs/guides/data-handling).
---
# Fireworks AI
Source: https://nyraxis.io/docs/integrations/fireworks
Put an explicit Nyraxis text gate around an OpenAI-compatible Fireworks AI call.
This is an integration recipe. The live OpenAI test does not certify a Fireworks AI account, model or compatibility edge case.
## Install and configure
Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside `example.py`.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL`, `FIREWORKS_API_KEY` and `FIREWORKS_MODEL`. Select a model available to your provider account.
```python
import os
from openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI(base_url="https://api.fireworks.ai/inference/v1", api_key=os.environ["FIREWORKS_API_KEY"])
def generate(prompt):
result = model.chat.completions.create(
model=os.environ["FIREWORKS_MODEL"],
messages=[{"role": "user", "content": prompt}],
)
return result.choices[0].message.content or ""
print(guarded_text_call("Explain how to contact support.", generate))
```
The helper checks input before this call and buffered output before returning. Incomplete evaluations and blocked text raise errors. Run safe, blocked-input, blocked-output and unreachable-Nyraxis cases, and verify actual provider-call counts.
Review [provider documentation](https://docs.fireworks.ai/) for request compatibility. Text evaluation does not authorize tools or inspect multimodal content. Streaming requires its own release boundary; do not send tokens to a user and then expect a final check to retract them.
See [SDK coverage](/docs/support-matrix), [Python client](/docs/sdk/python) and [data handling](/docs/guides/data-handling).
---
# Flask
Source: https://nyraxis.io/docs/integrations/flask
Gate an application-owned request and buffered model response in Flask.
This is a server integration recipe. Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis_gate.py](/examples/nyraxis_gate.py) in your application’s import path.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai Flask
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL` and `OPENAI_API_KEY` on the server. Save as `app.py` and run `flask --app app run --host 127.0.0.1 --port 8080` for local verification. Use a production WSGI server for deployment.
```python
from flask import Flask, jsonify, request
from openai import OpenAI
from nyraxis_gate import guarded_text_call
app = Flask(__name__)
app.config["MAX_CONTENT_LENGTH"] = 16 * 1024
model = OpenAI()
def generate(prompt):
answer = model.chat.completions.create(model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}])
return answer.choices[0].message.content or ""
@app.post("/chat")
def chat():
body = request.get_json(silent=True)
text = body.get("input") if isinstance(body, dict) else None
if not isinstance(text, str) or not text.strip() or len(text) > 4000:
return jsonify(error="Provide 1–4000 characters"), 400
try:
return jsonify(output=guarded_text_call(text, generate))
except PermissionError:
return jsonify(error="Policy blocked this request"), 403
except Exception:
return jsonify(error="Required check or model unavailable"), 503
```
## Verify and deploy
The helper requires a complete applicable evaluation, checks input before the provider call, and checks buffered output before release. Test malformed requests, a safe request, synthetic Secrets detection input/output, and an unavailable Nyraxis API. Verify that blocked input makes no provider request.
Keep authentication, authorization, rate limits, upstream request limits and production timeouts in your application. Returning a public error must not log raw prompts or credentials. Review the [framework documentation](https://flask.palletsprojects.com/) for deployment and [data handling](/docs/guides/data-handling) for processing/capture settings.
---
# Google Gemini
Source: https://nyraxis.io/docs/integrations/google-gemini
Evaluate input before Google Gemini runs and buffer output for a second decision.
Recipe for google-genai. Text gates do not inspect image, video or audio payloads; configure a separate multimodal boundary where required.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 google-genai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Google Gemini
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from google import genai
from nyraxis_gate import guarded_text_call
model = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
try:
def generate(prompt):
result = model.models.generate_content(model=os.environ["GEMINI_MODEL"], contents=prompt)
return result.text or ""
print(guarded_text_call("Explain how to contact support.", generate))
finally:
model.close()
```
The provider API follows its [upstream documentation](https://github.com/googleapis/python-genai). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Groq
Source: https://nyraxis.io/docs/integrations/groq
Put an explicit Nyraxis text gate around an OpenAI-compatible Groq call.
This is an integration recipe. The live OpenAI test does not certify a Groq account, model or compatibility edge case.
## Install and configure
Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside `example.py`.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL`, `GROQ_API_KEY` and `GROQ_MODEL`. Select a model available to your provider account.
```python
import os
from openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI(base_url="https://api.groq.com/openai/v1", api_key=os.environ["GROQ_API_KEY"])
def generate(prompt):
result = model.chat.completions.create(
model=os.environ["GROQ_MODEL"],
messages=[{"role": "user", "content": prompt}],
)
return result.choices[0].message.content or ""
print(guarded_text_call("Explain how to contact support.", generate))
```
The helper checks input before this call and buffered output before returning. Incomplete evaluations and blocked text raise errors. Run safe, blocked-input, blocked-output and unreachable-Nyraxis cases, and verify actual provider-call counts.
Review [provider documentation](https://console.groq.com/docs/openai) for request compatibility. Text evaluation does not authorize tools or inspect multimodal content. Streaming requires its own release boundary; do not send tokens to a user and then expect a final check to retract them.
See [SDK coverage](/docs/support-matrix), [Python client](/docs/sdk/python) and [data handling](/docs/guides/data-handling).
---
# Haystack
Source: https://nyraxis.io/docs/integrations/haystack
Evaluate input before Haystack runs and buffer output for a second decision.
Recipe for haystack-ai, not the older farm-haystack API. With a Pipeline, place gates around the exact generator and user-visible answer. Pipeline execution does not automatically become an intercepted SDK call.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 haystack-ai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Haystack
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from haystack.components.generators import OpenAIGenerator
from nyraxis_gate import guarded_text_call
model = OpenAIGenerator(model=os.environ["OPENAI_MODEL"])
def generate(prompt):
result = model.run(prompt=prompt)
return result["replies"][0]
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://docs.haystack.deepset.ai/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Integration recipes
Source: https://nyraxis.io/docs/integrations
Connect your provider or framework at an explicit application boundary.
Use the SDK to check input before a protected operation and buffered output before release. A recipe is an implementation starting point; live verification is listed separately in [the support matrix](/docs/support-matrix).
Integration names identify services you can connect from your application. They are not a list of Nyraxis’s internal detector engines or active subprocessors. Review [hosted service providers](/subprocessors) and your selected processing destinations separately.
## Start with a verified journey
A real OpenAI call, read-only tool, input enforcement, tool-result check, final-output gate and persisted traces.
Download the complete input/output gate used by the Python recipes.
Download a server-side gate that distinguishes blocking from incomplete evaluations.
## Choose a provider or framework
- [OpenAI](/docs/integrations/openai)
- [Anthropic](/docs/integrations/anthropic)
- [LangChain](/docs/integrations/langchain)
- [LangGraph agent journey](/docs/integrations/langgraph)
- [LlamaIndex](/docs/integrations/llamaindex)
- [Vercel AI SDK](/docs/integrations/vercel-ai)
- [CrewAI](/docs/integrations/crewai)
- [AutoGen](/docs/integrations/autogen)
- [Semantic Kernel](/docs/integrations/semantic-kernel)
- [Haystack](/docs/integrations/haystack)
- [DSPy](/docs/integrations/dspy)
- [Mistral AI](/docs/integrations/mistral)
- [Cohere](/docs/integrations/cohere)
- [Google Gemini](/docs/integrations/google-gemini)
- [AWS Bedrock](/docs/integrations/aws-bedrock)
- [Azure OpenAI](/docs/integrations/azure-openai)
- [Groq](/docs/integrations/groq)
- [Together AI](/docs/integrations/together-ai)
- [Fireworks AI](/docs/integrations/fireworks)
- [Replicate](/docs/integrations/replicate)
- [Ollama](/docs/integrations/ollama)
- [Express](/docs/integrations/express)
- [Flask](/docs/integrations/flask)
- [Django](/docs/integrations/django)
The reusable helpers default to the `docs-integration` agent. Set `NYRAXIS_AGENT_NAME` to select another configured agent without editing the helper.
## Acceptance for your application
Configure the correct agent policy scope, pin provider versions, test safe and blocked input/output, simulate an unavailable check, and count actual provider requests. Add permissions before tools with side effects. A trace receipt, recipe or successful import does not establish enforcement for every call in a framework.
---
# LangChain
Source: https://nyraxis.io/docs/integrations/langchain
Evaluate input before LangChain runs and buffer output for a second decision.
The live LangGraph journey exercised ChatOpenAI and real provider requests. This boundary checks submitted text; intermediate chain steps need their own gates.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 langchain-openai==1.7.2
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect LangChain
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from langchain_openai import ChatOpenAI
from nyraxis_gate import guarded_text_call
model = ChatOpenAI(model=os.getenv("OPENAI_MODEL", "gpt-4o-mini"), http_socket_options=())
def generate(prompt):
message = model.invoke(prompt)
if not isinstance(message.content, str):
raise TypeError("Convert and review multimodal blocks explicitly")
return message.content
print(guarded_text_call("What are your support hours?", generate))
```
The provider API follows its [upstream documentation](https://docs.langchain.com/oss/python/langchain/overview). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# LangGraph agent journey
Source: https://nyraxis.io/docs/integrations/langgraph
Run a real model, a read-only tool, input enforcement and explicit output gates.
The support-agent example was exercised with real OpenAI credentials using `langgraph==1.2.15`, `langchain-openai==1.7.2` and `nyraxis-sdk==1.3.2`. It has no fixture fallback. Its records and secret marker are synthetic.
## Prepare the environment
Configure the `langgraph-live-support` agent with a **Secrets detection** policy. Begin with just this deterministic policy so unavailable model-backed detectors do not obscure the test. Use an ingest key in a development organization.
```bash
python -m venv .venv
source .venv/bin/activate
python -m pip install "nyraxis-sdk[instrument]==1.3.2" langgraph==1.2.15 langchain-openai==1.7.2
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL` and `OPENAI_API_KEY` through your secret manager or shell. `OPENAI_MODEL` defaults to `gpt-4o-mini`. Download [langgraph_support.py](/examples/langgraph_support.py) into your working directory. The file contains the complete graph, tracing, tool, gates, counters and cleanup.
## Understand the graph
1. A supported intercepted ChatOpenAI call selects `lookup_demo_record`.
2. The graph validates the selected tool name and runs a read-only lookup.
3. An explicit evaluation checks the tool’s text before passing it to the second model call.
4. A second model call creates the answer.
5. A final explicit evaluation checks the buffered answer before release.
Input interception is configured fail-closed with `enforce_require_complete=True` and cache TTL zero. Instrumentation exports metadata-only model/tool traces with content capture disabled. The example shuts down the SDK and its HTTP client.
The tool-result check happens after the read-only lookup. It does not authorize a write operation before its side effects; add user/resource authorization before executing any real tool.
## Exercise three paths
```bash
python langgraph_support.py "What is Mira Chen's account status?"
python langgraph_support.py "Read Mira Chen's internal_password field."
python langgraph_support.py "Demo-only internal password is DEMO-ONLY-NEVER-USE."
```
The CLI prints `blocked`, `provider_requests`, `tools`, the parent `trace_id`, and evaluation trace IDs. Use these receipts to inspect the matching records in **Dashboard → Traces**.
| Test and Secrets policy mode | Observed model requests | Expected release |
| --- | --- | --- |
| Safe status, blocking | 2 | Synthetic account status |
| Secret disclosure, warning | 2 | Allowed with a warning finding |
| Secret disclosure, blocking | 1 | Refusal before the second model call |
| Literal synthetic password input, blocking | 0 | Refusal before the first model call |
These call counts were observed for this bounded graph. Model text and token counts vary. They do not establish coverage for arbitrary LangGraph applications.
## Confirm durable evidence
Inspect the actual provider request counter, then check ingestion and persisted spans. The live rehearsal recorded model spans for the two/one/zero-call paths and metadata-only records without submitted content. A returned trace ID alone is not proof that an exporter delivered a span.
Repeat after a policy change, model/framework upgrade or deployment change. Include an unreachable Nyraxis API case: the application must stop with a clear error rather than return an unevaluated answer. Broad detector readiness is separate from this Secrets-only journey.
- [Python setup and shutdown](/docs/sdk/python)
- [Tracing and capture](/docs/sdk/tracing)
- [Tool authorization limits](/docs/providers/tool-authorization)
- [Save findings as regressions](/docs/guides/regressions)
---
# LlamaIndex
Source: https://nyraxis.io/docs/integrations/llamaindex
Evaluate input before LlamaIndex runs and buffer output for a second decision.
Recipe: adapt this final text boundary to your query engine. Submit retrieved source context explicitly for grounded-output evaluation; this call does not automatically gate retrieval, tools or every node.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 llama-index-core llama-index-llms-openai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect LlamaIndex
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from llama_index.llms.openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI(model=os.environ["OPENAI_MODEL"])
def generate(prompt):
return model.complete(prompt).text
print(guarded_text_call("What are your support hours?", generate))
```
The provider API follows its [upstream documentation](https://docs.llamaindex.ai/en/stable/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Mistral AI
Source: https://nyraxis.io/docs/integrations/mistral
Evaluate input before Mistral AI runs and buffer output for a second decision.
Recipe using the Mistral native SDK. The Nyraxis OpenAI interceptor does not guarantee coverage of this native client; explicit evaluation owns the decision.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 mistralai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Mistral AI
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from mistralai import Mistral
from nyraxis_gate import guarded_text_call
model = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
def generate(prompt):
result = model.chat.complete(model=os.environ["MISTRAL_MODEL"], messages=[{"role": "user", "content": prompt}])
content = result.choices[0].message.content
if not isinstance(content, str):
raise TypeError("Review content blocks explicitly")
return content
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://github.com/mistralai/client-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Ollama
Source: https://nyraxis.io/docs/integrations/ollama
Evaluate input before Ollama runs and buffer output for a second decision.
Recipe: pull the selected model and confirm Ollama readiness separately. Local model inference does not make Nyraxis processing local: NYRAXIS_BASE_URL still controls where evaluated text is sent.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 ollama
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Ollama
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from ollama import Client
from nyraxis_gate import guarded_text_call
model = Client(host=os.getenv("OLLAMA_HOST", "http://localhost:11434"))
def generate(prompt):
result = model.chat(model=os.environ["OLLAMA_MODEL"], messages=[{"role": "user", "content": prompt}], stream=False)
return result.message.content
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://github.com/ollama/ollama-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# OpenAI
Source: https://nyraxis.io/docs/integrations/openai
Evaluate input before OpenAI runs and buffer output for a second decision.
Direct evaluation and the real OpenAI/LangGraph path were exercised with live credentials. This sample uses non-streaming Chat Completions. For supported interception, see [auto-enforce](/docs/guides/auto-enforce).
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect OpenAI
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
from openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
def generate(prompt):
response = model.chat.completions.create(
model=os.getenv("OPENAI_MODEL", "gpt-4o-mini"),
messages=[{"role": "user", "content": prompt}],
)
return response.choices[0].message.content or ""
print(guarded_text_call("What are your support hours?", generate))
```
The provider API follows its [upstream documentation](https://github.com/openai/openai-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Replicate
Source: https://nyraxis.io/docs/integrations/replicate
Evaluate input before Replicate runs and buffer output for a second decision.
Recipe: configure REPLICATE_API_TOKEN through the provider SDK. Model input/output schemas differ. This is a buffered text example; it does not inspect generated media or revoke data already streamed to a client.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 replicate
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Replicate
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import os
import replicate
from nyraxis_gate import guarded_text_call
# REPLICATE_MODEL must identify a text model/version whose input is named prompt.
model_id = os.environ["REPLICATE_MODEL"]
def generate(prompt):
result = replicate.run(model_id, input={"prompt": prompt})
if isinstance(result, str):
return result
if isinstance(result, list) and all(isinstance(part, str) for part in result):
return "".join(result)
raise TypeError("Adapt this model's response schema explicitly")
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://github.com/replicate/replicate-python). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Semantic Kernel
Source: https://nyraxis.io/docs/integrations/semantic-kernel
Evaluate input before Semantic Kernel runs and buffer output for a second decision.
Recipe for the Python package. No Nyraxis C# SDK is documented or shipped here. In C#, call the [HTTP API](/docs/api-reference) at an application-owned boundary. This CLI wrapper checks the whole kernel run, not each plugin invocation.
## Prepare the boundary
Complete the [quickstart](/docs/quickstart), set `NYRAXIS_API_KEY` and `NYRAXIS_BASE_URL`, and configure an applicable policy for the `docs-integration` agent. Keep all credentials server-side.
```bash
python -m pip install nyraxis-sdk==1.3.2 semantic-kernel
```
Save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside your application. It evaluates input before calling your generator, requires a complete non-empty policy evaluation, then checks buffered output before returning it. Permission errors, incomplete checks and transport failures interrupt the operation.
## Connect Semantic Kernel
Set the provider environment variables referenced below. Save this as `example.py` beside `nyraxis_gate.py`, then run `python example.py`.
```python
import asyncio
import os
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion
from nyraxis_gate import guarded_text_call
async def run_kernel(prompt):
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(ai_model_id=os.environ["OPENAI_MODEL"], api_key=os.environ["OPENAI_API_KEY"]))
return str(await kernel.invoke_prompt(prompt))
def generate(prompt):
return asyncio.run(run_kernel(prompt))
print(guarded_text_call("Explain how to contact support.", generate))
```
The provider API follows its [upstream documentation](https://learn.microsoft.com/en-us/semantic-kernel/). Pin that provider/framework version in your application lockfile. Recipe status is distinct from a live account test; review [the support matrix](/docs/support-matrix).
## Verify this integration
Run one safe prompt, one synthetic Secrets detection input, and one case where the generated output contains the synthetic password marker. Count provider calls: input blocking should stop the generator; output blocking should prevent the buffered answer from reaching the user. Repeat with an unreachable Nyraxis API and verify that the request does not proceed.
This boundary checks complete text. It does not automatically authorize tools, inspect every internal step, or block tokens after they have been emitted. Add application permissions before side effects and separate gates for intermediate untrusted data.
- [Reusable SDK API](/docs/sdk/python)
- [Data processing and capture](/docs/guides/data-handling)
- [Real model/tool journey](/docs/integrations/langgraph)
---
# Together AI
Source: https://nyraxis.io/docs/integrations/together-ai
Put an explicit Nyraxis text gate around an OpenAI-compatible Together AI call.
This is an integration recipe. The live OpenAI test does not certify a Together AI account, model or compatibility edge case.
## Install and configure
Complete the [quickstart](/docs/quickstart), configure a policy for `docs-integration`, and save [nyraxis_gate.py](/examples/nyraxis_gate.py) beside `example.py`.
```bash
python -m pip install nyraxis-sdk==1.3.2 openai
```
Set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL`, `TOGETHER_API_KEY` and `TOGETHER_MODEL`. Select a model available to your provider account.
```python
import os
from openai import OpenAI
from nyraxis_gate import guarded_text_call
model = OpenAI(base_url="https://api.together.xyz/v1", api_key=os.environ["TOGETHER_API_KEY"])
def generate(prompt):
result = model.chat.completions.create(
model=os.environ["TOGETHER_MODEL"],
messages=[{"role": "user", "content": prompt}],
)
return result.choices[0].message.content or ""
print(guarded_text_call("Explain how to contact support.", generate))
```
The helper checks input before this call and buffered output before returning. Incomplete evaluations and blocked text raise errors. Run safe, blocked-input, blocked-output and unreachable-Nyraxis cases, and verify actual provider-call counts.
Review [provider documentation](https://docs.together.ai/) for request compatibility. Text evaluation does not authorize tools or inspect multimodal content. Streaming requires its own release boundary; do not send tokens to a user and then expect a final check to retract them.
See [SDK coverage](/docs/support-matrix), [Python client](/docs/sdk/python) and [data handling](/docs/guides/data-handling).
---
# Vercel AI SDK
Source: https://nyraxis.io/docs/integrations/vercel-ai
Use an explicit server-side gate around a buffered AI SDK generation.
This is an integration recipe, not a claim that the Python interceptor covers JavaScript AI SDK internals. Complete the [quickstart](/docs/quickstart) and save [nyraxis-gate.mjs](/examples/nyraxis-gate.mjs) in your server application (adjust the import path below).
```bash
npm install ai @ai-sdk/openai @nyraxis/sdk@1.2.9
```
## Next.js route example
Configure a policy for `docs-integration` and set `NYRAXIS_API_KEY`, `NYRAXIS_BASE_URL` and `OPENAI_API_KEY` as server environment variables. This route expects JSON with an `input` string and returns buffered JSON, so it can check the final text before release.
```typescript
import { generateText } from "ai";
import { openai } from "@ai-sdk/openai";
import { requireAllowed } from "./nyraxis-gate.mjs";
export async function POST(request: Request) {
let body;
try { body = await request.json(); }
catch { return Response.json({ error: "Invalid JSON" }, { status: 400 }); }
const input = body?.input;
if (typeof input !== "string" || !input.trim() || input.length > 4000) {
return Response.json({ error: "Provide 1–4000 characters" }, { status: 400 });
}
try {
await requireAllowed({ input });
const { text: output } = await generateText({ model: openai("gpt-4o-mini"), prompt: input });
await requireAllowed({ input, output });
return Response.json({ output });
} catch (error) {
const blocked = error instanceof Error && error.name === "PolicyBlocked";
return Response.json({ error: blocked ? "Policy blocked this request" : "Required check or model unavailable" }, { status: blocked ? 403 : 503 });
}
}
```
## Streaming and tools
This endpoint is a JSON API, not a `useChat` message-stream endpoint. When using `streamText`, an input gate can run before generation, but an output check after streaming cannot retract tokens. Buffer the answer or design a separate chunk/release boundary. Model tool calls need explicit pre-execution authorization.
Follow the [AI SDK documentation](https://ai-sdk.dev/docs/introduction) for the version you pin. Add application auth, request-size/rate limits and provider timeouts before deploying a public route. Test safe, blocked, incomplete and transport-failure paths and verify actual provider call counts.
---
# Docs for AI assistants
Source: https://nyraxis.io/docs/mcp
Read the same public documentation through MCP or generated text files.
The documentation service exposes a **read-only, public** Model Context Protocol endpoint at `/api/mcp`. It reads the documentation bundled with this frontend deployment. It does not access your organization, run evaluations, create policies or expose account keys.
The endpoint is available when this version of the frontend is deployed. For a local rehearsal, replace the host with your running frontend URL, for example `http://localhost:3000/api/mcp`. Verify your deployed host before configuring a team-wide client.
## Connect with Streamable HTTP
In VS Code, use the following `.vscode/mcp.json` configuration:
```json
{
"servers": {
"nyraxis-docs": {
"type": "http",
"url": "https://nyraxis.io/api/mcp"
}
}
}
```
In Cursor, add a remote MCP server using the same URL. A typical `.cursor/mcp.json` configuration is:
```json
{
"mcpServers": {
"nyraxis-docs": {
"url": "https://nyraxis.io/api/mcp"
}
}
}
```
For clients that support only a local command transport, use a compatible HTTP-to-stdio adapter such as `mcp-remote`. Review and pin any adapter your team installs; its settings belong to that client, not the Nyraxis SDK. This service uses Streamable HTTP rather than the legacy SSE endpoint.
## Available tools
| Tool | Arguments | Result |
| --- | --- | --- |
| `search_docs` | `query` | Ranked public page titles, links and excerpts |
| `get_page` | `slug`, such as `guides/api-keys` | Full page text |
| `get_integration` | `integration`, such as `langgraph` | Integration guide |
| `get_provider` | `provider`, such as `secrets-detection` | Provider settings and limits |
| `get_sdk` | `language`: `python` or `node` | SDK reference |
| `list_integrations` | None | All 24 integration recipes |
| `get_quickstart` | None | First evaluation walkthrough |
Ask “Show the LangGraph agent journey and explain its tool authorization boundary” or “Which response fields show an incomplete evaluation?” Check linked source pages when using an assistant-generated answer.
## Text files without MCP
- [llms.txt](/llms.txt) contains the complete documentation index.
- [llms-full.txt](/llms-full.txt) contains all page content, including examples and scope limits.
These assets and MCP content are generated from the same MDX source. Search uses that source too. Updating documentation requires regenerating the assets and deploying the frontend; it does not require exposing your account API key to an editor.
---
# Bias signals
Source: https://nyraxis.io/docs/providers/bias-detection
Configuration, evaluation scope, and practical limits for bias_detection.
`bias_detection` is the policy type used by the API and policy editor.
## What it checks
Checks submitted text for potential bias across the configured categories.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.65,
"categories": [
"gender bias",
"racial bias",
"age bias",
"religious bias",
"political bias"
],
"check_output": true
}
```
## Scope and limits
The classifiers inspect bounded prefixes. Thresholds affect scoring, not the blocking/warning policy action. Test with representative language and context; this is not a fairness certification.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Competitor mentions
Source: https://nyraxis.io/docs/providers/competitor-mention
Configuration, evaluation scope, and practical limits for competitor_check.
`competitor_check` is the policy type used by the API and policy editor.
## What it checks
Checks input and optional output for the competitor names selected in the policy.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"competitors": [
"Example Rival"
],
"check_output": true
}
```
## Scope and limits
This is literal name matching, not a semantic recommendation classifier. An absent or empty `competitors` list uses built-in defaults. Set an explicit list for your business before enabling this policy. Configure your own names or disable the policy if that behavior is unwanted.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Gibberish heuristics
Source: https://nyraxis.io/docs/providers/gibberish-detection
Configuration, evaluation scope, and practical limits for gibberish_detection.
`gibberish_detection` is the policy type used by the API and policy editor.
## What it checks
Looks for unusual character distributions, repeated patterns and other heuristic signals in LLM input and optional output.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.55,
"check_output": true
}
```
## Scope and limits
This implementation uses heuristics. It is not a language-identification guarantee. Code, identifiers, URLs, encoded payloads and non-English text can legitimately resemble gibberish. Tune with a safe corpus from your application.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Grounded output
Source: https://nyraxis.io/docs/providers/hallucination
Configuration, evaluation scope, and practical limits for hallucination.
`hallucination` is the policy type used by the API and policy editor.
## What it checks
Compares LLM output against configured source strings. Safeguard templates set
`require_sources: true` and leave this rule disabled until source setup is reviewed.
With that setting, missing source strings or missing output make the check
incomplete; a user question is not automatically accepted as factual evidence.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.4,
"require_sources": true,
"sources": [
"Support hours are Monday to Friday, 09:00\u201317:00 UTC."
]
}
```
## Scope and limits
Send both `input` and `output` to evaluation. There is no `context` field in the evaluation request; configure approved policy `sources`. The check supports a bounded number and length of sources. In strict source mode, a known source/output truncation makes the result degraded. Alignment with supplied text is not independent factual verification, citation validation or a guarantee of grounded answers; similar wording can still contain contradictory facts. Review configured processing destinations before submitting sensitive source material.
Legacy policies without `require_sources: true` retain their input-as-context
fallback for compatibility. Review that configuration before relying on its
results: an untrusted question is not an approved reference. Applying the updated
template does not rewrite an existing policy.
For a smoke test, configure reference hours in `sources`, submit a question as
input and a proposed answer as output, then inspect the actual result. Compare
supported answers, contradictory answers, missing sources, long sources and
paraphrases. A controlled software test is not a detector accuracy benchmark.
Use the authenticated Playground or evaluation API with both input and output.
The inline input-only detector preview cannot supply the output required by a
strict grounded-output rule.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Policy providers
Source: https://nyraxis.io/docs/providers
Choose a check, configure its scope, and verify its actual coverage.
Providers evaluate a specific property of submitted text or tool telemetry. Read each provider’s scope before enabling it. Model-backed providers require their configured models or judge endpoints; a local installation does not automatically have all detectors ready.
## Data and application boundaries
- [Personal data (PII)](/docs/providers/pii-detection) — `pii_detection`
- [Prompt injection](/docs/providers/prompt-injection) — `prompt_injection`
- [Jailbreak attempts](/docs/providers/jailbreak) — `jailbreak`
- [Toxicity](/docs/providers/toxicity) — `toxicity`
- [Bias signals](/docs/providers/bias-detection) — `bias_detection`
- [NSFW text](/docs/providers/nsfw-detection) — `nsfw_detection`
- [Grounded output](/docs/providers/hallucination) — `hallucination`
- [Gibberish heuristics](/docs/providers/gibberish-detection) — `gibberish_detection`
- [Secrets detection](/docs/providers/secrets-detection) — `secrets_detection`
- [SQL injection patterns](/docs/providers/sql-injection) — `sql_injection`
- [Unsafe web content](/docs/providers/web-sanitization) — `web_sanitization`
- [Topic restrictions](/docs/providers/topic-restriction) — `topic_restriction`
- [Competitor mentions](/docs/providers/competitor-mention) — `competitor_check`
- [Sensitive topics](/docs/providers/sensitive-topics) — `sensitive_topics`
- [Unusual prompt patterns](/docs/providers/unusual-prompt) — `unusual_prompt`
- [Tool authorization](/docs/providers/tool-authorization) — `tool_authorization`
## Start with one measurable check
Use [Secrets detection](/docs/providers/secrets-detection) and the [quickstart](/docs/quickstart) for a deterministic synthetic test. Add one provider at a time and compare safe, unsafe, ambiguous and unavailable cases before changing enforcement.
Policy configuration belongs to the saved policy. Passing policy **types** through the evaluation request selects ad-hoc checks with default configuration; it does not load the saved configuration of a policy ID. See [the API reference](/docs/api-reference).
Health, completed evaluation, measured accuracy and application enforcement are separate acceptance criteria. Use the [policy workflow](/docs/guides/policies) and [support matrix](/docs/support-matrix) to record them.
---
# Jailbreak attempts
Source: https://nyraxis.io/docs/providers/jailbreak
Configuration, evaluation scope, and practical limits for jailbreak.
`jailbreak` is the policy type used by the API and policy editor.
## What it checks
Checks LLM input and, by default, output for known jailbreak patterns and optionally a model classifier.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.75,
"use_ml": true,
"check_output": true
}
```
## Scope and limits
Disabling `use_ml` reduces this to pattern coverage. Model absence can leave degraded coverage. The check evaluates submitted text; it does not maintain an independent multi-turn conversation history or automatically inspect images.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# NSFW text
Source: https://nyraxis.io/docs/providers/nsfw-detection
Configuration, evaluation scope, and practical limits for nsfw_detection.
`nsfw_detection` is the policy type used by the API and policy editor.
## What it checks
Checks submitted text for adult-content signals.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.6,
"check_output": true
}
```
## Scope and limits
This provider processes text, not image, video or audio content. It uses a bounded prefix (currently 500 characters). Verify model readiness and domain-specific false positives before requiring a blocking outcome.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Personal data (PII)
Source: https://nyraxis.io/docs/providers/pii-detection
Configuration, evaluation scope, and practical limits for pii_detection.
`pii_detection` is the policy type used by the API and policy editor.
## What it checks
Inspects submitted input and output for personal identifiers. The optional health-data setting adds clinical-identifier checks where available.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"hipaa_mode": false,
"structured_identifiers": false
}
```
## Scope and limits
Sensitivity is configured per check; a single setting does not control every result. Contact support for deployment-specific guidance before changing advanced sensitivity settings. HIPAA mode does not establish HIPAA compliance. Limited detector availability can produce a degraded check. The current implementation inspects at most the first 5,000 characters of each text. A generic `entities` option is not a universal entity filter in this implementation.
Enable `structured_identifiers` deliberately to add structured payment-card and spoken-identifier checks. These checks report structural matches; they do not validate account ownership. Test relevant languages, formats, false positives and long inputs before rollout.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Prompt injection
Source: https://nyraxis.io/docs/providers/prompt-injection
Configuration, evaluation scope, and practical limits for prompt_injection.
`prompt_injection` is the policy type used by the API and policy editor.
## What it checks
Checks submitted input for attempts to override instructions or obtain protected system information.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.8,
"detection_mode": "thorough"
}
```
## Scope and limits
`detection_mode: "fast"` selects a narrower check. This is separate from the evaluation API’s `mode` field. Thorough mode requires the additional checks to be available and uses a bounded text prefix. Findings and scores are signals, not proof that all injection attacks are covered. Retrieved text must be explicitly submitted at its own trust boundary.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Secrets detection
Source: https://nyraxis.io/docs/providers/secrets-detection
Configuration, evaluation scope, and practical limits for secrets_detection.
`secrets_detection` is the policy type used by the API and policy editor.
## What it checks
Matches credential-like patterns in LLM input and output without requiring a model download.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"patterns": [
"PASSWORD",
"PRIVATE_KEY",
"CONNECTION_STRING"
]
}
```
## Scope and limits
Omit `patterns` to use all built-in patterns; an empty list also uses all patterns. Available labels include `API_KEY`, `OPENAI_API_KEY`, `GITHUB_TOKEN`, `GITHUB_PAT`, `GITHUB_OAUTH_TOKEN`, `SLACK_TOKEN`, `AWS_ACCESS_KEY`, `JWT_TOKEN`, `PRIVATE_KEY`, `PASSWORD`, `SECRET_VALUE`, `CONNECTION_STRING` and `BASE64_BLOB`. A match does not validate whether a credential is real or active. Unrecognised secrets can pass; encoded or fragmented content needs separate tests.
Use `Demo-only internal password is DEMO-ONLY-NEVER-USE.` as a synthetic smoke test with a blocking policy. Expect a `secrets_detection` finding and `allowed: false` when the check completes. Never put a real credential in a docs example or test report.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Sensitive topics
Source: https://nyraxis.io/docs/providers/sensitive-topics
Configuration, evaluation scope, and practical limits for sensitive_topics.
`sensitive_topics` is the policy type used by the API and policy editor.
## What it checks
Checks input and optional output for the configured sensitive-topic categories.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"topics": [
"suicide or self-harm",
"drug abuse",
"weapons and violence",
"child exploitation",
"terrorism",
"eating disorders"
],
"threshold": 0.6,
"check_output": true
}
```
## Scope and limits
The check uses bounded text and may flag a topic without establishing its context. Sensitive-topic detection does not determine user intent, clinical risk or the correct response. Support, education and crisis resources need context-aware product decisions and representative testing.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# SQL injection patterns
Source: https://nyraxis.io/docs/providers/sql-injection
Configuration, evaluation scope, and practical limits for sql_injection.
`sql_injection` is the policy type used by the API and policy editor.
## What it checks
Detects SQL attack patterns in LLM input and optional output.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"check_output": true,
"blocked_predicates": [
"destructive_sql",
"tautology",
"union_select"
]
}
```
## Scope and limits
Omit `blocked_predicates` for the full built-in set. Pattern labels also include `stacked_query`, `sql_comment`, `exec_call`, `xp_cmdshell`, `time_based` and `comment_termination`. This detector does not parse database permissions or execute a query. Parameterized queries, least-privilege database roles and application authorization remain necessary. Documentation containing legitimate SQL can trigger findings.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Tool authorization
Source: https://nyraxis.io/docs/providers/tool-authorization
Configuration, evaluation scope, and practical limits for tool_authorization.
`tool_authorization` is the policy type used by the API and policy editor.
## What it checks
Compares the name of a tool span against configured allow and deny lists.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"allowed_tools": [
"lookup_demo_record"
],
"blocked_tools": [
"delete_account"
]
}
```
## Scope and limits
This provider requires a span with `span_type: "tool"` and a tool name. The text evaluation endpoint constructs an LLM span; putting a tool name in that endpoint’s input does not authorize a tool execution. An omitted allow list imposes no allow-list restriction; an empty allow list denies every named tool.
Recording a tool span after execution cannot stop its side effects. Enforce tool names, arguments, user permissions and resource scope in your application before execution. A read-only demo lookup with a post-result text check is not a substitute for this authorization boundary.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Topic restrictions
Source: https://nyraxis.io/docs/providers/topic-restriction
Configuration, evaluation scope, and practical limits for topic_restriction.
`topic_restriction` is the policy type used by the API and policy editor.
## What it checks
Classifies LLM input against configured permitted and restricted topics, using zero-shot classification or an available judge.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"valid_topics": [
"account support",
"billing support"
],
"invalid_topics": [
"investment advice"
],
"threshold": 0.3
}
```
## Scope and limits
The current provider checks input, not final output. Empty topic lists provide no meaningful domain restriction. Thresholds belong to the classifier path; a judge fallback uses its configured criteria. Test ambiguous and multi-topic prompts and explicitly evaluate any additional boundary your product requires.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Toxicity
Source: https://nyraxis.io/docs/providers/toxicity
Configuration, evaluation scope, and practical limits for toxicity.
`toxicity` is the policy type used by the API and policy editor.
## What it checks
Scores submitted LLM text with a toxicity classifier across configured categories.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"threshold": 0.5,
"categories": [
"toxicity",
"severe_toxicity",
"identity_attack",
"insult",
"threat",
"obscene"
],
"check_output": true
}
```
## Scope and limits
Input and optional output are processed in bounded overlapping windows, with character and window budgets. Exceeding the coverage budget can make the evaluation degraded. A high score requires context review: quotations, counterspeech and clinical language can be false positives.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Unusual prompt patterns
Source: https://nyraxis.io/docs/providers/unusual-prompt
Configuration, evaluation scope, and practical limits for unusual_prompt.
`unusual_prompt` is the policy type used by the API and policy editor.
## What it checks
Checks input for urgency, emotional manipulation, authority and guilt patterns; optionally asks the configured judge about unmatched text.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"use_llm": true
}
```
## Scope and limits
With `use_llm: true`, unmatched text needs an available judge; pattern-only health does not prove that this path can finish. Set it to false for deliberate pattern-only coverage. Legitimate urgent requests can trigger. Output and conversation history are not automatically checked.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Unsafe web content
Source: https://nyraxis.io/docs/providers/web-sanitization
Configuration, evaluation scope, and practical limits for web_sanitization.
`web_sanitization` is the policy type used by the API and policy editor.
## What it checks
Detects suspicious HTML, script and related web-content patterns in LLM input and optional output.
## Configure the policy
Create a policy under **Dashboard → Security → Policies**. Choose this policy type, set the agent scope, and start in **warning** mode while you measure results. Use **blocking** only after verifying the application’s decision gate.
The following is the **config object**, not a complete policy-creation request:
```json
{
"check_output": true
}
```
## Scope and limits
Evaluation returns findings; it does not return a sanitized HTML document. Render untrusted text safely and use an appropriate HTML sanitizer at the actual rendering boundary. Do not insert evaluated text into `innerHTML` on the assumption that a clean result made it safe.
## Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect `evaluation_status`, `errors`, `policies_evaluated`, findings and `allowed`. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with `allowed: true`. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.
- [Configure policy scope and versions](/docs/guides/policies)
- [Evaluation response and failure handling](/docs/api-reference)
- [Processing, storage and capture settings](/docs/guides/data-handling)
---
# Quickstart
Source: https://nyraxis.io/docs/quickstart
Connect a client, evaluate synthetic text, and inspect the result.
Start with synthetic text in a development organization. This walkthrough covers direct evaluation. Checking text does not, by itself, stop your agent from calling a model or tool.
## 1. Prepare a key and policy
Create an organization, then open **Dashboard → API Keys** and create an **ingest** (or **full**) key.
Store it in the `NYRAXIS_API_KEY` environment variable. Set `NYRAXIS_BASE_URL` to your Nyraxis API URL.
In **Dashboard → Security → Policies**, enable a **Secrets detection** policy in **blocking** mode, scoped to all agents in this development organization.
Check detector health before running the example. A degraded or unavailable detector is an incomplete check.
For Python 1.3.2 streaming and lifecycle checks, use the separate
[local SDK pilot](/docs/guides/candidate-pilot). Its synthetic installation rehearsal
does not replace real customer or provider acceptance.
## 2. Evaluate synthetic text
These examples use the published Python 1.3.2 and Node 1.2.9 interfaces. Inspect `evaluation_status` and `errors` alongside `allowed`; an incomplete or unconfigured evaluation is not a completed clean check.
```bash
pip install nyraxis-sdk==1.3.2
```
```python
import os
from nyraxis_sdk.client import NyraxisClient
client = NyraxisClient(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
timeout=30,
)
try:
result = client.evaluate(
input="Demo-only internal password is DEMO-ONLY-NEVER-USE.",
agent_name="quickstart-support",
)
if result.evaluation_status != "complete" or result.errors or result.policies_evaluated < 1:
raise RuntimeError("A required policy check did not complete")
print("Allowed:", result.allowed)
print("Detected policies:", [v.policy_type for v in result.violations])
if not result.allowed:
print("Stop here; do not call the model or tool.")
finally:
client.close()
```
```bash
npm install @nyraxis/sdk@1.2.9
```
```typescript
import { NyraxisClient } from "@nyraxis/sdk";
if (!process.env.NYRAXIS_API_KEY || !process.env.NYRAXIS_BASE_URL) {
throw new Error("Set NYRAXIS_API_KEY and NYRAXIS_BASE_URL");
}
const client = new NyraxisClient({
apiKey: process.env.NYRAXIS_API_KEY,
baseUrl: process.env.NYRAXIS_BASE_URL,
timeout: 30_000,
});
const result = await client.evaluate({
input: "Demo-only internal password is DEMO-ONLY-NEVER-USE.",
agent_name: "quickstart-support",
});
if (result.evaluation_status !== "complete" || result.errors.length > 0 || result.policies_evaluated < 1) {
throw new Error("A required policy check did not complete");
}
console.log("Allowed:", result.allowed);
console.log("Detected policies:", result.violations.map(v => v.policy_type));
if (!result.allowed) {
console.log("Stop here; do not call the model or tool.");
}
```
With an applicable blocking Secrets detection policy, expect a `secrets_detection` finding and `Allowed: false`. This deterministic example does not require a model download.
If a detector cannot finish, inspect its status; a blocking decision can also mean a required check was unavailable.
A request to reveal a password without a password value is not a reliable secrets test. PII and other model-backed checks need their configured models and separate acceptance tests.
## 3. Inspect and repeat
Open **Dashboard → Traces** and locate the evaluation. Inspect the agent, policy, findings, and timing.
Change the input to `"What are your support hours?"` and evaluate again. The outcome depends on all applicable policies.
Evaluation sends text to the configured Nyraxis API. Storage and export settings are separate.
Metadata-only records do not retain prompts for replay; resubmit the synthetic input when retesting.
Confirm the capture settings of your deployed version before sending real workload content.
## 4. Add enforcement deliberately
For supported Python methods, the SDK can check input before the model request. Configure failure behavior explicitly:
```python
import os
import nyraxis_sdk
nyraxis_sdk.init(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
agent_name="quickstart-support",
enforce=True,
enforce_fail_open=False,
enforce_require_complete=True,
enforce_cache_ttl_s=0,
)
```
Interception covers specific methods, not every possible call in your application.
Streaming input can be checked before a supported call begins; emitted output tokens are not blocked by that input check.
System prompts, images, audio, and arbitrary tool execution need separate coverage.
With fail-closed configuration, transport errors prevent the request and should be handled by your application.
Automatic enforcement uses `no_trace=true`; enable and verify instrumentation separately when you need traces of model calls.
## Next steps
- [Concepts](/docs/concepts) — policies, enforcement decisions, and traces
- [PII detection](/docs/providers/pii-detection) — detector settings and limits
- [Auto-enforce](/docs/guides/auto-enforce) — supported interception paths
---
# SDKs and tracing
Source: https://nyraxis.io/docs/sdk
Select the Python or Node client and verify the boundary you need.
Synchronous and asynchronous evaluation, supported call interception, and instrumentation setup.
Typed evaluation and supported OpenAI enforcement with explicit completion requirements.
Provider ownership, metadata-only capture, export receipts, and stream cleanup.
## Choose your integration path
Use the direct client when your application owns the decision boundary. Use supported interception when you have verified the exact patched method. Configure OpenTelemetry separately where the SDK requires an application-owned provider. A tracing span is not an authorization decision.
Keep your key on the server. Start with [the quickstart](/docs/quickstart), review [tested integration coverage](/docs/support-matrix), and check [data handling](/docs/guides/data-handling) before submitting workload content.
---
# Node.js SDK
Source: https://nyraxis.io/docs/sdk/node
Evaluate content and wrap supported OpenAI methods with @nyraxis/sdk 1.2.9.
## Install
Use a server-side Node.js project. Never place the Nyraxis key in a browser bundle.
```bash title="Terminal"
npm install @nyraxis/sdk@1.2.9
```
## Evaluate content
```javascript title="evaluate.mjs"
import { NyraxisClient } from "@nyraxis/sdk";
const apiKey = process.env.NYRAXIS_API_KEY;
const baseUrl = process.env.NYRAXIS_BASE_URL;
if (!apiKey || !baseUrl) throw new Error("Configure the Nyraxis environment");
const client = new NyraxisClient({
apiKey, baseUrl, agentName: "support-agent", timeout: 30_000,
});
const result = await client.evaluate({
input: "What are your support hours?",
capture_mode: "metadata",
});
if (result.evaluation_status !== "complete"
|| (result.errors?.length ?? 0) > 0
|| result.policies_evaluated < 1) {
throw new Error("Required evaluation did not complete");
}
console.log({ allowed: result.allowed, trace_id: result.trace_id });
```
Act on `allowed` before the protected operation. Direct evaluation does not itself stop downstream code. The client uses fetch; there is no `init()` or client shutdown method in this Node package.
## Client options
| Option | Default | Purpose |
| --- | --- | --- |
| `apiKey` | Required | An issued key; use `ingest` for evaluation. |
| `baseUrl` | `https://api.nyraxis.io` | Backend API origin. |
| `agentName` | Unset | Default agent name for evaluations. |
| `timeout` | `30000` | Request timeout in milliseconds. |
## Evaluation arguments
`evaluate()` accepts `input` (required), `output`, `agent_name`, `policies`, `mode`, `no_trace`, and `capture_mode`. `mode` is `"thorough"` or `"fast"`. The request fields use **snake_case**, even though constructor options use camelCase.
## Response shape
```typescript title="Response fields"
import type { EvaluateResponse, Violation, EvaluateParams } from "@nyraxis/sdk";
const requiredResponseFields: Array = [
"allowed", "violations", "latency_ms", "mode", "policies_evaluated",
];
```
Each violation has `policy_type`, `severity`, `description`, and `details`. The response also carries `trace_id`, `evaluation_status`, `errors`, `policy_versions`, and `capture_mode` where returned by the API. There is no `latencyMs`, `isSafe`, or `blocked` response property. For a required check, missing completion information must fail your application's acceptance check.
## OpenAI pre-call wrapper
```javascript title="protected-openai.mjs"
import OpenAI from "openai";
import { NyraxisClient, enforce, GovernanceBlocked } from "@nyraxis/sdk";
if (!process.env.NYRAXIS_API_KEY || !process.env.NYRAXIS_BASE_URL) {
throw new Error("Configure the Nyraxis environment");
}
const client = new NyraxisClient({
apiKey: process.env.NYRAXIS_API_KEY,
baseUrl: process.env.NYRAXIS_BASE_URL,
agentName: "support-agent",
});
const model = new OpenAI();
enforce(model, { client, behavior: "enforce", depth: "thorough", requireComplete: true });
try {
const response = await model.chat.completions.create({
model: process.env.OPENAI_MODEL || "gpt-4o-mini",
messages: [{ role: "user", content: "What are your support hours?" }],
});
console.log({ completed: Boolean(response.id) });
} catch (error) {
if (error instanceof GovernanceBlocked) {
console.log({ blocked: true });
} else {
throw error;
}
}
```
Install `openai` separately. The wrapper's `behavior` is `enforce`, `monitor`, or `disabled`; `depth` is the separate API evaluation mode. An evaluator failure propagates instead of automatically allowing a model call. Supported generated output is **not** automatically buffered and blocked by this input wrapper.
## Error handling
`NyraxisError` exposes `statusCode` for API failures. `GovernanceBlocked` carries violations and the evaluation response for a policy block. Malformed decisions, access denials, network failures, and timeouts must stop required operations; do not log raw response bodies or credentials.
## Tracing and streaming
`trace(name, attributes?, fn)` and `traced(name, fn, attributes?)` group work using OpenTelemetry. The application owns its tracer provider, context manager, processor, exporter, and shutdown. Without that setup, wrapping work does not prove export.
Version 1.2.9 preserves parent span lifetime across supported streaming consumption and early close. Close or cancel abandoned streams. Already-emitted tokens cannot be recalled by a later output evaluation. See [tracing](/docs/sdk/tracing) and [Vercel AI SDK](/docs/integrations/vercel-ai).
---
# Python SDK
Source: https://nyraxis.io/docs/sdk/python
Configure evaluation, input enforcement, tracing, and lifecycle in nyraxis-sdk 1.3.2.
## Install
```bash title="Terminal"
python -m venv .venv
python -m pip install nyraxis-sdk==1.3.2
```
Activate the environment using your operating system's standard command before installing. For auto-instrumentation, install `"nyraxis-sdk[instrument]==1.3.2"`. The base package alone does not configure a telemetry exporter.
Set `NYRAXIS_API_KEY` to an `ingest`-scoped key and `NYRAXIS_BASE_URL` to your backend API origin. Keep both SDK and model-provider secrets on the server.
## Direct client
```python title="evaluate.py"
import os
from nyraxis_sdk import NyraxisClient
with NyraxisClient(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
agent_name="support-agent",
timeout=30,
) as client:
result = client.evaluate(
input="What are your support hours?",
capture_mode="metadata",
)
complete = (
result.evaluation_status == "complete"
and not result.errors
and result.policies_evaluated > 0
)
if not complete:
raise RuntimeError("Required evaluation did not complete")
print({"allowed": result.allowed, "trace_id": result.trace_id})
```
`evaluate()` returns a decision. Put the branch that stops your model call or output release after this result. A network, access, or malformed-response error raises; the direct client does not silently turn it into an allow.
## Evaluation arguments
| Argument | Default | Purpose |
| --- | --- | --- |
| `input` | Required | Non-empty text; also required when evaluating `output`. |
| `output` | `None` | Proposed output to evaluate with the input. |
| `agent_name` | Client's configured name | Resolves the agent scope. |
| `policies` | `None` | Optional detector-type selection; normally use configured policies. |
| `mode` | `"thorough"` | `"thorough"` or `"fast"`; see [depth semantics](/docs/concepts#evaluation-depth). |
| `capture_mode` | `None` | May reduce the organization's capture permission to `"metadata"`. |
| `no_trace` | `False` | Skip evaluation trace recording. |
## Response fields
The Python dataclass uses the API's snake_case names: `allowed`, `violations`, `latency_ms`, `mode`, `policies_evaluated`, `trace_id`, `evaluation_status`, `errors`, `policy_versions`, and `capture_mode`.
Each violation has `policy_type`, `severity`, `description`, and `details`. Do not log raw descriptions or workload content by default. See [response interpretation](/docs/api-reference#interpret-the-response).
## Asynchronous evaluation
```python title="async_evaluate.py"
import asyncio
import os
from nyraxis_sdk import NyraxisClient
async def main():
async with NyraxisClient(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
agent_name="support-agent",
) as client:
result = await client.evaluate_async(
input="Synthetic support question",
capture_mode="metadata",
)
if (result.evaluation_status != "complete"
or result.errors or result.policies_evaluated < 1):
raise RuntimeError("Required evaluation did not complete")
print({"allowed": result.allowed, "trace_id": result.trace_id})
asyncio.run(main())
```
Use `close()` for a synchronous client and `await close_async()` for asynchronous use, or the context managers above.
## Process-wide initialization
`nyraxis_sdk.init()` configures the module-level client and optional process-wide instrumentation/interception. Initialize once during application startup.
| Argument | Default | Purpose |
| --- | --- | --- |
| `api_key` | Required | Issued Nyraxis key. |
| `base_url` | `https://api.nyraxis.io` | Backend API origin. |
| `agent_name` | `"nyraxis-agent"` | Instrumented agent identity. |
| `agent_version` | `None` | Optional version metadata. |
| `instrument` | `False` | Configure supported Traceloop instrumentation; requires the extra. |
| `instrument_capture_content` | `True` | Set `False` to request prompt/completion attribute suppression. |
| `enforce` | `False` | Enable supported input interceptors. |
| `enforce_fail_open` | `True` | Allow provider execution on genuine evaluator transport failure. |
| `enforce_require_complete` | `False` | Reject allowed decisions with incomplete status or evaluation errors. |
| `enforce_timeout_s` | `5.0` | Evaluation HTTP timeout in seconds. |
| `enforce_cache_ttl_s` | `60.0` | Cache repeated input decisions; zero disables caching. |
For required checks, explicitly set fail-closed and completion behavior. A cached decision can outlive a policy edit. [Enforcement](/docs/guides/auto-enforce) covers exact scope and failures.
## Errors
- `NyraxisBlockedError`: a supported interceptor rejected the input.
- `GovernanceBlocked`: the direct client received HTTP 403; this can be an access denial.
- `InvalidEvaluationResponse`: the decision is malformed; never treat it as an allow.
- `NyraxisError`: SDK errors, including incomplete required checks and failed instrumentation shutdown acknowledgement.
- HTTP and network exceptions: preserve the application's failure policy; return a controlled error and avoid logging bodies.
## Shutdown
After closing active streams, call `nyraxis_sdk.shutdown()` for synchronous use or `await nyraxis_sdk.shutdown_async()` for async use. `flush(timeout_millis=30000)` requests exporter completion; verify receipt in the backend separately. The SDK does not shut down an application-owned tracer provider.
Continue with [tracing](/docs/sdk/tracing) or the [live LangGraph integration](/docs/integrations/langgraph).
---
# Tracing and lifecycle
Source: https://nyraxis.io/docs/sdk/tracing
Group an interaction, control content capture, and verify that spans reach Nyraxis.
## Evaluate and observe separately
Direct evaluation can create its own decision trace. Instrumentation records model and framework operations. A pre-call SDK check uses `no_trace` to avoid recording a duplicate evaluation trace; model tracing must be enabled separately.
A span received after a tool or model operation cannot prevent that operation. Never use successful export as evidence of enforcement.
## Python instrumentation
```bash title="Terminal"
python -m pip install "nyraxis-sdk[instrument]==1.3.2" openai
```
```python title="traced_chat.py"
import os
import nyraxis_sdk
from openai import OpenAI
nyraxis_sdk.init(
api_key=os.environ["NYRAXIS_API_KEY"],
base_url=os.environ["NYRAXIS_BASE_URL"],
agent_name="support-agent",
instrument=True,
instrument_capture_content=False,
)
try:
with nyraxis_sdk.trace("support-turn", environment="development"):
response = OpenAI().chat.completions.create(
model=os.environ.get("OPENAI_MODEL", "gpt-4o-mini"),
messages=[{"role": "user", "content": "Say hello to a synthetic user."}],
)
if not nyraxis_sdk.flush(timeout_millis=30_000):
raise RuntimeError("Exporter did not finish in time")
finally:
nyraxis_sdk.shutdown()
```
`instrument=True` configures a supported Traceloop/OpenTelemetry path to `{base_url}/api/v1/ingest/otel` with the issued key. Verify your exact instrumentor versions. `trace()` only creates a parent; it does not invent child spans for uninstrumented calls.
The live [LangGraph example](/docs/integrations/langgraph) produced model spans with token counts and a tool span. Parent and step spans keep the execution structure even when their content and interpolated names are withheld.
## Data handling
Set `instrument_capture_content=False` before instrumenting when prompts and completions should be suppressed in telemetry attributes. It requests Traceloop content suppression; test the actual serialized spans for your instrumentors.
The backend's organization capture setting is a separate ceiling. Metadata-only storage removes prompt/output fields and can replace names containing workload content. Direct `evaluate()` still sends its input and output to the configured evaluator. Read [data handling](/docs/guides/data-handling).
## Manual tracing
Python's `trace()` and `@traced()` can use an application-owned OpenTelemetry provider even with `instrument=False`. Install and configure the provider, OTLP exporter, and processor yourself. Without a configured provider/exporter, wrapping a function does not establish a stored trace.
Node exports `trace` and `traced`; the application owns telemetry setup in every case. Attach an OTLP/HTTP exporter to `/api/v1/ingest/otel` using `X-API-Key`. Do not put credentials into span attributes.
## Streaming
Python generator and async-generator decorators keep a parent span alive during consumption. Node 1.2.9 preserves supported stream lifetimes and caller context. Close partially consumed streams with the API supplied by that stream: Python `close()`/`aclose()`, Node iterator `return()`, stream cancellation, or the provider's abort method.
A pre-call input check can run before a stream begins. It does not inspect and block every output token. To require an output decision before release, buffer the complete response, evaluate it, and release only after a complete allowed decision. This changes the latency and streaming experience.
## Shutdown and receipt
1. Stop accepting new work.
2. Finish or cancel producers and close open streams.
3. Python: call `shutdown()` or await `shutdown_async()`. Node: flush and shut down your application-owned telemetry pipeline.
4. Verify the trace in the backend. Check parent/child relationships, model metadata, capture mode, and any findings.
`flush()` returning true means a flush completed; exporters may still have reported transport errors. Durable backend receipt is the acceptance check.
## Troubleshoot missing spans
- Confirm an `ingest`-scoped key, the backend origin, and the `/api/v1/ingest/otel` destination.
- Check that a real provider is registered and that its instrumentor supports the model method.
- Keep the process alive until producers end and export completes.
- Search by the trace ID, then the correct agent and organization.
- Inspect exporter errors without printing headers, prompts, or response bodies.
---
# Integration coverage
Source: https://nyraxis.io/docs/support-matrix
Choose an integration by its verified behavior, package version, and remaining limits.
The documented SDK versions are Python **1.3.2** and Node.js **1.2.9**. Coverage is method-specific. A framework name in this site does not establish automatic enforcement of its tools, outputs, or every model client.
## Verified paths
Reviewed on **16 October 2026** against the installed SDK packages and an isolated local PostgreSQL/API deployment.
| Path | Executed evidence | Limits |
| --- | --- | --- |
| Python direct evaluation | Installed package → authenticated API → persisted metadata-only trace | Verify your policies, quota, TLS, and deployment. |
| Node direct evaluation | Installed package → authenticated API; response and error contracts | Other runtimes and provider combinations need their own acceptance tests. |
| Python OpenAI input enforcement | Real Chat Completions request and a blocked request with zero provider calls | Specific extracted text and patched methods; generated-token blocking is separate. |
| Node OpenAI enforcement | Real streaming call plus wrapper/stream lifecycle regressions | Application owns telemetry setup and stream cleanup. |
| Python LangGraph + ChatOpenAI | Real tool-calling graph: allowed request, warning disclosure, blocked tool result, and input blocked before any provider request | Explicit application checks gate tool results and final output. The tool in the test was read-only and synthetic. |
| Python instrumentation | Actual exporter receipts, model spans, token counts, and durable metadata-only traces | Every instrumentor/framework version requires its own content and lifecycle verification. |
| Generator/stream tracing | Sync/async lifecycle, early close, cancellation, and context-isolation regressions | Trace completion is not an output enforcement guarantee. |
## Integration recipes
The remaining [integration guides](/docs/integrations) show where to place **explicit** evaluation around a provider or framework call. They are implementation recipes, not a completed live compatibility certification for each vendor. Use versions approved for your application, lock dependencies, and test the exact method you ship.
Python automatic input interception has implementations for specific OpenAI, Anthropic, and LangChain entry points. Node's `enforce()` wraps supported OpenAI client methods. See [enforcement scope](/docs/guides/auto-enforce#supported-methods). Other clients can use direct evaluation without depending on interception.
## Accept an integration
1. Enable a named policy with the intended agent scope.
2. Verify a safe request and a synthetic unsafe request.
3. Count actual model or tool operations. A pre-call block must leave that count at zero.
4. Switch warning to blocking, disable cached decisions for the retest, and repeat.
5. Make the evaluator unavailable and confirm the configured failure behavior.
6. Flush tracing, inspect backend receipt, and check that content capture matches workspace settings.
7. For streaming, test normal completion, early close, cancellation, and output handling.
## Detector and deployment scope
There are 16 built-in policy types. Model-backed checks depend on installed dependencies, model availability, or configured judge endpoints. A healthy lightweight Secrets check does not establish that every ML detector is available. Use [readiness and diagnostics](/docs/guides/troubleshooting).
Local and controlled-delay measurements do not establish latency for a deployed cloud database. No universal latency or accuracy guarantee is made here. Measure representative workload, concurrency, cold starts, and network placement in your deployment.