How Qoren secures managed agent environments

Subprocessors and third-party services

The services Qoren uses to operate the platform, and what each one touches.

Isolation: one environment, one machine

Every Qoren environment is a dedicated virtual machine provisioned for you on DigitalOcean, not a shared container pool. One client's or project's agents, files, logs, and the keys written to them live on their own machine, separated from every other environment you run and from every other customer. Within a machine, each agent runs under its own system user with enforced memory and CPU ceilings, so a runaway agent is contained twice: by its user boundary and by its resource limits.

• Dedicated virtual machine per environment.
• Dedicated system user per agent, with memory and CPU limits enforced by the service manager.
• No shared agents or workspaces across environments; vault keys saved to one client reach only that client's agents.

Secrets: encrypted at rest, revealed deliberately

Credentials you store in the vault are encrypted at rest with AES-256-GCM. Listings are write-only by default: the dashboard shows that a secret exists, not its value, and revealing a value is an explicit, audited action. Secrets reach an agent only when you give them to it or a template you deploy asks for them by name, and the deploy form lists every key it fills in from the vault. An agency can save a key to one client so that only that client's agents can receive it. SSH keys used to manage machines are stored encrypted and decrypted only into ephemeral files during use. Traffic between your browser, the platform, and agent machines is encrypted in transit.

• AES-256-GCM encryption at rest for stored secrets and SSH keys.
• Write-only listings; value reveals are explicit and audited.
• Per-agent injection, with every vault key listed on the deploy form, not blanket sharing.
• TLS in transit throughout.

Blast radius: what one compromised agent can reach

The platform assumes any single agent could misbehave and keeps the damage bounded. An agent sees only the credentials you gave it, on the machine of its own environment, under its own system user. Model spend draws from your credit balance and stops at the cap, so a looping agent cannot generate an open-ended bill. Health monitoring raises alerts when an agent's process fails, goes offline, or degrades, and current service status is public.

• Least-privilege by structure: per-agent user, per-environment machine, opt-in secrets.
• Hard spend caps; you are never billed for usage you did not pre-pay.
• Health alerts on failures, offline machines, and degraded agents.

Sources: Qoren service status

Account access

Sign-in supports GitHub and Google OAuth, email one-time codes, and passwords. Billing is handled by Polar; Qoren does not store full card numbers.

Your data: controller, processor, and the DPA

Magentic Studio is the data controller for your account data. For personal data your agents process on behalf of your business or your clients, you are the controller and Qoren acts as your processor, following your instructions and configuration. A data processing agreement is available on request. Data may be processed outside the EEA through subprocessors, protected by the European Commission's Standard Contractual Clauses. When you delete your account, associated data is removed in a cascade rather than orphaned.

• GDPR controller/processor split, stated plainly in the privacy policy.
• DPA available on request at hello@qoren.sh.
• EU-based operator; SCCs for transfers outside the EEA.

Reporting a vulnerability

If you believe you have found a security issue in Qoren, email hello@qoren.sh with the details and enough information to reproduce it. You will get a human response, and we ask for reasonable time to fix confirmed issues before public disclosure.