SECURITY

Operational AI your team can control

Hyperscale is built for fleet operations where access, approvals, and visibility matter. Vic works across connected systems with verified identity, role-based permissions, human approval gates, and audit-friendly session history.

AICPA SOC 2 for Service Organizations SOC 2 Type I report completedIndependently audited against the AICPA Trust Services Criteria
Access controls

Access controls that match how your fleet operates

Every user signs in through your own identity provider, lands in a role, and only ever reaches the systems that role is meant to touch.

Verified identity
Microsoft or Google OAuth

Users authenticate through Microsoft / Azure AD or Google, the identity provider your organization already runs.

MFA and conditional access carry over

Whatever MFA and conditional-access policies you enforce are inherited automatically through your provider.

No separate Hyperscale passwords

Nothing extra for users to manage or rotate, and no password store to phish or leak.

SCIM user provisioning

Synchronize users from Microsoft, Google, Okta, or any other SCIM-compatible identity provider. Access stays up to date automatically as teams join, move, or leave.

Role-based permissions, scoped to real systems

Start with admin, member, and unassigned roles, then build custom roles. Permissions are additive, and new users default to effectively zero access.  Pick a role to see what it can do and which accounts it reaches.

Select a role

Roles and their bound credentials are configured during onboarding to match how your fleet is organized.

Dispatcher can run 3 actions across 3 connected accounts.

Permissions granted

Send driver messagescommunications:send_driver_message
View communication logscommunications:read
Update loads in the TMSloads:write
View session historysession_history:read
Create automationstriggers:write
Manage org settingssettings:manage

Connected accounts

McLeodDispatch ops No access Bound
McLeodBilling No access Bound
SamsaraEast fleet No access Bound
SamsaraWest fleet No access Bound
FleetioMaintenance No access Bound
TwilioDriver SMS No access Bound
Human in the loop

Controlled automation, not runaway automation

Vic can prepare operational work end to end, but consequential actions need permission and a human approval before anything executes.

Vic prepares the action

It gathers context across your systems and drafts the update or message.

Permissions are checked

The action is validated against the user's role and permissions before it can proceed.

Operator reviews the summary

A plain-English summary shows exactly what will change before anyone commits.

Action executes after approval

Nothing leaves Hyperscale or changes a system of record until a human approves it.

  • Write actions require approvalSending a message, updating a load, or attaching a document all pass through an approve-or-reject step.
  • Driver messages can require operator reviewOutbound driver messaging can be gated so a person signs off before it sends.
  • Email replies stage as draftsReplies can be configured to hold as drafts for human review before leaving the org.
  • Automation triggers require permissionWebhook and trigger-based automations need a dedicated permission that standard members do not have by default.
  • Reply-loop protectionCaps on consecutive automated replies prevent runaway bot-vs-bot loops.
Vic is ready to update Load #8821
Change summary
  • Add attached rate confirmation to McLeod
  • Update pickup notes with revised appointment time
  • Send driver message with new instructions
ApproveReject
Security architecture

Data protection and platform safeguards

Your data is encrypted, isolated, and run on hardened cloud infrastructure with least-privilege access throughout.

EncryptionAES-256
  • TLS 1.2+ enforced in transit
  • AES-256 at rest, AES-256-GCM for tokens
  • Session tokens hashed with SHA-256
InfrastructureAWS VPC
  • Isolated AWS VPC
  • Managed RDS PostgreSQL
  • Private / public subnet separation
SecretsAWS KMS
  • AWS Secrets Manager, never in code
  • SOPS backed by KMS with auto-rotation
  • CI/CD uses short-lived OIDC tokens
Abuse protectionRate-limited
  • Rate limiting, stricter on login
  • HTTP-only, SameSite cookies
  • Timing-safe token comparison
Storage controlsNo public access
  • All public bucket access blocked
  • Object versioning enabled
  • Rejects unencrypted connections
Logging hygieneAuto-redacted
  • Passwords and tokens redacted
  • API keys and secrets never in plain text
  • Structured, centralized logging
Tenant isolation
Every record scoped to one organization Membership validated on every request Anti-enumeration: unknown orgs return 404
AICPA SOC 2 for Service Organizations
Independently audited

SOC 2 Type I report completed

Hyperscale has completed a SOC 2 Type I examination against the AICPA Trust Services Criteria. An independent third-party auditor reviewed the design of our security controls and issued a SOC 2 Type I report.

AICPA Trust Services Criteria Independent third-party audit Report available under NDA
Auditability

Every action is reviewable

Hyperscale keeps audit logs, session history, and communication records so teams can understand what happened, who was involved, and what changed.

  • Immutable audit log
  • User, IP, and user agent
  • Session history
  • Communication logs
  • Permission-controlled access
  • Centralized CloudWatch logging
Audit trail · Load #8821
User verified via Microsoft OAuth09:41:02
Permission checked · communications:send_driver_message09:41:03
Vic drafted load update09:41:18
Operator approved change09:42:05
Driver message sent09:42:06
Session logged to audit trail09:42:06
Works with your stack

Your systems remain the source of truth

Hyperscale works across your TMS, telematics, maintenance, safety, and communication tools without replacing them. Vic reads, prepares, and executes approved work while your existing systems remain the record of truth.

Questions

Security and control questions

Does Hyperscale support SSO?
Yes. Users sign in through Microsoft / Azure AD or Google, and your existing MFA and conditional-access policies carry over automatically.
Can permissions be customized by role?
Yes. Alongside built-in admin, member, and unassigned roles, you can build custom roles with granular, additive permissions. New users default to effectively zero access.
Can integration credentials be scoped by team?
Yes. Integration credentials can be bound to specific roles, so different teams can use different McLeod, Samsara, or Fleetio accounts under least-privilege access.
Can Vic make changes without approval?
No. Any write action requires explicit operator approval before it executes, and triggers that drive automation require a permission most members do not have.
Are sessions and actions logged?
Yes. An immutable audit log captures the action, entity, before/after changes, IP, and user agent, with session and communication history available to permitted users.
Does Hyperscale replace our TMS?
No. Vic works across your existing TMS, telematics, maintenance, safety, and communication tools, which remain your record of truth.
How is data protected?
Data is encrypted in transit with TLS 1.2+ and at rest with AES-256, isolated per organization, and run on an isolated AWS VPC with managed secrets and least-privilege access.
What happens when a user is added or removed?
New users start in the unassigned role with effectively zero access until an admin grants a role. Because identity runs through your provider, removing a user there cuts off their access to Hyperscale.

Give AI access without losing control

See how Hyperscale connects to your systems, applies role-based controls, and gives your team full visibility before Vic takes action.

OAuth / SSO sign-in Role-based permissions Approval gates on writes