Documentación oficial

Seguridad en Linux

# Security Design

## Threat boundaries

The renderer is treated as untrusted. It receives only a minimal typed bridge through `contextBridge`; it has no Node.js integration and no direct filesystem access. The main process validates IPC senders, agent IDs, request shapes and script hashes.

## API key lifecycle

1. The user pastes the key into a password field.
2. The renderer trims leading/trailing whitespace and checks the `sk-iaolympus-` prefix locally.
3. The main process validates the key against `GET https://iaolympus.com/v1/models` with `Authorization: Bearer ...`.
4. The response must be successful and contain both `iaolympus-low` and `iaolympus-pro`.
5. Only then is the key encrypted with Electron `safeStorage` and written to the app user-data folder.
6. The key is injected into agent processes through environment variables or standard input.
7. No secret is placed in generated agent files except Reasonix’s documented private `.env`, which is necessary because that agent does not inherit the environment variable.

On Linux, the secure-storage directory uses mode `0700` and private files use mode `0600`. Shared code applies a user-only Windows ACL when the same build runs on Windows; if that restriction fails, the operation is cancelled.

The key is rejected if it contains whitespace, exceeds the allowed length or lacks the required prefix. The UI never renders the stored key.

## Linux fallback

If no OS keyring is available, or Electron reports a basic/unknown backend, the app uses AES-256-GCM with a key derived from machine/user context and stores the file with mode `0600`. The UI warns that this is a fallback, not an OS keyring.

The fallback was the backend exercised in the Linux 1.0.2 runtime certification because the container had no DBus/keyring. Clearing the key from the UI removes the secure file. If Reasonix is configured, the managed key is also removed from its private `.env`; the file is deleted when it has no other content.

## Process execution

- `spawn(command, args, { shell: false })`.
- No concatenated shell command.
- Arguments containing an API-key pattern are rejected.
- Timeouts and bounded output.
- Raw stdout/stderr are not shown to the user and are not written as full logs.
- Installer success is verified independently after the process completes.
- Hermes does not use remote `curl|bash`; the script is downloaded, hashed, shown, consented to and passed through stdin.
- Uninstall removes only packages from the app-managed prefix. If an agent was installed globally outside the app, the program is kept and only the IA Olympus configuration is removed.
- Agent uninstall removes its `.desktop` shortcut and stale state entry.
- Connection results expose only the two public IA Olympus model IDs, even if the API response contains additional entries.

## Logging

Logs are JSON lines in the app user-data folder. Key-like fields, tokens, authorization headers, cookies and secrets are redacted. URLs outside IA Olympus and known provider names are replaced. Logs contain operational metadata such as status codes, durations, model counts, agent IDs and version numbers; they do not contain prompts, completions or conversation history.

## UI restrictions

- External links are allowlisted to official HTTPS hosts.
- New windows, webviews and navigation are denied.
- All permission requests are denied; clipboard access uses a narrow main-process IPC call.
- The window uses a restrictive CSP in production.

## Out of scope

- Protecting a compromised operating system or a user who intentionally extracts the key from a running process.
- Third-party agents’ own security posture.
- Prompts or code generated inside an agent after launch.
- Antivirus/firewall bypass. The app never disables system protections.

## Reporting

Do not open a public issue with a real API key, header, cookie or provider response. Rotate the key first and report the issue privately to the IA Olympus maintainers with sanitized reproduction steps.

Volver a instaladores · Tutorial en español