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 is a single-perimeter governed AI platform. The runtime, memory, vector store, audit trail, tools, identity, and operator workflows run inside infrastructure the customer controls: their VPC, cluster, on-prem hosts, or single-node installation.
Trust Boundary
The customer perimeter is the primary security boundary.
Users, tools, models, memory, storage, and audit are governed through a single customer-controlled runtime. Optional outbound paths are explicit, visible, and operator-configurable.
Inside the Perimeter
Srasta runs as a governed runtime, not a hosted middleman.
The main services run inside the customer environment. They are packaged as containers or Helm-managed workloads and share one operating story: identity-aware entry, governed execution, local storage, local audit, and operator-controlled egress.
Execution
RAG API, Tool Gateway, LiteLLM routing, vLLM or Ollama local inference, and persona-scoped policy.
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
Only used when operators configure external routes. Model access can be governed by role and persona.
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 embedded 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?
Customer data lives inside the customer-controlled deployment: customer VPC, cluster, on-prem hosts, storage, vector database, and audit volumes. Srasta does not route customer prompts, documents, responses, audit records, or backups through Gandiva infrastructure in normal operation.
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.
The public page explains the data-flow model. The downloadable artifacts provide deeper evidence for security teams, auditors, and design partners.