# Adaptive — Full Website Reference > Adaptive combines Privileged Access Management (PAM), Database Activity Monitoring (DAM), and Identity and Access Management (IAM) in one control plane. It governs access to databases, servers, Kubernetes, cloud accounts, and applications for people, workloads, service accounts, and AI agents, with just-in-time privileges, data protection, and an identity-based audit trail. This is the expanded text companion to [the website index](https://adaptive.live/llms.txt). It brings together the current website overview, product descriptions, use cases, integration catalog, commercial information, and featured blog articles. Each section links to its source page. ## Platform Overview Source: https://adaptive.live/ The website describes this as security hyperconvergence: identity, data, infrastructure, access, and governance managed together. Adaptive brokers connections so users and agents can work through their existing clients, the Adaptive CLI, a browser, or MCP without receiving downstream credentials. Infrastructure access and data protection apply within the same session. Homepage headline: "Unlock security hyperconvergence." Adaptive connects human and non-human identities to resources through a shared policy and access layer. The platform covers privileged access, data activity monitoring, identity management, data masking, discovery and classification, credential rotation, access reviews, and agent governance. Teams can use native database clients, SSH, kubectl, the Adaptive CLI, browser sessions, and MCP clients. ### Capabilities Featured on the Homepage - **Govern agents through MCP:** MCP servers exposed through Adaptive; OAuth-authorized MCP access; Agent skills generated per endpoint; MCP access logs and review. ([details](https://adaptive.live/product/mcp)) - **Privileged sessions in the browser:** Terminal, RDP and VNC; Session recording and playback; Session, event and proxy logs. ([details](https://adaptive.live/product/access)) - **Role-based Access:** Read-only and read-write roles; Team and group assignment; Import existing database grants. ([details](https://adaptive.live/product/custom-access-policies)) - **Every query and command logged:** Full query and command audit; Preventive policies, enforced in-line; Database user management. ([details](https://adaptive.live/product/monitor)) - **Dynamic data masking:** Built-in masks for email, SSN, cards; Proxy-based, no database changes; Postgres, MySQL, MongoDB, SQL Server, Redshift. ([details](https://adaptive.live/product/protect)) - **Time-bound access, approved in Slack:** Single, multi-approver and auto-approval; Grants that expire, extend or revoke; Access schedules; Approve directly from Slack. ([details](https://adaptive.live/product/authorization)) - **Find sensitive data before it leaks:** Scans with reusable scan profiles; Data catalog and schema explorer; Data classes and labels. ([details](https://adaptive.live/product/discovery-and-classification)) - **Credential rotation:** Automatic password rotation; Firewalls and switches included; Password policies and history. ([details](https://adaptive.live/product/credential-rotation)) - **Approved scripts:** Curated script library; Execution behind approvals; Run history and output audit. - **Certification campaigns:** Reviewer, manager and owner sign-off; Revoke straight from findings; Completion tracking. ([details](https://adaptive.live/product/audit)) - **Access matrix and graph:** Who can reach what, at a glance; Event logs and triggers; Risk and posture dashboard. ([details](https://adaptive.live/product/audit)) - **Stream activity where you work:** Splunk, Datadog, Coralogix, Syslog; Alerts to Slack, Teams and email; Freshservice ticket creation. ([details](https://adaptive.live/product/siem-and-alerting)) - **Isolated browser sessions:** Managed browser isolation; Browser session recording; SSO app catalog. ([details](https://adaptive.live/product/browser-isolation)) - **Device inventory and posture:** Devices and machine IDs; Vulnerability scans; VPN monitoring. - **Evidence for every framework:** SOC 2, HIPAA, PCI DSS, ISO 27001, GDPR; Custom frameworks and controls; Compliance scans and reports. ([details](https://adaptive.live/usecases/accelerate-compliance)) - **CLI, Terraform and API:** adaptive CLI: connect, exec, scp; Declarative access grants; Terraform provider and REST API. ([details](https://adaptive.live/product/workloads)) ## How the Platform Works Source: https://adaptive.live/platform The control plane sits between privileged identities and the systems they access. It applies just-in-time access, approvals, masking, and an audit trail to users, workloads, and AI agents. ### Access Flow 1. **Agent requests access.** Your agent calls into Adaptive instead of holding long-lived credentials. 2. **Policy + approval check.** Adaptive evaluates the request against policy. High-risk actions route to a human approver. 3. **Brokered, scoped execution.** Just-in-time credentials are issued for that session only — to the database, cluster, cloud account, or service the agent needs. 4. **Captured and audited.** Every query, command, response, and reasoning trace is recorded for replay and compliance. ### Visibility, Approvals, Policy, and Audit - **Visibility:** Every tool call, query, command, and reasoning step from every agent is captured in a tamper-evident audit log. Replay sessions, inspect intent, and answer 'what did the agent do?' in one place. - **Approvals:** Route risky actions — destructive SQL, production deploys, IAM changes — through human-in-the-loop approvals. Agents pause, an operator confirms, the action proceeds. - **Policy controls:** Define what agents can and cannot do, per environment, per tool, per dataset. Scope permissions just-in-time. Block destructive verbs by default. Mask sensitive columns in flight. - **Audit logs:** Immutable, SOC 2 and HIPAA-aligned records of every agent action. Export to your SIEM. Satisfy auditors without rebuilding evidence after the fact. ## Access & Privileges ### Privileged Access Source: https://adaptive.live/product/access Broker privileged access to databases, servers, Kubernetes and cloud accounts over SSH, RDP, VNC and the browser. Enforce just-in-time access, MFA and SSO on every resource, and record every session. Adaptive brokers every connection through its own proxy, so the downstream credential never reaches the person or process using it. Connect through the Adaptive CLI, your existing client tools, or straight from the browser. Sessions are recorded and replayable, and an administrator can watch or terminate one while it is still running. - **Every Protocol, One Control Plane:** Reach databases, virtual machines, Kubernetes clusters, cloud providers and web services over SSH, RDP, VNC or a browser-based terminal. Adaptive works with the Adaptive CLI and with the third-party client tools your team already uses. - **Session Recording, Playback and Live Termination:** Every interactive session is captured and replayable, with a session-level database viewer and file explorer for in-session activity. Administrators can join or terminate a live session the moment something looks wrong. - **Endpoint Discovery and Grouping:** Discover endpoints automatically, organize them into groups, assign them to teams, and track endpoint activity and health from one place instead of maintaining separate inventories. - **SSO and Multi-Factor Authentication:** Connect Okta, Azure AD, OneLogin, JumpCloud, Google or LDAP, and enforce multi-factor authentication at the infrastructure level — including for resources that have no native MFA support of their own. The dedicated infrastructure access page also describes just-in-time approvals, session recording and database activity monitoring, masking and sensitive-data classification, role-based access, credential rotation, and infrastructure integrations. ### Authorization & Just-in-Time Access Source: https://adaptive.live/product/authorization Set granular roles and permissions, route requests through approvals, and grant privileges just in time so they expire on their own instead of accumulating as standing access. Create and manage fine-grained privileges using a simple allow/deny framework across every resource — restrict access to specific tables, limit what can be reached inside a Kubernetes cluster, or constrain which commands run on a virtual machine. Then attach time to it: requests route through approvals and grants expire automatically, so nobody keeps privileges they only needed once. - **Just-in-Time Access That Expires:** Grant privileges for the window they are actually needed. Access is provisioned on request and revoked automatically when it lapses, replacing standing root credentials with short-lived, scoped grants. - **Approval Workflows Where Your Team Works:** Route access requests through multi-tier approvals, auto-approval rules for low-risk paths, and scheduled windows for planned work. Approvals reach reviewers in Slack, Microsoft Teams, Jira, Linear or Freshservice. - **Granular Privileges and a Role Matrix:** Establish anything from Read and Read/Write down to individual tables in a database or specific commands on a virtual machine, and review the resulting entitlements across users and teams in a single role matrix. - **Library of Prebuilt Authorizations:** Unlock developer efficiency with our extensive library of prebuilt authorizations, and manage the whole policy set as configuration through the CLI, REST API or Terraform provider. ### Custom Access Policies Source: https://adaptive.live/product/custom-access-policies Set tailored access policies on IP ranges, geographies and device fingerprints - enhancing security posture, control and transparency. Adaptive allows organizations to build custom access policies on every infrastructure resource. Organizations can formulate these policies in a clear 'allow or deny' framework, simplifying the process of managing both inclusive and exceptional access workflows. Adaptive offers access gating on all important parameters including IP ranges, geography and device fingerprints. Adaptive also provides a pre-built library of malicious IP addresses, to protect the infrastructure from external threats. - **IP-Based Access Gating:** Restrict user access based on their IP addresses or geographical locations. Enhance security by ensuring that developers can only access resources from authorized location, reducing the risk of potential security breaches. - **Device-Based Access Control:** Log all device fingerprints natively in the product and build access workflows to allow only known ones. - **Default Blocklist:** Secure critical infrastructure resources with Adaptive’s default blocklist that is designed to provide robust protection against external cyber threats. ### Zero Trust Network Access Source: https://adaptive.live/product/zero-trust-network-access Inspired by Google's BeyondCorp architecture — every request is verified on identity and context, so you can securely share exactly the infrastructure resources and applications people need, across public and private subnets. Adaptive’s container-based architecture allows organizations to deploy a zero-trust solution at scale without needing to make architectural, hardware, or software changes. The platform creates ephemeral secure tunnels to connect with infrastructure resources in any network across different VPCs, improving the organization’s security posture and increasing granular traceability. - **Split Tunnelled Access:** Create point-to-point secure tunnels on the fly - only establishing connections to the resources that are needed. Achieve resource-level network isolation natively without needing network reconfiguration. - **Zero Knowledge Access Management:** Ensure that accessors never see any key or credential while accessing any infrastructure resource or have any knowledge of the network that the resource resides in. - **SSO and Multi-Factor Authentication:** Enhance security by enabling multi-factor authentication on all infrastructure resources, protecting against unauthorized access and potential security threats. ### Credential Rotation Source: https://adaptive.live/product/credential-rotation Rotate passwords for databases, servers, firewalls and switches automatically. Adaptive keeps credentials in its vault, enforces password policies and keeps a full history, so no one needs to know a privileged password. Adaptive stores privileged credentials in its vault and rotates them on a schedule or after every use. Because users and agents connect through Adaptive, they never see the password, and rotation never interrupts their access. - **Automatic Password Rotation:** Rotate credentials on a schedule, on demand, or after each session. Adaptive updates the password on the target and in its vault together, so connections keep working through every rotation. - **Firewalls and Switches Included:** Rotation covers network appliances as well as databases and servers, including Cisco, Fortinet, Juniper, Aruba, Palo Alto and HPE devices, bringing the whole estate under one policy. - **Password Policies and History:** Set length, complexity and rotation-interval policies per resource. Every rotation is recorded with who or what triggered it, giving auditors a complete credential history. ## Data Security ### Database Activity Monitoring Source: https://adaptive.live/product/monitor Monitor, detect, and prevent data activity across various multicloud and hybrid systems integrated into a single solution, ensuring comprehensive audits, zero blind spots, and enhanced protection against threats. Adaptive's Data Security and Activity Management modules complement access management by eliminating blind spots and providing a unified, comprehensive overview of an organization's data security posture. Adaptive assists in discovering, classifying, monitoring, and securing data sources while helping organizations generate compliance reports for SOC-2, ISO-27001, HIPAA, and SOX. - **Real-time Query Monitoring:** Capture and analyse every query, connection and schema change as it happens across Postgres, MySQL, SQL Server, Oracle, MongoDB, Snowflake, Redshift and more — each one attributed to the identity that issued it. - **Detective and Preventive Policies:** Detective policies raise an alert when activity looks anomalous. Preventive policies go further and block or restrict the statement in real time, so a destructive command is stopped before it reaches the database rather than investigated afterwards. - **Session Viewer and Data Event Analytics:** Replay exactly what a user or agent did with a session-level database viewer, and use rolling 30-day summaries of top queries, users and tables to see how data access is trending. - **Unified Alerts and Access Reports:** Receive alerts on policy violations and suspicious activity in real time through Slack, Teams, email or webhooks, and stream events to Splunk, Datadog or Coralogix. Generate access reports for SOC 2, ISO 27001, HIPAA and SOX. ### Masking & Tokenization Source: https://adaptive.live/product/protect Protect sensitive data from non-privileged users with pre-defined masks while maintaining existing user access and workflow. Adaptive's Dynamic Data Masking (DDM) prevents unauthorized exposure of sensitive data and reduces the potential impact of data leaks. Utilize pre-defined masks to conceal sensitive information seamlessly without changing user access and workflow. Additionally, create customized data masks tailored to specific types of stored data. - **Intelligent Data Masking:** Use pre-defined masks that require no configuration changes right out of the box. Adaptive automatically identifies data types such as email, credit card numbers, SSNs, phone numbers, and more, applying appropriate pre-defined mask types automatically. - **Enable Custom Data Masks:** Platform and security administrators can configure custom masks specific to their organization's data. Easily configure specific masking rules and functions based on data type and enforce them across all downstream data sources. - **Semi-Structured Data Masking:** Get native data masking for semi-structured data out of the box with Adaptive. Users can access semi-structured masked data with the same accuracy as structured data. - **Classification-Driven, Across Every Database:** Masking follows what discovery finds. Columns classified as PII, PHI or financial pick up the right mask automatically across Postgres, MySQL, MongoDB, Redshift and more, and the masked resource catalog shows exactly which fields are protected where. ### Discovery & Classification Source: https://adaptive.live/product/discovery-and-classification Discover data sources automatically in your cloud infrastructure and Classify sensitive data into custom and default data classifiers like PII, Financial, and PHI data. Adaptive’s data discovery and classification module helps classify the ever-increasing amount of enterprise data. Discover sensitive, classified, and systematically important data and organize them based on various data classes for added context. Create your own custom data classifiers in addition to default classifiers for PII, Financial, and PHI data. - **Discover and Secure All Data Sources:** Utilize a comprehensive discovery mechanism that seamlessly integrates with your cloud environment, ensuring every data source is identified and secured. Adaptive identifies all your data sources, adds privileged access, monitoring, and generates compliance reports. - **Classify with Custom Data Classes:** Use AI-powered classification to label structured and semi-structured data. Implement strong policies based on compliance frameworks to restrict access and certain activity across data sources. - **Data Residency Mapping:** Dynamically track and update the cloud-based location of sensitive data in real time. With enhanced data transparency, ensure compliance with data sovereignty laws and promptly address any potential risks associated with data residency changes. ### Anomaly Detection Source: https://adaptive.live/product/anomaly-detection Identify any unauthorized intrusion, data exfiltration attempts, or any other anomalous behavior or activity - reducing security incident’s time to response. Adaptive allows you to set policies that monitor data classes and events, thereby enhancing security and ensuring compliance. Collect various events and get alerts for any unauthorized and anomalous data activity patterns. - **Enhanced Anomaly Detection Capabilities:** Detect a wide range of anomaly types in the industry, including point anomalies, contextual anomalies, IP-based anomalies, collective anomalies, endpoint anomalies, and other types of anomalies. - **Context-Aware Detection Algorithms:** Identify intrusions and malicious activities faster with fewer false alerts with the accurate and higher-sensitivity anomaly detection algorithms. Experience better false alarm avoidance rates. - **Detection with Custom Policies:** Set custom policies to proactively protect against any unauthorized access, data tampering, data exfiltration, and other malicious activities. Create triggers to receive alerts for a variety of anomaly types from any data source. ## Identity & Governance ### Identity & Access Management Source: https://adaptive.live/product/iam One identity layer for every human and non-human identity. Connect your identity provider once, and Adaptive applies roles, SSO and MFA consistently across databases, servers, clusters and applications. Adaptive connects to your identity provider and becomes the one place access is defined. Users and groups sync automatically, roles map to resources across every environment, and each session is tied to a verified identity through SSO and MFA. Resource-level credentials stay with Adaptive, so people and services work with their own identity everywhere. - **Identity Provider Sync:** Sync users and groups from your identity provider and keep them current automatically. Joiners get access on day one and leavers lose it the moment they are deprovisioned. - **Role-Based Access Across Resources:** Define roles once and map them to databases, servers, Kubernetes clusters and applications. Every resource enforces the same model, wherever it runs. - **SSO and Multi-Factor Authentication:** Put every infrastructure resource behind your SSO and MFA policies, including systems that only understand local users and static passwords. - **Human and Non-Human Identities:** Manage engineers, service accounts, workloads and AI agents in one place, each with its own identity, scoped permissions and a complete record of what it accessed. ### Workload & Machine Identity Source: https://adaptive.live/product/workloads Give pipelines, BI tools, service accounts and AI agents their own scoped identity. Broker their access through a central vault so your real credentials never reach an external service. Non-human identities now outnumber human ones many times over, and they rarely get the same governance. Adaptive issues machine tokens and service-account credentials from its vault, rotates them on a policy, and puts every workload session into the same audit trail as a human one — with the same masking and preventive policies applied. - **Vault-Managed Secrets and Rotation:** Store workload credentials centrally and let Adaptive handle their lifecycle — issuance, rotation, renewal and offboarding — so long-lived keys stop living in config files and CI variables. - **Machine Tokens and Trusted Clusters:** Issue scoped machine tokens for service accounts and register trusted clusters, so each workload authenticates as itself instead of borrowing a shared human credential. - **BI Tools, Pipelines and Internal Tools:** Connect Metabase, Retool, Airflow, Kafka and CI/CD pipelines through Adaptive without exposing downstream credentials, and apply data policies so pipelines move masked data rather than raw sensitive values. - **AI Agents and MCP Servers:** Register Model Context Protocol servers and agent interfaces as governed resources. Agents get the same scoped, expiring grants, session recording and preventive policies as any other identity on the platform. ### Audit, Access Reviews & Access Graph Source: https://adaptive.live/product/audit Activate identity-based audit trails - Monitor all commands, queries, actions, and access attempts in real time for compliance and forensics. Consolidate access logs across every resource for audits like HIPAA, SOC 2, SOX, ISO 27001 and PCI. Every query and command is attributed to an identity, logged natively and replayable without extra configuration. Search the event log, trace a path through the access graph, and stream the whole trail to the SIEM you already run. - **Audit Logs and Session Recordings:** Capture every query and command against the identity that issued it. Review logs, search events, and replay recorded SSH, RDP, VNC and browser sessions for complete visibility into what actually happened. - **Access Matrix and Access Graph:** See who can reach what, and by which path, across every connected resource. The access matrix answers entitlement questions directly, and the access graph shows the route an identity would take to any given system. - **Alerts and SIEM Streaming:** Build alert rules on sensitive activity and dispatch them to Slack, Microsoft Teams, email or webhooks. Stream the underlying events to Splunk, Datadog, Coralogix or syslog so audit data lands where your security team already works. - **Reports for SOC 2, HIPAA and PCI:** Download compliance-ready reports including user access reviews, access matrices, activity logs and session recordings. Access review campaigns produce the certification and attestation evidence auditors ask for. ### SIEM & Alerting Source: https://adaptive.live/product/siem-and-alerting Send every session, query and access event from Adaptive to Splunk, Datadog, Coralogix or Syslog, and raise alerts in Slack, Microsoft Teams, email or Freshservice the moment something needs attention. Adaptive streams structured, identity-attributed events for every session, query, command and approval into your SIEM and observability stack, and routes alerts to the channels where people respond. Security gets full context without another console to monitor. - **Stream to Your SIEM:** Forward session, query and audit events to Splunk, Datadog, Coralogix or any Syslog collector. Every event carries the user, resource, role and policy decision, ready for correlation and detection rules. - **Alerts in Slack, Teams and Email:** Notify the right people when a policy blocks a query, a sensitive table is read or an access request needs approval. Alerts go to Slack, Microsoft Teams or email with links back to the session. - **Freshservice Ticket Creation:** Open Freshservice tickets automatically for access requests and flagged activity, so reviews and follow-ups are tracked in your existing ITSM workflow. ## AI Agents & Browser Security ### Governed MCP Access Source: https://adaptive.live/product/mcp Expose your infrastructure to AI agents through MCP servers brokered by Adaptive. Every agent authenticates with OAuth, gets only the access its user is allowed, and every tool call is logged for review. Adaptive exposes your databases, servers and clusters as MCP servers. Agents connect through the same broker your engineers use, authorize with OAuth as the person running them, and inherit that person's roles, masking rules and just-in-time grants. Nothing is handed to the agent that the user could not do themselves, and every call is recorded. - **MCP Servers Exposed through Adaptive:** Turn any endpoint registered in Adaptive into an MCP server with no agent-side credentials to manage. Point Claude Code, Cursor or any MCP client at Adaptive and it discovers only the resources the user is authorized for. - **OAuth-Authorized MCP Access:** Agents sign in through your identity provider with OAuth and act as the user who launched them. Role-based access, data masking and time-bound grants apply to agent traffic exactly as they do to people. - **Agent Skills Generated per Endpoint:** Adaptive generates skills for each endpoint describing how to connect and what the agent may do there, so agents use resources correctly without hand-written prompts or wrapper scripts. - **MCP Access Logs and Review:** Every tool call, query and command an agent issues is logged against the user and the agent that made it. Review MCP activity alongside human sessions and revoke access straight from the audit trail. ### Exo — Agent Identity & Secure Agent Harness Source: https://adaptive.live/product/exo Run agents with control and visibility in your infrastructure. Exo combines unique agent identities, ephemeral sandboxed environments, fine-grained authorization, and auditability without exposing infrastructure credentials. - **MCP Server Security:** Scope tool permissions per agent, enforce allowlists, and gate server access with approval workflows and TTLs. No standing access to any MCP endpoint. - **Tool Call Auditing:** Trace every tool call from prompt to response across your agent fleet. Replay any session to understand exactly what happened and why. - **Context & Memory Guardrails:** Redact sensitive data from agent context, enforce memory boundaries, and auto-expire context with configurable TTLs. No cross-session data leakage. - **LLM Provider Controls:** Gate which providers and models each agent can use. Enforce token budgets, cost ceilings, and usage tracking across every model interaction. - **Agent Policy Engine:** Define per-agent policies for tool access, infrastructure, and LLM routing. Govern or release agents in real time — nothing runs ungoverned. - **98+ Infrastructure Integrations:** MCP servers, LLM providers, databases, Kubernetes, cloud platforms, and developer tools — from OpenAI to PostgreSQL to Palo Alto firewalls. Exo authenticates each agent, brokers its session through an ephemeral environment, applies authorization per agent, MCP server and tool call, and attributes actions to the agent identity. Teams supply the prompts and workflows; Adaptive supplies the harness and controls. ### Browser Isolation Source: https://adaptive.live/product/browser-isolation Give users access to internal web apps and SaaS consoles through managed, isolated browser sessions. Nothing runs on the local device, every session is recorded, and apps are launched from a single SSO catalog. Adaptive runs each web session in a managed, isolated browser and streams only the rendered page to the user. Access is granted through SSO and Adaptive's policies, sessions are recorded end to end, and no credentials or data land on the local machine. - **Managed Browser Isolation:** Web apps run in an isolated browser managed by Adaptive, not on the user's device. Downloads, clipboard and credentials stay inside the session, which suits contractors and unmanaged devices. - **Browser Session Recording:** Every isolated session is recorded for playback, so you can see exactly what a user viewed and changed in an admin console or internal tool. - **SSO App Catalog:** Users launch approved web apps from one catalog behind your identity provider. Access follows the same roles, approvals and time-bound grants as the rest of your infrastructure. ### Stratos — Browser Security Source: https://adaptive.live/product/stratos Secure how agents and humans access SaaS and internal web applications. Stratos provides policy-driven browser isolation, URL filtering, session controls, and visibility into browser interactions. - **Session Isolation:** Every browser session runs in a controlled environment. Third-party SaaS via extension, internal services via containerized browser. No cross-session data leakage. - **Pixel-Level Control:** Control exactly which UI elements and fields agents can see and interact with. Mask sensitive regions and restrict actions to specific page areas. - **Policy Enforcement:** URL filtering, domain allowlists, and action-level controls enforced per agent and user. Block unauthorized navigation and quarantine malicious extensions automatically. - **Extension Governance:** Maintain an allowlist of approved browser extensions. Auto-disable unapproved extensions during governed sessions, with full forensic logging on blocked activation attempts. - **WebMCP and Agent Trap Detection:** Detect WebMCP endpoints embedded in websites that could serve as agent traps or prompt injection vectors. Flag and block suspicious MCP servers before agents interact. - **Navigation Path Auditing:** Record the full navigation path agents take through SaaS applications. Every page visited, every redirect, across application boundaries. - **Clipboard and Form Field Monitoring:** Track what agents paste into forms and copy out. Detect sensitive data entering or leaving the browser session in real time. - **Idle Session Timeout and Auto-Revoke:** Automatically terminate sessions that exceed idle thresholds, preventing stale sessions from becoming open attack surfaces. Product overview: https://adaptive.live/product/more ## Use Cases — Privileged Access, Data Protection & Compliance ### Privileged Access Management Source: https://adaptive.live/usecases/privileged-access-management Eliminate standing privileges for agents and humans. Just-in-time access, session recording, and automatic revocation for every privileged operation. Adaptive eliminates standing privileges entirely. Every privileged operation — whether initiated by an agent or a human — receives just-in-time credentials scoped to the specific task, with automatic revocation, session recording, and full audit trails. - **Zero Standing Privileges:** No persistent privileged credentials exist anywhere. Every privileged session is provisioned on demand with credentials that expire automatically when the task completes. - **Just-in-Time Access:** Privileged access is granted in seconds with approval workflows that support both human reviewers and policy-based auto-approval for known safe operations. - **Session Recording:** Every privileged session is recorded end-to-end — commands executed, queries run, responses received. Playback sessions for incident investigation or compliance review. - **Automatic Revocation:** Credentials are revoked the moment the session ends, the TTL expires, or anomalous behavior is detected. No manual cleanup, no forgotten accounts, no privilege creep. - **Access Reviews and Certification:** Run periodic review campaigns over who holds which entitlements, certify or revoke them in place, and export the attestation evidence auditors ask for — across users, service accounts and agents alike. ### VPN Alternative Source: https://adaptive.live/usecases/vpn-alternative Adaptive uses split tunnels to secure access to specific private resources as Zero Trust Network Access, or as an advanced VPN alternative. Adaptive’s container-based architecture allows organizations to deploy a zero-trust solution at scale without needing to make any architectural, hardware, or software changes. The platform creates ephemeral secure tunnels to connect with infrastructure resources across different VPCs. Thus organizations can impvove security posture and increase granular traceability over individual resources. Adaptive's peer-to-peer connections eliminate the need for a VPN solution. - **Better Network Security:** Improve organization’s security posture with native resource-level network isolation. Eliminate the need for overly permissive access and complex network reconfiguration. - **Granular traceability & resource level audit logs:** Get improved visibility and detailed audit logs that accelerate your compliance audits. Deeper forensic insights about the attack vector in case of an incident. - **Zero Knowledge Access Management:** Prevent breaches as no user gets exposed to any credentials or the network location, eliminating the potential of any lateral movement in case of an unauthorized access. - **Improved Performance due to peer-to-peer connection:** Access network resources remotely from anywhere without compromising on network security, performance, and efficiency. ### Protect PII and PHI Source: https://adaptive.live/usecases/protect-pii-phi Exo classifies and masks sensitive data so agents can read what they need while exfiltration paths stay closed. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — infrastructure resources mapped, data classified into PHI / PII / SPI buckets, and Dynamic Data Masking pipelines deployed so sensitive data is not accessible to unprivileged agents or users. You provide the prompts and workflows; the masking applies regardless of how the agent asks for the data. - **Elevated Data Security:** With class based security, distribute resources where necessary. Deploy policies based on the level of security required and protect your infrastructure resources. - **Enhanced Data Privacy:** With Adaptive’s Data Governance, ensure no one has access to sensitive information without privileges. - **Dynamic Masking:** Exo masks queried data according to standing privileges. Choose masks from the pre-defined list or create your own. ### Protect PII and PHI Source: https://adaptive.live/usecases/data-privacy Adaptive applies masking policies across databases so agents and users get access while sensitive fields stay protected — no application changes. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — masking applied at the infrastructure level, between the agent and the database. Sensitive fields are masked in real-time based on the accessor's identity and policy. You provide the prompts and workflows; the masking applies regardless of what the agent asks for. - **Infrastructure-Level Masking:** Masking is applied at the connection level, not the application level. Every query result is filtered through masking policies before reaching the agent or user. - **Identity-Aware Policies:** Masking policies vary by accessor identity. A support agent sees masked SSNs while a compliance auditor sees the full value — same database, different views. - **Zero Application Changes:** No code changes, schema modifications, or application updates required. Masking is transparent to agents and applications. - **Compliance Reporting:** Generate compliance reports showing which fields are masked, who accessed what, and which policies applied. Audit-ready documentation for HIPAA, GDPR, and CCPA. ### Reduce Insider Risk Source: https://adaptive.live/usecases/reduce-insider-threat Adaptive supports Just-in-Time access and other best-in-class access workflows tailored for use cases including Vendor access and Break-glass access seamlessly. Adaptive manages insider threats by effectively managing access. Adaptive’s Privilege Access Management (PAM) checks credential sprawl. Its Just-in-Time access workflow helps provide privileged access to resources instantly as and when needed, and without the need to share credentials. Grant and revoke access through role-based policies. - **Just-in-Time Access:** Provide Just-in-Time access to all resources to increase productivity and reduce time-to-access. - **Easy Vendor and Break-Glass Access:** Provide temporary access to third-party vendors and Break-Glass access to your team in critical situations within seconds. - **Reduce the Impact of Unauthorized Access:** Seamlessly implement Principle of Least Privilege to close potential attack surfaces and threat vectors. - **Streamlined Employee Onboarding and Off-boarding:** Grant access to all necessary resources for new employees during onboarding. With a single click, you can revoke users' access to all resources during off-boarding from a single platform. ### Data protection on ETL pipelines Source: https://adaptive.live/usecases/protected-data-for-etl Exo protects data moving through ETL pipelines from the source to data warehouses like Snowflake, Redshift, and others. You write the prompts and workflows that drive ETL agents; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive applies masking or tokenization policies to sensitive data, ensuring that only protected data reaches the destination data source. This approach minimizes the exposure of sensitive data and helps organizations remain compliant with privacy regulations by default. By centrally defining protection policies as configurations rather than embedding them in code, organizations gain higher visibility, enabling them to scale these policies across multiple ETL pipelines without errors. - **Masking and Tokenization Policies:** Utilises native database views to apply protection policies such as masking or tokenization. - **Observability for ETL Pipeline:** Comprehensive data observability for ETL pipelines, ensuring real-time monitoring and detailed insights into data flows. - **Drop-in Replacement:** Seamlessly integrates with your existing ETL pipeline workflow, requiring no changes to workflow and serving as a drop-in replacement. ### Accelerate Compliance Evidence Collection Source: https://adaptive.live/usecases/accelerate-compliance Adaptive provides compliance-ready reports for access requests, user activities, and session recordings - streamlining evidence gathering for major compliances. Combine all audit logs for access to resources, tools, activity logs, alerts, and incidents in a unified customizable report. Get evidence as ready to use reports necessary for compliance audits like HIPAA, SOC 2, SOX, ISO 27001, and HITRUST. Record all user queries, commands and actions that can be replayed without the need for any additional configurations. Make forensic investigations easy in case of any incident. - **Streamlined Evidence Collection:** Stay compliant with ready to use reports for all user access activity across all infrastructure resources. - **Screen Recordings for Every Session:** Enhance visibility into every query and command on all infrastructure access activities based on the identity of every accessor. - **Custom Policies to Restrict Access:** Limit access to protect personal data and stay GDPR compliant. ### Continuous Controls Audits Source: https://adaptive.live/usecases/compliance-audits Adaptive lets agents collect evidence for SOC 2, ISO, and HIPAA audits against real systems — without persistent credentials. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — ephemeral credentials scoped to specific evidence collection tasks, activated only during scheduled audit windows, with every access logged as part of the evidence. You provide the prompts and workflows. The agent runs your collection logic inside Exo policy envelope, never outside it. - **Scheduled Audit Windows:** Compliance agents activate only during defined audit windows. Outside these windows, no credentials exist — eliminating persistent access risk entirely. - **Evidence-Scoped Access:** Each audit agent gets access only to the specific systems and data needed for its evidence collection task. An access review agent cannot read application logs. - **Self-Documenting Audits:** The audit agent's own access is logged as part of the evidence. Auditors can verify that the evidence collection process itself followed proper access controls. - **Multi-Framework Support:** Run evidence collection for SOC 2, ISO 27001, HIPAA, PCI DSS, and other frameworks from a single platform. Map controls across frameworks to reduce duplicate evidence collection. ## Use Cases — AI Agents & Automation ### AI on Critical Systems Source: https://adaptive.live/usecases/ai-critical-systems Adaptive lets AI agents operate against critical production systems — databases, internal tools, and business applications — without standing credentials. JIT access, per-task scopes, full audit. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — JIT credentials scoped to the specific task, dataset, or tenant the agent is working on. You provide the prompts and workflows. Every call to a critical system runs inside Exo policy envelope, with full session capture and reviewable audit. - **Per-Task Scoping:** Bind each agent session to the task, tenant, or record it is meant to act on. Agents cannot read or write outside the scope the workflow declared. - **JIT Credentials Per Session:** Issue short-lived credentials for each session against databases, internal APIs, and SaaS admin endpoints. Credentials expire when the task is done — nothing persists on the agent. - **Guardrails for Irreversible Actions:** Block or require approval for destructive operations — drops, deletes, mass updates, exports — before they hit a critical system. Soft-fail with a clear reason instead of executing silently. - **Full Session Audit:** Every call an agent makes to a critical system is recorded with the prompt, the context, the credential identity, and the result. Replay any session to answer who did what and why. ### Ship with Coding Agents Safely Source: https://adaptive.live/usecases/coding-agents Adaptive provides isolated sandboxes, scoped repo access, policy-aware shells, and automatic teardown for Claude Code, Codex, and other coding agents. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — ephemeral sandboxes with scoped repo access, deny-listed shell commands, network allowlists, and automatic teardown. You provide the prompts and workflows. The agent runs your coding logic inside Exo policy envelope; time-boxed credentials expire when the task is done. - **Ephemeral Sandboxes:** Every coding agent session runs in an isolated environment with its own filesystem, network policies, and credential scope. Sessions are automatically torn down on completion. - **Policy-Aware Shell:** Block dangerous commands like rm, curl to unknown hosts, and ssh while still allowing agents to build, test, and deploy within approved boundaries. - **Scoped Repository Access:** Grant agents access to specific repositories and branches without exposing the full organization. Read-only or read-write scopes per session. - **Full Audit Trail:** Every command, file change, and network request is logged with the agent's identity. Review sessions end-to-end for compliance and debugging. ### Autonomous Testing With Zero Blast Radius Source: https://adaptive.live/usecases/autonomous-testing Let agents author, run, and iterate on tests — unit, integration, end-to-end, load, and soak — inside agent harness, with tools brokered through Exo MCP server registry and credentials issued least-privilege, scoped to a single environment per run. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. agent harness issues just-in-time credentials scoped to exactly one environment — unit, integration, staging, or perf — for the life of a single run. Tools are brokered through Exo curated MCP server registry, so agents only invoke what policy permits. Targets, data, tools, and runtime budgets are enforced as one policy. You bring the prompts and workflows; Exo enforces the boundary so autonomy scales with zero blast radius instead of accumulating it. - **Least-Privilege Credentials Per Run:** agent harness mints ephemeral, narrowly-scoped credentials for every run: the minimum IAM role, the minimum database grants, the minimum service accounts needed for that suite. Credentials expire on teardown, so there is no standing access for an agent to inherit on the next iteration. - **Environment-Scoped Targets:** A unit agent can only reach mocks. An integration agent can only reach the integration cluster. A perf agent can only reach the perf environment. The harness enforces the boundary at the network and credential layer, so a misbehaving agent physically cannot cross into production or an adjacent tenant. - **MCP Server Registry for Test Tools:** Exo MCP server registry curates every tool an agent can call — test runners, fixture generators, browser drivers, load injectors, coverage probes. Each server is signed, versioned, and permissioned per agent, so a test agent can only invoke the tools its suite is scoped to use. - **Rate Limits & Runtime Budgets:** Enforce per-target RPS caps and wall-clock budgets so a runaway agent-generated scenario cannot saturate shared infrastructure, trip third-party abuse detection, or run up the cloud bill. The harness kills the run and revokes its credentials the moment a limit is crossed. - **End-to-End Audit Trail:** Every command, query, MCP tool call, request, prompt, and generated artifact is logged with the test context — commit, suite, environment, trigger, and agent identity. Replay a failed agent-authored run end-to-end to diagnose root causes and prove least-privilege was honored. ### Browser Harness for Agents Source: https://adaptive.live/usecases/browser-harness Adaptive's Stratos is a browser plugin that gives agents just-in-time sessions — every navigation, click, form fill, and download brokered by policy. You write the prompts and workflows; Adaptive's Stratos provides the harness, tools, networking, and guardrails. Allow-listed origins, ephemeral profiles, masked PII, and a full session replay keyed to the harness id. Adaptive's Stratos gives every agent run its own isolated browser instance — fresh profile, ephemeral storage, allow-listed origins, DLP on inputs and outputs, full session replay, and credentials provisioned just-in-time and revoked when the harness tears down. The browser, the credentials, the network egress, and the tools are all bound to a single harness id, so an agent literally cannot reach anything its policy did not authorize. - **Just-in-Time Browser Sessions:** Every agent run gets a fresh browser profile with credentials provisioned for the job and revoked on teardown. No cookies, no SSO session, no autofill from the previous run — and no standing browser identity for the next prompt to inherit. - **Origin Allow-List Per Harness:** Each harness declares the origins its agent is permitted to navigate. Anything off-list — ad networks, link-shorteners, lookalike domains, hostile redirects — is blocked at the browser layer, before a single byte is sent. - **DLP on Inputs and Outputs:** Adaptive's Stratos inspects what the agent types into a form and what the page sends back. PII, secrets, and regulated identifiers are masked before they leave the harness, and screenshots, downloads, and clipboard reads are filtered against the same policy. - **Action Confirmation for Irreversible Steps:** High-impact actions — wires, refunds, role changes, share-link creation, destructive admin operations — pause the agent and require a typed confirmation or human approval. Reversible actions stay autonomous; irreversible ones get a guardrail. - **Full Session Replay:** Every page visited, every click, every keystroke, and every network request is recorded with the harness id. Replay a run pixel-for-pixel to debug a flaky agent, prove what data was seen, or hand a tamper-evident artifact to compliance. ### SRE Agents Source: https://adaptive.live/usecases/sre-agents Adaptive lets SRE agents diagnose and remediate production incidents — pulling traces, querying clusters, and running runbooks — without standing credentials. JIT access, scoped to the alert, with every action recorded. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — JIT credentials per incident, kube/SSH/cloud access bound to the affected service, and guardrails that block destructive actions until a reviewer signs off. You provide the prompts and workflows. The SRE agent runs your runbooks inside Exo policy envelope, with full session capture for the postmortem. - **Alert-Scoped Access:** Each SRE agent session is scoped to the alert it was paged on — the affected service, namespace, cluster, and time window. Agents cannot wander into unrelated systems while triaging. - **JIT Kube, SSH & Cloud Credentials:** Generate short-lived kubeconfigs, SSH certificates, and cloud roles per session. No static admin tokens on the agent — credentials expire when the runbook completes. - **Guardrails for Destructive Actions:** Block or require human sign-off on irreversible operations — pod deletes outside the affected service, config rollbacks across environments, schema changes, mass restarts. Safe diagnostics pass through automatically. - **Session Replay for Postmortems:** Every command, tool call, and MCP invocation an SRE agent makes during an incident is recorded against the alert. Replay the session in the postmortem instead of reconstructing it from chat scrollback. ### Turn Product Data Into Draft PRDs Source: https://adaptive.live/usecases/product-engineering Adaptive gives product-engineering agents scoped, policy-bound access to database schemas, application logs, metrics, runbooks, environments, and scale profiles — so the PRDs they draft are grounded in how the system actually behaves, not what someone remembers. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — the agent is bound to a single feature brief and exposed to exactly the data surfaces it needs: a read-only schema view, a redacted log slice, a metrics window, the runbooks for the affected service, the environment manifest, and the scale profile for the traffic it must handle. You provide the prompts and workflows. Credentials are ephemeral, PII is stripped at the connector, and every artifact the agent produces is signed with the session identity. - **Schema-Aware Drafting:** Agents read the live database schema — tables, columns, relationships, constraints — through a read-only, policy-filtered view. PRDs reference the domain as it actually exists, so proposed changes name real entities and surface the migrations a feature will require. - **Redacted Log and Metric Access:** Expose application logs and metrics through connectors that strip PII, secrets, and customer identifiers before the agent sees a single line. The agent learns which errors dominate, which endpoints are hot, and where users drop off — without ever touching raw identifiers. - **Process and Runbook Context:** Give the agent the runbooks, on-call notes, and incident post-mortems for the services the feature will touch. PRDs that emerge account for existing processes — deploy windows, migration playbooks, rollback paths — instead of inventing new ones that conflict. - **Environment and Scale Profiles:** Expose the environment manifest — dev, staging, regional prods, tenanted deployments — and the scale profile the feature must sustain: current traffic, peak, growth curve. The agent drafts rollout plans, capacity asks, and feature-flag strategies that match the system the team actually runs. - **Task-Bound Credentials and Signed Artifacts:** Every agent session is scoped to one feature brief. Credentials expire at session end, writes land as draft PRDs or Notion pages signed with the session identity, and nothing — draft, prompt, or tool call — leaves the perimeter without policy sign-off. ### Plan, Execute, and Remediate Migrations with an Agent Harness Source: https://adaptive.live/usecases/migrations Adaptive lets the agent connect to the datasource, draft a migration plan grounded in the live schema, execute it under scoped credentials, and remediate automatically when a step fails. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — a one-shot, schema-scoped credential to your datasource, a masked replica for dry-runs, and a policy envelope for blast radius. You provide the prompts and workflows. The agent inspects the live schema, drafts a plan, executes it step by step, and self-remediates on failure — all inside Exo policy envelope, never outside it. - **Harness Securely Allows Connection to the Datasources:** The agent pulls a short-lived credential from Exo and introspects the target database — schema, indexes, row counts, and current load — before writing a single line of SQL. Every connection is bound to one migration, one schema, and one time window. - **Agent Drafts a Migration Plan from Live State:** Define your own prompts to shape how the agent plans. Grounded in the real schema and table sizes, the harness follows your prompt to produce a step-by-step plan: ordering of DDL, online vs. offline strategy, batch sizes for backfills, and expected lock time. The plan is attached to the PR for review before execution. - **Dry-Run on a Masked Replica:** Before touching production, the harness runs the full plan against a production-shaped replica with PII masked. It measures lock duration, rows affected, and disk impact, then folds the results back into the plan for the reviewer. - **Scoped Execution with Blast-Radius Policies:** The harness executes the approved plan under policy limits on rows touched, lock duration, and DDL class. If a step would exceed the envelope, execution pauses and requires multi-party approval before continuing. - **Automatic Remediation on Error:** When a step fails — lock timeout, constraint violation, saturated primary — the harness captures the error, consults the plan's rollback path, and executes the compensating action. If remediation itself can't complete inside policy, it escalates with the full failure trace, not just a stack dump. - **Rollback-Ready Audit Trail:** Every step — plan, dry-run result, execution, error, remediation — is logged with commit, PR, approver, and effect counts. If a full rollback is needed later, the exact before-state and change set are one query away. ### AI Agents on Critical Systems Source: https://adaptive.live/usecases/customer-support Adaptive lets support copilots run against production databases without standing credentials — JIT access, per-ticket scopes, full audit. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — JIT database credentials scoped to the specific customer or ticket context. You provide the prompts and workflows. The support agent runs your resolution logic inside Exo policy envelope, with every query logged and reviewable. - **Per-Ticket Scoping:** Automatically scope database access to the specific customer or account associated with each support ticket. Agents cannot query data outside their assigned context. - **JIT Database Credentials:** Generate short-lived database credentials for each support session. Credentials expire automatically when the ticket is resolved or the session times out. - **Query Audit Trail:** Every database query executed by a support agent is logged with full context — ticket ID, customer scope, query text, and results summary. - **Sensitive Field Redaction:** Automatically mask PII, payment details, and other sensitive fields in query results. Support agents see enough context to resolve tickets without exposing raw sensitive data. ### Agent harness for Infrastructure Automation Source: https://adaptive.live/usecases/infra-automation Adaptive's Exo is an agent harness for SSH, Kubernetes, and database operations — every tool call, MCP call, session, context window, and memory write captured and governed from a single control plane. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Exo wraps agents in a harness that records every operation — tool calls, MCP calls, sessions, context, and memory — across SSH, Kubernetes, and database workflows. You author the prompts and workflows. Adaptive provides the harness, the MCP registry, the networking, and the guardrails. Operators manage policies, credentials, and replay from a single control plane. - **Capture Every Tool & MCP Call:** The harness intercepts every tool invocation and MCP call the agent makes — kubectl apply, ssh exec, SQL query, cloud API — and records arguments, outputs, timestamps, and the session that issued them. - **SSH, Kubernetes & Database Sessions:** Route agent access to servers, clusters, and databases through brokered sessions with per-session ephemeral credentials. Scoped kubeconfigs, short-lived SSH certificates, and time-boxed database roles — no static secrets on the agent. - **Session, Context & Memory Audit:** Every agent session is recorded end-to-end — the prompt, the context window at each step, the model's reasoning trace, and any memory the agent reads or writes. Replay a run months later to understand exactly what happened. - **Single Control Plane:** Manage policies, credentials, agents, and audit trails for all infrastructure automation from one place. Revoke a credential, pause an agent, or tighten a policy and have it apply everywhere the harness runs. - **Attribution for Every Change:** Every infrastructure change is tied back to the agent, session, prompt, and triggering event that produced it. Correlate a kubectl rollout or a SQL migration with the exact run that issued it. ### Agents Querying Warehouses Source: https://adaptive.live/usecases/data-analytics Adaptive scopes warehouse agents to specific schemas and row-level policies — review every query, redact sensitive fields, revoke instantly. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — schema-level access policies, row-level security, query budgets, and field redaction for every analytics agent session. You provide the prompts and workflows. The agent runs your analysis inside Exo policy envelope; every query is logged for review. - **Schema-Level Scoping:** Restrict agents to specific schemas, tables, and columns. Prevent cross-schema joins and access to tables outside the agent's defined scope. - **Row-Level Policies:** Apply row-level security policies that filter query results based on the agent's context — team, project, or customer scope. - **Query Budget Controls:** Set query frequency limits, result size caps, and compute budgets per agent. Prevent runaway queries and data exfiltration through large result sets. - **Sensitive Field Redaction:** Automatically mask PII, financial data, and other sensitive fields in query results. Agents get the analytical signal without raw sensitive values. ### SOC Copilots in the Loop Source: https://adaptive.live/usecases/security-triage Let agents investigate SIEM alerts with read-only access to logs and assets via agent harness and its tools — escalate findings with full reasoning trails. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — read-only access to logs and security assets scoped to the specific alert being investigated. You provide the prompts and workflows. Every investigation step the agent takes is logged inside Exo policy envelope with full reasoning trails, creating reviewable evidence chains. - **Read-Only Investigation:** Triage agents get read-only access to relevant logs, endpoints, and network data. They can investigate but never modify or delete evidence. - **Alert-Scoped Access:** Access is scoped to the specific alert context — time window, affected assets, and related telemetry. Agents cannot browse beyond the investigation scope. - **Reasoning Trails:** Every investigation step, hypothesis, and conclusion is captured in a structured reasoning trail. Analysts can review the agent's logic before acting on findings. - **Escalation Controls:** Agents can escalate findings to human analysts with full context but cannot take remediation actions. Severity-based routing ensures the right analyst reviews each escalation. ### Autonomous Incident Response Source: https://adaptive.live/usecases/incident-response Adaptive issues break-glass identities to agents responding to incidents — time-boxed privilege, reviewer sign-off, audit-ready transcripts. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — break-glass identities with time-boxed elevated privileges, reviewer sign-off on every action, and audit-ready transcripts for post-incident review. You provide the prompts and workflows. The agent runs your response logic inside Exo policy envelope, never outside it. - **Break-Glass Identities:** Create pre-defined incident response identities with elevated privileges that activate only during declared incidents. Access is automatically revoked when the incident is resolved. - **Time-Boxed Privilege:** All incident response access is time-boxed with hard TTLs. Even if an incident drags on, credentials rotate and require re-authorization at defined intervals. - **Reviewer Sign-Off:** Elevated actions require sign-off from an on-call reviewer before execution. The agent proposes actions with full context; the reviewer approves or modifies. - **Audit-Ready Transcripts:** Every incident response session produces a complete, signed transcript — actions taken, approvals received, evidence collected, and outcomes achieved. ### Agent harness for CI/CD Pipelines Source: https://adaptive.live/usecases/devops-cicd Adaptive lets pipelines trigger deploy agents inside private VPCs, on-prem clusters, or air-gapped networks — no inbound ports. Each invocation gets ephemeral cloud credentials scoped to a single release, with every artifact and command signed and traceable. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails for every CI/CD agent — ephemeral cloud credentials scoped to a single release, signed artifacts, logged commands, and credentials that expire the moment the deployment completes. You provide the prompts and workflows. The agent runs your release logic inside Exo policy envelope, never outside it. - **Invoke Agents in Private Environments:** CI/CD pipelines invoke deploy agents running inside your VPC, on-prem cluster, or air-gapped environment — no inbound ports, no exposed endpoints. Each invocation is issued ephemeral cloud credentials scoped to the single release it's deploying. - **Per-Release Credentials:** Generate unique cloud credentials for each deployment. Credentials are scoped to the specific release, environment, and resource set — no reuse across deployments. - **Artifact Signing:** Every build artifact, container image, and deployment manifest is cryptographically signed with the agent's session identity. Verify provenance at every stage. - **Deployment Scoping:** Restrict deploy agents to specific environments, regions, and resource groups. Prevent agents from deploying to production without the required approval gates. - **Command Traceability:** Every command executed during the pipeline is logged with the release context — commit hash, trigger event, approver, and execution environment. ### Browser Agents That Behave Source: https://adaptive.live/usecases/web-research Adaptive's Stratos is a browser plugin that wraps research, scraping, and form-fill agents in a policy boundary — URL allowlists, session recording, and DLP on every input and output. You write the prompts and workflows; Adaptive's Stratos provides the harness, tools, networking, and guardrails. Adaptive's Stratos provides the browser harness, the tool surface, the networking, and the guardrails — URL allowlists, DLP, and full session recording bound to a single harness id. You bring the prompts and workflows. The agent runs your logic inside Adaptive's Stratos browser boundary, never outside it. - **URL Allowlists:** Define which domains and URL patterns each agent can access. Requests outside the allowlist are blocked before the connection is made. - **Browser Isolation:** Every browser session runs in an isolated environment. Cookies, local storage, and cache are ephemeral — nothing persists between sessions. - **Data Loss Prevention:** Monitor and block attempts to post sensitive data to external sites. DLP policies scan form submissions and file uploads in real-time. - **Session Recording:** Record every browser session with full visual playback. Review what agents saw, clicked, and submitted for audit and debugging. ### Agents on HubSpot and Salesforce Source: https://adaptive.live/usecases/crm-agents Adaptive brokers CRM API access for agents calling HubSpot, Salesforce, and similar platforms — data use controls, blocked unauthorized exports, and end-to-end session capture. You write the prompts and workflows; Adaptive handles the harness, tools, MCP registry, networking, and guardrails. Adaptive gives CRM API agents a harness wired with the tools, MCP registry, networking, and guardrails they need — data use controls, blocked unauthorized exports, record access scoped by team or territory, and end-to-end session capture. You provide the prompts and workflows; the agent calls HubSpot or Salesforce inside the policy envelope, never outside it. - **Data Use Controls:** Define what agents can do with CRM data — read, update, export. Block unauthorized bulk exports and data transfers outside approved workflows. - **Territory Scoping:** Scope agent access to specific territories, teams, or account segments. Agents cannot access records outside their assigned scope. - **Export Controls:** Block bulk data exports and flag unusual access patterns. Agents can query and update individual records but cannot extract datasets. - **End-to-End Session Capture:** Every CRM agent session is captured with full context — records accessed, fields modified, queries executed, and data returned. ### Proactive Investigation Source: https://adaptive.live/usecases/threat-hunting Adaptive gives hunters and their agents read access across telemetry — with query budgets, masking, and reviewable audit trails. You write the prompts and workflows; Adaptive provides the harness, tools, MCP registry, networking, and guardrails. Adaptive provides the harness, tools, MCP registry, networking, and guardrails — scoped read access across security telemetry, per-agent query budgets, sensitive data masking, and complete audit trails. You provide the prompts and workflows. Hunters get the visibility they need; the agent runs your hunt logic inside Exo policy envelope, never outside it. - **Cross-Telemetry Access:** Grant hunting agents read access across SIEM, EDR, network, and cloud logs through a single policy-controlled interface. No need to manage credentials for each data source. - **Query Budgets:** Set per-agent limits on query volume, data scanned, and time range accessed. Prevent runaway queries that could impact production monitoring systems. - **Sensitive Data Masking:** Automatically mask PII, credentials, and sensitive business data in telemetry query results. Hunters see security-relevant indicators without raw sensitive values. - **Hunt Audit Trails:** Every query, result, and hypothesis tested by hunting agents is logged with full context. Build reviewable investigation records for team knowledge sharing. ## Use Cases — Industries ### Privileged Access Security for Banking & Insurance Source: https://adaptive.live/usecases/finance Adaptive governs privileged access to core banking, lending, claims and policy systems while protecting customer financial data and producing audit-ready evidence. Adaptive replaces standing credentials with identity-bound, approval-based access to databases, servers and cloud resources. Policies enforce least privilege and segregation of duties, sensitive customer fields can be masked in flight, and every query and command is captured in immutable logs for examinations, investigations and access reviews. - **Secure Core Financial Systems:** Grant time-bound access to core banking, lending, claims and policy administration systems without distributing long-lived credentials. - **Protect Customer Financial Records:** Mask account, policyholder and personally identifiable information in flight so operators and vendors see only the data required for their role. - **Evidence for Examiners and Auditors:** Produce approval histories, access reviews, session recordings and query-level audit trails for GLBA, FFIEC, OCC and SOX assessments. ### HIPAA-Compliant Access Governance for Healthcare Source: https://adaptive.live/usecases/healthcare Adaptive helps Healthcare companies keep the Protected Health Information of their patients tightly guarded to ensure compliance. Adaptive helps healthcare organizations stay on top of all regulatory requirements and stay compliant with HIPAA, HITECH, and other compliances. Reinforce PHI data security with unified control over access reviews to every resource, database, and network segment. Adaptive delivers detailed audit functionalities, automated endpoint access control, and security measures for HealthTech companies, thereby reducing the likelihood of external attacks. - **Maintain Operational Resilience:** Ensure strong data security policies with Adaptive. Maintain continuous monitoring of all queries and activities and get alerted in case of any unauthorized access attempts. - **Secure Sensitive Data:** Ensure that all patient PHI and other sensitive data is securely accessed with the help of Adaptive. Strengthen the organization’s security posture based on compliance frameworks such as HIPAA and HITECH. - **Easy Evidence Gathering:** Save time and man hours by eliminating manual evidence gathering for audits. Adaptive automates access to accurate, comprehensive and customizable logs that helps during audits. ### Access Governance for SaaS & Technology Companies Source: https://adaptive.live/usecases/technology Adaptive supports SaaS companies in protecting customer and user data, thereby enabling them to stay compliant with regulatory standards. Adaptive enables organizations to scale quick and stay compliant with all regulatory requirements like ISO 27001, GDPR, SOC 2, and more. The platform allows granting vendor access to select resources for external users and provides immediate alerts in case of any unauthorized access attempts. The Adaptive PAM solution facilitates integrated access requests and detailed audit capabilities, automating auditing, access control, and security measures for SaaS companies, thereby reducing the time and costs associated with compliance. - **Continuous Monitoring:** Adopt a proactive stance on compliance management with continuous monitoring. Oversee operations, queries, and activities to promptly identify potential compliance gaps or security risks and take swift remediation action. - **Monitored Third-Party Vendor Access:** Grant temporary, limited access to third-party vendors for selected resources. Create vendor-specific endpoints that offer total transparency on every vendor command and query, with alerts activated when sensitive data is accessed. - **Secure Infrastructure Resources:** By using ephemeral containers as bastion hosts, Adaptive minimizes the risk of unauthorized access and bolsters the security of infrastructure resources. Protect sensitive information, private resources, and customer data and maintain compliance. - **Detailed Audit Logs:** Save time and resources on audit preparation with Adaptive. Ensure the availability of accurate and current comprehensive audit logs of all queries, commands, access approvals, and incidents. ### Privileged Access & Data Security for Fintech Source: https://adaptive.live/usecases/fintech Adaptive gives fintech engineering, support and AI agents just-in-time access to production systems, with cardholder and account data masked and every action audited. Adaptive brokers every connection to databases, Kubernetes clusters and servers through identity-aware, just-in-time access tied to your SSO. Sensitive fields such as card numbers, account numbers and PII are masked in flight, so engineers, support staff and agents only see what they need. Every query and command is recorded in immutable audit logs, turning PCI DSS, SOC 2 and partner-bank evidence requests into a report instead of a project. - **Just-in-Time Production Access:** Replace standing credentials with time-bound, approval-gated access to production. Access expires automatically, removing the long-lived privileges attackers and insiders exploit. - **Mask Cardholder and Account Data:** Dynamically mask PANs, account numbers and customer PII at the access layer, keeping sensitive data out of terminals, BI tools and AI agents while workflows keep running. - **Audit-Ready Evidence:** Query-level logs, session recordings and access reviews give auditors and sponsor banks a complete record of who accessed what, when and under which approval. ### Access Governance for Enterprise Technology Source: https://adaptive.live/usecases/enterprise-tech Adaptive helps enterprise software and cloud companies govern privileged access for thousands of engineers, vendors and AI agents across multi-cloud infrastructure. Adaptive unifies access to databases, servers, clusters and cloud resources behind a single identity-aware control plane. Integrate with your IdP, define policies once and grant just-in-time access through Slack or the CLI. Vendor and agent access is scoped to specific resources and fully audited, and Adaptive can be deployed in your own VPC to meet enterprise data residency requirements. - **Centralized Policy Across Clouds:** Define access policies once and enforce them across every cloud, cluster and datastore, replacing fragmented per-tool permissions with a single source of truth. - **Developer-Friendly Just-in-Time Access:** Engineers request access from the tools they already use and get it in seconds after approval, without handling credentials or waiting on tickets. - **Scoped Vendor and Agent Access:** Give contractors, vendors and AI agents temporary access to exactly the resources they need, with every command and query logged and alerts on sensitive data access. - **Evidence for Customer Audits:** Answer security questionnaires and certification audits with access reviews, session recordings and immutable logs that are always up to date. ### Privileged Access Security for Telecom Source: https://adaptive.live/usecases/telecom Adaptive secures privileged access to telecom network infrastructure, OSS/BSS systems and subscriber data, protecting critical services from insider and supply-chain threats. Adaptive replaces shared accounts and vendor VPNs with identity-bound, just-in-time access to servers, databases and clusters. Access to subscriber data can be masked and restricted by policy, and every session is recorded for forensics and regulatory reporting. Vendors and managed-service partners get scoped, time-limited access without being placed on the network. - **Replace Vendor VPNs:** Give equipment vendors and managed-service partners brokered access to specific resources only, without network-level access to your infrastructure. - **Protect Subscriber Data:** Mask CPNI and subscriber PII in flight and enforce least-privilege access to billing, CRM and customer databases. - **Forensic-Grade Session Records:** Record every privileged session and query so security teams can investigate incidents quickly and meet regulatory reporting timelines. ### Access Controls for Public Companies Source: https://adaptive.live/usecases/public-companies Adaptive helps public companies enforce and prove the IT general controls behind SOX compliance and SEC cybersecurity disclosure requirements. Adaptive enforces just-in-time, approval-based access to financially significant systems and records every query and command in immutable audit logs. Periodic access reviews, segregation of duties and change traceability are built in, so ITGC evidence is available on demand. When an incident occurs, complete session and query history helps security and legal teams quickly scope impact and support disclosure decisions. - **ITGC Evidence on Demand:** Generate access review, approval and activity reports for SOX auditors without manual evidence gathering. - **Segregation of Duties:** Enforce approval workflows and time-bound access so no single user holds standing privileged access to financial systems. - **Faster Incident Scoping:** Use complete session recordings and query logs to determine what was accessed during an incident, supporting timely materiality assessment and disclosure. ## Enterprise Deployment & Governance Source: https://adaptive.live/enterprise Security, platform, and compliance teams define just-in-time access, approvals, masking, access reviews, and audit policies centrally. Engineering, data, and operations teams use the same controls when working with production resources. - **Govern AI agents at scale:** Centralized policy across every team running agents — engineering, data, support, security. One place to define what agents can do, where, and under what approvals. - **Audit-ready by default:** Immutable session recordings, reasoning capture, and tool-call logs aligned with SOC 2, HIPAA, ISO 27001, and RBI CSITE. Hand auditors evidence, not promises. - **Identity-first access:** Single sign-on with Okta, Azure AD, Google Workspace, JumpCloud, OneLogin, and LDAP. Agents inherit human identity context — no shared service credentials. - **Deploy where your data lives:** Self-hosted, hybrid, or SaaS. Adaptive runs inside your VPC when regulation or data residency requires it. ## Adaptive CLI Source: https://adaptive.live/cli The Adaptive CLI connects to databases, servers, Kubernetes clusters, and cloud accounts through brokered access. The same access policies apply in local workflows and CI pipelines. The CLI is supplied to onboarded teams. Contact the Adaptive account team or request a demo for signed macOS, Linux, and Windows binaries and installation instructions for the workspace. Authenticate through the organization's identity provider so actions run under the user's identity. - **Run agents with brokered access:** Hand the CLI an agent task; it negotiates just-in-time credentials, applies policy, and captures every tool call for audit. - **Local development, production guardrails:** Test agents against staging or sandboxed slices of production with the same policy engine that protects live systems. - **Wire into CI and operators:** Use the CLI in pipelines, on-call runbooks, and operator scripts. Approvals route to chat; logs land in your SIEM. ## Pricing & Getting Started Source: https://adaptive.live/pricing Adaptive has no fixed pricing tiers. Pricing depends on the modules deployed, the deployment model, and the number of identities and resources under management. Contact Adaptive for an organization-specific proposal. - Deployment options include on-premises and managed cloud; the enterprise page also describes self-hosted and hybrid deployment inside a customer VPC. - The pricing FAQ describes an agentless architecture with nothing to install on target infrastructure. - A scoped proof of concept is available before a commercial commitment. - All deployments include onboarding support. Dedicated account management, SLA guarantees, and 24/7 support are available for enterprise deployments. Request a walkthrough or discuss deployment: https://adaptive.live/request-demo ## Security & Compliance Source: https://adaptive.live/security Adaptive Automation Technologies has completed a SOC 2 Type II audit conducted by Prescient Assurance. Customers and prospects can request the audit report through the contact listed on the security page. The security overview describes personnel background checks and confidentiality agreements, employee security training, secure development reviews, static and dynamic testing, and internal and third-party penetration testing. Cloud controls include customer isolation, encryption at rest and in transit, separate encryption keys, monitoring, role-based access, and least-privilege reviews. The enterprise and industry pages describe controls and evidence supporting frameworks such as HIPAA, ISO 27001, PCI DSS, SOX, and RBI CSITE. These descriptions concern control alignment and audit support; the stated completed certification here is SOC 2 Type II. ## Integrations Source: https://adaptive.live/integrations The catalog covers databases, Kubernetes, virtual machines, cloud providers, network devices, identity providers, web services, logging, data warehouses, and collaboration tools. Consult each integration page for the supported access and policy capabilities. ### Databases - [MySQL](https://adaptive.live/integrations/mysql): Use Adaptive's MySQL integration to provide authenticated, auditable access to your MySQL database without directly sharing database credentials. - [PostgreSQL](https://adaptive.live/integrations/postgresql): Adaptive's PostgreSQL integration enables authenticated, auditable access to PostgreSQL databases without requiring users to handle database credentials directly. - [Microsoft SQL Server](https://adaptive.live/integrations/microsoft-sql-server): Adaptive enables authenticated, auditable access to SQL Server databases without sharing credentials, providing role-based access control through authorization profiles with granular management of server and database-level permissions. - [MongoDB](https://adaptive.live/integrations/mongodb): Provide authenticated, auditable access to MongoDB without sharing DB access credentials. Adaptive enables users to securely connect through role-based access control and automatic user provisioning. - [MongoDB Atlas](https://adaptive.live/integrations/mongodb-atlas): Adaptive's MongoDB Atlas integration provides authenticated and auditable access to MongoDB Atlas-hosted databases without exposing database credentials directly to users. - [Redis](https://adaptive.live/integrations/redis): Use Adaptive's Redis integration to provide authenticated, auditable access to the Redis database without sharing database credentials. - [Amazon ElastiCache](https://adaptive.live/integrations/amazon-elasticache): Adaptive's Amazon ElastiCache integration enables secure, audited access to your ElastiCache clusters without sharing credentials, supporting both Redis and Memcached engine types. - [Amazon DocumentDB](https://adaptive.live/integrations/amazon-documentdb): Use Adaptive to provide authenticated, auditable access to your Amazon DocumentDB clusters without sharing database credentials, with full audit trails of all access. - [CockroachDB](https://adaptive.live/integrations/cockroachdb): Adaptive's CockroachDB integration enables authenticated, auditable access to the database without sharing credentials, with centralized access governance and session monitoring. - [Amazon DynamoDB](https://adaptive.live/integrations/amazon-dynamodb): Adaptive's Amazon DynamoDB integration enables secure, Just-in-Time access to your DynamoDB tables without sharing AWS credentials directly. - [Amazon Keyspaces](https://adaptive.live/integrations/keyspaces): Use Adaptive's Amazon Keyspaces integration to provide authenticated, auditable access to your managed Apache Cassandra service without sharing credentials. - [Amazon Neptune](https://adaptive.live/integrations/amazon-neptune): Adaptive enables authenticated, auditable access to Amazon Neptune graph databases without sharing credentials, providing secure Just-in-Time access for your team. - [Google Cloud Bigtable](https://adaptive.live/integrations/google-cloud-bigtable): Use Adaptive's Google Cloud Bigtable integration to provide secure, audited access to your Bigtable instances without sharing credentials. - [Google Cloud Spanner](https://adaptive.live/integrations/google-cloud-spanner): Adaptive's Google Cloud Spanner integration enables authenticated, auditable access to Spanner databases without sharing credentials. - [Google Memorystore](https://adaptive.live/integrations/google-memorystore): Use Adaptive's Google Memorystore integration to provide authenticated, auditable access to your managed Redis and Memcached instances without sharing credentials. - [Google Firestore](https://adaptive.live/integrations/google-firestore): Adaptive's Google Firestore integration enables secure, credential-free access to your Firestore databases with full audit trails. - [Azure SQL](https://adaptive.live/integrations/azure-sql): Use Adaptive's Azure SQL integration to provide authenticated, auditable access to your Azure SQL databases without sharing connection strings or credentials. - [Azure Cosmos DB](https://adaptive.live/integrations/azure-cosmos): Adaptive's Azure Cosmos DB integration enables secure, Just-in-Time access to your globally distributed database without exposing credentials. - [Oracle Database](https://adaptive.live/integrations/oracle): Use Adaptive's Oracle integration to provide authenticated, auditable access to your Oracle database without sharing database credentials. - [ClickHouse](https://adaptive.live/integrations/clickhouse): Use Adaptive's ClickHouse integration to provide authenticated, auditable access to your ClickHouse database without sharing database credentials. - [Cassandra](https://adaptive.live/integrations/cassandra): Adaptive enables authenticated, auditable access to Apache Cassandra without sharing database credentials, providing centralized access control with session monitoring. - [MariaDB](https://adaptive.live/integrations/mariadb): Use Adaptive's MariaDB integration to provide authenticated, auditable access to your MariaDB databases without directly sharing credentials. - [ScyllaDB](https://adaptive.live/integrations/scylladb): Adaptive's ScyllaDB integration enables secure, credential-free access to your ScyllaDB clusters with full audit trails and Just-in-Time access provisioning. - [Neo4j](https://adaptive.live/integrations/neo4j): Use Adaptive's Neo4j integration to provide authenticated, auditable access to your graph database without sharing credentials. - [YugabyteDB](https://adaptive.live/integrations/yugabyte): Adaptive's YugabyteDB integration enables authenticated, auditable access to your distributed SQL database without sharing credentials. - [Elasticsearch](https://adaptive.live/integrations/elasticsearch): Use Adaptive's Elasticsearch integration to provide authenticated, auditable access to your Elasticsearch cluster, supporting role-based access control via authorization profiles. - [ProxySQL](https://adaptive.live/integrations/proxysql): Adaptive's ProxySQL integration enables secure, credential-free database proxy access with full audit trails and centralized access governance. - [Apache Druid](https://adaptive.live/integrations/apache-druid): Use Adaptive's Apache Druid integration to provide authenticated, auditable access to your real-time analytics database without sharing credentials. ### Kubernetes - [Kubernetes](https://adaptive.live/integrations/kubernetes): Adaptive's Kubernetes integration unlocks credential-less and audited access to your K8s cluster without sharing secrets. - [Google Kubernetes Engine](https://adaptive.live/integrations/gke): Adaptive enables secure, audited kubectl access to Google Kubernetes Engine clusters without sharing kubeconfig credentials. - [Azure Kubernetes Service](https://adaptive.live/integrations/aks): Use Adaptive's Azure Kubernetes Service integration to provide authenticated, auditable access to your AKS clusters without sharing credentials. - [Amazon EKS](https://adaptive.live/integrations/eks): Adaptive's Amazon EKS integration enables secure, credential-free access to your managed Kubernetes clusters with full audit trails. - [Digital Ocean Kubernetes](https://adaptive.live/integrations/doks): Use Adaptive's Digital Ocean Kubernetes integration to provide authenticated, auditable access to your DOKS clusters without sharing credentials. - [Rancher](https://adaptive.live/integrations/rancher): Adaptive's Rancher integration enables secure, audited access to your Rancher-managed Kubernetes clusters without sharing credentials. - [OpenShift](https://adaptive.live/integrations/openshift): Use Adaptive's OpenShift integration to provide authenticated, auditable access to your OpenShift clusters without sharing credentials. ### Virtual Machines - [SSH](https://adaptive.live/integrations/ssh): Adaptive's SSH integration enables secure connections to hosts and virtual machines without sharing or repeatedly specifying SSH credentials, with all access being logged and auditable. - [RDP](https://adaptive.live/integrations/rdp): Use Adaptive's RDP integration to provide authenticated, auditable access to Windows desktops and servers without sharing RDP credentials. - [VNC](https://adaptive.live/integrations/vnc): Adaptive's VNC integration enables secure, credential-free remote desktop access with full audit trails and session recording. - [AWS EC2](https://adaptive.live/integrations/aws-ec2): Use Adaptive's AWS EC2 integration to provide authenticated, auditable SSH and RDP access to your EC2 instances without sharing credentials. - [Google Compute Engine](https://adaptive.live/integrations/gce): Adaptive's Google Compute Engine integration enables secure, credential-free access to your VM instances with full audit trails. - [Azure VM](https://adaptive.live/integrations/azure-vm): Use Adaptive's Azure VM integration to provide authenticated, auditable access to your Azure virtual machines without sharing credentials. - [Digital Ocean Droplets](https://adaptive.live/integrations/digitalocean-droplets): Adaptive's Digital Ocean Droplets integration enables secure, audited SSH access to your Droplets without sharing credentials. - [Vultr](https://adaptive.live/integrations/vultr): Use Adaptive's Vultr integration to provide authenticated, auditable access to your Vultr instances without sharing credentials. ### Cloud Providers - [AWS](https://adaptive.live/integrations/aws): Adaptive's AWS integration allows you to provide authenticated, auditable CLI access to your AWS resources without sharing access keys or secrets. - [Azure](https://adaptive.live/integrations/azure): Use Adaptive's Azure integration to provide secure, audited access to Azure resources without sharing credentials or service principal secrets. - [Google Cloud](https://adaptive.live/integrations/google-cloud): Adaptive's Google Cloud integration enables authenticated, auditable access to GCP resources without sharing service account keys or credentials. - [Digital Ocean](https://adaptive.live/integrations/digitalocean): Use Adaptive's Digital Ocean integration to provide secure, credential-free access to your Digital Ocean resources with full audit trails. - [Heroku](https://adaptive.live/integrations/heroku): Adaptive's Heroku integration enables authenticated, auditable access to your Heroku applications and resources without sharing credentials. - [AWS ECS](https://adaptive.live/integrations/aws-ecs): Use Adaptive to provide authenticated, auditable access to AWS ECS containers and services without sharing credentials. - [AWS Lambda](https://adaptive.live/integrations/aws-lambda): Adaptive's AWS Lambda integration enables secure, Just-in-Time access to Lambda functions without exposing AWS credentials. ### Network Devices - [Cisco](https://adaptive.live/integrations/cisco): Adaptive's Cisco integration enables secure, credential-free access to Cisco network devices with full audit trails and centralized access governance. - [Juniper](https://adaptive.live/integrations/juniper): Use Adaptive's Juniper integration to provide authenticated, auditable access to Juniper network devices without sharing credentials. - [Fortinet](https://adaptive.live/integrations/fortinet): Adaptive's Fortinet integration enables secure, audited access to FortiGate firewalls and network devices without sharing credentials. - [Aruba](https://adaptive.live/integrations/aruba): Use Adaptive's Aruba integration to provide authenticated, auditable access to Aruba network devices without sharing credentials. - [Aruba Instant On](https://adaptive.live/integrations/aruba-instant-on): Adaptive's Aruba Instant On integration enables secure, credential-free network device management with full audit trails. - [PAN-OS](https://adaptive.live/integrations/panos): Use Adaptive's PAN-OS integration to provide authenticated, auditable access to Palo Alto Networks devices without sharing credentials. - [HPE Switch](https://adaptive.live/integrations/hpe-switch): Adaptive's HPE Switch integration enables secure, audited access to HPE network switches without sharing credentials. - [ZeroTier](https://adaptive.live/integrations/zerotier): Use Adaptive's ZeroTier integration to provide authenticated, auditable access to your ZeroTier network without sharing credentials. ### SSO Providers - [Okta](https://adaptive.live/integrations/okta): Integrating Okta enables Okta as an identity provider for resource access via Adaptive, allowing you to use your existing Okta authentication to manage how users access resources. - [Azure Active Directory](https://adaptive.live/integrations/azure-active-directory): Use Azure Active Directory as an identity provider with Adaptive to enable SSO-based access control across all your infrastructure resources. - [Google SSO](https://adaptive.live/integrations/google-sso): Adaptive's Google SSO integration enables using Google Workspace as your identity provider for seamless, authenticated access to all connected resources. - [JumpCloud](https://adaptive.live/integrations/jumpcloud): Use JumpCloud as an identity provider with Adaptive to centralize access control and enable SSO-based authentication for your infrastructure. - [OneLogin](https://adaptive.live/integrations/onelogin): Adaptive's OneLogin integration enables using OneLogin as your identity provider for SSO-based access to all your connected infrastructure resources. - [LDAP](https://adaptive.live/integrations/ldap): Use Adaptive's LDAP integration to connect your directory service as an identity provider, enabling centralized authentication and access control. ### Web Services - [Grafana](https://adaptive.live/integrations/grafana): Use Adaptive's Grafana integration to provide authenticated, auditable access to your Grafana dashboards without sharing credentials. - [Prometheus](https://adaptive.live/integrations/prometheus): Adaptive's Prometheus integration enables secure, credential-free access to your monitoring infrastructure with full audit trails. - [Jenkins](https://adaptive.live/integrations/jenkins): Use Adaptive to provide authenticated, auditable access to Jenkins without sharing credentials or API tokens. - [Gitlab](https://adaptive.live/integrations/gitlab): Adaptive's GitLab integration enables secure, audited access to your GitLab instance without sharing credentials. - [Kibana](https://adaptive.live/integrations/kibana): Use Adaptive's Kibana integration to provide authenticated, auditable access to your Kibana dashboards without sharing credentials. - [Kafka](https://adaptive.live/integrations/kafka): Use Adaptive's Kafka integration to provide authenticated, auditable access to your queue without sharing credentials, eliminating the need to distribute credentials directly to users. - [Confluent Cloud](https://adaptive.live/integrations/confluent-cloud): Adaptive's Confluent Cloud integration enables secure, credential-free access to your managed Kafka clusters with full audit trails. - [RabbitMQ](https://adaptive.live/integrations/rabbitmq): Use Adaptive's RabbitMQ integration to provide authenticated, auditable access to your message broker without sharing credentials. - [MinIO](https://adaptive.live/integrations/minio): Adaptive's MinIO integration enables secure, credential-free access to your S3-compatible object storage with full audit trails. - [Airflow](https://adaptive.live/integrations/airflow): Use Adaptive's Apache Airflow integration to provide authenticated, auditable access to your workflow orchestration platform without sharing credentials. - [Docker Registry](https://adaptive.live/integrations/docker-registry): Adaptive's Docker Registry integration enables secure, credential-free access to your container registry with full audit trails. - [OpenAI](https://adaptive.live/integrations/open-ai): Use Adaptive's OpenAI integration to provide authenticated, auditable access to OpenAI API keys without exposing credentials to developers. ### Logging & Monitoring - [Datadog](https://adaptive.live/integrations/datadog): Use Adaptive's Datadog integration to stream and store all events and audit logs from Adaptive directly in your Datadog account for centralized monitoring and analysis. - [Splunk](https://adaptive.live/integrations/splunk): Send Adaptive Activity Logs to your Splunk Instance for centralized monitoring and analysis of all access events. - [AWS CloudWatch](https://adaptive.live/integrations/aws-cloudwatch): Use Adaptive's AWS CloudWatch integration to stream access logs and audit events from Adaptive to CloudWatch for centralized monitoring. - [Coralogix](https://adaptive.live/integrations/coralogix): Adaptive's Coralogix integration enables streaming of all access events and audit logs to Coralogix for centralized analysis and alerting. - [Syslog](https://adaptive.live/integrations/syslog): Use Adaptive's Syslog integration to forward access logs and audit events to any syslog-compatible destination. ### Data Warehouses - [Redshift](https://adaptive.live/integrations/redshift): Use Adaptive's Redshift integration to provide authenticated, auditable access to your Amazon Redshift data warehouse without sharing credentials. - [Amazon Redshift](https://adaptive.live/integrations/amazon-redshift): Use Adaptive's Amazon Redshift integration to provide authenticated, auditable access to your Redshift data warehouse without sharing credentials. - [Amazon Athena](https://adaptive.live/integrations/amazon-athena): Adaptive's Amazon Athena integration enables authenticated, auditable, serverless query access to your S3 data lake without sharing credentials. - [Amazon Glue](https://adaptive.live/integrations/amazon-glue): Adaptive's AWS Glue integration provides authenticated, auditable access to your data catalog and ETL pipelines without directly sharing credentials. - [Amazon QLDB](https://adaptive.live/integrations/amazon-qldb): Adaptive's Amazon QLDB integration enables authenticated, auditable access to your ledger database without sharing credentials. - [Snowflake](https://adaptive.live/integrations/snowflake): Use Adaptive's Snowflake integration to provide authenticated, auditable access to your Snowflake data warehouse without directly sharing credentials. - [Databricks](https://adaptive.live/integrations/databricks): Adaptive's Databricks integration enables secure, credential-free access to your Databricks workspace with full audit trails. - [Google BigQuery](https://adaptive.live/integrations/google-bigquery): Use Adaptive's Google BigQuery integration to provide authenticated, auditable access to your data warehouse without sharing credentials. - [Starburst](https://adaptive.live/integrations/starburst): Adaptive's Starburst integration enables secure, credential-free access to your query engine with full audit trails. - [Azure Synapse](https://adaptive.live/integrations/azure-synapse): Use Adaptive's Azure Synapse integration to provide authenticated, auditable access to your analytics service without sharing credentials. - [AWS S3](https://adaptive.live/integrations/aws-s3): Adaptive's AWS S3 integration enables secure, credential-free access to your S3 buckets with full audit trails and Just-in-Time access provisioning. ### Collaboration - [Slack](https://adaptive.live/integrations/slack): Use Adaptive's Slack App to create request approval flows for your endpoints, enabling teams to manage access requests directly through Slack with approval notifications in designated channels. - [Microsoft Teams](https://adaptive.live/integrations/msteams): Adaptive's Microsoft Teams integration enables managing access request approvals directly within Teams, with notifications sent to designated channels. - [Jira](https://adaptive.live/integrations/jira-integration): Use Adaptive's Jira integration to connect your ticket management workflow, enabling access request tracking and approval directly within Jira. - [GitHub](https://adaptive.live/integrations/github-integration): Use Adaptive's GitHub integration to connect your GitHub account for workflow automation and issue tracking within Adaptive. - [Linear](https://adaptive.live/integrations/linear): Adaptive's Linear integration enables connecting your project management workflow for access request tracking and approval within Linear. - [Asana](https://adaptive.live/integrations/asana): Use Adaptive's Asana integration to connect your project management workflow for access request tracking and approval. - [Freshservice](https://adaptive.live/integrations/freshservice): Adaptive's Freshservice integration enables ticket-based access request management, allowing teams to handle Just-in-Time access requests through their ITSM workflow. - [Zoom](https://adaptive.live/integrations/zoom): Use Adaptive's Zoom integration to provide authenticated, auditable access to Zoom resources without sharing credentials. ## Comparisons Source: https://adaptive.live/compare The website includes comparisons with StrongDM and Teleport, discussing infrastructure access, deployment, authorization, and data protection. - [Adaptive vs. StrongDM](https://adaptive.live/compare/strongdm) - [Adaptive vs. Teleport](https://adaptive.live/compare/teleport) ## Featured Blog Articles ### Virtual Patching with Access Proxies: Shield Systems You Cannot Patch Yet Source: https://adaptive.live/blog/virtual-patching-with-access-proxies Published: 2026-11-05T00:00:00.000Z Updated: 2026-11-05T00:00:00.000Z Author: Adaptive Team Category: General Learn what virtual patching is, why the patch window keeps widening, and how Adaptive's database, SSH, Kubernetes, web and MCP proxies can block an exploit path before the vendor fix is installed. **Virtual patching blocks the exploitation of a known vulnerability without changing the vulnerable system.** [OWASP defines it](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) as "a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability." The vendor patch fixes the code. The virtual patch changes what is allowed to reach the code while the patch is tested, scheduled, or still being written. The window it has to cover is widening at both ends. According to [Mandiant's M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026), exploits were the most common initial infection vector for the sixth year running, and the mean time to exploit was an estimated negative seven days: exploitation typically began before a patch existed. [Verizon's 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) found that only about a quarter of CISA Known Exploited Vulnerabilities were fully remediated during 2025. Most virtual patching tooling sits at the web edge: a web application firewall (WAF) or intrusion prevention system (IPS) in front of a public website. Databases, SSH hosts, Kubernetes clusters, internal consoles and MCP servers rarely have an equivalent. Adaptive brokers every connection to those systems through its own proxy, and that proxy already parses the queries, commands, API requests and tool calls passing through it. A policy that denies the specific statement, command, path or tool an exploit needs is a virtual patch applied at one point, for every identity, without touching the vulnerable system. *Published November 5, 2026. Statistics and vulnerability details are attributed to their sources. The proxy-based patterns and validation steps below are Adaptive's analysis.* #### What is virtual patching? A virtual patch is a rule enforced somewhere between the attacker and the vulnerable code. OWASP's cheat sheet notes that the technique is also called "external patching" or "just-in-time patching," and that the enforcement layer is typically a WAF or web server plugin such as ModSecurity that analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the application. Three properties separate it from a real patch: - **It does not change the vulnerable software.** The flaw stays in place. Only the traffic that can trigger it is filtered. - **It is fast to deploy and fast to remove.** A rule can be written in hours and retired the day the patch lands, with no reboot and no release train. - **It is a compensating control.** It reduces risk until remediation. It is tracked as residual risk, not closed as fixed. | At a glance | Vendor patch | Virtual patch | | --- | --- | --- | | What changes | The vulnerable code | The policy on traffic that reaches it | | Where it lives | On every affected host | At one enforcement point, applied to many hosts | | Lead time | Vendor release, testing, change window | Hours, once the exploit path is understood | | Downtime | Often needs a restart or maintenance window | None for the protected system | | Residual risk | Removed for that CVE | Remains; exploit paths the rule misses still work | | Lifetime | Permanent | Temporary, retired once the patch is applied | OWASP also notes that virtual patching is ideally suited to injection-type flaws and may not provide adequate attack surface reduction for every category. A rule can block a malformed command. It cannot fix a flawed business decision that looks like normal traffic. #### Why can't teams simply patch faster? OWASP's cheat sheet lists the reasons organizations cannot edit vulnerable code immediately: lack of resources, third-party software they do not control, and outsourced development. Mission-critical systems add another: some cannot be taken offline on a vendor's schedule. [SQL Server 2016 left extended support in July 2026](https://www.neowin.net/news/microsoft-ends-support-for-sql-server-2016-but-admits-that-it-is-still-heavily-deployed/) while Microsoft acknowledged it remained heavily deployed. Every unsupported database engine, appliance or embedded system is a permanent patch gap by definition. The numbers describe how wide the gap is: | Measure | Figure | Source | | --- | --- | --- | | Share of intrusions where an exploit was the initial vector | 32% | [Mandiant M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026) | | Mean time to exploit, relative to patch release | About -7 days | Mandiant M-Trends 2026 | | Share of breaches that began with vulnerability exploitation | 31% | [Verizon 2026 DBIR](https://www.verizon.com/business/resources/reports/dbir/) | | KEV entries fully remediated during 2025 | 26%, down from 38% | [Verizon 2026 DBIR, as analyzed by Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2026/05/19/inside-the-2026-verizon-dbir-what-one-billion-records-revealed-about-vulnerability-remediation) | | Median time to fully remediate a KEV | 43 days, up from 32 | Verizon 2026 DBIR, as analyzed by Qualys | | KEVs with exploitation evidence on or before CVE publication, 2025 | 29% | [VulnCheck State of Exploitation 2026](https://www.vulncheck.com/blog/state-of-exploitation-2026) | Read together: an exploit often exists before the patch, the patch takes weeks to reach every host, and a large share of known-exploited flaws are never fully closed. The question for a security team is not whether a gap exists but what sits inside it. #### Where can a virtual patch be enforced? The enforcement point decides what a rule can see. A network firewall sees addresses and ports. A WAF sees HTTP. A database proxy sees SQL. Each layer can only block what it can parse. | Enforcement point | What it parses | Typical coverage | | --- | --- | --- | | Network firewall or IPS | Packets and signatures | Exposure reduction, known exploit signatures | | WAF or reverse proxy | HTTP requests | Public web applications and APIs | | Kubernetes admission controller | Resource manifests | Objects created through the API server | | Host configuration | Daemon settings | Single-host mitigations such as a disabled feature | | Access proxy or broker | Database wire protocols, SSH sessions, kubectl calls, HTTP, MCP | Internal infrastructure reached by people, services and agents | The first four are well established. The fifth is the one most organizations do not have. Internal protocols such as the PostgreSQL wire protocol, Redis commands, SSH sessions and MCP tool calls usually travel from a client straight to the server with nothing in between that understands the conversation. An identity-aware access proxy is the inline point that does. #### How do Adaptive's proxies apply a virtual patch? [Adaptive brokers every connection through its own proxy](https://adaptive.live/product/access), so the downstream credential never reaches the person, service or agent using it. Users authenticate with SSO and MFA, receive a role that scopes what they can do, and work in a recorded session. Because the proxy parses the protocol, [preventive policies](https://adaptive.live/product/monitor) can block or restrict a statement in real time, [authorization profiles](https://adaptive.live/product/authorization) can constrain which commands run on a virtual machine or what can be reached inside a Kubernetes cluster, and [MCP access](https://adaptive.live/product/mcp) can be limited to specific tools. A virtual patch on the broker uses four mechanisms, in increasing order of how closely the exploit traffic resembles legitimate work: 1. **Remove exposure.** The vulnerable service accepts connections only from the broker. [Zero trust network access](https://adaptive.live/product/zero-trust-network-access) builds ephemeral tunnels to the resource, so an unauthenticated attacker on the network never reaches the listener. This covers pre-authentication bugs, where no rule on session content helps because the exploit happens before the session exists. 2. **Deny the trigger.** When the exploit needs a specific command, statement, verb, path or tool, a preventive policy denies it for everyone, or for everyone outside a named role. 3. **Gate the risky path.** When the feature cannot be removed, keep it behind [just-in-time approval](https://adaptive.live/product/authorization), a short grant and a recorded session. The feature stays available for approved work and unavailable to an attacker holding a stolen session. 4. **Detect and terminate.** For traffic that cannot be distinguished in advance, [audit records](https://adaptive.live/product/audit), [anomaly detection](https://adaptive.live/product/anomaly-detection), live session termination and [SIEM streaming](https://adaptive.live/product/siem-and-alerting) shorten the time between misuse and response. The examples below map real vulnerabilities to those mechanisms. Each one is a pattern to adapt, not a claim that the vulnerability is closed. Verify which commands and paths each integration parses in your deployment before relying on a rule. ##### Databases: deny the statement the exploit needs [CVE-2025-49844](https://www.sysdig.com/blog/cve-2025-49844-redishell), known as RediShell, is a critical use-after-free in Redis's Lua engine. An authenticated client sends a crafted Lua script, escapes the sandbox and executes code on the host. Lua scripting is on by default, so every unpatched instance is exposed to any client that can authenticate. The published interim mitigation is to restrict the scripting commands with Redis access control lists until the instance is upgraded. Through Adaptive's [Redis](https://adaptive.live/integrations/redis), [ElastiCache](https://adaptive.live/integrations/amazon-elasticache) and [Memorystore](https://adaptive.live/integrations/google-memorystore) integrations, clients reach Redis through the broker with their own identity rather than the shared instance password. The virtual patch is a preventive policy that denies the scripting commands (`EVAL`, `EVALSHA` and script loading) for every role except the one that owns the application's scripts, applied across every Redis endpoint from one place instead of instance by instance. Every attempt is logged against a named identity, which also tells you who still sends scripts and where the real patch has to land first. The same pattern applies to any database where a documented exploit depends on a statement shape: a specific stored procedure, an extension function, a schema change or a bulk export. [Adaptive's database activity monitoring](https://adaptive.live/product/monitor) parses queries across PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Snowflake, Redshift and others, so the deny rule is written once, in terms of the statement, rather than once per client. ##### Servers: take the vulnerable daemon off the network [CVE-2024-6387](https://rockylinux.org/news/2024-07-01-openssh-sigalrm-regression), known as regreSSHion, is a signal handler race condition in OpenSSH 8.5p1 through 9.7p1 that allows unauthenticated remote code execution as root. The documented host-side mitigation, setting `LoginGraceTime` to zero, trades the race for a denial-of-service exposure. A year later, [CVE-2025-32433](https://censys.com/advisory/cve-2025-32433) in the Erlang/OTP SSH server allowed commands to run before login completed. It was added to CISA's Known Exploited Vulnerabilities catalog, and Censys counted hundreds of exposed servers. No rule on session content helps with a bug that fires before authentication. The virtual patch is exposure removal: the host's SSH daemon accepts connections only from Adaptive's broker, and engineers reach it over [brokered SSH](https://adaptive.live/integrations/ssh) with SSO and MFA. The unauthenticated attack surface becomes one hardened path instead of every reachable port 22. For post-authentication bugs, [command restrictions on virtual machines](https://adaptive.live/product/authorization) deny the binary or argument the exploit needs, and [credential rotation](https://adaptive.live/product/credential-rotation) ensures the host password is not also sitting in a configuration file somewhere else, as the [FortiBleed 2.0 exposures](https://adaptive.live/blog/fortibleed-2-firewall-secrets-privileged-access) showed for network appliances. ##### Kubernetes: shrink who can send the dangerous request [CVE-2024-10220](https://access.redhat.com/security/cve/CVE-2024-10220) allowed arbitrary command execution through a crafted `gitRepo` volume in a pod specification on kubelet versions before the 1.28.12, 1.29.7, 1.30.3 and 1.31.0 fixes. The documented mitigation is a validating admission policy that rejects any pod carrying a `gitRepo` volume. That is the right tool for inspecting the request body. The admission policy answers "what may be created." The broker answers "who may create it, from where, and for how long." Through Adaptive's [Kubernetes integration](https://adaptive.live/integrations/kubernetes), each identity receives a scoped role that limits which verbs and resources it can reach in the cluster, and privileged verbs such as pod creation in sensitive namespaces can require approval and expire. While the cluster waits for its upgrade window, the set of identities that could send a malicious manifest shrinks from every holder of a kubeconfig to the approved sessions of the moment, and each of those sessions is recorded. ##### Web services and consoles: block the path Grafana's [CVE-2021-43798](https://github.com/grafana/grafana/security/advisories/GHSA-8pjx-jj86-j47p) was a directory traversal under `/public/plugins//` that read arbitrary files from the server. The advisory's interim recommendation was a reverse proxy that normalizes the request path. Jenkins's [CVE-2024-23897](https://www.jenkins.io/security/advisory/2024-01-24/) let attackers with read permission read entire files, and unauthenticated attackers read the first lines of files, through a CLI argument-parser feature. The advisory's workaround was to disable CLI access entirely. These are the classic WAF use cases, and the point is that internal consoles rarely sit behind a WAF. Adaptive brokers access to [Grafana](https://adaptive.live/integrations/grafana), [Jenkins](https://adaptive.live/integrations/jenkins), [Kibana](https://adaptive.live/integrations/kibana) and [GitLab](https://adaptive.live/integrations/gitlab), and [browser isolation](https://adaptive.live/product/browser-isolation) runs the console in a managed session rather than on the user's device. [Stratos](https://adaptive.live/product/stratos) adds URL filtering and action-level policies per user and agent. The virtual patch is a URL rule that blocks the CLI path or the traversal pattern for every brokered session, with the console itself reachable only through SSO, so unauthenticated path probes never arrive. ##### MCP servers and agents: allowlist tools, not servers AI agents introduced a class of software that is young, widely deployed and patched unevenly. The [Filesystem MCP server](https://cvefeed.io/vuln/detail/CVE-2025-53110) shipped with sandbox escapes through path traversal (CVE-2025-53109 and CVE-2025-53110). The [mcp-remote package](https://db.gcve.eu/cve/CVE-2025-6514) allowed operating-system command injection when a client connected to an untrusted server (CVE-2025-6514). Researchers chained flaws in the [Git MCP server](https://www.techradar.com/pro/security/anthropics-official-git-mcp-server-had-some-worrying-security-flaws-this-is-what-happened-next) with the filesystem server to reach code execution. [Adaptive's MCP gateway](https://adaptive.live/product/mcp) exposes infrastructure to agents through brokered MCP servers, with OAuth sign-in as the user running the agent and every tool call logged. [Exo](https://adaptive.live/product/exo) scopes tool permissions per agent, enforces allowlists, and gates server access with approvals and time limits. The virtual patch is a change to the allowlist: when a tool is reported vulnerable, remove it from every agent's permitted set centrally until the server is updated. Because agents never hold downstream credentials, a compromised MCP server does not inherit the database password or the cloud key. The [LiteLLM incident](https://adaptive.live/blog/litellm-breach-agent-access-security) is a reminder of how quickly a flaw in agent tooling becomes an access problem. #### What does a virtual patching workflow look like on the proxy? OWASP's cheat sheet describes virtual patching as a process with six phases. The table maps each phase to what a team does when the enforcement point is the access broker. | OWASP phase | What it means on an access proxy | | --- | --- | | Preparation | Route the systems that matter through the broker before you need to, so a rule has somewhere to land. [Discovery](https://adaptive.live/product/discovery-and-classification) finds the endpoints you forgot. Keep policies as code through the CLI, REST API or Terraform provider. | | Identification | Watch vendor advisories and CISA's KEV catalog. Match affected versions to brokered endpoints using the inventory the broker already keeps. | | Analysis | Decide which protocol element the exploit needs: a command, a statement, a verb, a path, a tool, or a pre-authentication connection. That decides which of the four mechanisms applies. | | Virtual patch creation | Prefer the positive model where you can: allow the statements the application is known to send and deny the rest. Fall back to a negative rule that denies the exploit trigger. | | Implementation and testing | Deploy as a detective policy first and read the alerts. Promote to preventive once legitimate traffic is clean, and test in an approved environment. | | Recovery and follow-up | Apply the vendor patch, confirm it, retire the rule, and keep the audit trail as evidence that the window was covered. | OWASP's point that code-level fixes and virtual patching are not mutually exclusive applies here too. The rule on the proxy buys time. It does not replace the upgrade. #### What can a proxy not patch? Honest scope matters more for a compensating control than for a fix. Four limits apply. - **Client-side bugs.** PostgreSQL's [CVE-2025-1094](https://www.postgresql.org/support/security/CVE-2025-1094/) was a quoting flaw in the `psql` client's handling of invalid UTF-8, chained with a BeyondTrust vulnerability to reach code execution. A server-side proxy cannot fix a parser on the user's laptop. It can ensure that only brokered identities with scoped roles reach the database, and it can alert on the "invalid byte sequence" errors that exploitation attempts leave behind. - **Traffic that bypasses the broker.** A direct connection with a shared password, or an application service account that talks straight to the database, is outside the rule. Route service traffic through [workload access](https://adaptive.live/product/workloads) and rotate the credentials that used to allow direct connections. Absence from the broker's records does not establish absence of access. - **Exploits that look like legitimate work.** A logic flaw triggered by a normal-looking request is invisible to a deny rule. The positive model narrows the gap but cannot close it. - **The broker itself.** Adaptive is software with its own update cadence. A virtual patching program includes patching the enforcement layer. A virtual patch also carries an organizational risk: it works well enough that the real fix stops being urgent. Record each rule with the CVE it covers, an owner and a retirement condition, and review the open set in the same cadence as the vulnerability backlog. #### How can teams validate these controls? Use an approved test environment and a representative engineering account: 1. Pick one recent advisory that affects a brokered system and identify the exploit trigger: the command, statement, path, verb or tool it needs. 2. Write the rule as a detective policy. Run the team's normal workload for a day and confirm the alert count is zero or explained. 3. Promote the rule to preventive. Send the trigger through the broker from a test account and confirm it is denied and logged against the identity. 4. Try the same trigger around the broker: a direct connection to the host, an old kubeconfig, a saved console cookie. Each success is a bypass to close with a network rule, a credential rotation or a workload identity. 5. Apply the vendor patch, confirm the trigger is harmless, retire the rule, and export the audit records that show the window was covered. #### Frequently asked questions **Q: What is virtual patching?** Virtual patching is a security policy enforced between an attacker and a vulnerable system that blocks attempts to exploit a known vulnerability without changing the vulnerable code. OWASP defines it as "a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability." It is a compensating control used until the vendor patch is applied. **Q: Is virtual patching the same as a WAF?** No. A web application firewall is one place a virtual patch can be enforced, and the most common one for public web applications. The same idea applies at a network IPS, a Kubernetes admission controller, a host's configuration, or an access proxy that parses database, SSH, Kubernetes, HTTP and MCP traffic to internal systems. **Q: Can virtual patching replace patching?** No. It reduces the risk of a known exploit path while the fix is tested and deployed. The vulnerability remains, exploit paths the rule does not cover still work, and OWASP notes that code fixes and virtual patches are not mutually exclusive. Track every virtual patch as residual risk with an owner and a retirement date. **Q: How is virtual patching on an access proxy different from a WAF?** A WAF inspects HTTP to applications. An access proxy such as Adaptive's sits inline for every protocol that engineers, services and agents use to reach infrastructure, and attributes each request to an authenticated identity. That allows rules on database statements, server commands, Kubernetes verbs, console paths and MCP tools, scoped per role, with approval and expiry attached. **Q: Can Adaptive virtually patch any vulnerability?** No. It can remove network exposure for systems behind the broker, deny a specific statement, command, path or tool, gate a risky feature behind approval, and detect and terminate misuse. It cannot fix client-side bugs, traffic that bypasses the broker, or exploits that are indistinguishable from legitimate requests. Verify which elements each integration parses in your deployment. **Q: How long should a virtual patch stay in place?** Until the vendor patch is applied and verified on every affected system. Retire the rule at that point and keep the audit records as evidence. A rule that outlives its CVE is a sign that the real remediation has stalled. #### Cover the patch window with Adaptive Start with the next advisory that lands in your queue. Identify the exploit trigger, find the brokered systems it affects, and write the rule once on the proxy instead of once per host. [Request an Adaptive demo](https://adaptive.live/request-demo) to see how brokered access, preventive policies and tool-level allowlists can shield databases, servers, clusters, consoles and agents while the patch is on its way. Download this article as [Markdown](https://adaptive.live/blog/virtual-patching-with-access-proxies/article.md) or [plain text for LLMs](https://adaptive.live/blog/virtual-patching-with-access-proxies/llms.txt). Both include publication metadata and source links. ### Binance Hack: From DevOps Access to Wallet Control Source: https://adaptive.live/blog/binance-hack-eip-7702-privileged-access Published: 2026-11-02T00:00:00.000Z Author: Adaptive Team Category: Bits and Breaches How the reported Binance compromise reached wallet signing authority through DevOps access, and how Adaptive helps govern the infrastructure behind the signer. **An attacker does not have to steal a private key if they can make the system holding it sign a malicious request.** That is the access-security problem at the center of [Fireblocks' analysis of the Binance exploit](https://www.fireblocks.com/blog/binance-hack-eip-7702). In its [October 30, 2026 update](https://www.binance.com/en/square/post/383048947006139), Binance reported approximately $6.3 billion in assets stolen from hot wallets on October 29. It said its initial investigation suggested a compromised laptop, that investigators had found additional compromise points, and that it had found no evidence of leaked wallet private keys. For engineering and security teams, the question is concrete: **what can someone controlling an engineer's machine persuade production systems to do?** Adaptive can help constrain that access through brokered connections, temporary privileges, separate workload identities, and activity records. *Published November 2, 2026. The incident account below draws on the October 30 Binance update and Fireblocks analysis. Those disclosures do not establish the complete intrusion path. The proposed access design is Adaptive's analysis.* #### How did the reported compromise reach the wallets? [Fireblocks describes this sequence](https://www.fireblocks.com/blog/binance-hack-eip-7702): 1. **A DevOps workstation was compromised.** The attacker reportedly reached a service container through a machine with deployment access and signing capabilities. 2. **Wallet authority was redirected.** A signed EIP-7702 authorization delegated the Binance 14 hot wallet to a malicious contract. The attack established a new delegation rather than exploiting an existing delegation contract. 3. **The attacker invoked the delegated wallet.** The malicious code executed in the wallet's context and transferred assets out. Fireblocks reports the first transfers within three minutes of delegation. 4. **The delegated authority remained useful.** Subsequent calls could drain additional funds, including new deposits, without a fresh wallet signature for each transfer. This describes the reported EIP-7702 component. It does not explain every affected chain: Fireblocks explicitly separates Bitcoin and Tron movements from that mechanism. The disclosures also leave open how the laptop was first compromised and the full extent of access to the signing infrastructure. #### What made EIP-7702 delegation powerful? [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) lets an externally owned account, normally controlled by a private key, authorize execution of another contract's code in its own context. The account signs an authorization identifying the delegate, chain scope, and nonce; another party can submit it. The delegation persists until changed or cleared. It is not limited to the transaction that installs it. A malicious delegate can therefore permit later asset transfers without requiring the account owner to approve each one. The security decision is the delegation itself: **which code is this account authorizing to act for it?** Reviewing ordinary transfers alone leaves that decision outside the review. The standard's [security considerations](https://eips.ethereum.org/EIPS/eip-7702#security-considerations) emphasize the substantial authority granted to delegated code. #### Why protecting the key is only part of the design Consider a hypothetical withdrawal service. Its key stays inside a dedicated signing system. An engineer cannot export it, but can change the service that prepares signing requests. If the signer accepts whatever that service submits, the engineer's deployment permission indirectly controls what gets signed. That is a design review scenario, not a claim about Binance's exact implementation. It illustrates why access reviews need to follow permissions through several systems: | Permission to review | Question it should answer | | --- | --- | | Inspect a production service | Can the operator also execute code inside it or read its secrets? | | Deploy an application | Can the deployer change the component that constructs signing requests? | | Use a workload identity | Does that identity permit ordinary operations, policy changes, or both? | | Administer the signer | Can the same person change policy and approve the resulting request? | | Manage access controls | Can an operator grant themselves a more powerful role? | A login approval answers who may enter a system. A separate signing decision must assess the operation that system requests. Both boundaries need their own enforcement and evidence. #### How Adaptive can help secure the infrastructure behind the signer ##### Give engineers access to a task, with an expiry [Adaptive's authorization controls](https://adaptive.live/product/authorization) support granular roles, approval workflows, and expiring grants. Use them to define what an on-call engineer needs for a particular investigation: the resource, permitted operations, approver, and access window. For example, diagnosing a withdrawal queue might require logs and selected database reads for 30 minutes. It need not include a shell on the signing host, production secret access, or permission to deploy a replacement service. Escalation to maintenance should be a separate reviewed grant. Scope matters as much as duration. A temporary administrator can still do serious damage during an approved session. Validate restrictions against the actual commands, resource roles, and integration in use. ##### Keep infrastructure credentials behind the access broker [Adaptive's privileged access](https://adaptive.live/product/access) brokers supported connections to servers, databases, Kubernetes, and cloud resources. Engineers authenticate with their own identities while downstream credentials remain behind the broker. That reduces reusable infrastructure secrets on laptops and makes individual access easier to revoke. A compromised endpoint may still abuse an active, permitted session, so pair credential isolation with narrow permissions and session controls. Enforce the same access design through destination permissions and network restrictions. Direct SSH, cloud consoles, emergency accounts, and cluster credentials must not provide an unrestricted alternative to the approved connection. ##### Separate people, deployments, and runtime workloads [Adaptive's workload access](https://adaptive.live/product/workloads) supports distinct identities and brokered access for pipelines, services, and agents. Give each production workflow an identity with a specific owner and resource scope. For a withdrawal platform, separate the engineer investigating a failure, the pipeline deploying an approved artifact, and the running service accessing its database. Manage permission to alter any of those identities separately too. This makes a useful review possible: can the diagnostic identity become the deployment identity, or can the deployment identity rewrite its own access policy? Enforce the answers through the relevant cloud, cluster, and application controls as well as Adaptive. A signing system still needs to evaluate requests independently of those infrastructure identities. ##### Make access activity available to responders [Adaptive's audit capabilities](https://adaptive.live/product/audit) capture supported commands, queries, and sessions against identities. [SIEM integration](https://adaptive.live/product/siem-and-alerting) brings those records into the tools security teams already use. Correlate an access approval with the resulting session, a deployment change, a signing request, and an on-chain event. That requires evidence from the access platform, deployment system, signer, and blockchain monitoring; no single log establishes the whole sequence. Administrators can terminate supported live sessions through Adaptive. During an incident, coordinate that action with endpoint isolation, credential revocation, and wallet-specific containment. Ending an infrastructure session does not reverse an authorization already recorded on-chain. #### Where wallet controls must take over Adaptive governs supported infrastructure access. Wallet custody, transaction validation, and EIP-7702 delegation policy belong in the signing and wallet systems. For an example architecture, require independent review of delegation changes, restrict general-purpose signing, and test that a service authorized for routine withdrawals cannot change wallet authority. Keep the approval mechanism under administration separate from the workload making the request. These are deployment requirements to verify, not claims of a native Adaptive wallet integration. The implementation needs a concrete rejection test: an engineer with a valid maintenance grant should still be unable to obtain an unauthorized wallet delegation. A successful login or an audit record alone does not demonstrate that boundary. #### Test the access path before an incident Use a non-production environment and test wallets with no real funds: 1. Grant a diagnostic identity access to one service and verify that unrelated resources and privileged operations are denied. 2. Check whether that identity can obtain a workload credential, replace deployed code, or change its own permissions. 3. End the grant and verify both new-request denial and the handling of existing sessions. 4. Confirm that the signing layer independently rejects unauthorized changes to wallet authority, even from an otherwise approved service. 5. Reconstruct the exercise from access, deployment, and signing records, and assign owners to any missing evidence. This turns an access policy into a demonstrated limit on what a compromised identity can accomplish. #### Frequently asked questions **Q: Did Binance confirm that private keys were stolen?** Its [October 30 update](https://www.binance.com/en/square/post/383048947006139) said it had found no evidence of leaked wallet private keys. That was an investigative finding at that time, not a complete explanation of the compromise. **Q: Would just-in-time access alone prevent this kind of attack?** No. Expiry reduces standing access, but an attacker can misuse privileges while a grant is active. Narrow resource permissions, independent approvals, and signing policy must also constrain the operation. **Q: Can Adaptive replace wallet signing controls?** No. Adaptive can govern supported access to the surrounding infrastructure. The wallet system must enforce which authorizations and transactions it will sign, and monitor changes to wallet authority. #### Review your production access with Adaptive Choose one sensitive service and trace the people, pipelines, and workloads that can inspect it, modify it, or change its permissions. [Request an Adaptive demo](https://adaptive.live/request-demo) to map supported access paths, replace standing privileges with scoped grants, and build an attributable record of production activity. Download this article as [Markdown](https://adaptive.live/blog/binance-hack-eip-7702-privileged-access/article.md) or [plain text for LLMs](https://adaptive.live/blog/binance-hack-eip-7702-privileged-access/llms.txt). ### Club Tourism Data Breach: 4.32 Million Member Records at Risk Source: https://adaptive.live/blog/club-tourism-data-breach-customer-pii-access Published: 2026-11-01T02:00:00.000Z Updated: 2026-11-01T02:00:00.000Z Author: Adaptive Team Category: Bits and Breaches What we know about the Club Tourism data breach affecting up to 4.32 million member records, and how Adaptive helps protect customer PII databases. **Club Tourism, a Japanese travel agency in the KNT-CT Holdings group, said on October 31, 2026 that personal information of about 4.32 million internet reservation members may have leaked after unauthorized access from outside.** According to [BigGo Finance's summary of the company's announcement](https://finance.biggo.com/news/8ac00f65-0d92-45fa-8550-754880eb0fb1), the data may include names, nationalities, genders, addresses, phone numbers and emergency contact details. The company said passport information, payment card details and authentication passwords were not included. The intrusion route had not been disclosed when the incident was announced. The access-control question for any company that holds customer data is still clear: **which people, applications and vendors can read an entire customer table, and would anyone notice if they did?** Adaptive can help teams classify customer PII, mask fields for roles that do not need raw values, broker and time-limit privileged access, and alert on unusual bulk reads. These controls reduce exposure on the paths they govern. They do not replace application security, patching or network defenses. *Published November 1, 2026. Incident details are attributed to Club Tourism's announcement as reported by [BigGo Finance](https://finance.biggo.com/news/8ac00f65-0d92-45fa-8550-754880eb0fb1) and [Jiji Press](https://news.infoseek.co.jp/article/jiji_2026103100452/). The access design and validation steps below are Adaptive's analysis.* #### What happened in the Club Tourism data breach? Club Tourism detected unauthorized access at 5:45 a.m. Japan time on October 30, 2026 and began investigating. It confirmed that some user information may have been taken from its systems. The company isolated the affected server, blocked communications from the source of the attack, and suspended its website while it determines the cause. It plans to restore the site once safety is confirmed. | At a glance | As reported | | --- | --- | | Organization | Club Tourism (KNT-CT Holdings group), Japan | | Detected | October 30, 2026, 5:45 a.m. Japan time | | Disclosed | October 31, 2026 | | Potentially affected | About 4.32 million internet reservation member records | | Data that may be exposed | Names, nationalities, genders, addresses, phone numbers, emergency contacts | | Reported as not included | Passport information, payment card data, authentication passwords | | Attack method | Not disclosed at announcement | | Status | Server isolated, website suspended, investigation ongoing | The 4.32 million figure is the scope of possible exposure. It is not a confirmed count of exfiltrated records or of unique individuals. #### Why does this customer data matter if no passwords or cards were taken? Names, addresses, phone numbers and nationality give attackers enough context for convincing targeted phishing, phone scams and impersonation. A travel company is an easy pretext: messages about booking changes, refunds or account verification can look routine to a customer. Emergency contact details add a second group of affected people. Family members and friends listed as contacts never created an account, but their names and phone numbers may now sit next to the member's address. Club Tourism members should treat unexpected messages about bookings, refunds or account checks with caution and verify them through official channels. Anyone who reused their Club Tourism password elsewhere can change it as a precaution, even though passwords were reported as not included. #### Why are reservation databases a high-value access target? A reservation platform rarely has a single front door. The booking website, call-center tools, customer relationship systems, marketing pipelines, analytics copies and outsourced developers may all touch the same member data. BigGo's analysis also notes that the company may face scrutiny over group-wide governance, including oversight of outsourced contractors. Each path deserves its own review: | Path to customer data | Question for the access review | | --- | --- | | Web application service account | Can its database credential export the whole member table, and would a full-table read raise an alert? | | Call-center and support staff | Do agents need full addresses, nationality and emergency contacts, or would masked values support the task? | | Engineers and database administrators | Is production access standing, or granted per task with an expiry? | | Outsourced developers and vendors | Is vendor access brokered, scoped, time-bound and recorded? | | Analytics and marketing copies | Do downstream copies hold raw PII that the task does not require? | This is an example review model, not a reconstruction of Club Tourism's environment. Each answer should name an owner and a control. #### What should consumer and travel companies do first? Start with the data, not the perimeter. Build an inventory of where member PII lives, including replicas, backups, exports and analytics stores. Then list every identity, human or machine, that can read those tables in bulk. Set a baseline for normal read volume per identity and alert when it is exceeded. A support agent who reads a few dozen records an hour and a service account that suddenly reads millions of rows are both worth investigating. Prepare the evidence that a notification decision will need. Japan's Act on the Protection of Personal Information (APPI) requires reporting to the Personal Information Protection Commission and notifying individuals for certain incidents, including those that may affect more than 1,000 people. Query-level records showing which identity read which data, and when, help narrow the affected population faster than server logs alone. #### How can Adaptive help protect customer PII databases? ##### Find and classify customer PII [Adaptive's data discovery and classification](https://adaptive.live/product/discovery-and-classification) identifies data sources across your cloud environment and labels sensitive columns with built-in and custom data classes. Fields such as nationality and emergency contacts can be tagged explicitly so policies follow them. Classification is the starting point, not the outcome. Review the results with the system owner, because copies and free-text fields may hold PII that column names do not reveal. ##### Mask fields for roles that do not need raw values [Adaptive's data masking](https://adaptive.live/product/protect) applies predefined and custom masks to email addresses, phone numbers and other classified fields for non-privileged users, without changing the underlying data or the application. A support workflow can confirm a customer's identity with partial values instead of displaying a full address and emergency contact. Masking at the access layer governs connections that pass through it. Application screens and exports that read the database directly need their own controls. ##### Broker and time-limit privileged access [Adaptive's privileged access](https://adaptive.live/product/access) lets engineers, database administrators and vendors reach production databases with their own identity, without receiving shared database passwords. [Authorization workflows](https://adaptive.live/product/authorization) add approvals and grants that expire, so a contractor's access to the member database ends when the task does. Keep vendor identities separate from employee identities so one relationship can be revoked without disrupting others. ##### Give applications and pipelines scoped identities [Adaptive's workload access](https://adaptive.live/product/workloads) issues scoped identities to pipelines, BI tools and internal tools, and can apply data policies so pipelines move masked data instead of raw values. Reducing the number of raw PII copies reduces the number of places a breach can reach. ##### Monitor data activity and flag bulk reads [Adaptive's database activity monitoring](https://adaptive.live/product/monitor) records queries against the identity that issued them. Detective policies raise alerts on unusual activity, and preventive policies can block or restrict a statement in real time. [Anomaly detection](https://adaptive.live/product/anomaly-detection) and [SIEM integration](https://adaptive.live/product/siem-and-alerting) help security teams spot and correlate unusual volume. Tune thresholds against real workloads first. A batch job that legitimately reads the whole table should run under its own identity so its activity does not mask a human's. ##### Keep evidence for scoping and notification [Adaptive's audit capabilities](https://adaptive.live/product/audit) keep identity-linked query logs and session recordings, and the access matrix shows who could reach which data source. That evidence supports both incident scoping and regulatory reporting. Store exported audit evidence where the identities under investigation cannot change it. #### How can teams validate these controls? Use a non-production copy of a customer database with synthetic records: 1. Run classification and confirm that every PII column, including emergency contacts and free-text notes, is labeled. 2. Connect as a support-role user and confirm that sensitive fields are masked while the task still works. 3. Run a full-table read as a test identity and confirm that an alert fires, or that a preventive policy blocks it, within your target time. 4. Grant a vendor test account time-limited access, let it expire, and confirm that new connections fail. 5. Reconstruct the test from audit records alone, including who read which records and when. #### Frequently asked questions **Q: What happened in the Club Tourism data breach?** On October 31, 2026, Club Tourism said unauthorized access detected on October 30 may have exposed personal information tied to about 4.32 million internet reservation members. The company isolated the affected server, blocked communications from the attack source, and suspended its website during the investigation. **Q: What data was exposed in the Club Tourism breach?** Reported data includes names, nationalities, genders, addresses, phone numbers and emergency contact details. The company said passport information, payment card data and authentication passwords were not included. **Q: Is 4.32 million the number of affected people?** It is the number of member records the company described as potentially affected. It does not confirm that every record was taken or that each record represents a unique person. **Q: What should Club Tourism members do?** Be cautious with unexpected calls, emails or texts about bookings, refunds or account verification, and verify through official channels. Change reused passwords as a precaution and watch for official notices from the company. **Q: Would Adaptive have prevented the Club Tourism breach?** The intrusion route has not been disclosed, so no one can say what would have prevented it. Adaptive helps reduce bulk access to customer data through classification, masking, scoped and expiring access, activity monitoring and identity-linked audit records on the paths it governs. #### Review customer data access with Adaptive Pick one customer database and map every identity that can read it in bulk, every copy of its PII, and every alert that would fire on a full-table read. [Request an Adaptive demo](https://adaptive.live/request-demo) to see where classification, masking, expiring access and data activity monitoring can close the gaps. Download this article as [Markdown](https://adaptive.live/blog/club-tourism-data-breach-customer-pii-access/article.md) or [plain text for LLMs](https://adaptive.live/blog/club-tourism-data-breach-customer-pii-access/llms.txt). Both include publication metadata and source links. ### VOLTA Infostealer: AI Victim Appraisal and Access Risk Source: https://adaptive.live/blog/volta-infostealer-ai-victim-prioritization-access-risk Published: 2026-11-01T01:00:00.000Z Updated: 2026-11-01T01:00:00.000Z Author: Adaptive Team Category: Bits and Breaches Learn how the VOLTA infostealer uses an LLM to rank stolen credentials by value, and how Adaptive limits the access an infected endpoint can expose. **VOLTA is a Windows infostealer that sends what it steals to a large language model for appraisal.** According to [Cisco Talos's October 31 analysis](https://blog.talosintelligence.com/appraisal-by-ai-model-driven-victim-prioritization-in-the-volta-infostealer/), the malware, which names itself "VOLTA-AUTODOXER", collects browser credentials, session tokens, SSH keys and cloud configuration files. It then asks an LLM to rank the victim's assets by monetization value and to assess the victim's security habits. Talos calls the AI's contribution "effort displacement": the model does the triage an operator would otherwise do by hand. That leaves security teams with a practical question: **what would an automated appraisal find on your engineers' laptops?** Every long-lived key, saved password and persistent session on an endpoint makes it a more valuable target. Adaptive can help reduce that inventory. Users reach infrastructure through a broker with their own identity, receive scoped grants that expire, and work in recorded sessions that administrators can terminate. These controls do not remove malware or prevent theft from the browser. They limit what a stolen session can reach and how long it stays useful. *Published November 1, 2026. Technical findings are attributed to Cisco Talos. The access design and validation steps below are Adaptive's analysis.* #### What is the VOLTA infostealer? Talos describes VOLTA as "a mature stealer implant with an optional AI-integration layer." The sample is a 64-bit Windows executable that may delete itself after running. It appears to be sold through a builder: each customer's binary is generated from a template with slots for API keys, a Telegram channel and settings. Talos does not describe how VOLTA is delivered or first executed. It found no attacker-owned infrastructure: "All the observed endpoints for this malware are third-party controlled." | At a glance | As reported by Talos | | --- | --- | | Malware | VOLTA ("VOLTA-AUTODOXER"), Windows PE32+ x86-64 | | First seen | October 11, 2026 (UTC) | | Role of AI | Ranks stolen assets and profiles the victim after collection | | LLM access | Third-party API through OpenRouter, with fallback across three model providers | | Local output | `Identity_Report.txt`, `AI_Analysis.txt`, and staged ZIP archives | | Infrastructure | No actor-owned servers observed | #### What data does VOLTA steal? Talos lists a broad set of targets. It takes passwords, cookies and saved payment cards from Chromium browsers, plus Firefox, Thunderbird and Outlook profiles. It also collects Slack workspaces, Microsoft OAuth tokens, SSH keys and cloud-provider configuration files (including gcloud), as well as Discord, Telegram and gaming sessions. The list continues with saved Wi-Fi passwords, cryptocurrency wallet seed phrases and screenshots. VOLTA then uses stolen sessions to add context. It searches a victim's Gmail for retail and delivery receipts to confirm a home address, pulls food-delivery order history, and values gaming inventories. The resulting identity report includes the victim's employer and domain. For organizations, personal data is often not the most consequential part of that list. An engineer's Microsoft OAuth tokens, Slack workspace, SSH keys and gcloud configuration can lead into corporate systems. Talos notes that much of VOLTA's token theft depends on bypassing Chrome's App-Bound Encryption. #### How does VOLTA use AI to prioritize victims? After collection, VOLTA serializes the identity report as JSON and sends it to OpenRouter's chat completions API. According to Talos, the hardcoded default model is `anthropic/claude-opus-4.6`, with fallbacks to `moonshotai/kimi-k2` and `google/gemini-2.5-flash`. The malware checks each response for refusal phrases such as "I can't" and switches to the next model when it finds one. The system prompt tells the model to act as a forensic intelligence analyst. It must produce two sections. "WHAT THEY'RE WORTH" ranks the victim's valuables by monetization tier. "THEIR OPSEC" assesses security posture and password hygiene. The output is written to `AI_Analysis.txt` and exfiltrated with the identity report. Without an API key, VOLTA still runs as a conventional stealer. In Talos's view, the value of AI here is not speed or scale: "there is a difference between a wide net and a wide net that sorts itself." Talos also expects fallback chains that route around model refusals to become a standard design requirement. #### Why does AI appraisal raise the stakes for corporate access? Infostealers infect large numbers of machines, and sorting the haul for valuable access used to take operator time. If a model is told to find what a victim is worth, a laptop that holds an employer domain, admin console sessions, cloud CLI credentials and SSH keys is easy to pick out. The operator does not need to be targeting that company. The table below uses a hypothetical engineering laptop to show how endpoint credentials translate into reach: | Item on the endpoint | What it can unlock | Access-design question | | --- | --- | --- | | Cloud CLI configuration | Projects the account can administer | Does the laptop hold a refreshable cloud credential, or does access require a fresh, brokered sign-in? | | SSH private keys | Every server that trusts the key | Can servers be reached without a private key stored on the device? | | Admin console cookies | Authenticated console sessions | Do admin consoles run in the endpoint's browser or in an isolated session? | | Saved database passwords | Direct database connections | Does the user need to know or store the database password at all? | | Slack and Microsoft tokens | Messages, files and any secrets pasted into them | Are secrets shared in chat rather than through a governed workflow? | The "THEIR OPSEC" section shows what such an appraisal looks for. In an organization, standing credentials on endpoints are an opsec signal in the same way that reused passwords are. #### What should security teams do now? Talos recommends: - **Restrict headless Chrome.** Use an application control policy that limits which processes can launch Chrome with `--headless`, which blocks the decryption path VOLTA relies on. Alert when a process that is not a known developer tool starts headless Chrome. - **Use hardware-backed credential storage** where possible. - **Preserve evidence.** On a suspected infection, keep `%APPDATA%\volta_debug.txt`, because the executable may delete itself. The log records what was collected and whether the LLM call succeeded. - **Revoke and reset.** Revoke potentially compromised tokens and change passwords. Treat any wallet whose seed phrase was stored in plaintext as fully compromised. When the infected device belongs to someone with infrastructure access, scope the response from the evidence. List the corporate credentials that were present, such as cloud CLI tokens, OAuth grants, SSH keys and saved database passwords, and revoke each one with the system that issued it. A single-sign-on password reset may not invalidate every refresh token, key or downstream credential already issued. #### How can Adaptive help reduce infostealer access risk? ##### Keep infrastructure credentials off the endpoint [Adaptive's privileged access](https://adaptive.live/product/access) brokers connections to databases, servers, Kubernetes clusters and cloud accounts over SSH, RDP and browser-based terminals using centrally managed credentials. Engineers authenticate with SSO and MFA and reach the resource without receiving a database password or server key to store locally. The broker's sign-in then becomes the credential to protect. Configure session lifetimes and re-authentication through your identity provider, and test how long a copied session remains usable in your deployment. ##### Make privileged grants expire [Adaptive's authorization workflows](https://adaptive.live/product/authorization) grant production privileges just in time, with approvals and automatic expiry. A stolen session without standing production privileges is worth less to an operator. Because stolen credentials are not always used immediately, expiry also narrows the window in which they work. ##### Move admin consoles into isolated browser sessions [Adaptive's browser isolation](https://adaptive.live/product/browser-isolation) runs internal web apps and SaaS consoles in a managed browser instead of on the user's device. Downloads, clipboard and credentials stay inside the session, so console cookies are not sitting in the local Chrome profile for a stealer to decrypt. The user's identity-provider session on the endpoint still needs its own protection. ##### Give machines and agents their own identities Developer laptops often hold copied service account keys and tool tokens, and VOLTA explicitly collects cloud-provider configuration files. [Adaptive's workload access](https://adaptive.live/product/workloads) issues scoped machine tokens and stores workload secrets centrally, so long-lived keys stop living in local files. The [Google Cloud integration](https://adaptive.live/integrations/google-cloud) provides audited access to GCP resources without sharing service account keys. AI coding agents can use [Adaptive's MCP gateway](https://adaptive.live/product/mcp) instead of holding their own downstream credentials. ##### Detect misuse and cut it off [Adaptive's audit capabilities](https://adaptive.live/product/audit) record supported activity against identities, and [anomaly detection](https://adaptive.live/product/anomaly-detection) includes IP-based and contextual anomalies, which can surface a session replayed from an unexpected location. Administrators can join or terminate a live session, and [SIEM integration](https://adaptive.live/product/siem-and-alerting) streams events to the tools your security team already uses. Coverage matters. Activity through a direct connection or an unmanaged credential needs its own logging. Absence from the broker's records does not establish absence of access. ##### Rotate what the device could reach [Adaptive's credential rotation](https://adaptive.live/product/credential-rotation) can rotate supported database, server and network-device credentials on a schedule or on demand. When an endpoint is compromised, rotate the downstream credentials its user could reach, then confirm that the old values fail. #### How can teams validate these controls? Use an approved test environment and a representative engineering account: 1. Inventory the credential stores on a test laptop: browser profiles, `~/.ssh`, cloud CLI directories and tool configuration files. Record every item that grants corporate access. 2. Complete a routine task, such as querying a staging database, through the broker. Confirm that no new password or private key is written to disk. 3. In an approved exercise, reuse the test user's session from a different device and network. Check whether re-authentication requirements, policies or anomaly alerts respond. 4. Let a grant expire and confirm that new connections fail. Terminate a live session and confirm that it ends. 5. Reconstruct the test from independently stored audit records, then list any credential that remained on the endpoint as a remediation task. #### Frequently asked questions **Q: What is the VOLTA infostealer?** VOLTA is a Windows infostealer documented by Cisco Talos in October 2026. It steals browser credentials, session tokens, SSH keys, cloud configuration files and cryptocurrency wallets. It can then send the collected data to an LLM that ranks the victim's assets and assesses their security habits. **Q: How does VOLTA use AI to prioritize victims?** VOLTA sends a JSON identity report to an LLM through OpenRouter. The model is instructed to act as a forensic intelligence analyst and return two sections: one ranking the victim's valuables by monetization tier and one assessing their opsec. If a model refuses, the malware tries the next model in its fallback chain. **Q: Does VOLTA exploit a vulnerability in AI models?** Talos does not describe one. VOLTA calls third-party model APIs as an ordinary client. It detects refusals and switches to another model rather than relying on a single provider. **Q: How can organizations reduce the impact of an infostealer on a developer laptop?** Keep long-lived infrastructure credentials off endpoints, make privileged grants short-lived, isolate admin consoles from the local browser, and monitor for session reuse. Follow Talos's guidance on restricting headless Chrome and revoking tokens after an infection. **Q: Can Adaptive stop an infostealer from stealing credentials?** No. Adaptive is not endpoint protection and does not remove malware. It reduces the infrastructure credentials stored on endpoints, limits standing privilege, and records and terminates brokered sessions, which limits what stolen access can reach. #### Review endpoint access with Adaptive Start with one engineering team. Map the infrastructure credentials on their laptops, the systems each one reaches, and how quickly each could be revoked. [Request an Adaptive demo](https://adaptive.live/request-demo) to see where brokered access, expiring grants and isolated sessions can reduce what an infected endpoint gives away. Download this article as [Markdown](https://adaptive.live/blog/volta-infostealer-ai-victim-prioritization-access-risk/article.md) or [plain text for LLMs](https://adaptive.live/blog/volta-infostealer-ai-victim-prioritization-access-risk/llms.txt). Both include publication metadata and source links. ### PingCAP Security Incident: Stolen Service Account Credentials Source: https://adaptive.live/blog/pingcap-security-incident-service-account-credentials Published: 2026-11-01T00:00:00.000Z Updated: 2026-11-01T00:00:00.000Z Author: Adaptive Team Category: Bits and Breaches PingCAP says stolen service account credentials gave an attacker four weeks of access. See what was exposed and how Adaptive limits machine-identity risk. **PingCAP, the company behind TiDB and TiDB Cloud, reported that an unauthorized party used stolen service account credentials to access certain internal systems between September 9 and October 7, 2026.** In its [October 2026 security incident report](https://www.pingcap.com/trust-hub/security/security-update-october-2026/), PingCAP says the attacker copied data and obtained source code. The copied data includes TiDB Cloud account and usage records, business and billing information, and a table of encrypted TiDB Cloud API-key values. PingCAP says there is "no evidence that data stored in TiDB was impacted." For engineering and security teams, the takeaway is broader than one vendor: **a service account credential can be used for weeks without anyone noticing, and its permissions set the blast radius.** PingCAP's remediation steps include removing excessive permissions between cloud projects, adding storage access logging, and planning alerts for large data exports. Those steps line up with the controls that limit machine-identity risk. Adaptive can help teams give workloads scoped identities, rotate and expire their secrets, find excessive access paths, and alert on large exports with query-level evidence. These controls apply to the paths Adaptive governs and complement cloud IAM and secret scanning. *Published November 1, 2026. Incident details are attributed to PingCAP's report. The access design and validation steps below are Adaptive's analysis.* #### What happened in the PingCAP security incident? According to PingCAP, an unauthorized party used stolen service account credentials to access certain internal systems, copy data and obtain source code. The report does not say how the credentials were stolen. An external incident response firm "found no evidence that the attacker ran commands or maintained persistent access" in the production systems it reviewed. PingCAP adds: "This finding does not resolve the data exposure above." | Date (2026) | Event reported by PingCAP | | --- | --- | | September 9 | Unauthorized access window begins | | October 7 | PingCAP becomes aware and begins disabling or revoking affected accounts and credentials | | October 10 | Additional compromised credentials deleted, excessive permissions between cloud projects removed, extra cloud storage access logging enabled | | October 12–13 | External firm reports four vulnerabilities | | October 14 | All identified compromised credentials invalidated, identified unauthorized access paths blocked, all four vulnerabilities fixed and retested | | October 19 | Report published; investigation ongoing | PingCAP did not describe the type of the four vulnerabilities. It says it is checking production logs for any exploitation before they were fixed. #### What data was exposed in the PingCAP breach? | Category | What PingCAP reported | | --- | --- | | TiDB Cloud accounts and product use | User names, email addresses, organization and project associations, and SQL editor text and errors; some records also contained organization, project and cluster identifiers | | Business and billing | Customer contacts, contract terms, orders, pricing, payment terms and billing configuration | | Credentials | An exported table of encrypted TiDB Cloud API-key values; one investigator-owned value could not be used directly as an API key | | Source code | Obtained by the attacker | | Data stored in TiDB | No evidence of impact | PingCAP is still determining whether other usable credentials were exposed. It states that "The attacker's claims about credentials in support materials have not been verified." It also notes that "These findings do not mean that every customer had every category of information exposed." The company says it will notify affected customers directly once customer-specific impact is established. #### Why are service account credentials such a common breach path? Service accounts are built to run without a person present, and that makes them attractive to attackers. They usually authenticate without MFA, often use long-lived keys, and may be shared across jobs. Their permissions also tend to grow over time. Automated traffic can look routine, so a bulk export by a service account may not stand out the way an engineer downloading millions of rows would. | Service account property | Why it raises risk | Control to look for | | --- | --- | --- | | Long-lived key | Works until someone notices and revokes it | Short-lived credentials, scheduled rotation and documented revocation | | No interactive MFA | A stolen key is enough to authenticate | Workload identity bound to a trusted runtime, with network restrictions | | Accumulated permissions | One key reaches several projects or data stores | Per-task scope, regular access reviews and an access graph | | Automated access patterns | Bulk reads can blend in | Per-identity baselines and alerts for large exports | | Shared use | Activity is hard to attribute to one job | One identity per workload with an owner | PingCAP's own planned improvements follow the same pattern: broader credential rotation, access controls, code and secret scanning, audit logging, and "alerts for unusual access and large data exports." #### What should TiDB Cloud customers do now? PingCAP has not asked customers to take specific actions and says it will contact affected customers directly. Questions go to security@pingcap.com. The following precautions are Adaptive's suggestions, not PingCAP's instructions: - **Rotate TiDB Cloud API keys** and review where each key is stored and which automation uses it. Rotation is low cost compared with waiting for a final determination. - **Review organization and project membership** for unexpected users, and confirm that billing and technical contacts are current. - **Treat SQL editor content as potentially exposed.** If anyone pasted secrets, tokens or sensitive values into SQL editor queries, rotate those secrets. - **Watch for invoice and contract fraud.** Exposed contract terms, pricing and payment details can make fake invoices or payment-change requests look legitimate. Verify payment changes through a known contact. #### What should engineering teams learn for their own service accounts? Inventory every service account and key, with an owner, a purpose and a list of the systems it can reach. Remove permissions that cross project boundaries without a documented need. Enable access logging on storage buckets and data stores before an incident, not during one. PingCAP's October 10 change shows how important this visibility becomes during an investigation. Then test detection. Run a large export with a test service account and measure how long it takes for someone to be alerted. A four-week access window is a detection problem as much as a credential problem. #### How can Adaptive help limit service account and machine access risk? ##### Issue scoped machine identities [Adaptive's workload access](https://adaptive.live/product/workloads) issues scoped machine tokens to service accounts, pipelines, BI tools and AI agents, and registers trusted clusters. Each workload authenticates as itself instead of borrowing a shared credential, so one key does not quietly cover several systems. ##### Store, rotate and expire workload secrets Adaptive stores workload credentials centrally and manages issuance, rotation, renewal and offboarding, so long-lived keys stop living in config files and CI variables. [Adaptive's credential rotation](https://adaptive.live/product/credential-rotation) can rotate supported database and server credentials on a schedule or on demand, with a history of each change. Confirm coverage for each credential type. Cloud provider keys, third-party API tokens and application secrets may each need their own rotation process. ##### Find excessive and cross-project access [Adaptive's audit capabilities](https://adaptive.live/product/audit) include an access matrix and access graph that show which identity can reach which resource, and by which path. Use them in access reviews to find service accounts whose reach has grown beyond their job. ##### Broker database access and alert on large exports [Adaptive's database activity monitoring](https://adaptive.live/product/monitor) records queries against the identity that issued them, including machine identities brokered through Adaptive. Detective policies raise alerts on unusual activity, and preventive policies can block or restrict statements in real time. [Anomaly detection](https://adaptive.live/product/anomaly-detection) helps flag volume or access patterns that do not match an identity's baseline. Integrations such as [MySQL](https://adaptive.live/integrations/mysql) and [Google Cloud](https://adaptive.live/integrations/google-cloud) provide authenticated, auditable access without sharing downstream credentials. Validate support for your specific engine, service and version before relying on it. ##### Keep query-level evidence for impact analysis PingCAP is determining impact customer by customer. That work goes faster with records showing exactly which tables and rows each identity read. Adaptive keeps identity-linked query logs, and [SIEM integration](https://adaptive.live/product/siem-and-alerting) streams them to Splunk, Datadog, Coralogix or syslog for correlation with cloud audit logs. Coverage matters. Access that bypasses the broker, such as a direct cloud storage read with a cloud key, needs its own logging. #### How can teams validate these controls? Use a non-production project and a test workload: 1. Inventory the workload's current credentials and every resource each one can reach. Compare the result with what the job actually needs. 2. Move the workload to a scoped machine identity and confirm that it still works while access outside its scope is denied. 3. Rotate the workload's credential and confirm that the old value fails and the job recovers. 4. Run an oversized export with the test identity. Confirm that an alert reaches the right team, or that a preventive policy blocks the export, within your target time. 5. Reconstruct the test from audit records, including which identity read which data and from where. #### Frequently asked questions **Q: What happened in the PingCAP security incident?** PingCAP reported that between September 9 and October 7, 2026, an unauthorized party used stolen service account credentials to access certain internal systems, copy data and obtain source code. PingCAP found out on October 7. By October 14, it had invalidated all identified compromised credentials, blocked the identified access paths, and fixed four vulnerabilities reported by an external firm. **Q: Was customer data stored in TiDB affected?** PingCAP says there is no evidence that data stored in TiDB was impacted. Investigators found no evidence that the attacker ran commands or maintained persistent access in the production systems reviewed. However, account, usage, billing and contract records were exported. **Q: Were TiDB Cloud API keys exposed?** An exported table contained encrypted TiDB Cloud API-key values. One investigator-owned value could not be used directly as an API key. PingCAP is still determining whether other usable credentials were exposed. **Q: Should TiDB Cloud customers rotate their API keys?** PingCAP has not asked customers to take specific actions. Rotating TiDB Cloud API keys and reviewing account members is a low-cost precaution while the investigation continues. **Q: How can Adaptive help protect service account credentials?** Adaptive gives workloads scoped machine identities, stores and rotates their secrets centrally, shows excessive access paths, and records query-level activity with alerts for unusual exports. These controls apply to the access paths Adaptive governs. **Q: Does Adaptive replace cloud IAM or secret scanning?** No. Adaptive complements cloud IAM, secret scanning and code security. Cloud keys and storage access outside the broker still need least-privilege IAM policies and their own logging. #### Review machine-identity access with Adaptive Start with your most privileged service account. Map what it can reach, how long its credential lives, and how quickly a large export would be noticed. [Request an Adaptive demo](https://adaptive.live/request-demo) to see where scoped workload identities, managed rotation and data activity monitoring can shrink that blast radius. Download this article as [Markdown](https://adaptive.live/blog/pingcap-security-incident-service-account-credentials/article.md) or [plain text for LLMs](https://adaptive.live/blog/pingcap-security-incident-service-account-credentials/llms.txt). Both include publication metadata and source links. ### FortiBleed 2.0: Firewall Secrets and Privileged Access Source: https://adaptive.live/blog/fortibleed-2-firewall-secrets-privileged-access Published: 2026-10-28T00:00:00.000Z Updated: 2026-10-28T04:35:00.000Z Author: Adaptive Team Category: Bits and Breaches Understand FortiBleed 2.0's reported firewall credential exposure and how Adaptive helps with privileged access, password rotation, and audit trails. **FortiBleed 2.0 is a follow-up investigation into exposed FortiGate configuration material.** [Hudson Rock's October 27 report](https://www.infostealers.com/article/fortibleed-2-0-975-new-domains-40573-exposed-secrets-claim-your-ethical-disclosure/) identifies 40,573 records containing cleartext secrets. That is an exposure count, not a count of currently working logins. For infrastructure teams, the access-control question is broader than the firewall's administrator password: **which other systems can the credentials in a configuration reach?** A recovery plan needs to account for those dependencies as well as the appliance itself. Adaptive can help govern supported administrative connections, reduce shared-password distribution, rotate supported credentials, and keep identity-linked activity records. These controls complement appliance hardening and incident response; their effectiveness depends on the paths and permissions actually configured. *Published October 28, 2026. Reported findings are attributed to their sources. The access design and validation examples below are Adaptive's analysis.* #### What does the FortiBleed 2.0 report establish? The [investigation](https://www.infostealers.com/article/fortibleed-2-0-975-new-domains-40573-exposed-secrets-claim-your-ethical-disclosure/) analyzed 1,703 configuration reports. Most carry February 20, 2026 timestamps, which do not establish when compromise occurred. Its 975 additional domain labels are absent from the earlier comparison set; they are not 975 independently confirmed new victim organizations. The reported material includes local-user, directory-bind, administrative, mail, and cluster secrets. Account status, credential changes, authentication policy, and reachability affect whether exposed values can still be used. A blank MFA field does not prove MFA was disabled. The evidence does not establish one initial-access mechanism for every host. Organizations can use [Hudson Rock's disclosure portal](https://www.hudsonrock.com/fortinet) to investigate their own exposure. #### Why should firewall configuration be treated as sensitive access material? A configuration backup has two responsibilities that need different permissions: helping an operator restore a service, and preserving settings that may include authentication material. Giving someone permission to retrieve the entire backup can disclose more than the small configuration change they were asked to review. Consider a hypothetical branch-office firewall connected to a directory and a mail relay. Its maintenance operator needs a short session to update a network rule. That task does not require downloading configuration archives, changing the directory service account, or administering the mail system. Review those permissions separately: | Boundary | Question for the access review | | --- | --- | | Appliance administration | Can this identity change users, authentication settings, or management reachability? | | Configuration and backups | Can it export settings or retrieve historical copies containing secrets? | | Directory integration | What can the bind account read or modify, and where else can it authenticate? | | Remote access | Which identities can establish sessions, and which internal resources can those sessions reach? | | Credential lifecycle | Who can issue, rotate, revoke, or retrieve each credential? | This is an example review model, not a reconstruction of every affected environment. Treat each permission as an explicit grant with an owner. A directory lookup requirement, for example, provides no operational reason to grant directory-wide administration. #### What should potentially affected teams do first? [Fortinet's June assessment of the wider campaign](https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices) discussed credential reuse and brute-force activity rather than a new vulnerability. That historical assessment should not be treated as a proven root cause for every record in the October investigation. For impacted appliances, Fortinet recommends terminating administrative and VPN sessions, resetting credentials, enforcing MFA, updating software, comparing configurations with a trusted baseline, and reviewing appliance and directory logs. It also recommends restricting management exposure. Evidence of unauthorized modification requires compromised-device recovery; configured AD/LDAP identities need investigation as potentially compromised credentials. Use the vendor's current guidance for the device and software version involved. In your own response record, separate four outcomes: unauthorized access is contained, the appliance is trusted, affected credentials are replaced, and dependent services are working. Replacing a password proves only one of those outcomes. A successful service connection does not establish that old sessions have ended or that an unauthorized administrator has been removed. Record who verified each outcome and the evidence supporting it, without copying secret values into tickets. #### How can Adaptive help reduce this access risk? ##### Broker supported administration without distributing passwords [Adaptive's privileged access controls](https://adaptive.live/product/access) let teams broker supported infrastructure connections using centrally managed credentials and attributable identities. For a maintenance workflow, an operator should authenticate with their own identity and receive access to the selected resource. They should not need a shared appliance password in a chat message, local script, or personal password file. Separate identities for employees, vendors, and automation make it possible to revoke one relationship without losing track of every other consumer. Validate the supported protocol and device integration before designing the workflow. Brokering one management interface does not automatically govern a separate web console, local console, API token, or backup account. The appliance and its administrators may also retain access to configuration secrets; a broker cannot eliminate that exposure by itself. ##### Scope maintenance privileges and make grants expire [Adaptive's authorization workflows](https://adaptive.live/product/authorization) support granular permissions, approval routing, and grants that expire. Define the resource, task, approver, and access window for privileged maintenance. A contractor inspecting a branch device should not receive permanent administration of the entire fleet. An automation job that gathers health information should use a different identity from one allowed to alter authentication policy. Enforce the intended role at the destination and use the restrictions available for the connected protocol. Keep emergency access separately controlled and reviewed. An expiring grant reduces standing access, but powerful operations still need appropriate limits while the grant is active. ##### Rotate supported network-device credentials [Adaptive's credential rotation](https://adaptive.live/product/credential-rotation) covers supported network devices, including Fortinet integrations, alongside databases and servers. Teams can define password policies, schedule or trigger rotation, and retain a history of changes. Confirm coverage for the specific model, software, account type, and connection method. Network-device password rotation does not imply automatic replacement of every LDAP bind secret, mail credential, cluster secret, or external token stored in a configuration. Maintain a dependency record for each credential: its issuer, owner, consumers, privilege scope, and verification procedure. When an integration requires a separate rotation process, assign that process explicitly. Test both rejection of the old value and successful operation with the replacement. ##### Restrict alternate management paths [Adaptive's private resource access](https://adaptive.live/product/zero-trust-network-access) can help provide authorized access to selected resources. Pair it with appliance management restrictions, network controls, and destination roles so a direct route does not bypass the intended policy. Protect the broker, its credential store, and configuration backups as separate privileged systems. A maintenance identity should not automatically be able to change its own authorization or retrieve the broker's stored credentials. ##### Connect access records to the response timeline [Adaptive's audit capabilities](https://adaptive.live/product/audit) record supported activity against identities, while [SIEM integration](https://adaptive.live/product/siem-and-alerting) helps teams correlate it with other evidence. Combine these records with appliance, identity-provider, directory, and backup-system logs. The review should connect a person or workload to its approved task, accessed resource, session window, and observed changes. Keep exported evidence under administration separate from the identity being investigated. Coverage matters: activity through an unmanaged console or direct connection requires its own logging. Absence from a broker's records does not establish absence of access. #### How can teams validate the controls before rollout? Use a non-production device or an approved test environment and a representative maintenance identity: 1. Complete the intended task through the supported connection and confirm that the operator does not receive the downstream password. 2. Attempt an operation outside the approved role and access to a second device. Confirm that the relevant policies reject both. 3. End the grant and verify what happens to new requests and existing sessions for that integration. 4. Rotate a supported test credential, confirm the old value fails, and verify legitimate connections still work. 5. Check alternate management and backup paths, then reconstruct the activity from independently stored records. Document any gap as an explicit implementation task. A policy name or successful login is not evidence that the complete access boundary works. #### Frequently asked questions **Q: Is FortiBleed 2.0 the name of a new vulnerability?** It names a follow-up investigation, not a newly established vulnerability. Refer to the [published findings](https://www.infostealers.com/article/fortibleed-2-0-975-new-domains-40573-exposed-secrets-claim-your-ethical-disclosure/) and applicable vendor advisories separately. **Q: Does changing a firewall administrator password revoke every dependent credential?** No. Directory, remote-access, mail, backup, and other integration credentials have their own lifecycles. Inventory their issuers and consumers, then verify each affected credential's replacement and revocation. **Q: How can Adaptive help protect firewall administration?** For supported integrations, Adaptive can broker access, apply scoped and expiring grants, rotate device passwords, and maintain attributable activity records. Destination permissions and alternate access paths must enforce the same intended boundary. **Q: Does Adaptive remove the need to patch or recover a compromised firewall?** No. Access controls do not patch appliance software, remove persistence, or establish that a compromised device is trusted. Follow vendor recovery guidance and validate the device before relying on it again. #### Review your privileged access with Adaptive Start with one network device and map its administrative identities, configuration exports, dependent credentials, and recovery procedures. [Request an Adaptive demo](https://adaptive.live/request-demo) to assess supported connections and identify where scoped access, managed rotation, and independent records can improve that workflow. Download this article as [Markdown](https://adaptive.live/blog/fortibleed-2-firewall-secrets-privileged-access/article.md) or [plain text for LLMs](https://adaptive.live/blog/fortibleed-2-firewall-secrets-privileged-access/llms.txt). Both include publication metadata and source links. ### Railway Security Incident: Credential Exposure and Access Controls Source: https://adaptive.live/blog/railway-security-incident-workload-access Published: 2026-10-28T00:00:00.000Z Updated: 2026-10-28T04:35:00.000Z Author: Adaptive Team Category: Bits and Breaches What Railway disclosed in October 2026, how exposed credentials create downstream risk, and how Adaptive helps govern workload access and credential rotation. **Railway's October 2026 security incident involved unauthorized access to internal systems and possible exposure of customer secrets.** Its [October 21 disclosure](https://blog.railway.com/p/security-disclosure-wednesday-october-21st) warned that encrypted environment variables, and some decrypted values, may have been accessed. Railway advised customers to rotate stored secrets, including API keys and private registry credentials, and inspect service logs. For teams using a deployment platform, the access question extends to every system those credentials can reach. A database password, registry token, or AI provider key carries authority outside the platform that stores it. Adaptive can help reduce that exposure for supported connections by brokering credentials, restricting workload permissions, and recording access. Those controls require deliberate integration and enforcement; they do not establish that Adaptive would have prevented Railway's internal compromise. *Published October 28, 2026. Incident facts below reflect Railway's public reports reviewed on that date; the architectural recommendations are Adaptive's analysis.* #### What happened in the Railway security incident? Railway's [October 22 preliminary report](https://blog.railway.com/p/preliminary-report-october-security-incident), subsequently updated, describes escalation across internal systems, access to CI credentials, and decryption of a subset of customer environment variables. It estimates potential exposure in at most 1.85% of workspaces, approximately 100,000. Broader precautionary key revocations do not prove that every notified customer's secrets were accessed. Railway says running customer applications stayed online while new builds were paused. Its October 26 update reports service restoration for existing users. The report does not disclose the complete initial exploit, so claims about a specific unpatched vulnerability or a proven attacker attribution would go beyond the published evidence. The practical distinction is between **platform availability** and **credential validity**. An application can continue serving traffic while a credential it uses needs revocation at another provider. #### Why does an environment-variable exposure create downstream risk? Environment variables are a convenient configuration interface. When they contain reusable secrets, access to that configuration can become access to a database, cloud account, code repository, or paid API. Encryption at rest protects stored values under a particular key and access model. The application still needs a way to use those values. If the same compromise reaches both ciphertext and an authorized decryption path, storage encryption alone cannot enforce the intended workload boundary. [OWASP's secrets-management guidance](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) addresses this distinction and recommends restricted secret access, lifecycle management, and auditing. For your own application, review three separate permissions: who can retrieve a credential, who can use it, and who can broaden its authority. Combining all three under the deployment identity makes a single exposure harder to contain. #### What should affected Railway customers do? Start with [Railway's customer guidance](https://blog.railway.com/p/security-disclosure-wednesday-october-21st) and the issuing providers' revocation procedures. A useful recovery record should answer these questions for every relevant secret: | Recovery question | Evidence to keep | | --- | --- | | Has the exposed credential been revoked at its issuer? | Credential identifier, revocation time, and a failed authentication check using the old credential | | Which deployments and jobs used it? | Service owners, environments, scheduled jobs, and deployment versions | | Are replacement credentials narrowly scoped? | Allowed resources and operations, with separate production and development identities | | Is the replacement active in the running workload? | Successful connection checks after redeployment, without printing secret values | | Was the old authority used unexpectedly? | Provider audit events, repository and registry changes, and unusual API usage or billing | Treat containment as urgent. If replacing a credential requires downtime, choose that tradeoff explicitly rather than silently leaving a suspected credential active. Preserve investigation evidence while removing access. Railway's [deployment recovery guide](https://blog.railway.com/p/security-disclosure-recommendation-recover-failing-deploys) explains another operational issue: commits submitted during the pause were not queued. Teams may need to reconnect GitHub, recreate revoked CLI or CI credentials, and trigger the intended deployment. Updating a dashboard variable is not evidence that the running application has adopted it. #### How can Adaptive help with this scenario? ##### Keep downstream credentials out of workload configuration [Adaptive's workload access controls](https://adaptive.live/product/workloads) give service accounts and pipelines their own identity and broker supported resource connections through centrally managed credentials. For example, an application that only needs a reporting database should receive access to that resource through a restricted workload identity. Its deployment configuration should not carry the database administrator's reusable password. The broker and its credential store must sit behind a separate administrative boundary from the workload. This changes the consequence of a configuration leak: an exposed workload token should authorize only its configured scope. It is still a credential and still needs revocation if compromised. A broker does not make a compromised application harmless. ##### Separate routine access from privileged maintenance [Adaptive's authorization workflows](https://adaptive.live/product/authorization) support resource permissions, approval routing, and grants that expire. Use them to separate an application's normal data access from migrations, production debugging, and administrative changes. A reporting worker might read approved tables continuously. A migration identity might receive write access for a short, approved maintenance window. Neither needs permission to change the other identity's policy or retrieve unrelated secrets. Enforce these restrictions at the destination as well. If the workload can connect directly using a second credential, that path can bypass the broker's policy. ##### Make rotation a maintained operating capability [Adaptive's credential rotation](https://adaptive.live/product/credential-rotation) supports password rotation for connected databases, servers, and network devices. Central management can reduce the number of places an operator must update when a supported credential changes. Provider-issued AI keys, registry tokens, and third-party API credentials still require the corresponding provider's supported revocation and replacement process. Validate integration coverage before including a credential type in an automated rotation plan. Keep issuer identifiers and ownership records so an incident does not begin with a search for who controls each key. ##### Preserve attributable evidence outside the workload [Adaptive's audit capabilities](https://adaptive.live/product/audit) associate supported operations with identities. [SIEM streaming](https://adaptive.live/product/siem-and-alerting) sends access events to the team's monitoring tools for correlation. Combine these records with deployment, cloud, database, registry, and AI-provider logs. Investigators need to connect an identity to its permitted resources, the operations attempted, and the time its access ended. Keep the exported evidence under credentials the workload cannot use to delete it. For AI agents that operate infrastructure, [governed MCP access](https://adaptive.live/product/mcp) applies authorization and records tool activity on supported endpoints. This governs agent tool access; it does not automatically proxy every model-provider request made by an application. #### How should a team validate the access boundary? Use a staging workload with the permissions you intend to grant in production. Confirm that its ordinary task succeeds, then test the limits: 1. Attempt access to a second database or environment. It should be denied. 2. Attempt an administrative operation outside the workload's role. It should be denied even when the identity can authenticate. 3. Revoke the workload's grant and check both new connections and existing sessions according to the connector's behavior. 4. Verify that the workload cannot retrieve the downstream password or erase exported activity records. 5. Check that direct network paths and alternate credentials do not bypass the intended policy. These checks give a concrete measure of exposure. A successful broker login alone does not show that the workload has appropriately narrow authority. #### Frequently asked questions **Q: Were all Railway customers' secrets confirmed stolen?** No. Railway reported potential exposure affecting a subset of workspaces and requested broader precautionary revocations. A revocation notice alone is not confirmation of theft. See its [preliminary report](https://blog.railway.com/p/preliminary-report-october-security-incident). **Q: Does changing an environment variable revoke the old API key?** No. Replacing the configured value and revoking the old credential at its issuer are separate actions. Confirm the old key is rejected and the running workload uses the replacement. **Q: Can Adaptive prevent a deployment provider from being compromised?** Adaptive governs supported access paths you configure through it. It can help limit downstream credential exposure and permissions, but cannot guarantee prevention of a separate provider's internal compromise or remove an attacker's existing access there. **Q: Does Adaptive automatically rotate every AI-provider or registry key?** No such universal coverage is implied. Use Adaptive's supported credential-rotation integrations where available and the issuing provider's procedures for other keys. Test the complete recovery workflow before relying on it. #### Review your workload access with Adaptive Choose one production workload and map its identities, stored secrets, reachable resources, and emergency revocation steps. [Request an Adaptive demo](https://adaptive.live/request-demo) to evaluate which connections can be brokered, which privileges can be reduced, and which activity records your team needs. Download this article as [Markdown](https://adaptive.live/blog/railway-security-incident-workload-access/article.md) or [plain text for LLMs](https://adaptive.live/blog/railway-security-incident-workload-access/llms.txt). Both include publication metadata and source links. ### Zeabur Security Incident: Privileged Access and Secret Rotation Source: https://adaptive.live/blog/zeabur-security-incident-privileged-access Published: 2026-10-28T00:00:00.000Z Updated: 2026-10-28T04:35:00.000Z Author: Adaptive Team Category: Bits and Breaches Understand Zeabur's October 2026 incident, the risks of persistent admin credentials, and how Adaptive helps with scoped access, rotation, and audit trails. **Zeabur's October 2026 security incident illustrates how leaked administrative credentials can connect infrastructure compromise to customer-data exposure.** Its [preliminary report](https://zeabur.com/blogs/october-2026-security-incident) describes unauthorized access on October 14–15 to shared clusters, GCP Dedicated Servers, and internal systems, followed by reads from its platform database. The access-control lesson is specific: replacing an application password does not close every path held by a cluster administrator, cloud identity, or backup reader. Recovery requires finding the authority behind those paths and removing it. Adaptive can help teams govern supported administrative and workload access through scoped identities, expiring privileges, managed credentials, and attributable records. Its value depends on controlling the actual paths into the infrastructure, including alternatives that could bypass the intended policy. *Published October 28, 2026. This article separates Zeabur's reported findings from Adaptive's architectural recommendations. The provider's investigation remains preliminary.* #### What did Zeabur confirm? The [incident report](https://zeabur.com/blogs/october-2026-security-incident) identifies non-expiring cluster tokens, plaintext internal credentials, and publicly reachable administration interfaces. It confirms reads of 3,218,965 environment-variable records and account data covering 321,810 accounts. It also records root sign-ins to 101 GCP servers. A newly rotated credential entered a backup and was later used without authorization; the attacker's retrieval of that backup is assessed rather than directly confirmed. The original credential leak, including a possible connection to August's GitHub App key exposure, remains unconfirmed. These distinctions matter. A confirmed database read, an assessed acquisition route, and an unverified theory about initial access carry different evidentiary weight. They should not be compressed into a single definitive attack narrative. #### Why can changing a database password be insufficient? A database password controls one authentication path. A person or process with permission to run commands inside the database container may have additional ways to reach its data. A cloud administrator may have authority over the underlying disk. A backup reader may possess an older copy independently of the live service. Our architectural takeaway is to assess the **complete set of access paths to the data**, including the infrastructure around it. The application's login is only one part of that assessment. For example, consider a maintenance workflow that should inspect a single service. If its identity can also execute arbitrary commands across the cluster, read every secret, attach disks, and download backups, reducing the database role leaves substantial authority in place. That example is a design review scenario, not a claim about every affected Zeabur service. #### Why does credential rotation need a complete inventory? Rotation is effective when the old credential is rejected and the replacement cannot be obtained through the same exposure path. A team also needs to know which credentials can create, retrieve, or replace other credentials. Include configuration repositories, build settings, backup access, server initialization data, emergency accounts, and service identities in the inventory. For each item, record the issuing system, owner, scope, expiry, consumers, and procedure for verifying revocation. Keep backup authorization separate from live administrative access. A backup containing secrets is part of the secret-management boundary, even when it is kept for recovery. [OWASP's secrets-management guidance](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) recommends maintaining lifecycle records, limiting access, and making revocation and rotation repeatable. This leads to a practical completion criterion: rotation is not finished when a new value has been written. It is finished when the previous authority is invalid, legitimate consumers work with the replacement, and the exposure path has been addressed. #### How can Adaptive help with these access risks? ##### Replace shared administration with attributable access [Adaptive's privileged access](https://adaptive.live/product/access) brokers supported infrastructure connections and records sessions. [Workload identities](https://adaptive.live/product/workloads) give automation an identity distinct from a shared human administrator. Use separate identities for support, deployment, backup operations, and emergency recovery. A support engineer diagnosing one service should not inherit the credentials used to administer all clusters. A backup process should not use the deployment pipeline's cloud identity. Brokered access reduces the need to distribute reusable downstream passwords. It still requires protecting broker authentication and ensuring that a compromised client receives only the permissions intended for that identity. ##### Make privileged grants narrow and temporary [Adaptive's authorization controls](https://adaptive.live/product/authorization) support granular privileges, approvals, and expiring grants. Apply them to specific maintenance tasks and resources instead of issuing permanent administrative access for occasional work. | Task | Access to define | Separate authority to withhold | | --- | --- | --- | | Inspect a service failure | Approved diagnostic commands for the selected service | Cluster-wide secret retrieval and unrelated container execution | | Maintain a database | Required operations on the selected database during an approved window | Cloud disk administration and backup export | | Restore a backup | Access to the selected recovery material and destination | Permission to enumerate unrelated backups or alter retention policy | | Run a deployment | The intended repository, artifact, and target environment | Administration of workload identities and access policies | This table is an example policy design. Available enforcement depends on the connector, protocol, and destination permissions. Test the actual operation, including subprocesses and alternate interfaces, before treating a policy label as an effective boundary. ##### Reduce direct routes around governed access [Adaptive's private resource access](https://adaptive.live/product/zero-trust-network-access) can help teams expose selected resources to authorized identities. Pair it with destination firewall rules, cloud IAM, and cluster authorization so administrative interfaces do not remain reachable through unrestricted alternatives. Network membership alone should not grant database or cluster privileges. A newly connected machine still needs an explicitly scoped identity. A permitted database connection should also have an appropriate database role. These layers address different questions: whether a resource can be reached, whether the caller can authenticate, and whether the requested operation is allowed. ##### Manage supported credential lifecycles centrally [Adaptive's credential rotation](https://adaptive.live/product/credential-rotation) provides rotation for supported database, server, and network-device passwords. Centralizing these credentials can make ownership, replacement, and revocation easier to operate consistently. Cloud service-account keys, cluster tokens, application signing keys, and external API keys need their own supported lifecycle mechanisms. Do not assume a database-password rotation feature covers every credential in an incident. Coordinate issuer revocation with infrastructure recovery and verify the old credentials fail. ##### Keep evidence tied to identities and resources [Adaptive's audit capabilities](https://adaptive.live/product/audit) record supported queries, commands, and sessions against their identities. [SIEM integration](https://adaptive.live/product/siem-and-alerting) lets teams correlate those events with cloud, cluster, network, and database logs. For the example policies above, useful review signals include access outside the approved resource set, unusual secret reads, administrative grants, and unexpected backup operations. Configure these detections using the systems that observe the underlying activity. Adaptive cannot record traffic that bypasses its access path. Store exported evidence under separate administrative control, and test that the workload under investigation cannot delete it. A missing event should prompt a visibility check, not an automatic conclusion that nothing happened. #### What should affected Zeabur users do? Follow [Zeabur's remediation instructions](https://zeabur.com/blogs/october-2026-security-incident) for your deployment type. They call for replacing affected credentials, checking provider activity, and rebuilding compromised GCP hosts. Zeabur warns that earlier rotation after August does not remove the need to respond to this incident. Separate three workstreams in your own response: contain unauthorized access, recover trusted infrastructure, and investigate what the exposed authority was used to do. Changing a password does not remove an installed persistence mechanism or recover data that has already left a system. Introducing an access broker is a follow-on control improvement. It does not substitute for the provider's incident-specific remediation or establish that a host is clean. #### Frequently asked questions **Q: Was Zeabur's October incident conclusively traced to the August GitHub App key leak?** No. Zeabur identifies that connection as a hypothesis, not a confirmed initial-access path. Refer to the distinctions in its [preliminary report](https://zeabur.com/blogs/october-2026-security-incident). **Q: Does rotating an application password remove cluster-level access?** No. Cluster, cloud, host, and backup permissions are separate authorities. Review and revoke the affected administrative identities as well as the application's credentials. **Q: How can Adaptive reduce the impact of stolen credentials?** For supported access paths, Adaptive can keep downstream credentials behind a broker, restrict an identity's resource permissions, require temporary approvals, rotate supported passwords, and record activity. Direct paths and alternate credentials must be controlled too. **Q: Can Adaptive protect a database after its host is already compromised?** An access broker does not remove an attacker's local host privileges. Contain and recover the host first, then enforce and validate the intended network, identity, and resource boundaries. #### Review privileged access with Adaptive Start with one production service and list every identity that can reach its database, container, host, secrets, and backups. [Request an Adaptive demo](https://adaptive.live/request-demo) to review which access paths can be brokered and how to make each privileged operation scoped, temporary, and attributable. Download this article as [Markdown](https://adaptive.live/blog/zeabur-security-incident-privileged-access/article.md) or [plain text for LLMs](https://adaptive.live/blog/zeabur-security-incident-privileged-access/llms.txt). Both include publication metadata and source links. ### The LiteLLM Breach and How to Secure Agent Access Source: https://adaptive.live/blog/litellm-breach-agent-access-security Published: 2026-10-27T00:00:00.000Z Updated: 2026-10-28T04:20:00.000Z Author: Adaptive Team Category: Bits and Breaches Understand the October 2026 LiteLLM breach and how Adaptive addresses agent access risks through credential isolation, scoped permissions, and audit trails. **The October 2026 LiteLLM breach compromised release `v1.107.0` through stolen credentials and release-pipeline access.** The affected artifacts reached PyPI and container registries and contained credential-stealing malware. LiteLLM says its private enterprise distribution was unaffected. See its [incident advisory](https://docs.litellm.ai/blog/security-incident-oct-21-2026) for affected artifacts and response instructions, and its [October 23 investigation](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) for the corrected attack sequence. For teams building with AI agents, the incident raises a practical access question: **how much authority should an agent platform hold, and what happens if someone gains access to it?** Adaptive addresses that question by placing identity, authorization, credential handling, and audit controls between agents and the systems they use. The useful design goal is specific: a coding task should have access to its approved repositories and tools, without carrying administrative authority over the release process. *Reviewed October 28, 2026 against LiteLLM's incident advisory and completed investigation. The access-control recommendations below are Adaptive's analysis.* #### How did the LiteLLM breach happen? LiteLLM's [October 23 investigation](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) supersedes its early explanation about credentials leaking through logs. It describes this sequence: 1. **An exposed key remained valid.** A master key committed publicly on May 27 was removed from the repository but never revoked. 2. **Platform access revealed a privileged token.** On October 10, the attacker used that key to query the Agent Platform API and retrieve an organization owner's GitHub CLI token. 3. **CI became a way to collect more credentials.** Malicious workflows extracted additional secrets, including two maintainers' tokens. 4. **Release protections were overridden.** The owner token bypassed repository protections and redirected the release workflow to an attacker-controlled repository. 5. **Stolen identities completed the release.** The attacker triggered and approved the build using compromised accounts. The pipeline signed the artifacts; workflow records were subsequently deleted. The architectural lesson is that access to one service should not expose credentials powerful enough to administer unrelated systems. Removing a secret from a file also leaves the credential valid until the issuing system revokes it. #### Why did existing security controls fall short? Authentication establishes which credentials a request presents. Authorization determines what those credentials permit. When a workflow carries an administrator's token, an attacker who obtains that token can inherit authority far beyond the workflow's intended job. Approval processes need the same scrutiny. Two accounts provide limited separation if the same environment exposes both accounts' credentials. Protecting an approval requires separating the approver's access from the workload requesting the change. Artifact signing addresses another boundary. A valid signature cannot establish that the source was appropriate when the authorized pipeline itself built malicious input. Our takeaway from the [documented release sequence](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) is that release integrity depends on protecting source selection, workflow changes, and publishing authority together. #### How can Adaptive address these access risks? Adaptive provides controls for the agent's identity, execution environment, resource access, and activity records. Apply them to the operations routed through Adaptive, and remove direct credentials and alternate routes that would bypass those controls. GitHub permissions and CI configuration must enforce the same boundaries at the destination. ##### Keep infrastructure credentials outside the agent runtime An agent that needs to run a query or call a tool does not need to read the credential used to authenticate that operation. [Adaptive's governed MCP access](https://adaptive.live/product/mcp) brokers supported resource connections and applies the invoking user's authorization, without requiring downstream credentials in the agent's configuration. That changes what a compromised agent can collect. The agent can request a permitted operation through the broker; its configuration should not contain a reusable credential for unrestricted direct access. Broker authentication still needs protection. The broker and its credential store remain privileged infrastructure, with their own administrative boundaries. An agent must not be allowed to retrieve their secrets through another tool or configuration endpoint. ##### Give the agent a role specific to its task For a coding task, define the repository, allowed operations, and access duration before execution. A workflow that proposes a change should not also administer the organization, edit release protections, or approve its own deployment. [Adaptive's coding-agent controls](https://adaptive.live/usecases/coding-agents) support scoped repository access and policies for the commands and network endpoints available to a session. Use those controls alongside narrowly scoped destination credentials. The authorization needs to hold even if the agent produces an unexpected command. Delegating a user's access also requires care: if that user has broad privileges, inheritance alone is too permissive for a narrow task. Choose a restricted role or identity for the workflow. ##### Limit elevated access by time and approval [Adaptive's authorization workflows](https://adaptive.live/product/authorization) support granular permissions, approval routing, and grants that expire. A production operation can require a separate access request with a defined purpose and duration. Keep release approval credentials outside the coding environment. Routine code changes should not require temporary organization-owner access. If exceptional administration is necessary, use a separate administrative workflow and review its activity. Expiry reduces the time available for misuse. It does not make a powerful permission safe while active. Test how revocation affects both new requests and already established sessions for each connected system. ##### Enforce restrictions while the agent runs [Exo, Adaptive's agent harness](https://adaptive.live/product/exo), combines isolated execution environments with authorization for agents and tool calls. The coding-agent environment also supports command restrictions and network allowlists. For a repository task, configure access to approved source repositories and required build services. Restrict arbitrary outbound destinations, unrelated production systems, and administrative tools. Check scripts, subprocesses, and alternate clients when validating those boundaries; a command-name rule alone is not a complete isolation mechanism. A sandbox should start with limited credentials and limited reachability. Destroying it after execution does not reverse data already sent elsewhere or changes already made to a remote system. ##### Preserve evidence outside the execution environment [Adaptive's audit capabilities](https://adaptive.live/product/audit) associate supported activity with identities and provide session records and SIEM streaming. Combine those records with GitHub, CI, registry, and cloud audit events to reconstruct a release across systems. Store the exported evidence under separate administrative control. An identity allowed to run a workload should not also be able to erase the security team's records. Configure alerts for changes to access policy, unexpected privilege grants, and missing audit ingestion. Recording an operation helps investigation. Blocking it requires an enforcement policy at the relevant access or execution boundary. #### What would a scoped coding-agent workflow look like? Consider an agent asked to fix a bug and open a pull request. The following is an example access design, rather than a description of LiteLLM's deployment: | Boundary | Access to configure | |---|---| | Identity | A dedicated task identity or restricted delegated role, attributable to its requester | | Repository | The selected repository and the operations needed to propose a change | | Credentials | Brokered tools where supported; no organization-owner token in the agent environment | | Execution | An isolated session with approved commands and network destinations | | Duration | A grant bounded by the task, with a tested revocation path | | Release | A separate workflow, publishing identity, and independent approval | | Evidence | Activity exported to storage the task identity cannot modify | Before enabling the workflow, test whether it can reach a second repository, change access controls, contact an unapproved destination, or invoke release operations. Those requests should fail under the configured policies. Also verify that the permitted task still succeeds and that its activity can be reconstructed. This gives the team a concrete acceptance criterion: the agent can complete its assigned work within a defined set of permissions. #### What still needs protection in the release pipeline? Agent access controls are one part of software supply chain security. Separately protect the repository rules, workflow definitions, build inputs, signing authority, and registry permissions used to produce and distribute software. Review who can override protections. Keep publishing credentials out of ordinary test jobs. Verify the expected source repository and revision before promotion, and limit who can change those checks. Export release evidence to a separately controlled destination. For an environment that ran an affected LiteLLM artifact, follow the [maintainer's incident response instructions](https://docs.litellm.ai/blog/security-incident-oct-21-2026). Rebuilding affected environments and revoking exposed credentials are response actions; deploying new access controls does not clean up an existing compromise. #### Frequently asked questions **Q: What caused the October 2026 LiteLLM breach?** An unrevoked Agent Platform key exposed an organization-owner token, enabling further credential theft and release compromise, according to [LiteLLM's investigation](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain). **Q: How does Adaptive help secure AI agent access?** Adaptive combines scoped permissions, brokered resource access, time-bound grants, and identity-linked audit records. [Exo](https://adaptive.live/product/exo) adds isolated agent execution and tool-call policies. Their effectiveness depends on routing the relevant operations through those controls and removing bypass access. **Q: Does putting an agent in a sandbox protect its credentials?** A sandbox limits execution boundaries, but secrets placed inside it may still be accessible to its processes. Keep downstream credentials outside the agent runtime where supported, restrict outbound access, and limit the permissions of every credential the session can use. **Q: Can Adaptive replace GitHub and CI security controls?** Adaptive governs connected access and agent execution. Repository protections, CI isolation, source verification, signing, and registry permissions still require their own configuration. The access layer and destination permissions should enforce a consistent scope. **Q: What should a team evaluate first?** Choose one agent workflow and document its identities, credentials, reachable resources, and allowed operations. Then test whether its configured permissions permit anything beyond the task, whether revocation stops access, and whether independent records capture the activity. #### Apply this to your agent workflows Start with the tasks your agents perform today and remove authority they do not need. Use Adaptive to broker supported access, restrict execution, and maintain an attributable record, while keeping release administration separately controlled. [Request an Adaptive demo](https://adaptive.live/request-demo) to review a real workflow, the integrations it uses, and the policies needed to enforce its access boundaries. Download this article as [Markdown](https://adaptive.live/blog/litellm-breach-agent-access-security/article.md) or [plain text for LLMs](https://adaptive.live/blog/litellm-breach-agent-access-security/llms.txt). Both include publication metadata and source links. ### The eMudhra certificate compromise, explained Source: https://adaptive.live/blog/cve-2026-111943-emudhra-certificate-compromise Published: 2026-10-22T10:00:00.000Z Author: Adaptive Team Category: Bits and Breaches What broke in the eMudhra certificate compromise, why backend clients need updates, and how Adaptive patched in under an hour with Codex and Claude Code. [CVE-2026-111943](https://www.cve.org/CVERecord?id=CVE-2026-111943) tracks Go's response to the eMudhra certificate compromise. The underlying problem reaches beyond Go: private keys belonging to a certificate authority were recoverable, and some clients could still trust certificates signed with them. The part that deserves attention is how unevenly the fix reaches different software. A browser can reject a certificate while an API client on the same machine still accepts it. #### What actually broke Eight intermediate CA certificates associated with eMudhra had compromised private keys. [Google's security team](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) says those keys were generated with insufficient randomness. [CERT-In's advisory](https://www.cert-in.org.in/s2cMainServlet?CACODE=CICA-2026-3649&pageid=PUBADV01) gives a striking detail: the affected P-384 private keys had values smaller than 256. That means the numbers themselves were below 256, not that they were 256-bit keys. The keys could be recovered almost instantly from their public counterparts. This is a key-generation failure. The mathematics behind a strong algorithm does not help if its private key comes from a tiny, predictable set of values. In [its incident statement](https://emudhra.com/en/post/certificate-security-incident), eMudhra says the affected intermediates came from an April 2025 key-generation ceremony. It says its root CA private keys and other intermediate CAs were unaffected. That limits the scope to particular authorities; it does not make accepting their signatures safe. #### How a forged certificate gets accepted When an HTTPS client connects to a server, it checks a certificate chain. A server certificate is signed by an intermediate CA, which in turn chains to a root the client trusts. The client also checks the hostname, dates, certificate constraints, and applicable trust policies. An intermediate CA's private key carries the authority to sign other certificates. Recovering that key can let an attacker issue a certificate for a hostname they do not control. If a client still trusts the chain, the certificate's signatures can validate even though the server is an impostor. The attacker also needs to intercept or redirect the connection. Having the signing key does not automatically provide access to traffic. [Mozilla's disclosure](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) describes the risk as website impersonation, with the possibility of reading or modifying intercepted traffic. That could matter to a service sending an authorization token or a confidential request body. The connection may be encrypted, but the client has authenticated the wrong endpoint. There is an important limit to the public findings. [Google reports](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) that no TLS certificates chaining to the six affected TLS-issuing intermediates appeared in Certificate Transparency logs before its block. That rules out their use against CT-enforcing clients during that period. It does not settle what happened to clients without CT enforcement. #### Why backend clients need their own updates Firefox received a block through OneCRL on October 17, 2026. [Mozilla says](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) distribution to standard configurations finished within three hours of the report, without a browser update or restart. Backend software does not necessarily receive that protection. An HTTP library might use the operating system's roots, a runtime's bundled roots, or an explicitly configured CA file. [Cloudflare's write-up](https://blog.cloudflare.com/emudhra-certificate-compromise/) describes this split between verification paths. ![Editorial illustration of separate browser, operating-system, and application environments, each with its own certificate store.](https://adaptive.live/blog/cve-2026-111943-emudhra-certificate-compromise/separate-trust-stores-illustrated.webp) *Browser, operating-system, and application trust stores can update independently.* Updating the host does not replace a CA bundle baked into a container image. Updating a build toolchain does not change a compiled executable that is already running. And revoking a certificate at the CA only helps clients that receive and enforce the relevant revocation information. For Go, the additional protection is a denylist in `crypto/x509`. The [Go advisory](https://pkg.go.dev/vuln/GO-2026-6809) explains that it covers cases where system trust-store updates may not reach an application. The fixed releases filter out chains containing the distrusted intermediates. #### What to patch and how to check it These are reference fixes as of **October 22, 2026**. Use the current supported release or your distribution's documented backport. | Component | Reference fix | Follow-through | | --- | --- | --- | | Go 1.26 applications | [Go 1.26.10](https://groups.google.com/g/golang-announce/c/66pojueaQek) | Rebuild and redeploy the executable. | | Go 1.27 applications | [Go 1.27.3](https://groups.google.com/g/golang-announce/c/66pojueaQek) | Update build images as well as deployed artifacts. | | Applications using Mozilla NSS | [NSS 3.131.1](https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/vSxZxnOMMvs) | Confirm the application loads the updated trust data. | | Python applications using certifi | [certifi 2026.10.19](https://github.com/certifi/python-certifi/releases/tag/2026.10.19) | Check each environment and packaged bundle. | | OS and container CA packages | Your distribution's incident update | Check deployed images separately from their hosts. | The [incident coordination site](https://emudhra.we-have-a-problem.com/) maintains a longer list of affected software and patches. For an actual deployment, we would start with the processes making outbound TLS connections: services, background workers, CI jobs, package managers, agents, and administrative tools. For each one, identify the verifier and trust source, apply the appropriate update, and confirm the replacement artifact is running. Then check the behavior. The coordination site publishes diagnostic hosts with affected chains, including these curl examples: ```bash curl --head --connect-timeout 10 --max-time 20 \ https://dv-g3b-emudhra.we-have-a-problem.com/ curl --head --connect-timeout 10 --max-time 20 \ https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ ``` A certificate-validation error is the expected result. A timeout or DNS failure tells you nothing about certificate rejection. Do not add `-k` or `--insecure`. This checks that curl installation, not every application on the host. Run equivalent checks through the deployed application's TLS stack. The two URLs are spot checks; the coordination site lists more affected chains, including cross-signs. Also test the legitimate endpoints the application needs. Distrust can break a real service whose certificate chains through a removed authority. The answer is to follow the issuer's migration guidance, rather than switching off certificate verification. #### A few practical questions **Q: Is CVE-2026-111943 only a Go issue?** The CVE tracks Go's defensive update. The compromised CA keys can affect other clients that still accept the affected certificate chains. **Q: Do I need to replace my own website certificate?** Check its actual chain and the issuer's guidance. A certificate under a distrusted hierarchy may need replacing. Replacing an unrelated server certificate does not update your outbound clients' trust stores. **Q: Does a working website mean the patch is complete?** No. Verify the certificate-validation behavior of the clients you run, including services and containers. A browser's result does not establish what those clients trust. --- *Release references checked October 22, 2026. The linked upstream advisories carry subsequent updates.* #### Adaptive's defensive patch We patched Adaptive in under an hour in response to the eMudhra certificate compromise. There was no apparent issue in our environment. We used Codex and Claude Code with Astra and Fable to implement and validate the patch as a precaution. ## Company & Resources Company: Adaptive Automation Technologies, Inc. Product and website name: Adaptive. - [About Adaptive](https://adaptive.live/about): Company background and team. - [Blog](https://adaptive.live/blog): Articles on access management, identity, data security, infrastructure, and AI agents. - [Careers](https://adaptive.live/careers): Careers and applications. - [Partners](https://adaptive.live/partners): Partner program and collaboration. ## Legal & Discovery - [Website Text Index](https://adaptive.live/llms.txt): Concise overview and canonical page links. - [Privacy Policy](https://adaptive.live/privacy-policy) - [Terms and Conditions](https://adaptive.live/terms-and-conditions) - [End User License Agreement](https://adaptive.live/eula) - [Sitemap](https://adaptive.live/sitemap.xml): Index of website sitemaps. - [Blog Sitemap](https://adaptive.live/server-sitemap.xml): Published blog URLs. ## Citation Guidance Use https://adaptive.live/ for the company overview. Cite the relevant product, platform, integration, pricing, or use-case page for specific details. Use the current pricing page for commercial terms and the security page for audit and security statements. Cite each blog article's canonical source URL for its analysis; release references reflect the article's stated date, and linked upstream advisories carry subsequent updates.