Security Model¶

CloudSlash runs entirely on your machine. It never phones home. Here is every trust boundary and what crosses it.

Plugin Security¶

Plugins are external binaries launched as subprocesses via gRPC. CloudSlash applies four layers of verification before executing any plugin:

Path Pinning¶

Plugin binaries must reside inside ~/.cloudslash/plugins/. Any path containing .. or resolving outside that directory is rejected immediately. Path traversal is impossible.

Manifest Verification¶

Every plugin ships with a plugin.yaml manifest containing:

name: aws
version: 1.0.0
checksum: sha256:a1b2c3d4e5f6...
permissions:
  - ec2:DescribeInstances
  - ec2:DescribeVolumes

CloudSlash reads and validates this manifest before touching the binary.

Binary Checksum¶

Double Hash

The binary's SHA-256 hash is computed at runtime and compared against the manifest checksum. If they don't match, the plugin is rejected.

The go-plugin framework's SecureConfig performs a second independent hash verification immediately before launching the subprocess. This catches any modification between the manifest check and exec time.

SafeProviderWrapper¶

The raw gRPC plugin client is wrapped in a SafeProviderWrapper with sync.RWMutex. This intercepts panics and disconnects from plugin subprocesses, preventing a misbehaving plugin from crashing the engine.

Hot-Load Safety¶

HotLoadPlugin() performs zero-downtime live plugin reload. It acquires a 50ms exclusive graph lock during the synaptic re-wiring phase. This ensures no in-flight graph operations see a partially-loaded plugin state.

API Security¶

The daemon's HTTP API runs on loopback (127.0.0.1:8080) and applies these controls:

CORS¶

Localhost-Only Origin Validation

The CORS policy only allows requests from: - http://localhost:* - http://127.0.0.1:* - http://[::1]:*

Wildcard origins (*) are never permitted. Requests from other origins receive a 403 Forbidden.

Security Headers¶

Every response includes:

Request Guards¶

• Body size limits: requestGuard middleware rejects oversized POST/PUT bodies before they reach handler logic.
• Rate limiting: writeLimiter enforces 1 request/second with a burst of 10 on state-mutating endpoints, preventing brute-force config mutations.
• Typed config updates: PUT /api/v1/config only accepts a validated UpdateConfigPayload struct, preventing arbitrary Viper key injection.

Secret Masking¶

The GET /api/v1/config endpoint masks sensitive values in responses. API keys, webhook URLs, and credentials are replaced with *** before being returned.

Socket Security¶

The TUI connects to the daemon via a Unix domain socket. The socket is created with strict permissions:

• Socket directory: Created with 0700: only the owning user can access it.
• Socket file: Created with 0600: read/write for owner only.
• Stale socket detection: TOCTOU-safe. It checks if the socket is actually accepting connections before removing it, preventing race conditions where a live socket is deleted.

AI Agent Security¶

Agentic Tool Confirmation¶

Every MCP tool in the agentic category (generate_plugin, build_plugin, save_policy, write_file) presents a mandatory confirmation prompt before execution. DEVI cannot take any file-writing or code-compiling action autonomously.

Sandboxed File Writes¶

The write_file MCP tool only accepts paths within ~/.cloudslash/. Any path attempting to escape this directory is rejected at validation time.

Deterministic Classifier¶

The two-tier routing classifier is entirely deterministic. It uses word-pair matching and substring checks to decide whether a query goes to the router or deep model. No LLM call is made for routing. This means: - Zero latency overhead for routing decisions - Zero cost per classification - No prompt injection attack surface on the routing layer

Sensitive Data Redaction¶

The engine's panic recovery middleware strips sensitive values (API keys, credentials, account IDs) from OTel span attributes and log output before they are written to any telemetry backend.

Credential Handling¶

CloudSlash never stores cloud credentials. It reads them at scan time using each SDK's standard credential chain:

• AWS: ~/.aws/credentials, AWS_* env vars, IMDSv2, ECS task role
• GCP: GOOGLE_APPLICATION_CREDENTIALS, gcloud auth application-default
• Azure: AZURE_* env vars, az login tokens, Managed Identity
• Kubernetes: ~/.kube/config, in-cluster service account

Credentials are held in memory for the duration of the scan and not persisted to disk or transmitted to any external service.