BUILT TO SURVIVE AN AUDIT.
Not a compliance checklist bolted on after the fact. The design constraint from day one was: prove it to an auditor. Every call traced, every secret isolated, every action enforced.
Air-Gapped Deployment
systemprompt.io ships as a single Rust binary that is its own token issuer and validator. It runs entirely on your infrastructure with a local Postgres database. There are no external API calls, no telemetry, no phone-home behavior. Your data never leaves your network.
This is not a SaaS product with an "on-prem option." The architecture is fundamentally self-contained. The binary includes the web server, API layer, job scheduler, AI orchestration, and admin dashboard. No sidecar services, no external dependencies beyond Postgres.
Plug your existing IdP in and the binary handles the rest. Tokens issued by the binary are embedded in the data ingestion layer, which means you can cryptographically trace usage by user throughout the entire system. Mapping RBAC roles to existing Okta or AD groups is table stakes.
- Single Binary, Own Token Issuer — One executable contains the entire platform and its own identity layer. No external auth service required. Plug your IdP in and go.
- Zero Outbound Connections — The platform makes no external network calls. All AI provider connections are explicitly configured and routable through your proxy infrastructure.
- Cryptographic User Tracing — Tokens are embedded in data ingestion. Every action is cryptographically tied to the authenticated user across the entire system.
Secrets Never Touch Inference
This is the problem most organizations have not cracked onto yet. With agents calling tools, secrets end up flowing through inference endpoints. API keys, database credentials, and tokens sitting in plain text in prompts. That is a massive attack surface.
systemprompt.io abstracts secrets through MCP services. The agent calls the tool, the MCP service injects the credential server-side, and the LLM never sees it. No secrets in context windows, no secrets in logs, no secrets leaking through prompt injection.
All secrets are encrypted at rest using ChaCha20Poly1305 AEAD with a per-user key hierarchy. Each user's secrets are encrypted with a unique derived key. Master keys are derived using Argon2id, a memory-hard function resistant to GPU and ASIC attacks. Keys never leave the server process.
- Server-Side Credential Injection — MCP services inject credentials at the tool layer. The LLM never sees API keys, database passwords, or tokens. They cannot leak through prompts or logs.
- ChaCha20Poly1305 AEAD — Authenticated encryption ensures both confidentiality and integrity. The same primitive used by WireGuard and TLS 1.3.
- Per-User Key Hierarchy — Each user has a unique encryption key derived from the master key. Isolation between users is cryptographic, not just logical.
Identity-Bound, Replayable Audit Trails
Every tool call in the audit trail is tied to the authenticated user, timestamped, and replayable. This is non-negotiable. When an auditor asks "who accessed what, and when," the answer is a database query, not a guess.
Tokens issued by the binary are embedded in the data ingestion layer. This means every action, every tool invocation, every secret access is cryptographically traceable to the authenticated user throughout the entire system.
Audit logs are stored in dedicated database tables: user_activity for general actions and secret_audit_log for secret access events. Queryable through the admin dashboard and exportable for your SIEM. Retention is configurable from 1 to 365 days.
- Identity-Bound Tool Calls — Every tool invocation is tied to the authenticated user. No anonymous actions, no shared service accounts hiding who did what.
- Replayable Events — Audit events contain enough context to replay the action. What was called, with what parameters, by whom, and what happened.
- Queryable and Exportable — Search by user, action type, date range, or resource. Export to CSV or JSON. Feed into your existing SIEM pipeline.
Policy-as-Code on PreToolUseHooks
The platform treats every tool invocation as a policy decision point, not an afterthought. PreToolUse hooks can abort a tool call before anything hits inference. Security teams can ship rules independently of the development team.
This is now natively integrated into Claude Code with HTTP hooks. Your policy engine evaluates every tool call against your rules before the call executes. Block unauthorized data access, enforce data classification boundaries, require approval for sensitive operations.
Policies are code, not configuration toggles. Version them, review them, test them, deploy them through your existing CI/CD pipeline. When the CISO asks "how do we prevent agents from accessing production databases," the answer is a hook that runs before every tool call.
- Pre-Execution Enforcement — Hooks abort before anything hits inference. Not after. Not in a log you review later. Before the action happens.
- Independent Security Rules — Security teams ship policy rules independently. No waiting on product releases. No coupling between governance and feature development.
- Native Claude Code Integration — HTTP hooks are natively supported in Claude Code. Your policy engine plugs directly into the tool invocation pipeline.
Data-Domain Scoping
Skills, plugins, and MCP servers are scoped by role and department. Finance sees finance tools. Engineering sees engineering tools. Down to which MCP servers are even visible to a given user.
This is not just RBAC at the API level. The entire tool surface changes based on who is authenticated. A finance-analyst sees a completely different set of capabilities than an engineering-lead. The tools that do not apply to your role do not exist in your session.
Access control is enforced in middleware on every request. A user cannot access another user's secrets, modify another user's skills, or view another user's analytics, regardless of how the request is constructed. Entity ownership is enforced at the database query level.
- Role + Department Scoping — Every skill, plugin, and MCP server is scoped to specific roles and departments. Users only see the tools that apply to them.
- Invisible by Default — Tools outside your scope are not hidden behind a permission error. They do not exist in your session. Reduced attack surface by design.
- Middleware Enforcement — Access control runs before your request reaches application code. No bypass, no exceptions, no race conditions.
Full Data-Plane Control
The platform sits in front of the API layer and every call goes through the policy engine. Who is calling, what data, what action, why now. This is the question every compliance framework asks, and the platform answers it structurally.
This is a serious piece of engineering built in Rust, fully auditable code for enterprise buyers who need to prove compliance. Rust memory safety eliminates entire vulnerability classes: buffer overflows, use-after-free, double-free, and null pointer dereferences. These are structurally impossible in safe Rust.
The build pipeline uses cargo audit to check all dependencies against the RustSec Advisory Database. The final artifact is a single statically linked binary. What you audit is what you deploy. Reproducible builds via Cargo.lock.
- Policy Engine on Every Call — Every API call is evaluated against your governance rules. Who, what data, what action, why now. Answered structurally, not retroactively.
- Rust Memory Safety — The compiler prevents buffer overflows, use-after-free, data races, and null dereferences at compile time. Not with sanitizers. At compile time.
- Cargo Audit and Reproducible Builds — Every dependency checked against RustSec. Cargo.lock pins every version. The same source always produces the same binary.
Compliance Framework Compatibility
systemprompt.io's architecture maps directly to controls required by major compliance frameworks. The platform does not certify your organization, but it provides the technical controls that auditors look for.
SOC 2: Air-gapped deployment satisfies CC6.1 (logical access controls). Secrets isolation maps to CC6.7 (data classification and protection). Identity-bound audit trails cover CC7.2 (system monitoring). Policy hooks address CC6.3 (role-based access).
ISO 27001: Secrets management maps to A.10 (cryptography). Data-domain scoping addresses A.9 (access control policy). Audit trails support A.12.4 (logging and monitoring). Data retention aligns with A.18 (compliance with legal requirements).
HIPAA: Server-side credential injection satisfies the encryption addressable specification under the Security Rule. Data-domain scoping maps to the access control standard. Identity-bound audit trails support the audit controls standard.
FedRAMP (on-prem): Air-gapped deployment enables FedRAMP authorization for on-premises environments. The single-binary architecture simplifies the system boundary definition. Policy-as-code hooks and audit trails map to NIST 800-53 access control and audit families.
- SOC 2 Type II — Technical controls for logical access, data protection, system monitoring, and role-based access. Map directly to Trust Services Criteria.
- ISO 27001 — Controls aligned with Annex A requirements for cryptography, access control, logging, monitoring, and legal compliance.
- HIPAA and FedRAMP — Secrets isolation, access control, audit trails, and data retention address Security Rule standards and NIST 800-53 control families.