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, model access, or tool policy 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.
Tool policy
Persona policy controls allowed tools, paths, commands, sandbox behavior, approval mode, and policy blocks.
Auditability
The audit trail is evidence, not decoration.
Structured events
Auth, inference, tool, admin, rate-limit, license, and policy decisions emit 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 relaxed tool bypass
Even permissive approval modes remain subject to tool policy, path rules, command rules, and audit emission.
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's public security page carries the dated SOC 2 commitment. The controls matrix maps SOC 2 Common Criteria to implementation and evidence, while this page explains the runtime model in plain language.
Current public posture
- SOC 2 Type I commitment by Q1 2027.
- SOC 2 Type II commitment by Q4 2027.
- Customer-perimeter architecture and data-flow artifact.
- Controls matrix and CAIQ Lite support for buyer review.
- Security, privacy, and compliance artifacts linked from the Docs hub.
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 single gateway, and access, model use, tools, audit, and license posture are enforced before execution.
How does Srasta control model access?
Srasta enforces model access at the gateway with role-aware model whitelists and persona routing, so teams can decide which roles may use local models, external models, or higher-risk capabilities.
How are tool actions governed?
Tool execution is constrained by persona-scoped policy: allowed tools, path deny lists, command allow lists, sandbox configuration, approval mode, and audit emission.
How does Srasta support auditability?
Srasta writes structured audit events for auth, authorization, rate limits, inference, tools, admin actions, license events, and policy blocks. Audit logs are hash-chained for tamper detection and can optionally be forwarded to customer SIEM or S3 sinks.
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.