Applied research lab
Infrastructure for production autonomy at enterprise grade for Enterprise.
Devence Lab is an applied research lab accelerating the development and deployment of autonomous AI solutions for enterprises operating where failure is not an option.
Our approach
We design autonomous systems as production infrastructure
The model provides intelligence; the surrounding system defines authority, execution boundaries, observability, and recovery.
Bound authority
Agents never inherit more access than the task requires
Identity and authorization are first-class components of the system, not an afterthought behind a shared service account. An organization controls not only what an agent can do, but where, for how long, and on whose behalf.
- Dedicated machine identity per agent
- Short-lived, task-scoped delegation
- Revocable authority, least privilege
Enforce outside the model
Safety decisions do not depend on the model choosing to behave
Enforcement lives in the execution infrastructure around the agent. The agent may propose an action; the system decides whether that action is allowed to execute. That separation is what makes autonomous behaviour governable.
- Policy engines and permission checks
- Runtime isolation and resource limits
- Approval gates and intervention paths
- The agent starts when the request is sent.
Attribute every action
The chain from intent to execution is captured in full
User or workflow, agent identity, model decision, retrieved context, tool call, authorization, external action, resulting state. At enterprise scale, observability is part of the execution architecture rather than a monitoring add-on.
- Auditable from intent to outcome
- Debuggable across agent handoffs
- A system of record for autonomous work
Capabilities
What we build across the stack
Devence Lab works across the full stack required to design, deploy and operate autonomous systems inside complex organizations.
01
Autonomous system architecture
Agentic systems designed around real enterprise workflows, decomposed so that responsibilities, authority and failure modes stay explicit.
- Single-agent and multi-agent architectures
- Long-running workflows and persistent execution
- Retrieval, memory and human-agent coordination
02
Agent identity and authorization
Every autonomous actor gets a distinct identity, scoped credentials and explicit delegation linked back to the user, service or workflow that initiated it.
- Least-privilege access per agent
- Attribution, revocation and containment
- Forensic reconstruction after the fact
03
Execution isolation
Agent sessions, tools, processes and data access are isolated so that failures stay bounded and no single task can reach the whole estate.
- MicroVMs and sandboxed runtimes
- Ephemeral environments, scoped secrets
- Restricted network and file access
04
Policy and control enforcement
Deterministic controls placed around non-deterministic systems, so autonomy can grow without granting unrestricted operating freedom.
- Which tools may be called, and where
- Which actions require an approval
- What is reversible, and when to stop
05
Evaluation at system scale
Behaviour measured over complete operational trajectories rather than benchmark scores: how a system behaves repeatedly under production conditions, not whether it succeeded once.
- Planning quality and tool selection
- Permission compliance and escalation
- Long-horizon reliability, cost and latency
06
Observability and auditability
Every consequential action produces an inspectable execution record — a system of record for autonomous work that operations, security and compliance can all read.
- Tool calls, context and policy decisions
- Credential use and state changes
- Approvals and handoffs between agents
07
Multi-agent orchestration
Complex work decomposed into specialized agents with narrow roles: one investigates, another validates, another executes, another verifies the result.
- Separation of responsibility
- Narrower permissions per role
- Clearer execution paths to test
08
Enterprise integration
Autonomous systems operate where the work already happens, designed around the enterprise environment rather than around an isolated AI interface.
- Cloud, SaaS and internal APIs
- Identity providers and security tooling
- Ticketing, workflow and observability platforms
Works with your current stack
Add an intelligence and execution layer without replacing your existing controls
- Amazon Web ServicesAccounts, identities, workloads and data.
- Microsoft AzureSubscriptions, Entra ID and workloads.
- Google CloudProjects, IAM bindings and storage.
- KubernetesClusters, workloads and RBAC.
- OktaEffective access and entitlements.
- SplunkDetections and search across telemetry.
- DatadogRuntime signals and service context.
- GitHubRepositories, actions and infrastructure as code.
- TerraformPlanned and applied infrastructure state.
- JiraChange records and ticket workflow.
- SlackApprovals and notifications where the team already works.
- And many moreServiceNow, GitLab, Snowflake, Databricks, PagerDuty, Grafana and the rest of your stack through the API.
Supported models
Bring the models you have already chosen
The execution harness is model-neutral: an agent session can run on a frontier API, open weights on your own hardware, your cloud provider’s gateway, or a dedicated inference endpoint — with your key, in your account.
Frontier / proprietary
Called over the vendor's API with your key.
- OpenAIGPT-6 Astra, GPT-5.6 Sol
- AnthropicClaude
- GoogleGemini 3.8
- MistralMistral Medium 3.5
- DeepSeekDeepSeek V4 / V4 Flash
- CohereCommand family
- AI21Jamba family
- xAIGrok family
Open-weight / self-hosted
Run on your own hardware, inside your boundary.
- MetaLlama 4 Maverick
- MetaLlama 4 Scout
- MistralMistral Large 3
- MistralMistral Small 4
- Z.aiGLM 5.3 Open
- DeepSeekV4-family deployments
- QwenQwen family
- NVIDIANemotron family
- MicrosoftPhi family
- IBMGranite family
Hyperscaler / enterprise
Through the gateway your cloud contract already covers.
- AWS Bedrock
- Azure AI Foundry
- Google Vertex AI
- Databricks Mosaic AI
- NVIDIA NIM
Dedicated inference providers
Where latency or cost decides the deployment.
- Together AI
- Fireworks AI
- Cerebras
- Groq
- Baseten
- DeepInfra
- Modal
- RunPod
- SambaNova
- Replicate
- Hugging Face Inference Endpoints
Scaling autonomy safely
Increase authority as confidence increases
Autonomy should expand only when the underlying controls, evaluation results and operating evidence support it. That is what turns a pilot into production.
01
Observe
Understand the environment without taking action.
02
Recommend
Propose actions for human review.
03
Execute with approval
Perform actions after explicit authorization.
04
Bounded autonomy
Execute predefined classes of actions independently.
05
Continuous operation
Operate within defined policy, authority and risk boundaries.
06
Review and re-certify
Re-test the controls on a schedule, and pull authority back where the evidence no longer holds.
Built to scale inside the enterprise
Autonomy without uncontrolled authority.
Every agent, every human and every connection is administered in one place: who they are, what they may reach, and what is recorded when they act. Automation can grow across teams and environments without anyone losing track of the authority it carries.
- Identity, scope and approval per agent
- Directory, providers and sessions in one console
- Every action logged, attributed and revocable
Deployment options
Where it runs is your decision.
The same platform, four boundaries.
Choose by where the data has to sit and who has to operate it.
Deployment models
01
Devence Lab Cloud
Managed by Devence Lab. Nothing to host.
- Billed by the second, free tier to start
- US, EU, and APAC regions
- SOC 2 Type II, HIPAA
02
BYOC
Your account. Devence Lab operates it.
- Sandboxes and data stay in your VPC
- Your IAM, KMS, and audit logs
- Azure in development
03
Private cloud
The whole platform inside your boundary.
- Control plane in your account
- For air-gapped and sovereign networks
- Design partners welcome
04
Devence Lab Embed
The whole Devence Lab stack on one node.
- Ship it inside your product or a customer tenancy
- Docker Compose, Terraform on GCP, or Kubernetes
- Open source, Apache-2.0
Compare the models
What changes between them, and what does not.
Where the data sits, who holds the keys, how it is provisioned, and what each model is for.
TLS in transit on every model.
Devence Lab Cloud
- Data path
- Google Cloud, operated by Devence Lab. One microVM per session.
- Keys and storage
- Managed by Devence Lab on Google Cloud
- Provisioning
- Sign up
- Best for
- Most teams start here
BYOC
- Data path
- Client to your VPC, never through Devence Lab Cloud. Aggregate CPU and memory metrics and control-plane API traffic reach Devence Lab.
- Keys and storage
- Your IAM role, VPC, storage, and cloud audit log
- Provisioning
- Terraform and machine images. Devence Lab provisions, monitors, and operates the cluster.
- Best for
- Regulated data, selling into enterprises
Private cloud
- Data path
- Nothing leaves
- Keys and storage
- Yours
- Provisioning
- Terraform, inside your network
- Best for
- Air-gapped, sovereign, and on-prem networks
Devence Lab Embed
- Data path
- Control plane and Firecracker sandboxes on one node. Nothing leaves it.
- Keys and storage
- Yours
- Provisioning
- Docker Compose, Terraform on GCP, or Kubernetes
- Best for
- Self-hosting, embedding in your product, customer tenancies
| Compare | Devence Lab Cloud | BYOC | Private cloud | Devence Lab Embed |
|---|---|---|---|---|
| Data path | Google Cloud, operated by Devence Lab. One microVM per session. | Client to your VPC, never through Devence Lab Cloud. Aggregate CPU and memory metrics and control-plane API traffic reach Devence Lab. | Nothing leaves | Control plane and Firecracker sandboxes on one node. Nothing leaves it. |
| Keys and storage | Managed by Devence Lab on Google Cloud | Your IAM role, VPC, storage, and cloud audit log | Yours | Yours |
| Provisioning | Sign up | Terraform and machine images. Devence Lab provisions, monitors, and operates the cluster. | Terraform, inside your network | Docker Compose, Terraform on GCP, or Kubernetes |
| Best for | Most teams start here | Regulated data, selling into enterprises | Air-gapped, sovereign, and on-prem networks | Self-hosting, embedding in your product, customer tenancies |
SLA and support terms are set in your Enterprise agreement. support@devencelab.com on every plan.
SSO, SCIM, and RBAC are planned. Ask about timelines.
Security architecture
Containment is enforced by the system, not the prompt.
Six properties hold, whichever boundary you deploy into.
Each one is a property of the runtime around the model, so it survives a model that is wrong, jailbroken or replaced.
Isolation and enforcement
01
Tenant isolation
Every tenant and agent session is isolated by design, with workload, data, credentials, and execution context separated across customer boundaries.
02
Kernel-level sandbox isolation
Each session runs inside its own Linux microVM with a dedicated kernel. A compromise inside the sandbox still has to cross the virtualization boundary before it can reach the host.
03
Controlled network egress
Define allow and deny policies per sandbox, route traffic through your own proxy, and restrict public endpoints with authentication or signed access controls.
04
Secretless execution
Secrets are resolved only when required for an outbound request. They are not persisted in the sandbox, returned to the model, exposed in API responses, or written to logs.
05
Hard-enforced execution policy
Access, tool use, network calls, filesystem operations, privilege boundaries, and persistence rules are enforced by the system runtime around the model, rather than relying on prompt instructions or model compliance.
06
Enterprise observability and auditability
Export metrics and logs to your OTLP-compatible observability stack, stream lifecycle events through signed webhooks, and retain a traceable record of agent actions, identities, tool calls, and policy decisions.
Regulated deployment
Built for the rules you operate under
EU AI Act
NIST RMF
ISO 42001
Regulated deployment
Built for the rules you operate under
EU AI Act
NIST RMF
ISO 42001
Regulated deployment
Built for the rules you operate under
EU AI Act
NIST RMF
ISO 42001
Our assurance work is aligned to these frameworks. It is not a certification.
Industry
Assurance across every sector we serve
Finance
Compliance, fraud detection and risk systems built inside strict regulatory frameworks, with every decision traceable to a rule, a model and a reviewer.
Cyber security
Agents for threat analysis and intelligence synthesis, kept under human oversight and built to run away from the open internet.
Healthcare
Clinical decision support held to the highest evidentiary and safety standards, integrated via HL7/FHIR into the systems clinicians already use.
Telecom
Self-optimising networks and predictive capacity built for carrier-grade resilience, where a false positive costs as much as a missed one.
Government
Transparent, auditable systems deployable inside controlled environments, answerable to oversight bodies as readily as to operators.
Critical Infrastructure
Control systems for energy, water and transport with deterministic fail-safe guarantees, co-located with the operational technology.
From the lab
Read our recent published articles
What we are finding as we build and operate autonomous systems: architectures, failure modes and the controls that hold them.
Interpretability
Why Static Interpretability Fails on Multi-Step Agentic Decision Chains
A technical account of the mismatch between single-forward-pass interpretability methods and the failure modes of agents that plan, act, observe, and revise over many steps - grounded in published circuit-analysis literature, a controlled failure-attribution benchmark, and emerging graph-based tracing methods.
Assurance
The Agent Sandbox: A Reference Architecture for Isolating Autonomous AI Systems
An industry-neutral engineering reference on containing agents that browse, execute code, and act on the open internet - synthesized from disclosed CVEs, published isolation-technology internals, OWASP's agentic risk taxonomy, and the operating architectures of production agent-sandbox vendors.
Assurance
Runtime Monitors for Autonomous Systems: Detecting Drift and Misbehavior After Deployment
A methodological deep dive into why evaluation is not oversight, how the runtime-verification and machine-learning-monitoring traditions converge on autonomous language-model agents, and what the published, quantitative record says about how well post-deployment monitors actually work.
FAQ
Questions enterprises ask us
We build the infrastructure that makes autonomous AI safe to deploy and dependable to operate at enterprise scale: agent identity and authorization, execution isolation, policy enforcement, evaluation, and observability. The model supplies intelligence; the system around it decides what may run.
We design the architecture, build the control plane, and integrate it with the identity, cloud and approval systems you already run. Deployment follows a ladder — observe, recommend, execute with approval, bounded autonomy, continuous operation — and authority widens only when the evaluation results support it.
Dedicated machine identity and short-lived, task-scoped credentials per agent; isolated runtimes and microVM sandboxes; policy engines that check every tool call and action before it executes; approval gates on anything irreversible; and an execution record that ties each action to an agent, an authority and an outcome.
Architectures and control mechanisms for autonomous systems, agent security models, failure modes at scale, evaluation over complete operational trajectories, and interpretability applied to deployment decisions. Published work is on the research and articles pages.
Yes. Most engagements are agentic systems designed around a specific workflow rather than a general assistant — single-agent or multi-agent, with the tools, permissions and escalation paths that workflow needs, built to run inside your environment.
By placing enforcement outside the model. The agent proposes an action; policy, permissions, isolation and approval gates decide whether it executes. Nothing depends on the model choosing to behave, and every consequential action leaves an inspectable record.
Finance, cyber security, healthcare, telecom, government and critical infrastructure — sectors where an autonomous system has to answer to a regulator, an auditor or a safety case as well as to its operators.
A pilot is scoped to one workflow and one boundary. We connect to a defined part of your estate, run against real work under observation, and measure the figures that matter: findings handled without a person, time to investigate and remediate, and evidence produced automatically. You get the measurements whichever way the decision goes.
Write to sales@devencelab.com for a pilot, pricing or a procurement conversation, or contact@devencelab.com for anything else. The contact form reaches the same place. A reply comes from someone who works on the problem, normally within two business days.
Get in touch
Tell us what you're building
Whether you're exploring autonomous systems or strengthening an existing deployment, we're interested in the complexity behind your challenge.