Security at Vertex Systems

Outbound-only agent: nothing can reach it

The agent is a client, not a server. It never accepts an inbound network connection. It polls for work over outbound HTTPS and receives instructions only as replies to connections it opened, so it runs behind NAT and corporate firewalls with only outbound 443 allowed. There is no listening port to expose or attack.

• Read-only telemetry. Performance counters, disk and SMART health, services, drivers, scheduled tasks, policy, and event logs. No screen capture, no keylogging, no reading user files or browser credentials.
• Pinned-certificate control plane. The agent validates the server against a CA pinned at install, so a man-in-the-middle cannot impersonate the control plane.
• Enrollment identity. A new agent presents a one-time, hashed enrollment token bound to its organization, then authenticates with a per-device secret verified in constant time.

Strict multi-tenant isolation

Every record is organization-scoped at the data layer, not just hidden in the UI. Reads and writes for a non-administrator are constrained to the caller's organization, and lookups resolve through helpers that require that organization, so a request referencing another tenant's identifier resolves to nothing. Remediation paths re-scope the target to the requesting organization before any command is queued.

Gated, audited remediation

Vertex can fix machines, and the safety of that rests on layers enforced server-side:

• Allow-listed actions. The agent understands only a fixed set of action types; anything else is rejected.
• Risk tiering and role-based approval. Medium and high-risk changes require an approver role; a lower-privileged request becomes a durable approval request instead of an action. The gate is enforced on every dispatch path, including fleet-wide.
• Separation of duties. A user cannot approve their own request.
• Full audit trail. Every dispatch and every approval decision is recorded with the actor, their IP, and the target.

Apollo AI governance

Apollo is a natural-language interface, never the source of truth and never with unmediated access to your machines. It can only call a fixed, allow-listed set of deterministic tools, and anything that changes a machine flows through the same gated, role-based approval as a human request. Apollo is powered by Apollo AI, our proprietary engine, which does not train on your data and does not retain prompts or telemetry after a request is served.

Data protection and encryption

Traffic is TLS 1.2+ in transit and the database is encrypted at rest. Passwords use PBKDF2-SHA256 with per-user salts; session, API, enrollment, and agent secrets are stored only as SHA-256 hashes. The platform stores inventory, workflows, approvals, and the audit log, not plaintext secrets, OS-level PII, or payment-card data. Deleting an organization cascades through every table for full removal on request.

Secure development and testing

Every database query is parameterized, so there is no SQL injection by construction. Responses carry a strict Content-Security-Policy, HSTS, nosniff, and frame-deny headers. Outbound webhooks cannot reach internal or cloud-metadata addresses, and file-write actions cannot target system paths. The authentication, tenant-isolation, and remediation paths undergo adversarial penetration testing, with findings remediated and re-verified before release. Because the platform is a single serverless worker, security fixes deploy globally within minutes.

Compliance posture

Vertex runs on infrastructure that maintains SOC 2 Type II and ISO 27001 certifications, with WAF and DDoS protection at the edge, and inherits those infrastructure-layer controls. The platform is built SOC 2-aligned and HIPAA-ready: this describes the engineering controls in place and inherited certifications, not a completed Vertex-level third-party audit. Contact the team for current attestation status, a Business Associate Agreement, or an auditor walk-through.