Trust center
Concrete security and data-flow commitments for agentic work
Snipara optimizes context for AI agents. This page explains what enters the platform, how credentials and memory are scoped, where self-hosting changes the data boundary, and which security claims are intentionally not made.
Last reviewed: May 2026
01
Trust model
The operational boundary is simple: Snipara stores and retrieves context that a customer chooses to provide, returns compact cited answer packs to the agent, and leaves model choice with the customer. Hosted Snipara is the fastest path. Self-hosted Snipara is the path for customers that need the data plane inside their own infrastructure.
02
Hosted vs self-hosted data flow
| Area | Hosted Snipara | Self-hosted Snipara |
|---|---|---|
| Context upload | Selected documents, code, and metadata are sent to Snipara hosted services for indexing and retrieval. | The same context workflow can be operated inside customer-controlled infrastructure when self-hosted is required. |
| Optimized context | Snipara returns compact context, references, caveats, and source maps to the connected agent or application. | Optimized context is produced from the customer's own deployment and data plane. |
| LLM inference | Customers keep using their own LLM provider or agent. Snipara optimizes context; it is not the inference provider by default. | Customers choose and operate the model provider or local model path that fits their environment. |
| Operational control | Snipara operates the hosted API and web dashboard; customers manage projects, users, credentials, and selected sync sources. | The customer controls hosting, networking, backup policy, monitoring, secrets, and regional placement. |
03
What Snipara processes
Documents, code, and project context
Files or repository content that a user, team, integration, or sync workflow chooses to upload or index for context retrieval.
Retrieval metadata
Project IDs, document metadata, chunk references, source maps, quality signals, and freshness information needed to return grounded context.
Reviewed memory
Durable decisions, learnings, preferences, and session carryover that are intentionally written through memory tools or managed workflows.
Automation configuration
Client-specific MCP, instruction, and supported automation files generated by create-snipara or snipara-companion.
What Snipara does not do
- Snipara does not replace the customer's LLM or require model lock-in.
- Snipara does not ask users to commit secrets, API keys, or private tokens to a repository.
- Snipara does not make memory automatically trusted without review, scope, or expiry rules.
- Snipara does not claim every AI client supports native hooks; unsupported hook bundles stay disabled.
04
Credential handling
| Control | How it works |
|---|---|
| Environment variables | Local setup instructions use environment-backed keys such as SNIPARA_API_KEY instead of hardcoded secrets. |
| Server-side hashes | API key records store hashes and prefixes for lookup and display; raw keys are shown only at creation time. |
| Scope and expiry | Project, team, service-account, integrator, and OAuth credentials are resolved through scoped access checks, expiry checks, and revocation checks. |
| Client file safety | Generated agent setup files are client-specific. Unsupported native hook bundles are blocked instead of being installed silently. |
05
Project isolation
Context retrieval and memory tools resolve requests against authenticated project, team, user, integrator-client, service-account, or OAuth identity. The same boundary is used for documents, vector search, memory ownership, automation state, and agent session context.
For teams, project access and advanced permission controls determine which users and service accounts can read, write, or administer project context. For integrators, user-scoped memory requires an external end-user identity so one customer account cannot read another account's memory.
06
Memory governance
Reviewed
Durable memory should store reusable decisions, learnings, and preferences, not raw logs, secrets, or one-off noise.
Scoped
Memory can be scoped to project, team, user, or agent boundaries, with ownership metadata used during recall.
Expiring
Workflow memory can carry TTL guidance so stale session context does not become permanent product truth.
08
Sandboxed execution
Snipara Sandbox is the repeatable execution path for tasks that benefit from isolation: generated artifact checks, focused code experiments, risky validation, or final verification that should not depend on the main shell state.
Local agent hooks can execute commands in a repository. Snipara only installs native hook bundles for clients with verified support in the compatibility matrix; other clients stay on Hosted MCP, instruction files, and explicit companion commands.
09
Threat model and mitigations
| Risk | Mitigation |
|---|---|
| API key leakage | Use environment variables, store only hashes server-side, support revocation and expiry, and avoid printing raw secrets in generated files. |
| Overbroad project access | Resolve requests against project, team, service-account, OAuth, and integrator access before executing context or memory tools. |
| Stale memory or stale indexed context | Return source maps, freshness metadata, TTL-backed memory, review status, and caveats so agents can verify before relying on old context. |
| Prompt injection in uploaded material | Treat uploaded content as source material, not instructions. Prefer cited answer packs and explicit verification checklists for claims. |
| Unsafe local code execution | Use Snipara Sandbox for repeatable or isolated execution, and keep native hooks disabled for clients without a verified public hook surface. |
| Cross-project leakage | Keep documents, vectors, memory, automation state, and agent session context tied to project, team, user, or agent ownership. |
10
What we do not claim on this page
This page does not claim SOC 2, ISO 27001, HIPAA, FedRAMP, universal enterprise SSO, universal audit export, universal retention guarantees, or that hosted Snipara keeps all raw source local. Those claims require separate, current evidence and should be stated only where the implementation, contract, or deployment mode supports them.
11
Security contact
Report security issues to security@starbox-group.com. For privacy, contract, or DPA questions, contact legal@starbox-group.com.