Infomatics operates an agentic intelligence layer above your existing supply chain systems, which means we hold copies of shipment data, credentials to your ERP, TMS, email and ELD systems, and the ability to act on your behalf inside them. This page describes how that platform is built and operated, and is written for security reviewers evaluating Infomatics as a vendor. Read it alongside the Privacy Policy and the Terms of Service.
Infomatics is not a system of record. It sits above the ones you already run — ERP, TMS, WMS, carrier portals, ELDs, IoT trackers — ingests and reconciles data from them, and acts through their APIs. Two consequences follow for security. First, we store a working copy of shipment, document and telemetry data outside your source systems. Second, we hold delegated access to those systems, so a compromise of Infomatics is a potential compromise of the systems we connect to. The controls described on this page are ordered around those two facts.
Infomatics is responsible for the platform: infrastructure, tenant isolation, encryption, credential storage, the execution environment for AI agents, platform monitoring, and the security of the Kopilot mobile app. The customer is responsible for what happens inside their tenant: user and role lifecycle, identity provider configuration, which integrations are connected and with what scopes, which mailboxes are exposed to order ingestion, and the approval policy that governs which agent actions run without a human.
Access we hold to your source systems is bounded by the scopes you grant, and revocation at the source system is always available to you as an independent control.
The platform runs on managed cloud infrastructure operated by a major provider; Infomatics does not operate its own data centers.
Application services, data stores and job runners are deployed into private network segments, and data stores are designed not to be reachable from the public internet. Ingress is limited to a small number of load-balanced entry points, and outbound traffic to integration partners is made over TLS from known egress paths. Our practice is to hold runtime secrets in a managed secret store rather than in configuration files or environment files committed to source control.
If your deployment has data residency requirements, raise them during the security review described at the end of this page and we will tell you what options are available.
The platform is multi-tenant. Every record — shipment, order, document, telemetry ping, carrier record, agent action — carries a tenant identifier. Authorization is designed to be enforced in a shared data access layer rather than at individual query call sites, so that a missed check in one code path cannot expose another tenant's data. The tenant context is derived from the authenticated session, API key or device token rather than from a value supplied by the client, and background jobs, ingestion workers and agent runs are designed to inherit the tenant context of the record they were started for.
Object storage for documents and photo evidence — BOL, POD, rate confirmations, insurance certificates, custody-point images — is namespaced per tenant. Access is intended to be issued through short-lived, scoped URLs rather than shared bucket credentials.
All external traffic is encrypted in transit with TLS: the operator console, the public API, webhooks, EDI and TMS connectors, Kopilot mobile traffic, and telemetry ingestion. Legacy protocol versions and weak cipher suites are disabled. Service-to-service traffic inside the platform is encrypted rather than relying on network position alone.
Data at rest is encrypted at the storage layer, including primary databases, backups, object storage for documents and images, and log stores. Encryption keys are managed through the cloud provider's key management service, with access to key material restricted to the services that need it.
Integration credentials are intended to receive protection beyond storage-layer encryption; see the section on integration credentials below.
Access to the operator console is authenticated through your identity provider where you have one. The federation and directory provisioning options we support for a given deployment are confirmed during the security review. Where SSO is not in use, accounts authenticate with password plus MFA, and administrators can require MFA for all users in the tenant.
Authorization is role-based. Roles separate what a user can see from what a user can do: viewing shipment and evidence records, editing plans and routes, approving agent actions, connecting or revoking integrations, managing users, and exporting data are intended to be distinct permissions. Access is designed to be further scoped so that a user sees only the business units, sites or customer accounts they work on.
Machine access uses scoped, revocable API keys or OAuth clients rather than shared user credentials, and every key is attributable to a named owner. Kopilot device sessions are separate from console sessions and are intended to be revocable independently, so that removing a driver's device access does not require touching office user accounts.
Infomatics staff do not hold standing access to customer production data. Engineering and support work is done against telemetry, logs and metadata by default. Where a specific customer record must be examined — a failed integration, a disputed agent action, a support escalation — our practice is that access is requested, tied to a ticket, approved by someone other than the requester, granted for a limited window, and set to expire automatically. We require MFA for elevation, and elevation is available only to a small named group.
Break-glass access exists for incidents where the normal approval path would cause unacceptable delay. It is designed as a distinct, named path: time-bound, requiring a second approver where one is reachable, and emitting an audit record containing the operator, the customer tenant, the records touched, the justification and the duration.
Personnel are subject to background screening where permitted by law, sign confidentiality agreements, and complete security training at onboarding and on a recurring basis. Company endpoints require disk encryption, screen lock and managed updates. Access is revoked on the day employment or a contract ends, and contractors are held to the same access and training requirements as employees.
Integration credentials are the most concentrated risk in the platform. To do its job, Infomatics holds delegated access to customer systems: TMS platforms such as Turvo, McLeod, Aljex, Tai, Revenova and 3PL Systems; mailboxes and messaging in Gmail, Outlook, Front, Slack, Microsoft Teams and RingCentral; carrier verification services such as Highway, Truckstop RMIS and MyCarrierPackets; rating and market data sources including DAT, Truckstop, Transfix, Sonar, AVRL, Tabi, Bitfreighter and Triumph/Greenscreens; EDI gateways including Cleo, Orderful and Atadex; and ELD and telemetry providers. A single credential store therefore stands in front of many customers' operational systems, and the compromise scenario we design against is theft of that store rather than theft of a single record.
Credentials and OAuth tokens are held in a dedicated secret store. The design intent is envelope encryption with key material held separately from the application database, so that a database compromise alone does not yield usable credentials, and decryption in memory at the point of use by the service performing the call, with no path that writes a secret to application logs, returns it through the API, or renders it back to a user or to Infomatics support staff — including the staff member who entered it. Where a partner supports OAuth we use it in preference to static API keys or shared passwords, and we request the narrowest scopes the integration's function requires.
Token refresh and rotation are automated where the partner supports it. Access to the credential store from outside the normal execution path is alerted on, and unusual patterns — a spike in calls to a connected system, use from an unexpected service, repeated authentication failures at a partner — raise alerts to the on-call rotation. Revocation at the source system is always available to you as an independent control. The credential store is designed around the following controls.
Kopilot is the driver and security-escort app. It handles trip acceptance, navigation, photo, BOL and POD upload, digital signature capture, and escort position and status reporting. The data it produces is personal data about individuals who are frequently not employees of the customer — drivers working for a contracted carrier — so it is handled as personal data by default: driver name, phone number, duty status, device location, captured images and signature. Kopilot accounts are issued to users aged 18 or over, consistent with the minimum age stated in the Terms of Service and the Privacy Policy.
The app requests operating-system location and camera permissions explicitly, and drivers can see when a trip is active. Photo evidence retains capture time and position because that is what makes it evidence at a custody point; those images are stored under the tenant's namespace and are access-controlled like any other shipment document.
Devices authenticate with per-device tokens that are intended to be revocable individually, which is the response to a lost or stolen phone. On-device storage is limited to what is needed for the current assignment and offline queueing; queued uploads are encrypted at rest on the device and transmitted over TLS when connectivity returns. Driver location history and captured media are retained for as long as the customer's account is active and for a limited period afterwards, as set out in the customer agreement.
Agents monitor shipments, create orders from inbound email, plan and route loads, coordinate with carriers, detect exceptions, and escalate to a human by SMS when judgment is required. Every agent run executes inside a single tenant's context and can only use a defined set of tools — specific API operations against specific connected systems — that the customer has enabled. An agent cannot exceed the OAuth scope granted to the connection it is using, so the credential itself is a hard ceiling on what any agent can do, independent of anything the model produces. Read and write capabilities are separate permissions, and an agent configured to observe cannot be talked into acting.
Which actions run automatically and which require a person is configured per customer. Actions that are externally visible or hard to reverse — tendering a load, sending an email or EDI transaction to a carrier or customer, altering a rate confirmation, changing a delivery appointment — are the ones customers most often place behind approval. When an agent reaches the edge of its authority or its confidence, it escalates by SMS to a named human with the shipment context and the action it proposes, and waits.
Guardrails sit around the model rather than depending on it. Tool calls are validated against the shipment record before execution, so an action whose parameters do not match a real load, carrier or stop is rejected. Idempotency keys are used so that a retry does not produce a second tender or a duplicate email. Rate and volume limits cap how much any agent can do in a window, and an operator can pause a single agent, an agent type, or all agents in a tenant. Content ingested from the outside world — inbound email bodies, OCR'd document text, carrier replies — is treated as untrusted data, not as instructions: agents act on extracted structured fields under policy, and text arriving from an external party cannot expand an agent's permissions or add a tool to its set. Every agent decision and every resulting external call is recorded.
The tenant boundary applies to model training as well as to agent execution. Customer Data is not used to train or fine-tune models that serve any other customer, and derived intelligence, including network and lane intelligence built from shipment history, stays within the tenant that produced it.
Customer-visible audit logs cover user sign-in and session events, permission and role changes, integration connect and revoke events, data exports, changes to shipment plans and routing templates, and every agent action with its inputs, outcome and approver. Records are designed to be append-only and attributable to a user, a device, an API key or an agent run. Audit log retention, and any export into your own logging or SIEM tooling, are confirmed during the security review.
On the platform side, application, infrastructure and access logs are centralized and monitored. Alerts fire on authentication anomalies, privilege escalation, access to the credential store outside expected paths, unusual export volumes, sudden changes in agent action rates, and integration error spikes that could indicate a partner-side compromise or a misconfigured connection. An on-call rotation receives these alerts.
Changes are made through version control with peer review and protected branches, and builds are promoted through separate environments. Production customer data is not copied into development or test environments; engineering works against synthetic or masked fixtures. Schema migrations and changes to agent action policy are reviewed as security-relevant changes, not routine ones.
We accept vulnerability reports from security researchers and customers. Send reports to contact@infomatics.ai with SECURITY in the subject line. Please include enough detail to reproduce the issue. Testing against the Platform requires prior written authorization from Infomatics (see Terms of Service, Acceptable Use). Do not access or modify data that is not yours, do not degrade the service, and do not test against a customer tenant.
Because Infomatics sits above your systems of record, degradation is designed to be non-destructive. If a customer's TMS, a carrier portal or a partner API becomes unavailable, ingestion queues and retries with backoff rather than dropping events, and reconciliation resumes when the source recovers. Agents fail closed on write actions when the data they depend on is stale or a source is unreachable: they escalate to a human instead of acting on an out-of-date picture of the shipment. Your source systems remain the authoritative record, so an Infomatics outage does not stop freight from moving.
Infomatics uses third parties to deliver the service. The categories are cloud hosting and managed data services, model inference for the AI agents, OCR for document text extraction, SMS delivery for human escalation, transactional email, error monitoring, and product analytics. Two of these deserve attention in a review: escalation means a telecommunications provider processes driver and dispatcher phone numbers and message content, and agent reasoning means a model provider may process shipment, document and email content. The current subprocessor list is available to customers on request.
The integration partners named on this site — TMS, verification, communications, rating and EDI platforms — are systems the customer already uses and directs us to connect to. They are not Infomatics subprocessors, and data flowing to them flows under the customer's own relationship with them. Subprocessors are vendors Infomatics chooses in order to operate the platform.
New subprocessors are reviewed for security posture and data handling before onboarding, and are bound by contractual terms that flow down the confidentiality and security obligations we owe customers.
Infomatics maintains a documented incident response plan with defined roles, severity levels and an on-call rotation. The lifecycle is triage, containment, eradication, recovery and post-incident review, with evidence preserved throughout. Severity is driven by customer impact, with unauthorized access to customer data or to the integration credential store treated as the highest severity regardless of scope.
Credential compromise has its own playbook because of the concentrated risk described above. It runs revocation and forced reconnection for affected connections, and includes telling each affected customer precisely which connections to rotate at the source system.
We notify affected customers without undue delay after confirming an incident, through their designated contacts. Notifications state what happened, what data and which connections were involved, what we have done, and what we are asking the customer to do. To report a suspected incident affecting your tenant, contact contact@infomatics.ai and mark it urgent.
A current list of attestations and completed security questionnaires is available to customers and prospects on request.
Reviewers of a platform in this category commonly ask about SOC 2; ISO/IEC 27001; the company's role as controller or processor under GDPR and UK GDPR, the availability of a Data Processing Addendum (DPA), and the transfer mechanism used for data leaving its region of origin; CCPA and CPRA obligations and the consumer request process; and, for government and defense logistics prospects, FedRAMP, CMMC, ITAR or EAR relevance. We answer each of these with its current status on request.
One domain-specific item belongs here as well: ELD-derived driver location and duty status is regulated personal data in most jurisdictions and is subject to the carrier's own obligations. How personal data is collected, used and retained is described in the Privacy Policy, and the commercial and acceptable-use terms are in the Terms of Service. The legal entity and governing jurisdiction that apply to these commitments, and the data protection commitments themselves, are set out in the customer agreement and its Data Processing Addendum (DPA).
Security reviews are a normal part of our sales process. Write to contact@infomatics.ai or sales@infomatics.ai with SECURITY REVIEW in the subject line and tell us the scope of the deployment you are evaluating, which systems you intend to connect, and your review timeline. Most documentation is available under NDA.
Reviewers commonly ask for the documents below. Tell us which ones your process requires and we will confirm what we can share and on what terms.
Write to contact@infomatics.ai and we will route your question to the right team.