Profile
Manage your display name and profile information.
OmniSense Integration
Connect your SIRP OmniSense tenant to query live incidents, run agents, and execute response actions.
https://your-company.sirp.io)Email + password: Enables multi-tenant switching and JWT-based features. May conflict with browser sessions.
Both: Best of both worlds. API key for data, credentials for admin features.
| Query incidents, alerts, cases | API key or credentials |
| View assets and risk scores | API key or credentials |
| Run agents (enrichment, analysis, triage) | API key or credentials |
| Execute actions (block IP, contain host) | API key required |
| Multi-tenant switching (MSSP) | Credentials required |
| Threat advisory feed ingestion | API key or credentials |
Enabled Apps & Actions 0
Apps and actions available on your connected OmniSense tenant. Click any card to expand and see the underlying actions.
OmniSense Agents 0
AI agents available on your connected tenant for automated analysis and response. Capability chips show each agent's active modules.
SARA's Capabilities
Everything SARA can do — automatically selected based on your question. Free tools below; OmniSense connection unlocks per-tenant agent execution.
Investigation Skills
Skills transform SARA into a specialist. When active, SARA uses an agent loop with tools instead of the standard pipeline — investigating step by step like a senior analyst.
How Skills Work
- Standard mode — SARA runs a fixed pipeline: analyze → enrich → respond in one shot
- Skill mode — SARA uses an agent loop: call tools → examine results → decide next step → iterate up to 12 times
- Each skill defines: investigation steps, preferred tools, output format, and hard rules
- Activate from the welcome screen (skill pills) or here
- Deactivate to return to standard mode
SARA's Memory
SARA remembers your preferences, corrections, and investigation patterns to personalize responses across sessions.
Add a Memory
Stored Memories (0)
Untagged Memories 0
These memories were created before tenant scoping. Assign each to a tenant so they're recalled correctly when you switch tenants. Otherwise they stay visible from every tenant context (legacy fallback).
Untagged Projects 0
Projects created before tenant scoping (or via a path that didn't tag the tenant). Assign each to the right tenant so they appear only in that tenant's sidebar.
Untagged Investigations 0
Investigations not bound to a tenant — usually chat-shortcut creates from before PR #449 closed that leak. Assigning binds them to the right tenant view; otherwise they stay visible from every tenant context.
How Memory Works
- Preferences — "I prefer EPSS over CVSS" → SARA prioritizes EPSS in CVE analysis
- Corrections — "10.0.0.0/8 is our internal range" → SARA won't flag as malicious
- Expertise — "I'm a senior SOC analyst" → SARA adjusts detail level
- Context — "We use CrowdStrike + Splunk" → SARA references your stack
- Patterns — "I always check SPF/DKIM first" → SARA learns your workflow
- Memories decay if not accessed — confidence drops 20% per week
- Thumbs-down feedback with a comment auto-creates a correction memory
Privacy & Data
Your data, your control. SARA stores conversations to provide chat history — you can delete them anytime.
Delete All Conversations
Permanently delete all your saved conversations from both your browser and the server. This cannot be undone.
Delete Account
Remove your account and all associated data permanently — conversations, settings, API keys, integrations.
Billing & Plans
Upgrade your plan to unlock more messages, full enrichment, and OmniSense connectivity.
Current Subscription
Your usage limits -
Current usage at your plan tier.
Plan capabilities
What your plan enables. Unlimited means no daily/per-query cap; numeric values indicate the cap.
Message breakdown
Total messages sent across all sessions.
API Access
Programmatic access to SARA's intelligence. Use API keys to integrate with your SOAR, SIEM, or custom tools. View full API documentation →
Your API Keys
Quick Start
x-api-key header.
curl -X POST https://sara-open.sirp.io/api/v1/chat/completions \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"sara","messages":[{"role":"user","content":"What is CVE-2024-3400?"}]}'
Response format (OpenAI)
{
"id": "chatcmpl-abc123",
"object": "chat.completion",
"model": "sara",
"choices": [{"index":0,"message":{"role":"assistant","content":"..."},"finish_reason":"stop"}],
"usage": {"prompt_tokens":150,"completion_tokens":200,"total_tokens":350}
}
Python SDK example
from openai import OpenAI
client = OpenAI(base_url="https://sara-open.sirp.io/api/v1", api_key="YOUR_KEY")
r = client.chat.completions.create(model="sara", messages=[{"role":"user","content":"..."}])
print(r.choices[0].message.content)
curl -X POST https://sara-open.sirp.io/api/v1/chat \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"message": "What is CVE-2024-3400?"}'
Response format
{
"response": "CVE-2024-3400 is a critical...",
"mode": "threat_intel",
"sources": ["Knowledge Base", "NVD"],
"iocs_detected": [],
"remaining_this_hour": 499,
"hourly_limit": 500
}
curl -X POST https://sara-open.sirp.io/api/v1/enrich \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"iocs": [{"value": "8.8.8.8", "type": "ip"}]}'
curl -X POST https://sara-open.sirp.io/api/v1/analyze \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"content": "EventID=4625 ...", "type": "alert"}'
Auth:
x-api-key: sara_... header on every requestMulti-turn: Use
{"messages": [...]} for conversation context
Connectors
Create custom webhook actions and connect external AI agents. Connectors start in dry-run mode for safety.
New Connector
Configure your connector's endpoint, triggers, and authentication.
Tenant Policies
Author tenant-specific rules that the assistant must follow when answering. Rules compile into a natural-language block injected at retrieval time alongside doctrine and KB content.
Current published policy
Quick start
Pick a tier below to load it as a starting point. Conservative (recommended for regulated/high-risk tenants) keeps a human in the loop on every destructive action. Balanced (most enterprises) automates tier-1 noise but still gates destructive ops. Autonomous-First (high-velocity SOCs) trusts the model on everything except critical-severity incidents. Stack Weekend freeze or Compliance-heavy on top for situational guardrails. Loading a sample replaces your current draft — confirm before clicking.
How policies work Click to expand
Each policy is a list of rules. Every rule reads as when [trigger] then [effect]. SARA evaluates the rules against every response and applies the matching effects (require approval, force a disclaimer, block, etc.).
Triggers — five kinds, plain English:
- Classification confidence below — fires when SARA's own confidence in the answer drops below a threshold (e.g.,
0.7). Good for forcing disclaimers on shaky answers. - Action type in — fires when the response involves running an action of a given type (e.g.,
block_ip, isolate_host, disable_user). Good for gating destructive ops. - Tenant tier equals — fires when your tenant's tier matches a string (e.g.,
regulated). Useful if the same SARA serves multiple tenants with different policies and you want to opt in by tier. - Incident severity in — fires when SARA is reasoning over an incident with one of these severities (e.g.,
critical, high). Good for "critical incidents need an extra approval". - Day of week in — fires only on specified days (e.g.,
sat, sun). Useful for weekend / off-hours operational freezes.
Effects — five kinds, what SARA does when a trigger fires:
- Require approval — SARA prepares the response but won't proceed without explicit human approval. Value names the role/tier (e.g.,
T2,SOC manager). - Require ack from role — softer than approval; a designated role must acknowledge. Value names the role.
- Block — SARA refuses with the value as the reason. Use sparingly; this is a hard "no".
- Force disclaimer — SARA still answers but prepends the value text as a disclaimer. Good for low-confidence cases.
- Require citation — SARA must cite a source. Value is a free-text reminder shown to the analyst.
Tips:
- Start small. One or two rules cover most of the value; long policies become hard to reason about.
- Use force disclaimer first, escalate to require approval only if the disclaimer isn't enough.
- For multi-value triggers (action type, severity, day of week), enter values comma-separated:
sat, sun. - Confidence threshold —
0.7is a good starting balance; lower if you're seeing too many disclaimers, raise if you're seeing too few. - Click Validate before publishing — the rule grammar is strict and the backend rejects malformed rules with a clear error message.
Draft
Build rules with the dropdowns below. Each rule reads as when [trigger] then [effect]. Validate before saving — the backend rejects malformed rules.
Preview (what the LLM will see)
This is the natural-language block that gets injected into context — see how it will look formatted before approve.
Publish
Pending approvals
Version history
All versions, newest first. Click Restore on a superseded version for one-click rollback (D2c).
Members
Users on your OmniSense tenant. Pulled live from OmniSense (source of truth for org membership). The SARA Role column controls policy authoring + retrieval permissions inside SARA — independent from OmniSense's org-level role today; will sync later.
| Name | OmniSense Role | SARA Role | Queries | Last seen | Status |
|---|
Tenant usage at a glance
SARA-side usage for your tenant. All metrics are scoped to your tenant and refresh on click.
Top modes (last 7 days)
Which response modes your tenant uses most. Surfaced from thumbs-up/down feedback events; modes with no feedback are absent.
Member leaderboard
Ranked by lifetime queries on this tenant. Per-window columns show recent activity.
| Name | SARA Role | Total | 7d | 24h | Today | Last seen |
|---|