Security

Overview

Dryade is a self-hosted AI agent orchestration platform designed with a security-first architecture. Every design decision — from plugin loading to model routing to agent execution — follows the principle that security boundaries must be enforced at the system level, not delegated to user configuration or runtime toggles.

The platform is built on three foundational principles:

Fail-closed by default. If a security check cannot be completed — whether due to a missing allowlist, an invalid signature, or an unreachable verification endpoint — the operation is denied. There are no fallback paths that bypass security controls.
Defense in depth. Security is enforced at multiple independent layers: cryptographic signatures on plugin packages, signed allowlists controlling plugin loading, hash verification of on-disk code, sandboxed frontend rendering, and audit logging of every agent action. Compromising one layer does not grant access through the others.
Sovereign deployment model. Dryade is designed for environments where data must never leave the deployment perimeter. In air-gapped configurations, the platform makes zero outbound network connections — all model inference, plugin execution, and agent orchestration happens within the customer’s infrastructure.

This document covers the security architecture in detail, intended for engineering teams, security auditors, and enterprise procurement reviewers evaluating Dryade for deployment in regulated environments.

Plugin Security Model

The plugin system is the primary extensibility surface of the platform and, accordingly, the most aggressively hardened. Dryade uses a signed allowlist model — no plugin code executes unless it is explicitly permitted by a cryptographically signed document.

Signed Allowlist Architecture

The allowlist is a JSON document stored at ~/.dryade/allowed-plugins.json on the core instance. It contains:

The list of permitted plugin identifiers
SHA-256 hashes of each plugin’s source files
Tier enforcement parameters (max_users, custom_plugin_slots)
An Ed25519 signature from the Plugin Manager (PM)

Loading behavior is strictly determined by the allowlist:

If the allowlist file is missing, zero plugins load.
If the allowlist has an invalid or unverifiable signature, zero plugins load.
If a plugin is not listed in the allowlist, it is invisible — it never loads, never mounts API routes, and never appears in plugin listings.
There is no configuration toggle, environment variable, or escape hatch that bypasses this check (no DRYADE_DISABLE_PLUGINS, no community_mode, no plugins_enabled flag).

Ed25519 Signature Verification

The allowlist is signed using Ed25519 (RFC 8032), a deterministic elliptic-curve signature scheme. Core verifies the signature against the PM public key before reading any allowlist contents. The verification happens in core/allowlist.py and is the first gate in the plugin loading pipeline.

TOFU Key Pinning

The Plugin Manager’s Ed25519 public key is pinned using a Trust-On-First-Use (TOFU) model. The first time core receives a signed allowlist from PM, it records the public key. All subsequent allowlist updates must be signed by the same key. This prevents key substitution attacks where a compromised intermediary could inject a different signing key.

Plugin Code Hash Verification

Beyond verifying the allowlist signature, core performs a second integrity check at plugin load time. For each plugin in the allowlist, core computes a SHA-256 digest of the plugin’s Python source files on disk and compares it against the plugin_hashes entry in the signed allowlist. If the hashes do not match — indicating that on-disk plugin code has been modified after the allowlist was signed — the plugin is silently skipped. No tampered code ever executes, and no error is exposed to the end user.

This check is enforced in core/plugins.py during the validate_before_load() phase, before any plugin module is imported into the Python process.

Plugin Manager Pipeline

The Plugin Manager (PM) is a standalone Rust binary responsible for allowlist signing and delivery. PM never runs inside the core process — it pushes signed allowlists to core via a file write followed by an HTTP POST to core’s internal endpoint (port 9471). Core is a passive consumer and never calls PM via gRPC or any other RPC mechanism.

Production pipeline:

The marketplace forges an encrypted allowlist based on the customer’s subscription and installed plugins
PM receives the encrypted allowlist and stores it as ~/.dryade/allowlist.enc
PM decrypts the allowlist and verifies its integrity
PM re-signs the allowlist with its embedded Ed25519 keys
PM pushes the signed allowlist to core via file write + HTTP POST

Development pipeline:

For local development, dryade-pm push --plugins-dir <path> scans local plugin directories and generates a development allowlist (tier=dev, unlimited slots). This bypasses the marketplace encryption step but maintains the same signing and verification flow.

Post-Quantum Cryptography

Dryade implements dual-signature verification using both classical and post-quantum cryptographic schemes:

Ed25519 — The classical elliptic-curve signature scheme, providing 128-bit security against conventional computers.
ML-DSA-65 (FIPS 204) — A lattice-based digital signature algorithm standardized by NIST as part of the post-quantum cryptography migration. ML-DSA-65 provides NIST Security Level 3, designed to resist attacks from both classical and quantum computers.

