Autonomy with enforced limits
DeepEngine assumes that an AI must not be trusted blindly. Whatever an agent wants to change passes your policy first, and a sensitive step requires a human decision.
Reasoning and execution are separated by design
Agent sandbox
at DeepEngine- The agent reasons here
- One isolated container per thread
- Evaluates every action against your policy
Worker
on your system- No model and no provider keys
- Connects outbound only
- Executes permitted actions only
Policy engine
Restrictions deny an action or require an approval: for commands, file changes, clicks in an agent’s browser and calls to connected services. A simulator shows what a rule would do.
Autonomy per agent
Ask first, accept edits, or auto. The level covers what no rule decides, and there is no setting that switches rules and approvals off.
Zero-trust workers
The worker on your system is a small process. It connects outbound only, holds no model and no provider credentials, and accepts nothing but signed, short-lived permits.
Verifiable audit trail
Every event goes into an append-only log chained by hashes, and a check confirms the chain is intact.
Hosted in Switzerland, inside a high-security bunker
DeepEngine runs in a high-security bunker data center in Switzerland. Both are ISO 27001 certified: the data center, and we ourselves. The place your agents work from is as protected as the rules they work under.
- Hosted in SwitzerlandThe platform and the data it stores are hosted in Switzerland.
- High-security bunker data centerThe servers stand inside a bunker, behind rock and controlled access.
- ISO 27001 certifiedTwice over: our own information security management system is certified, and so is the data center.
See what your policy would decide
Restrictions are plain rules: deny, or require an approval. Everything else follows the agent’s autonomy level. The product has a simulator for them. This is a small version with four example rules.
Example rules
- DenyDeleting volumes
- Require approvalChanges in namespace production
- Require approvalRestarting services on database servers
- Require approvalBot browser: buttons named *pay*
Needs approval
- Matched rule
- Bot browser: buttons named *pay*
- What happens
- The agent waits. The click appears in Approvals and happens once a person approves it.
Controls in detail
- Agent browser
- It reaches the public web or only the addresses you allow; internal networks and private addresses are always blocked. A Vault login is filled in only on its own site, and the agent never sees the value. You can watch live, take control, and clear the saved sign-ins.
- Connected services
- After connecting a service, tools that only read run right away and everything else asks a person first. You decide which agents may use a connection, and its key is kept in the Vault.
- Access to systems
- Each agent and channel is granted the workers it may use. On Kubernetes you can limit namespaces and actions, and root access has to be switched on explicitly.
- Runtime isolation
- An agent runs in one container per thread: not as root, read-only, without extra capabilities and without access to the host’s files.
- Secrets
- Secrets are stored encrypted and cannot be read back. An agent gets a secret only for the run that needs it. SSH private keys never reach the model, and credential patterns are removed from prompts.
- Tenant separation
- Data is separated per organization in the database, and each organization has its own memory.
- Identity and roles
- People sign in with a password or a passkey. Roles are owner, admin, engineer and viewer, and service accounts have fixed roles.
What leaves DeepEngine
Agents run on Claude or Codex. Requests to the model go to its provider, Anthropic or OpenAI, with the key configured for your organization. Voice calls use a speech provider with your organization’s own key.
Put your first agent into production
Talk to us and follow an agent from the first request to completed, audited work.