Single gateway
External requests enter through Srasta API, where auth, authz, license posture, rate limits, and audit are enforced.
Security Model
Governance sits on the execution path, not beside it.
Srasta is designed for enterprise AI environments where useful work must happen under identity, policy, model-access, tool-control, audit, and recovery constraints. The platform makes those controls part of the runtime path before inference or tool execution occurs.
Enforcement Path
Every external request crosses the same control boundary.
Srasta keeps security decisions in the path of execution. A request that fails identity, authorization, license posture, rate limits, or model access does not reach the internal service that would act on it.
Control Layers
Security is layered across identity, model access, tools, and audit.
Srasta does not rely on one checkbox-style control. Each runtime surface has a purpose-built control and a corresponding evidence path for operators and security reviewers.
Identity and RBAC
OIDC-backed identity and signed principal headers carry user, tenant, and role context to internal services.
Model access
Per-role model whitelists prevent sensitive roles from reaching unapproved models or external routes.
Governed tools · planned
Any future tool pack will need validated role, workflow, path, command, sandbox, approval, and audit controls before it is supported.
Auditability
The audit trail is evidence, not decoration.
Structured events
Gateway and RAG activity, including auth, inference, admin, rate-limit, license, and access decisions, emits structured events.
Hash chain
Audit records are linked with SHA-256 chain hashes so deletion, edits, or reordering can be detected.
Operator visibility
Admin surfaces provide live audit review, filters, CSV export, health status, and security findings.
Optional export
Customers can forward audit events to their own S3 or SIEM sinks without moving the core data plane.
Supply Chain
Release provenance matters when customers run the platform themselves.
Self-hosted software still needs a verifiable delivery chain. Srasta's release model is designed around signed artifacts, vulnerability scanning, SBOMs, digest pinning, and operator-controlled upgrades.
Signed releases
Release artifacts are signed using Sigstore/Cosign workflows so customers can verify what they run.
SBOM and CVE scanning
Images are scanned and accompanied by software bill-of-materials artifacts for security review.
Digest-pinned deployment
Customer compose artifacts can pin image digests to avoid ambiguous runtime pulls.
Operator-controlled upgrades
Srasta does not silently update customer installations. Operators decide when to upgrade or roll back.
Security Boundaries
What Srasta deliberately does not do.
No SaaS data-plane dependency
Customer prompts, documents, completions, audit records, and backups do not need to pass through Gandiva infrastructure.
No tool capability assumed
Governed Tool Packs are planned. A supported release would require validated approval, path, command, and audit controls.
No hidden customer-data telemetry
Operational telemetry is counts and shapes only, and excludes prompts, responses, documents, audit content, and end-user identifiers.
No automatic update channel
Updates are explicit operator actions with verification and rollback paths.
SOC 2 Posture
Security review is backed by controls and evidence.
Srasta has not completed SOC 2 attestation. This page explains the runtime model in plain language; ask for current controls evidence and the attestation plan during your security review.
Current public posture
- No issued SOC 2 report yet.
- Current supported deployments are the single-node profiles in the public support matrix.
- Architecture, data-flow, security, and privacy pages are linked from the Docs hub.
- Request current controls evidence or a questionnaire response for your review.
FAQ
Security questions buyers usually ask first.
What is the Srasta security model?
Srasta uses a customer-perimeter security model: the runtime runs inside customer-controlled infrastructure, external requests pass through a gateway, and access, model use, audit, and license posture are checked before execution. Governed tool packs remain planned.
How does Srasta control model access?
Srasta enforces model access at the gateway with role-aware model whitelists and certified route controls, so teams can decide which roles may use local models, external models, or higher-risk capabilities.
How are tool actions governed?
Governed Tool Packs are a planned extension. A future tool path would need explicit role, workflow, approval, sandbox, and audit controls before a supported release.
How does Srasta support auditability?
Current gateway and RAG audit writers record structured events for auth, authorization, rate limits, inference, and admin actions. Audit logs are hash-chained for tamper detection; review optional export with the deployment team.
Trust Review
Use this page with the architecture and SOC 2 posture pages.
Together they explain where data lives, how execution is controlled, what is audited, and how buyers can evaluate Srasta before a pilot.