Security by architecture, not by policy

When you create a Sprigr Team workspace, your company receives its own dedicated storage instances. Your agents run as independent stateful processes, each with its own persistent storage. There are zero shared databases. There are zero shared tables. There is no shared query layer between companies.

This is fundamentally different from how most platforms work. The typical approach is a single large database with row-level access controls where a single misconfigured query, a single injection vulnerability, or a single permission error can expose every customer’s data. In Sprigr Team, that scenario is architecturally impossible. Your data does not exist in any storage instance that another company’s agents can reach.

Access controls can be misconfigured. Physical separation cannot.

Storage: Encrypted at rest in isolated namespaces

Secrets are stored encrypted at rest in isolated per-company namespaces. No other company’s agent, no API endpoint, and no internal service can read the raw values from another company’s namespace. The storage boundaries are enforced by infrastructure, not by application logic.

Injection: Decrypted only at runtime inside isolated sandboxes

When an agent needs a credential to make an API call or connect to a service, the secret is decrypted and injected into an isolated sandbox environment at the moment of execution. The secret exists in memory only for the duration of the task. It is never written to disk, never stored in logs, and never included in database records.

AI-level defense: Platform directives that cannot be overridden

Beyond infrastructure controls, the AI itself has platform-level directives that refuse to extract, encode, transform, or display credential values. These directives are injected at the platform level. They are independent of any company-configured prompts, invisible to end users, and cannot be overridden by user instructions, prompt injection, or social engineering. They cover all encoding forms: base64, hexadecimal, reversed strings, URL encoding, character splitting, and any other transformation. The AI will refuse to write code that extracts credentials, not just warn about it.

Each code execution creates a fresh, isolated environment. There is no shared memory between agent instances or between companies. There is no filesystem persistence between runs. Each execution starts completely clean.

Network access is controlled and all requests are auditable. Each sandbox receives only the specific credentials authorized for that agent. Execution environments are destroyed after each task completes, leaving no residual data in memory or on disk.

A prompt injection that tricks the AI past its behavioral controls still faces infrastructure isolation. A vulnerability in sandboxing still faces encrypted storage. Each layer is a complete defense on its own. Together, they create a security posture that no single attack vector can defeat.

Most platforms store all customer data in a single shared database, relying on application-level access controls to prevent cross-tenant queries. A single bug in the query layer, a single injection vulnerability, or a single permission misconfiguration can expose every customer’s data at once. This is not a theoretical risk. It is the most common class of multi-tenant security vulnerability in the industry.

Credentials are typically stored as plaintext environment variables or in shared secret management services with software-level access policies. If the application server is compromised, every customer’s credentials are exposed simultaneously. There is no per-company isolation at the storage level.

Few platforms defend against credential leakage in agent output. If an agent is prompted into outputting a credential through social engineering or prompt injection, it appears in logs, API responses, and potentially user-facing interfaces with no automated defense in place.

Almost no platform implements AI-level behavioral controls against credential extraction. Typical AI agent platforms will comply with any sufficiently creative prompt to base64-encode, hex-encode, reverse, or otherwise obfuscate a secret in their output. Without platform-level directives, prompt injection is a reliable attack vector against stored credentials.

The result is a security model that depends entirely on things going right. One misconfigured policy, one overlooked query path, one creative prompt, and the defenses collapse. Sprigr Team is designed so that even when things go wrong at one layer, the others continue to protect your data independently.