5.1 Argus Client: Your Central Guard
TheArgusClient is the primary interface for all interactions with the Argus API. It is designed to be a long-lived object within your application.
Best Practice: In a web server or long-running application, you should create a single, shared instance of the ArgusClient when your application starts and reuse it for all subsequent requests. Creating a new client for every request is inefficient and will introduce significant latency due to repeated authentication and connection setup.
The SDK intelligently distinguishes between user tiers based on the provided API key, automatically enabling or disabling platform-specific features. You do not need to specify your user level; the client handles it for you.
5.2 Anatomy of a Scan: Inputs and Outputs
Every scan consists of well-defined inputs (your security rules) and outputs (the scan result).Inputs: Defining Your Security Rules
You control the behavior of a scan by defining aPolicy. A policy is built using several key components:
The Action Enum: What to Do
The Action enum can be used to define what action to take for a policy violation
| Member | Value | Description |
|---|---|---|
Action.BLOCK | "block" | High-risk response. The scan verdict should be "blocked". Your application should immediately stop the request. |
Action.FLAG | "flag" | Monitor-only response. The scan verdict will be "flagged". The request is not stopped, but the event is recorded for later review. |
Action.DISABLED | "disabled" | Disables the policy. It will not be evaluated during the scan. |
The InteractionType Enum: What You’re Scanning
This enum provides context to the scanner about the nature of the text being analyzed.
| Member | Value | Description |
|---|---|---|
InteractionType.PROMPT | "PROMPT" | The text is a user-generated prompt. |
InteractionType.RESPONSE | "RESPONSE" | The text is an LLM-generated response. |
The Policy Object: Your Complete Security Configuration
The Policy object is the heart of your security rules. It is a Python dictionary where keys are members of the PolicyName enum and values are configuration dictionaries.
Each configuration dictionary must contain an "action" key with a value from the Action enum. Some policies require additional configuration keys, as detailed below.
Comprehensive Policy Object Example:
PolicyName Configuration Requirements:
PolicyName Member | Required Configuration Key | Python Type | Description |
|---|---|---|---|
PII_DETECTION | (none) | N/A | Detects common PII. |
TOXICITY | (none) | N/A | Detects toxic language. |
PROMPT_INJECTION | (none) | N/A | Detects prompt injection attacks. |
UNSAFE_PROMPT | (none) | N/A | Detects requests for harmful content. |
UNSAFE_RESPONSE | (none) | N/A | Detects if a response contains harmful content. |
LANGUAGE_VIOLATION | (none) | N/A | Detects non-allowed languages. |
POLICY_VIOLATION | rules | List[str] | A list of forbidden keywords or phrases. |
COMPETITOR_MENTION | competitors | List[str] | A list of competitor names to detect. |
BANNED_TOPICS | topics | List[str] | A list of forbidden topics. |
SYSTEM_PROMPT_LEAK | system_prompt | str | The system prompt string to check against for leaks. |
SECRETS_KEYS | patterns | List[Tuple[str, str]] | A list of (name, regex) tuples to whitelist patterns. |
Outputs: Understanding the Scan Result
Every scan method returns a consistentApiResult object. To ensure type safety and prevent bugs from typos, you should always use the Verdict enum when interpreting the result.
The Verdict Enum: The Final Outcome
| Member | Value | Description |
|---|---|---|
Verdict.PASSED | "passed" | No policies were violated. The request is safe to proceed. |
Verdict.FLAGGED | "flagged" | A policy with action: Action.FLAG was triggered. The request is not blocked. |
Verdict.BLOCKED | "blocked" | A policy with action: Action.BLOCK was triggered. The request must be stopped. |
The ApiResult Object: Structure and Attributes
All scan methods return an ApiResult object which provides the complete, structured outcome of the scan. This serves as the single source of truth for the scan’s results.
Top-Level Attributes
| Key | Type | Description |
|---|---|---|
verdict | Verdict | Required. The definitive outcome of the scan ("passed", "flagged", "blocked"). |
request_id | str | Required. A unique UUID for the scan request, crucial for logging and troubleshooting. |
policies_applied | List[AppliedPolicyInfo] | Required. A list detailing every policy that was evaluated, including those that were not violated. |
policies_violated | List[ViolatedPolicyInfo] | Required. A list detailing each policy that was triggered. If the verdict is "passed", this list will be empty. |
The AppliedPolicyInfo Object Structure
This object confirms which policies were part of the scan evaluation.
| Key | Type | Description |
|---|---|---|
policy_name | PolicyName | The identifier of the policy that was evaluated. |
action | Action | The action configured for this policy (BLOCK, FLAG, or DISABLED). |
metadata | Metadata | Internal metadata associated with the policy evaluation. |
The ViolatedPolicyInfo Object Structure
This object provides detailed context about a specific violation.
| Key | Type | Description |
|---|---|---|
policy_name | PolicyName | The identifier of the policy that was triggered. |
action_taken | Action | The action that was executed ("block" or "flag"). |
details | Dict | An object containing violation-specific data. Its structure varies by policy. |
details Object Schema by Policy
The structure of the details object is unique to each policy, providing the most relevant information for that specific risk type.
| Policy Name | details Schema | Description of Fields |
|---|---|---|
policy_violation_detection | {'reason': str} | Currently returns 'N/A'. Reserved for future enhancements. |
secrets_keys_detection | List[Dict] with {'text': str, 'score': float} | A list of detected secrets. Each object contains the matched text and a confidence score. |
pii_detection | List[Dict] with {'text': str, 'score': float} | A list of detected PII entities with their matched text and confidence score. |
toxicity_detection | {'label': str, 'score': float} | Contains a label (e.g., 'toxicity') and a confidence score. |
competitor_mention_detection | {'detected_competitors': bool} | A boolean that is True if any of the configured competitor names were found. |
banned_topics_detection | {'detected_topics': List[str]} | A list of the specific banned topic categories that were matched. |
prompt_injection_detection | {'score': float} | A confidence score indicating the likelihood of a prompt injection attack. |
unsafe_prompt_protection | {'safety_score': float} | A score where a higher value indicates a higher probability of the prompt being unsafe. |
unsafe_response_detection | {'safety_score': float} | A score where a higher value indicates a higher probability of the response being unsafe. |
system_prompt_leak_detection | {'similarity_score': float} | A score indicating how closely the response text matches the provided system prompt. |
5.3 Client State vs. Call-Time Overrides: Two Ways to Configure
The SDK provides two powerful patterns for applying policies and configurations: setting a default state on the client and overriding that state for individual calls.Method 1: Configuring the Client’s Default State
You can configure a default security posture when you initialize theArgusClient. This state will be automatically applied to every scan call that does not have an explicit override. This is the most common pattern for applications with a consistent security requirement.
Default state can be set for:
policyasset_id(Platform Only)session_id(Platform Only)save(Platform Only)
set_policies(), set_asset_id(), etc.).
Example: Setting a Default State
Method 2: Using Call-Time Overrides for Dynamic Control
For maximum flexibility, every parameter you can set at creation time can also be overridden for a single API call by passing it directly to thecheck_prompt() or check_response() methods.
This override is temporary and does not affect the client’s default state. It is perfect for situations where you need to apply a different policy or log to a different asset dynamically.
Example: Temporarily Overriding the Default State
5.4 Agentic Threat Observability with Guardrail Decorators (Platform Tier)
For users with a Platform Tier key (rsk_...), the SDK offers a feature set that goes far beyond simple scanning: full-stack observability for agentic workflows. This is primarily achieved through a powerful set of Guardrail Decorators.
Instead of manually calling check_content() before and after every function call, you can use these decorators to declaratively trace and protect your entire application. The SDK automatically handles creating execution timelines, applying policies, and logging all the data to the Argus Platform for visualization.
The Core Concept: Traces and Spans
Think of how a debugger’s call stack helps you understand a traditional application’s flow. Argus decorators provide a similar concept for your AI system:- Trace: A trace represents the entire end-to-end execution of a single workflow. For example, a user’s entire request from “start research” to “get final answer” would be one trace.
- Span: A span represents a single, instrumented unit of work within that trace. Each function you wrap with a guardrail decorator creates a new span.
The Primary Decorators
There are three main decorators, each designed for a specific role in an agentic workflow. Using them correctly provides the richest possible context in your observability traces.1. @client.guard_entrypoint()
This decorator should be used on the single function that kicks off your entire workflow. It wraps the top-level span of the trace.
- Purpose: Marks the beginning and end of the entire operation.
- Typical Use: Placed on a function like
main(),run_agent(), or a web server’s primary request handler.
2. @client.guard_agent()
This decorator is for wrapping the core logic or decision-making components of your system.
- Purpose: Represents a logical “agent” or a major step in the workflow. It’s the “brains” of the operation.
- Key Behavior: By default,
guard_agentdoes not scan the output of the function (check_output=False). This is because agents often return complex objects, control signals, or iterators—not just raw text that needs scanning. Its primary role is to create a logical grouping span in the trace.
3. @client.guard_tool()
This is the most common decorator and the workhorse for security enforcement. It should be used to wrap individual tools that your agent can call.
- Purpose: Wraps functions that perform a specific, isolated task, especially those that interact with the outside world (e.g., calling an API, querying a database, running code).
- Key Behavior: This is where you will most frequently apply security policies. It defaults to scanning the function’s output (
check_output=True), as tools often return external data that needs to be validated before being passed back to the agent.
A Cohesive Example: A Simple Research Agent
Let’s see how these decorators work together to trace and protect a simple agent that uses a search tool and a summarization tool.WebSearchTool:
- MainAppEntry (Trace Root)
- ResearchAgentLogic (Span)
- WebSearchTool (Sub-Span) -> VIOLATION FLAGGED: Banned Topic ‘finance’ detected.
- SummarizationTool (Sub-Span)
- ResearchAgentLogic (Span)
Key Decorator Parameters
You can customize the behavior of any guardrail decorator with these optional parameters:| Parameter | Type | Description |
|---|---|---|
name | Optional[str] | A custom, human-readable name for the span in the trace. Defaults to the function’s name. |
check_input_args | Optional[List[str]] | A list of the function’s parameter names. Their string values will be scanned when the function is called. |
check_output | bool | If True, the function’s return value will be scanned before it is returned. Defaults vary by decorator. |
policies | Optional[Policy] | (guard_tool only) A local Policy object to use for this specific tool’s scans, overriding the default. |
session_id | Optional[str] | A specific session ID to associate with this trace. |
node_metadata | Optional[Dict] | A dictionary of custom key-value pairs to attach to the span, useful for logging extra context. |
Convenience Aliases
For common tool types, the SDK provides semantic aliases for@client.guard_tool to make your traces more readable. These are functionally identical to @client.guard_tool but assign a different default subtype icon in the UI.
@client.guard_database()@client.guard_knowledge_base()@client.guard_model_generation()
5.5 Observability and Platform Integration (Platform Tier)
For users with a Runtime Security Key, the SDK unlocks a powerful set of features centered around the Argus Platform dashboard, transforming the SDK from a simple scanner into a comprehensive security and observability tool.Leveraging Platform-Managed Policies
This is the primary and most powerful workflow for Platform users. Instead of defining complexPolicy objects in your code, you can build, test, and manage them entirely within the Argus UI. Your security, legal, and product teams can collaborate on policies without requiring code changes.
To use a platform-managed policy, simply associate your client with an Asset ID and make scan calls without a local policy object.
Organizing Your Data with Assets (asset_id)
An Asset is a logical container in the Argus Platform that represents a specific application, environment, or use case you are protecting (e.g., “Production Support Chatbot”, “Staging Marketing Assistant”, “Developer Sandbox”).
- Why use Assets? They allow you to apply different policies to different applications and view their analytics separately in the dashboard.
- How to use: You can set a default
asset_idwhen creating the client or override it on a per-call basis, which is ideal for centralized AI gateways managing multiple applications.
Tracking Conversations with Sessions (session_id)
A Session is a unique identifier that you create and manage to group a series of related interactions. For a chatbot, a session would typically represent a single user’s complete conversation from start to finish.
-
Why use Sessions? They are critical for observability. In the Argus dashboard, all prompts and responses with the same
session_idare linked, allowing you to review the full context of a conversation to understand why a policy was triggered. -
How to use: You can manage sessions in two ways, depending on your application’s architecture.
**Method 1: Passing **
session_idper Call (Stateless) This is the most common and robust pattern, especially for web servers or stateless applications where a singleArgusClientinstance may handle requests from many different users simultaneously. You pass thesession_idas a parameter to each scan call.**Method 2: Setting **session_idon the Client (Stateful) This pattern is useful in scenarios where a client instance or process is dedicated to a single, stateful conversation (e.g., a worker process, a desktop application, or a chatbot object). You set thesession_idonce on the client and then clear it when the conversation is over.
Persisting Data for Analytics (save=True)
The save parameter controls whether the full details of a scan (input, output, verdict, etc.) are persisted in the Argus Platform.
save=True: This is the standard for production environments. It populates your Argus dashboard with the data needed for analytics, log investigation, and model performance monitoring. Anasset_idis required to save data.save=False: This is useful for development, testing, or scenarios where you do not want to clutter your production analytics. You can perform a scan and get a verdict without the record being stored.
save=True by default but override to save=False for requests coming from a developer’s test script. |
