Security

Overview

Fleet is designed with a security-first architecture. Every aspect of the system, from how analysis runs to how credentials are handled to how external services are accessed, is built to protect your data, your infrastructure, and your privacy. This page details Fleet’s security model.

Isolated Execution Environment

All analysis Fleet performs runs in a secure, isolated environment that is completely separate from:

• Your AIR deployment — Fleet’s analysis environment has no access to AIR’s internal systems, databases, or configuration.
• Your network — Fleet cannot reach your internal network, VPNs, or any systems behind your firewall.
• Your endpoints — Fleet cannot directly access managed endpoints. All endpoint interaction goes through the AIR API (see AIR Integration).
• Other users — each Fleet session runs in its own isolated environment. There is no cross-session or cross-user data access.

This isolation ensures that even if Fleet processes malicious files (which is its primary purpose), the malware cannot escape the analysis environment or affect any production systems.

Credential Protection

Fleet implements a strict credential separation architecture to ensure that API keys and credentials are never exposed to the AI agent.

How Credentials Are Protected

When you configure an API key for AIR integration or other services, the following protections apply:

1. Encryption at rest — credentials are encrypted when stored. They are never saved in plaintext.
2. Encryption in transit — all communication channels use encryption. Credentials are never transmitted in the clear.
3. Secure gateway separation — all external API calls (to AIR, threat intelligence services, web search) are routed through a secure gateway. The AI agent sends requests to the gateway, which attaches the appropriate credentials on the other side. The AI agent never sees, handles, or has access to your actual API keys.
4. No credential exposure — the architecture is designed so that even if the AI agent were instructed to extract credentials (which it is designed to refuse), it physically cannot access them. Credentials exist only within the secure gateway layer, outside the AI’s execution boundary.

What This Means in Practice

• You can safely use Fleet with your AIR API keys knowing they cannot be leaked through the AI conversation.
• External service credentials (for threat intelligence lookups, web searches) are handled the same way.
• No credentials appear in Fleet’s conversation history, workspace files, or analysis outputs.

Data Handling

No Persistent Storage

Fleet does not retain customer data between sessions:

• Session-scoped data — all files, analysis results, and conversation history exist only for the duration of the session.
• No cross-session memory — Fleet does not remember previous conversations or retain context from past sessions.
• No training on customer data — customer evidence and analysis results are not used to train AI models.

Data in Transit

• All communication between your browser and Fleet uses encrypted channels.
• All communication between Fleet and AIR uses authenticated, encrypted API channels.
• All communication between Fleet and external services routes through the secure gateway with encryption.

What Fleet Processes

Fleet processes only the data you explicitly provide:

• Files you upload as attachments
• Text you type in prompts
• Data retrieved from AIR when you request specific operations (endpoint information, evidence, triage results)
• Data retrieved from external services when you request threat intelligence lookups or web searches

Fleet does not independently scan your network, pull data from systems you have not connected, or access information beyond what you explicitly request.

AI Communication Security

All AI model communication is routed through Binalyze-managed secure endpoints:

• No direct third-party access — your data does not flow directly to AI model providers. All requests pass through Binalyze’s secure infrastructure.
• Request isolation — each request is processed independently. There is no shared context between different users or organizations.
• Response filtering — Fleet is designed to refuse requests that attempt to extract system information, credentials, or internal configuration details.

Administrative Controls

Usage Limits

Administrators can configure monthly usage limits to control Fleet consumption:

• Token-based usage limits can be set per organization.
• When the limit is reached, Fleet becomes unavailable until the next billing cycle or until the limit is increased.

Authentication

Fleet uses its own authentication system:

• Users log in to Fleet with their organization credentials.
• When AIR integration is configured, Fleet respects AIR’s role-based access control for endpoint operations. Users can only perform AIR operations that their role permits.
• All Fleet interactions are associated with the authenticated user for audit purposes.

Audit Trail

All Fleet interactions are logged and auditable:

• Session history — which users accessed Fleet, when, and for how long.
• Operations performed — what AIR operations Fleet executed on behalf of the user (endpoint queries, evidence acquisition, triage deployment, interACT commands).
• File uploads — what files were uploaded for analysis.

Audit logs are available through Fleet’s administration interface.

Summary

Security Control	Implementation
Execution isolation	Separate environment, no network/endpoint access
Credential protection	Encrypted storage, secure gateway separation, no AI exposure
Data persistence	None — session-scoped only
Data in transit	Encrypted on all channels
AI communication	Routed through Binalyze-managed secure endpoints
Administrative control	Usage limits, organization management
Authentication	Fleet credentials, RBAC enforced for AIR operations
Audit	Full interaction logging