Every plugin package carries both signatures. Verification requires both to pass — the system does not fall back to Ed25519-only verification if the ML-DSA-65 check fails. This dual-signature approach provides immediate protection against harvest-now-decrypt-later attacks while maintaining backward compatibility with existing Ed25519 tooling.

The post-quantum signatures apply to the .dryadepkg plugin package format, which implements a four-layer protection model:

Cython compilation — Plugin source is compiled to native extensions, raising the bar for reverse engineering
AES-256-GCM encryption — The compiled package is encrypted at rest
Ed25519 author signature — The plugin author signs the package with their key
Marketplace counter-signature — The Dryade marketplace applies a second signature, attesting that the package passed review and integrity checks

Authentication & Authorization

Identity Provider Integration

Dryade integrates with Zitadel as its identity and access management layer. Zitadel provides:

OIDC and SAML support for federating with existing enterprise identity providers (Azure AD, Okta, Google Workspace, Keycloak, and others)
Multi-factor authentication (MFA) — TOTP, WebAuthn/FIDO2, and SMS-based second factors
Session management with configurable token lifetimes and forced re-authentication policies

Role-Based Access Control

The platform enforces RBAC at multiple levels:

Platform roles govern access to administrative functions: user management, plugin approval, system configuration, and audit log access.
Per-plugin permissions control which users and roles can access specific installed plugins. A plugin installed at the organization level can be restricted to specific teams or roles.
Agent execution permissions determine which users can create, modify, and trigger agents, and which tools and model providers each agent is allowed to use.

API Key Management

API keys are scoped to individual users and inherit the user’s role-based permissions. Keys can be created, rotated, and revoked from Settings > Subscription. Each API request must include the key in the Authorization header as a Bearer token. Rate limits are enforced per key based on the subscription tier (see Getting Started for tier-specific limits).

API keys are stored as salted hashes — the platform does not retain plaintext keys after initial generation. Key rotation does not invalidate active sessions but does require updating any external integrations using the previous key.

Data Encryption

At Rest

PostgreSQL — All database storage uses encryption at rest. Sensitive fields (API keys, user credentials, plugin configuration secrets) use application-level encryption in addition to disk-level encryption.
pgvector — Vector embeddings stored for RAG and semantic search are encrypted with the same at-rest protections as all other database contents.
Plugin configuration — Per-plugin secrets and configuration values are encrypted before storage and decrypted only at the point of use within the plugin sandbox.

In Transit

TLS 1.3 is enforced on all external-facing connections. The platform does not negotiate TLS 1.2 or earlier.
mTLS (mutual TLS) is used for internal service-to-service communication, ensuring both ends of each connection are authenticated. This applies to the communication path between core, the Plugin Manager, and any sidecar services.
Certificate management supports both automated (ACME/Let’s Encrypt) and manual certificate provisioning for air-gapped environments.

Network Security

Air-Gapped Deployment

In Sovereign tier configurations, Dryade is designed to operate with zero outbound network connections. All components — model inference, plugin execution, vector storage, and identity management — run within the deployment perimeter. No telemetry, no update checks, no external API calls. This makes the platform suitable for classified environments, defense applications, and regulated industries where data exfiltration risk must be eliminated.

HTTP Security Headers

The platform enforces a strict Content Security Policy (CSP) that:

Restricts script execution to known origins
Prevents inline script injection
Sandboxes plugin UI rendering in isolated iframes with restricted permissions

CORS is configured with an explicit allowlist of permitted origins. Wildcard origins are never used in production configurations.

Rate Limiting

API rate limits are enforced per authentication key at the application layer:

Tier	Requests per minute
Starter	60
Team	300
Enterprise	1,000

Rate limiting headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are included in all API responses. Requests exceeding the limit receive an HTTP 429 response.

Audit Trail

Every operation within the platform is logged with full provenance metadata, producing an immutable audit trail designed for compliance review and incident investigation.

What Is Logged

Agent execution — Every agent decision, including which tool was selected, what input was provided, and what output was produced.
Tool calls — Full input/output capture for each tool invocation, including external API calls made by plugins.
Model interactions — Which model provider and model version handled each inference request, along with token counts and response metadata.
User actions — Authentication events, plugin installations, configuration changes, and administrative operations.
Plugin lifecycle — Plugin loading, unloading, allowlist updates, and hash verification results.

Audit Log Structure

Each audit entry includes:

Timestamp (UTC, millisecond precision)
Session and correlation IDs for request tracing
Agent identity and framework version
User identity (when the action is user-initiated)
Action type and detailed payload
Source IP and user agent (for API-initiated actions)

