OIDC identity and gateway RBAC
srasta-api validates OIDC JWTs through discovery and JWKS, maps tenant and role claims,
and enforces gateway permissions across inference, RAG, tools, sessions, audit, and admin routes.
Security Review
Srasta is self-hosted by design. The inference path, admin plane, memory services, tool gateway, audit logs, and backups run in the customer's environment. The security model is not a promise to route sensitive AI traffic through Srasta SaaS. It is a product architecture that keeps the AI data plane inside customer-controlled infrastructure.
These are grounded in the current codebase and deployment artifacts, not just roadmap intent.
srasta-api validates OIDC JWTs through discovery and JWKS, maps tenant and role claims,
and enforces gateway permissions across inference, RAG, tools, sessions, audit, and admin routes.
Internal services can run in forwarded-auth mode. The gateway signs X-Srasta-*
principal headers with HMAC-SHA256 and a short timestamp window so downstream services can verify
that identity context came from the gateway.
Gateway and tool/RAG audit writers record structured JSONL events with request correlation and SHA-256 chain hashes. The chain can be verified to detect log tampering.
The tool gateway enforces repository allowlists, branch rules, path denylists, command allowlists, persona gates, role gates, execution timeouts, and patch-size limits before tool execution.
Admin telemetry is intentionally allow-listed to counts and deployment shapes. The daemon explicitly excludes prompts, responses, retrieved documents, audit-log content, secrets, stack traces, hostnames, and customer infrastructure IPs.
The srasta-security engine checks for disabled auth/RBAC, weak internal secrets,
default MinIO/Postgres credentials, rate-limit posture, exposed admin ports, license expiry, and
package vulnerabilities.
Inference routes through the customer deployment. Srasta supports local vLLM/Ollama paths and OpenAI-compatible routing, so security teams can review model access and routing inside their own environment.
Installer and control-plane APIs cover topology, handoff credentials, backup sets, backup verification plans, restore plans, rollback plans, and recovery readiness signals.
Admins manage users, roles, runtime health, licenses, config, release identity, support bundles, and operational telemetry status from the customer-controlled install.
Gateway, tool, RAG, and admin events create the evidence path for model access, policy decisions, memory/tool usage, auth failures, authorization denials, and rate limits.
These documents remain the buyer-facing packet. The page above explains how they tie back to the current implementation.
Not ready for a pilot yet?
Some teams need a specific control, integration, export, approval workflow, or review artifact before they can sponsor a pilot. Send us that signal now, or subscribe for product and security updates while you evaluate.
Srasta has not completed SOC 2 attestation yet. The current buyer-review packet is the architecture artifact, controls matrix, CAIQ Lite, privacy policy, and SOC 2 roadmap. The roadmap targets SOC 2 Type I by Q1 2027 and SOC 2 Type II by Q4 2027, with controls mapped honestly as implemented, partial, or planned.