Security

Security properties and controls for AIMO: where secrets live, how identity is proved, what crosses your network boundary, and what the platform does not do. Setup steps are in Getting started, Architecture, Registration, Agent CLI, and Operations.

Network boundary: no cloud path to your database

AIMO’s cloud coordinates the product and talks to the agent over an outbound connection from your environment. There is no supported path from AIMO to your databases—no firewall rules, reverse tunnel, or SQL port opened for the cloud.

• Outbound-only agent — The agent initiates TLS (or equivalent) toward AIMO. You do not publish databases or the agent to the public internet for normal operation.
• Jobs, not shells — Work dispatched to the agent is limited to a fixed set of job types (analysis, monitor calculation, validation, connection tests, and similar). The agent is not general-purpose remote execution for arbitrary cloud code. See Operations.

Credential use and query execution stay on infrastructure you control, beside your data.

Data leaving the perimeter: aggregates and metadata, not raw rows

Raw field values are not bulk-exported to AIMO for routine monitoring. What crosses the boundary is summarized: schema and profiling metadata, aggregates over time windows (counts, grouped monitor results), and similar bounded payloads. Charts and modeling use those aggregates, not row-level dumps. SQLQueryMonitor still returns a single aggregate per group, inside the same fixed query shell as other monitors. See Monitors.

Outlier detection runs on monitor time series and derived artifacts in AIMO after the agent has produced aggregates—not on a full copy of your raw tables. See Outlier detection.

Human users: sign-in to the web UI

Access uses passkeys (WebAuthn) only—password login is not available. After sign-in, AIMO uses a server-side session; API calls from the UI are authorized from that session, with account roles (viewer vs admin, etc.) where the product defines them.

Sign-in is provided by the AIMO deployment as delivered. Bring-your-own IdP (for example OpenID Connect) is not available today; it is planned for a future release.

Recovery (lost passkey) and new devices are your responsibility: register additional passkeys while you still have access. Use platform passkey sync where your devices support it.

Agent identity: registering the keypair

Each agent uses an asymmetric keypair. Registration binds that keypair to your account: AIMO stores the public key; the private key stays in your environment (unless you only supply the public key yourself). A short-lived, single-use registration token lets the CLI upload the public key once; see Registration. That flow is pairing only—not day-to-day authentication.

Agent JWTs: authenticating with the stored keypair

The running agent does not use a static API password. It keeps the private key (and related env, e.g. agent UUID) on disk or in the container. Whenever it calls AIMO (REST, job WebSocket), it obtains a short-lived JWT by proving possession of the private key; AIMO verifies against the stored public key and issues a token. Tokens refresh as they expire.

Rate limiting — The token endpoint applies per-IP limits (default on the order of 10 requests per minute); overloaded clients may see HTTP 429.

Agent WebSocket channel

The job channel requires a valid agent JWT before it carries work. Unauthenticated or invalid connections are closed.

Database credentials: encryption, storage, decryption

Connection credentials are never typed into the browser for storage. They are created through the agent CLI, encrypted before upload, and stored as ciphertext in AIMO’s database.

• At rest — AIMO stores only the ciphertext (plus metadata such as name and type). Decryption for database access happens on the agent when executing jobs, using the passphrase and keys available there.
• API responses — List/get APIs may return ciphertext to authorized clients. Without agent-side key material, that data is not usable as plaintext passwords.

The CLI’s show command prints non-secret fields for debugging; sensitive fields are masked. Agent REST operations that mutate connections require a valid agent JWT.

Job payloads: typed, bounded work only

Work must deserialize into known job models. Unknown or malformed payloads are rejected. Each job carries structured fields (credential references, table IDs, time ranges, monitor definitions)—not executable scripts. That aligns with the strict monitor type system: SQL on your database is generated from validated monitor definitions, not unconstrained strings in the envelope. See Operations and Monitors.

Operational hygiene

• aimo_agent.sh and private keys — Treat as secrets: restrict filesystem permissions, avoid committing to version control, rotate via key update / re-registration when policy requires.
• Registration tokens — Treat like one-time passwords: short-lived, shown only at creation as documented in the UI.
• TLS — Use HTTPS/WSS between agents and AIMO in production on untrusted networks.

For diagrams, see Architecture.