Security

Tenancy + isolation (today)

• Each customer gets a dedicated GPU instance running their private model. No shared inference fleet. No third-party routing — your requests go directly from our proxy to your dedicated GPU on a single backing provider.
• Shared-Small is the only multi-tenant option. It runs on a single shared GPU at a clearly-labeled discount, opt-in only, and is the exception to the dedicated-tenancy default.
• Customer API keys are scoped to that customer's instance (auxk_…) or that customer's account (auxen_live_/auxen_test_). A per-instance key cannot be used against another customer's endpoint.

Data handling (today)

• Deleted on destroy. When you destroy an instance, its model state, attached Knowledge Base embeddings, and any conversation history scoped to it are removed.
• No training on customer data. Your prompts, completions, and uploaded documents are not used to train any model — ours or anyone else's.
• Knowledge-base storage. Documents you upload are stored per-customer on our application server and used only to serve your endpoint via retrieval. Per-instance attachment means each instance only sees the documents you explicitly attach.
• All browser traffic is HTTPS-only. Server-to-instance traffic goes over the GPU provider's private network layer plus an API key.

Authentication (today)

• OAuth 2.1 + PKCE on the public MCP server at api.auxen.ai/mcp — agents register via Dynamic Client Registration and obtain scoped access tokens. No long-lived secrets transit between client and server.
• Bounded API keys for non-MCP usage: auxk_… tokens authorize inference calls against a single instance; auxen_live_… / auxen_test_… tokens authorize account-level operations (provision, list, destroy).

Payments

Stripe processes all payment card data. Auxen never stores or sees full card numbers, CVVs, or bank details.

Secrets management

Platform secrets (Stripe keys, Anthropic key, GPU-provider credentials) live in the host's protected environment store, not in source code or configuration files committed to version control.

Incident response

We maintain an internal runbook for security incidents. If an incident affects customer data, we notify affected customers via email promptly with what we know, what's been contained, and what we recommend they do.

On the roadmap (not live yet)

We're calling these out so nothing is implied as current that isn't. We'll move each item to the section above as it ships.

• Billing guardrails: per-instance spending caps and account-wide max-burn limits, so an autonomous agent can't run up an unbounded GPU bill. Per-instance spending caps exist in the data model today; the user-visible enforcement + alerting is in active development.
• Public status / uptime page with verifiable incident history.
• SOC 2 Type I → Type II.
• Full sub-processor list with an update feed.
• Public security disclosure policy + security.txt.

Contact

Responsible disclosure or security questions: [email protected].