Security

Workers (today)

• Its own budget, with a hard stop. A worker's budget moves from your balance into the worker when you hire it. It is checked before every wake and again during it: when the budget runs out, the worker stops, even mid-wake, and you get a worker.out_of_budget event. It never draws on the rest of your balance. Unspent budget comes back when you fire it.
• Only the sites you list. A worker can open pages only on the sites in its list, over https. Everything else is refused, including private and internal addresses, and every refusal is logged.
• Only the actions you grant, with your approval. A worker can act only through the connected-tool actions you pick for it (for example, “send an email” through Zapier). Each action waits for your approval, showing the exact details, unless you allow that action to go ahead without asking. Approving runs exactly what you saw, once. Requests expire after 7 days.
• Never holds your credentials. A worker has no access to your account, your API keys or your other workers. The full address and key of a connected tool server are encrypted when you add them (AES-256-GCM), never returned by the API (only the site name is shown), and never given to a worker: it only names the action, and Auxen makes the call.
• Link check. Before a worker sends a message or takes an action, every link in it must come from a page it actually read that wake; otherwise it's refused.
• Code runs (only if you allow them) happen in a sealed space with no internet access, deleted right after the run.
• What we can see. To run a worker, Auxen stores its job, notes, messages, wake log and approval requests. Staff can see a worker's wake log for support and to investigate abuse; secrets are redacted from it. Staff tools never show connection keys or full addresses.
• Retention. A fired worker's notes, messages, wake log and approval requests are deleted 30 days after you fire it. The money ledger and the log of refused sites are kept with your account's billing and security history.
• Workers think on models Auxen runs, shared between workers, and are never used for training. To report a worker being misused, use the report form.

Spending limits (today)

• Workers: each has its own budget with a hard stop (above).
• Model deployments: set a spending cap per deployment (PATCH /v1/deployments/{id}/spending-cap). When it's reached, the deployment is suspended and billing stops.

Tenancy + isolation (today)

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

Data handling (today)

• Erased on delete. When you delete a deployment, 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-deployment attachment means each deployment only sees the documents you explicitly attach.
• All browser and API traffic is HTTPS-only (encrypted in transit). Traffic between our servers and your deployment goes over the hosting provider's private network layer plus an API key.
• Stored secrets. Agent management keys (auxen_live_… / auxen_test_…) are stored only as one-way hashes. Deployment keys (auxk_…) and tool-server addresses and keys (for workers and for model tools) are encrypted with AES-256-GCM; deployment keys are matched by a one-way hash. Full encryption of all stored data at rest is on the roadmap.

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 deployment; auxen_live_… / auxen_test_… tokens authorize account-level operations (deploy, list, delete).

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, hosting-provider credentials) live in the host's protected environment store, not in source code or configuration files committed to version control.

The Anthropic key is used only to write setup text (a worker's job from what you type in the guided hire setup, and a system prompt from your onboarding answers); it never answers requests to your model or does your workers' work. See the privacy policy.

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.

• Account-wide spending limit across all deployments (per-deployment caps and worker budgets are live, above).
• Full at-rest encryption of all stored data.
• 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]. To report a worker or deployment being misused, use the report form.