Audit logs are stored in PostgreSQL and are accessible to users with administrative roles. Logs can be exported in structured JSON format for integration with external SIEM systems.

Supply Chain Security

The plugin supply chain is hardened at every stage to prevent execution of unauthorized or tampered code.

Gate at Discovery Time

The allowlist check occurs in validate_before_load() before any plugin module is imported into the Python process. This means plugin code — including module-level side effects, import hooks, and __init__.py execution — never runs unless the plugin is explicitly listed in the signed allowlist with a matching hash.

Blocked Plugins Are Invisible

Plugins not present in the signed allowlist are completely invisible to the system. They do not load, do not mount routes, do not appear in the /api/plugins endpoint, and produce no log entries indicating their presence. This prevents information leakage about what plugins exist on disk versus what is permitted to run.

Package Integrity

The .dryadepkg format ensures that the plugin package delivered to the customer is identical to the package reviewed and signed by the marketplace. The four-layer protection (Cython compilation, AES-256-GCM encryption, Ed25519 author signature, marketplace counter-signature) creates a chain of custody from the plugin author through marketplace review to the customer’s deployment.

No Remote Code Execution Paths

Plugins cannot fetch and execute code at runtime. The plugin sandbox restricts network access, filesystem access, and subprocess creation. All executable code must be present in the signed package at installation time and must pass hash verification at load time.

Deployment Security

Container Isolation

Dryade is distributed as a set of container images designed for deployment via Docker Compose or Kubernetes. Each service runs in its own container with:

Non-root user execution
Read-only root filesystems (where supported by the service)
Dropped Linux capabilities beyond the minimum required set
Resource limits (CPU, memory) to prevent denial-of-service from runaway processes

Secrets Management

Secrets (database credentials, API keys, signing keys) are injected via environment variables or mounted secret files. The platform does not store secrets in configuration files, container images, or version control. For Kubernetes deployments, the architecture supports integration with external secret stores (HashiCorp Vault, AWS Secrets Manager, or Kubernetes-native Sealed Secrets).

Air-Gapped Installation

For environments without internet access, Dryade provides offline installation bundles that include all container images, plugin packages, and model weights. The installation process does not require any network connectivity. Updates are delivered as signed bundles verified before application.

Compliance Alignment

Dryade’s architecture is designed to support compliance with the following regulatory frameworks. Note that compliance alignment describes architectural capabilities — specific certification status is listed in the Security Roadmap section below.

All data processing occurs within the customer’s infrastructure (self-hosted model)
No data leaves the deployment perimeter in air-gapped configurations
Audit trails provide the record-keeping required under Articles 5 and 30
User data can be exported and deleted to support data subject rights (Articles 15-17)

EU AI Act

Agent decision audit trails support the transparency and traceability requirements for AI systems
Model interaction logging provides the documentation required for high-risk AI system record-keeping
Human oversight controls (approval workflows, agent execution boundaries) align with human-in-the-loop requirements

ANSSI Alignment

The platform architecture is aligned with ANSSI (Agence nationale de la securite des systemes d’information) security recommendations for cloud and on-premise deployments. This includes cryptographic choices (post-quantum readiness), network isolation capabilities, and audit logging. ANSSI SecNumCloud certification is in progress (see Roadmap).

CLOUD Act-Free Jurisdiction

Dryade is a French company with infrastructure hosted in France under EU jurisdiction. Customer data stored on Dryade-hosted instances is not subject to US CLOUD Act extraterritorial data access provisions. Self-hosted customers maintain full jurisdictional control over their data based on their chosen hosting location.

Vulnerability Disclosure

If you discover a security vulnerability in Dryade, please report it responsibly:

Email: security@dryade.ai
Scope: All Dryade platform components, including core, Plugin Manager, marketplace, and client SDKs
Response time: We aim to acknowledge reports within 48 hours and provide an initial assessment within 5 business days

Please do not disclose vulnerabilities publicly until a fix has been released and customers have had reasonable time to update. We credit researchers who report valid vulnerabilities (with their permission) in our security advisories.

Security Roadmap

The following certifications and security milestones are planned or in progress:

Initiative	Status
SOC 2 Type II	Planned
ISO 27001	Planned
ANSSI SecNumCloud certification	In progress
NIST post-quantum migration (ML-DSA-65 dual signatures)	Implemented
Plugin hash verification (SHA-256)	Implemented
Air-gapped deployment support	Implemented
SBOM (Software Bill of Materials) generation	Planned
Penetration testing (third-party)	Recurring, scheduled annually

For questions about Dryade’s security architecture or to request a detailed security questionnaire response, contact security@dryade.ai.