No cameras. No video. No footage leaving your floor.

Botpylon's data model starts with what it does not collect. No cameras, no video feeds, no worker presence data, no persistent floor positional history beyond the rolling dispatch session window. We need robot ID, position, velocity, task state, and battery level. That is the full list.

Data minimization principles

Each principle is an intentional architectural decision, not a compliance checkbox added after the fact.

01

Telemetry only: no video or image capture

Botpylon ingests only robot telemetry data: robot ID, position coordinates, velocity, task state, and battery level. We do not access, request, or store any camera feeds, sensor images, or visual data from robot-mounted cameras or facility CCTV systems. This is a hard architecture boundary, not a configuration option.

02

No persistent floor positional data beyond session

Real-time position data is used for dispatch decisions and floor graph construction within the active dispatch session. Granular robot position history is not stored beyond the rolling congestion model window (approximately 7 days for trend modeling). No historical floor replay capability is provided or maintained.

03

Encrypted API tokens with rotation support

All WMS and fleet controller API integrations use encrypted bearer tokens. Tokens are stored encrypted at rest. Botpylon supports token rotation via the configuration portal, and all token access is logged with timestamp and requesting service identity. Tokens are scoped to minimum required API permissions per integration.

04

TLS encryption in transit for all data flows

All data flows between Botpylon and external systems (WMS API, fleet controllers, dispatch API) use TLS 1.2 minimum. Internal service communication within the Botpylon platform uses mutual TLS. No unencrypted telemetry ingestion endpoints are exposed.

SOC 2 Type II in progress

We're honest about where we are in the compliance journey. The SOC 2 roadmap is public so you can make an informed decision.

SOC 2 Type II: designing to controls, formal audit planned for 2026

Botpylon is designing its infrastructure, access controls, and operational procedures to SOC 2 Type II standards. We are not yet SOC 2 certified. Formal audit engagement is planned for 2026. We do not claim certification we have not earned. If your procurement process requires current SOC 2 certification, contact us to discuss timeline and contractual alternatives.

Role-based access and audit logs

Role-based access control

Botpylon accounts are structured by role: Admin (full configuration access), Operator (dispatch console view and manual override), Read-Only (monitoring and reporting only). Roles are assignable per user and auditable from the admin console.

Single-tenant deployment option

Enterprise customers can request single-tenant deployment (dedicated infrastructure, no shared compute or storage with other customers). Single-tenant deployments are available as on-premises or dedicated cloud environment options under the Enterprise plan.

API key rotation and scoping

Integration API keys are rotatable on demand from the configuration portal. Each key is scoped to specific integration types (WMS read, fleet dispatch write, monitoring read-only). Old keys are immediately invalidated on rotation. Key access events are logged with timestamp and IP.

Audit logs with export

All configuration changes, dispatch overrides, and API key events are logged with full audit trail: timestamp, user identity, action type, and before/after state. Audit logs are retained for 90 days and exportable in structured JSON format for your security operations team.

Security disclosures and questions

For security vulnerability disclosures, architecture questions, or procurement security reviews, contact us directly. We respond to security disclosures within 24 hours on business days.

[email protected]