Entry and control
nginx, Srasta API, Admin, license posture, model access, RBAC, rate limits, and signed service headers.
Architecture & Data Flow
Srasta keeps the AI data plane inside the customer perimeter.
Srasta's current supported profiles are single-node deployments. Local inference, retrieval, audit, identity, and operator workflows run in the customer's environment. Hosted licensing, optional telemetry, and any operator-configured external model provider cross separate outbound boundaries.
Trust Boundary
The customer perimeter is the primary security boundary.
Users, model access, retrieval, storage, and audit are governed through the customer-controlled runtime. Membrane memory and the company agent harness remain roadmap concepts. Review optional outbound paths explicitly.
Inside the Perimeter
Srasta runs as a governed runtime, not a hosted middleman.
The main services run inside the customer environment. In current supported profiles, containers share a single host and one operating story: identity-aware entry, governed execution, local storage, local audit, and operator-controlled egress.
Execution
RAG API, LiteLLM routing, catalog-certified vLLM or MLX local inference, model policy, and audit evidence.
Data stores
Postgres for state, Milvus for embeddings, MinIO for objects and backups, Valkey for cache and limits.
Governance
Zitadel identity, audit JSONL, hash-chain verification, optional SIEM forwarding, and operator runbooks.
Data Locations
Every data class has a customer-controlled home.
Data class Where it lives Default behavior
Source documents Customer filesystem, ingest source, or MinIO Customer-controlled retention
Embeddings Milvus inside the deployment Stored until operator removes collection
Prompts and completions In memory by default; optional customer-owned tracing Not persisted by default
Audit records Local audit volume, optional MinIO archive, optional SIEM Hash-chained and retention configurable
Identity and operator config Zitadel and Postgres inside the deployment Managed by customer operators
Backups Customer MinIO or operator-configured external S3 No backup path to Gandiva infrastructure
Outbound Channels
Any data leaving the perimeter must be explicit.
External model providers
Used only when an operator configures an external route. Review the provider, data transfer, and access policy separately from the local profile.
Audit export sinks
Optional SIEM or S3 forwarding for audit events. Core audit still remains local when export is disabled.
License lifecycle
Runtime license verification is offline against the explicitly configured Srasta license public key. Issuance and renewal are control-plane actions.
Operational telemetry
Install and feature-use metadata only. No prompts, responses, documents, audit content, or end-user identifiers.
Failure Behavior
The architecture is designed to degrade visibly.
Srasta separates runtime execution, identity, storage, audit export, and license issuance so a problem in one area does not silently compromise the whole platform.
External LLM unavailable
External-routed requests fail clearly while local model routes can continue operating.
Audit export sink down
Local audit remains intact and forwarding can resume when the sink recovers.
License server unreachable
Running deployments are unaffected because runtime verification is offline by design.
Storage dependency down
Admin health and operator surfaces show degraded state instead of pretending the runtime is healthy.
FAQ
Architecture questions security reviewers ask first.
Where does customer data live in Srasta?
In a supported single-node deployment, local prompts, documents, responses, audit records, and backups stay in customer-controlled infrastructure during normal operation. External model providers, hosted licensing, and optional telemetry have separate boundaries.
Does Srasta require a SaaS data plane?
No. Srasta is designed as a customer-perimeter deployment. The runtime data plane runs inside the customer environment, while license issuance and optional operational telemetry are separate control-plane interactions.
What outbound traffic can exist?
Outbound traffic is operator-controlled: external model providers if configured, optional audit export sinks, license issuance or renewal, and optional operational telemetry that excludes prompt, response, document, audit-log, and end-user identifier content.
What is the main trust boundary?
The main trust boundary is the customer infrastructure perimeter. External users enter through the Srasta API gateway, where TLS, identity, RBAC, model access, license posture, rate limits, and audit emission are enforced before requests reach internal services.
Security Review
Use the architecture page as the front door for buyer review.
This page explains the data-flow model. For current controls evidence or a questionnaire response, contact us with the scope of your review.