Back to App

Security & Trust

SETI AI runs critical power infrastructure, so security isn't a feature we bolt on — it's a design principle we build around. This page explains, in plain terms, how we protect your data, your credentials and your systems. It's written for the people deciding whether to trust SETI AI with their operation: buyers, security reviewers and new administrators.

The short version: access is controlled and enforced on the server, credentials are encrypted, every tenant's data is isolated, outbound connections are hardened, and the platform was independently security-audited and remediated in 2026.


Independently audited and hardened

In 2026, SETI AI underwent a full, independent security audit covering the web application, its APIs and its integrations. Every finding — across all severity levels — was remediated, deployed and re-tested before this release. Security fixes ship with an automated test suite that runs on every build, so the protections described below don't just exist on paper; they're verified continuously and re-checked every time the platform is updated.

We treat security as an ongoing commitment, not a one-time checkbox. The audit-and-harden cycle is part of how we ship.


Role-based access control (RBAC)

Every user is assigned one of three roles, and those roles are enforced on the server — not merely hidden in the interface:

Role Can do
Admin Full control: manage users, change agent configuration, view audit logs, build and operate workflows.
User Build, deploy and operate workflows and dashboards.
Viewer Read-only. Can see dashboards and data but cannot change anything.

Because enforcement happens at the API layer, a read-only viewer genuinely cannot make changes — the server rejects any attempt to modify data, regardless of what the browser shows. This is the right way to do access control: the user interface is a convenience, but the server is the gatekeeper.

Administrators manage users from a dedicated Admin panel, and every account action is recorded.


Encrypted password storage

Passwords are never stored in a readable form. SETI AI uses bcrypt, the industry-standard adaptive password-hashing algorithm, with a unique random salt per user. That means:

  • No one — not administrators, not engineers, not an attacker who somehow reached the database — can read or recover a user's password.
  • Password strength is enforced at creation: a minimum length plus a mix of upper-case, lower-case and numeric characters.
  • Password changes are validated and re-hashed the same way.

Session security

When you log in, SETI AI issues a strong, randomly generated session token stored in a secure, server-side session:

  • Strong tokens. Sessions use cryptographically random tokens, not guessable identifiers.
  • Sensible expiry. Sessions expire automatically after a bounded window (7 days), limiting the value of any stolen session and prompting periodic re-authentication.
  • Automatic cleanup. Expired sessions are purged on a continuous schedule, so stale credentials don't linger.
  • Brute-force protection. Repeated failed logins are rate-limited and locked out for a cooldown period. This is scoped per account, so one user's failed attempts can never lock everyone else out — protecting both individual accounts and overall availability.
  • Optional IP binding. For high-security deployments, sessions can be bound to the originating network address, so a copied session cookie won't work from anywhere else.

Protection against common web attacks

SETI AI is hardened against the attack classes that matter most for a connected operations platform:

  • Injection-resistant data access. All database access uses parameterized queries, so user input is always treated as data, never as executable commands. This neutralizes SQL-injection-style attacks by design.
  • Server-Side Request Forgery (SSRF) protection. SETI AI talks to a lot of external systems — inverter APIs, forecast services, webhooks. A shared, fail-closed safeguard validates every outbound connection and refuses to reach internal, private, loopback or cloud-metadata addresses. In practice, this means the platform's outbound features can't be tricked into reaching systems they were never meant to touch. The guard covers energy drivers, network tools, workflow HTTP requests, and notification webhooks and mail.
  • Cross-site and framing protections. User-supplied content that's displayed back in the interface is properly escaped, and the application sets protective browser security headers to defend against cross-site scripting and clickjacking.
  • Path-traversal containment. File and document operations are containment-checked so they stay strictly within their intended boundaries — no reaching outside the permitted area.
  • Validated tool inputs. Built-in operational tools validate and constrain their inputs rather than passing them through unchecked.

Per-tenant data isolation

In a multi-tenant deployment, one customer's data must never bleed into another's. SETI AI scopes data to its owner throughout the system:

  • Workflows and runs are tied to the account that created them. Non-administrators see only their own.
  • Chat history and live workflow event streams are scoped to their owner.
  • Agent actions are bound to the session of the user who initiated them.

The result is clean separation: each tenant sees their own world, and nothing else.


No secrets in code; hardened connections

  • No secrets committed to source. Credentials, API keys and connection strings live in protected configuration — never baked into the application code. The initial administrator password, for example, is supplied through secure configuration rather than hard-coded.
  • Encrypted, verified outbound connections. Connections to external services are encrypted and certificate-verified by default. Any exception for an internal service with a self-signed certificate must be explicitly allow-listed for that specific host — there is no blanket "trust everything" switch.
  • Least-exposure networking. Internal services (message broker, databases, graph store) are bound to private interfaces and are not directly reachable from outside, and high-risk capabilities are restricted to administrators only.
  • Audit trail. Authentication events and sensitive actions are logged, giving administrators a record of who did what and when.

Our security posture, summarized

Area What you get
Access control Three roles, enforced server-side; viewers are truly read-only
Credentials bcrypt-hashed passwords, enforced strength, never recoverable
Sessions Strong tokens, bounded expiry, auto-cleanup, per-account lockout
Injection Parameterized database access throughout
SSRF Shared, fail-closed outbound guard on every external call
Web hardening Output escaping, protective headers, path-traversal containment
Isolation Per-tenant scoping of workflows, history and agent actions
Secrets Kept in protected config, never in source
Connections Encrypted and verified by default; explicit, per-host exceptions only
Assurance Independently audited and fully remediated in 2026; tested every build

Security is a journey, and we're committed to staying ahead of it. If your security team would like to review specifics for a procurement or compliance process, your SETI AI contact can arrange a deeper technical briefing.


See also: Getting Started for login and roles, and Home for the full platform overview.