Cloud Agentic Security
Autonomous cloud security for complex enterprise environments.
Increase coverage without scaling analyst workload at the same rate.
The problem it solves
The cloud security problem is no longer visibility. It is execution.
Security stacks are fragmented
71% of organizations use more than 10 cloud security tools, and 16% use more than 50. Coverage exists, but context remains split across separate systems.
Alert volume overwhelms teams
Nearly half of organizations receive 500+ security alerts per day, and about 1 in 4 receive 1,000+. More findings do not automatically mean better prioritization.
Detection still happens too late
Only 35% of incidents are identified by security tools, and just 9% are detected within the first hour. Critical signals can remain buried across tools and telemetry.
Remediation moves slower than attackers
62% of organizations take more than 24 hours to remediate breaches, while nearly 1 in 5 incidents see data exfiltration within the first hour.
Identity risk remains systemic
IAM-related factors contribute to 41% of incidents, while 99% of cloud identities have permissions unused for 60+ days. Least privilege remains difficult to maintain at cloud scale.
Attack paths remain exposed
76% of organizations have at least one public-facing asset capable of enabling lateral movement, and 36% have assets connected to 100+ attack paths.
Capabilities
Built for autonomous execution in real enterprise environments
A dedicated machine for every agent session
Each session runs inside its own Linux microVM: a complete execution environment, not a constrained tool sandbox. Any model, tool or credential can operate inside it.
Controlled access to your environment
The sandbox reaches external systems only through your own egress and network policy. Agents work across your infrastructure without bypassing the controls already governing it.
One operational view across your cloud estate
Continuous visibility across multi-cloud, Kubernetes, SaaS and hybrid infrastructure — assets, identities, permissions, vulnerabilities and runtime signals in one working context.
Specialized agents for every task
Complex operations decompose into specialized micro-agents, each with one defined responsibility, and every action stays traceable through the execution pipeline.
Safety enforced around the model
Frontier models run inside an execution harness that controls what they can access, call, modify and persist. Safety is enforced at the system layer, not left to the model.
Identity and authority for every agent
Every agent carries its own identity, scoped credentials and short-lived delegation, so actions attribute to the agent, the workflow and the user — never a shared account.
Features
What the platform does, one surface at a time.
Asset knowledge graph
Your account as a graph, not an inventory list
Cloud and security data is normalized into one graph of the account: services, the identities that can reach them, and the relationships between them — resolved continuously as the environment drifts.
- Every resource and relationship in one model
- Network, identity and data edges together
- Reconciled against what is actually running
Reasoning over the graph
Agents walk the path an attacker would
An agent traverses the graph hop by hop, testing each step against effective permissions and runtime activity, until it can say whether a path is genuinely reachable and what it reaches.
- Each hop validated, not inferred
- Hypotheses tested in a sandbox
- A conclusion with the evidence attached
Findings
Findings ranked by what they actually reach
Every validated finding carries its status, the blast radius computed from the graph, and a criticality that reflects reachable impact rather than the severity of the rule that fired.
- Blast radius computed, not estimated
- Status from triage through validation
- Ranked by reachable impact
Remediation lifecycle
From discovery to closure, with the simulation in the middle
A finding moves through a defined lifecycle: triage, risk assessment, investigation, blast radius analysis, a remediation plan, then execution — simulated first, approved at your boundary, validated afterwards and closed with the evidence.
- Simulated before anything changes
- Approved inside the policy you set
- Validated, then closed with a record
Enterprise use cases
Automate high-cost security work without removing control.
Cloud exposure analysis
Identify exploitable paths across cloud configuration, network access, identities, vulnerabilities, and data.
Autonomous investigation
Investigate security conditions across cloud, identity, workload, endpoint, and security telemetry.
Identity risk analysis
Determine effective access, privilege escalation opportunities, dormant privilege, and toxic permission combinations.
Vulnerability prioritization
Prioritize vulnerabilities using reachability, exploitability, privilege, business context, and downstream impact.
Cloud misconfiguration analysis
Determine which configuration failures create meaningful exposure rather than generating undifferentiated findings.
Threat investigation
Collect and correlate evidence across multiple security systems automatically.
Data exposure analysis
Identify how sensitive information can be reached through assets, identities, applications, or compromised workloads.
AI and agent security
Discover and govern enterprise agents, models, tools, machine identities, MCP infrastructure, and data access.
Autonomous remediation
Execute approved corrective actions with defined policy, permissions, rollback procedures, and human approval where required.
How it compares
Built for the whole security lifecycle, not one part of it.
Eighteen capabilities across the lifecycle of autonomous cloud security and the architecture that makes it safe to run, compared with the platforms teams evaluate most.
| 18 evaluated features | DLDevence Lab18 / 18 | Microsoft9 / 18 |
|---|---|---|
| Lifecycle phases | ||
| Connection & access | Supported | Partial |
| Recon & modeling | Supported | Supported |
| Capability loading | Supported | Supported |
| Assessment & detection | Supported | Supported |
| Risk prioritization | Supported | Supported |
| Remediation planning | Supported | Supported |
| Impact simulation | Supported | Not supported |
| Controlled execution | Supported | Partial |
| Governance & audit | Supported | Supported |
| Architecture dimensions | ||
| Agent execution architecture | Supported | Supported |
| Deterministic execution harness | Supported | Partial |
| Sandboxed analysis runtime | Supported | Not supported |
| Specialized multi-agent system | Supported | Supported |
| Runtime-grounded context | Supported | Supported |
| MCP / external agent interface | Supported | Not supported |
| Human approval / autonomy modes | Supported | Partial |
| Pre-change safety / rollback | Supported | Partial |
| Cryptographically tamper-evident audit | Supported | Partial |
- Supported
- Partial
- Not supported
Evaluated September 2026.
Works with your current stack
Add an intelligence and execution layer without replacing your existing controls.
Cloud Agentic Security connects to the systems already generating security context.
- 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
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 model
Start with observation. Expand autonomy as evidence builds.
- 01
Connect
Integrate selected cloud environments and security systems.
- 02
Model
Build the unified representation of the environment.
- 03
Observe
Operate initially without autonomous changes and establish baseline performance.
- 04
Configure
Define security policy, workflows, agent permissions, risk thresholds, and approval boundaries.
- 05
Pilot
Deploy selected use cases under human supervision.
- 06
Measure
Compare investigation quality, coverage, time, and analyst workload against the existing process.
- 07
Scale
Expand automation and autonomous execution where performance and governance requirements are satisfied.
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.
Business case
What it is worth against your own numbers.
A bottom-up model of the hours your team spends on investigation, remediation, incident response and compliance, and what automating them returns. Nothing here assumes a price: enter your own budget and it works out payback.
01 / 09
Organization profile
58 figures, all of them live
The result on the right updates as you type; nothing waits for the last step.
FAQ
Questions security teams ask
No. It connects to them. The platform reads from your cloud, identity, detection and engineering systems as sources of evidence, and where you permit it, uses them as execution surfaces. Your existing controls stay in place and keep governing what an agent can reach.
Whatever you have defined and nothing else. Every agent runs with its own identity, scoped credentials and a short-lived delegation, inside an approval boundary you set. A remediation is simulated for blast radius and rollback, and held for a named approver before it runs.
Because the platform shows its work. A finding arrives with the path it walked, the evidence gathered at each hop, and the blast radius computed from the graph rather than inferred from a rule's severity. If a path cannot be validated, it is not raised as one.
Each agent session runs in its own isolated microVM and reaches your environment only through your defined egress and network policy. It sees the systems you connect and nothing outside that boundary.
Findings carry their control references, so one exposure maps to CIS, NIST CSF, NIST SP 800-53, MITRE ATT&CK and D3FEND at the same time, and every remediation action records the control it answers. The mappings support your programme; they are not a compliance attestation.
Connect a defined part of your stack, run the platform against real workflows in observation mode, and measure investigation quality, coverage and time against your current process before any autonomy is enabled.
Talk to sales
Evaluate it on your own environment
Connect Cloud Agentic Security to a defined part of your stack, run it against real workflows, and measure the outcome against your current operating model.