Security-First Architecture

Enterprise Security by Design

EDDI eliminates entire classes of security vulnerabilities by design. There is no eval(), no code execution blocks, and no dynamic code injection, agent behavior is defined through declarative JSON configuration only.

Why This Matters Now

The AI agent ecosystem is under unprecedented security pressure. In early 2026, hundreds of critical vulnerabilities were publicly documented across major open-source agent frameworks, including CVSS 10.0 remote code execution flaws, sandbox escapes, and authorization bypasses. The root cause in most cases: platforms that execute user-supplied or dynamically generated code at runtime.

The Cloud Security Alliance identified a systemic "AI Agent Disclosure Vacuum": traditional vulnerability reporting processes cannot keep pace with the non-deterministic nature of AI systems. For enterprises deploying agents in regulated environments, the security posture of the underlying platform is no longer a nice-to-have. It is a board-level risk decision.

EDDI's Architectural Defense

Rather than attempting to sandbox code execution after the fact, EDDI eliminates the attack surface entirely. Agent behavior is defined through declarative JSON configuration, never through executable code blocks, eval() statements, or dynamic script injection. This architectural decision structurally prevents the vulnerability classes that have affected competing platforms.

Security Capabilities

• Zero eval(): No dynamic code execution of any kind. Agent logic is declarative JSON only
• OIDC/Keycloak: Enterprise authentication and authorization with RBAC roles (admin, editor, viewer) and a dedicated approver role
• Per-User Workspaces: Every configuration resource has an owner, a personal or team space, and explicit sharing at use, view, edit, or own level
• Connections: One credential model for outbound calls, from organization-wide keys and OAuth2 service accounts to each user's own OAuth account or a credential the calling system supplies per request. Secrets are always vault references
• Tool-Result Guardrails: Every tool result carries its provenance, and directive-shaped text inside it is marked, redacted, warned on, or blocked before the model acts on it
• Secrets Vault: AES-256-GCM envelope encryption for API keys with automatic secret scrubbing on export
• Path Traversal Protection: Input validation at every boundary prevents directory escape attacks
• SSRF Protection: URL validation and domain allowlisting prevent server-side request forgery, and cloud metadata endpoints are refused for HTTP call, MCP, and A2A targets, including through DNS resolution and redirects
• Cryptographic Audit Trails: HMAC-SHA256 signed, tamper-evident operation logs with per-agent cryptographic signing
• EU AI Act Ready: Built-in governance capabilities for regulatory compliance
• Secret Redaction: Automated filter scrubs API keys, vault references, and sensitive data from all audit entries
• PII-Safe Logging: GDPR operations log SHA-256 pseudonyms, never raw user identifiers
• Sigstore Cosign: Keyless OIDC container image signing, cryptographically verify any Docker image was built by official CI
• Hardened Base Image: Digest-pinned Red Hat UBI 10 runtime, published to the Red Hat certified catalog
• Secret Context Values: A caller can hand an agent a credential that is usable for one turn and is never stored or returned
• Restricted Runtime Templates: Templates built from runtime data render on a restricted engine with no configuration or bean access and per-render limits, and user input is always substituted as data, never parsed as a template

Automated Security Pipeline

Every change passes through automated security tooling, with every GitHub Action pinned by SHA to prevent supply-chain attacks:

• CodeQL: Semantic SAST analysis with security-extended queries
• Trivy: CVE scanning for filesystem dependencies and Docker images (blocking on CRITICAL/HIGH)
• Gitleaks: Git history scanning to prevent secret and credential leakage
• Dependency Review: New dependencies with known vulnerabilities are flagged on the pull request that adds them
• CycloneDX: SBOM generation for supply chain transparency
• ClusterFuzzLite with Jazzer: Coverage-guided fuzz testing for security-critical parsers
• OpenSSF Scorecard: Continuous scoring of the repository's supply-chain security practices

Why Rules Belong Outside the Model

Prompt injection is the attack that matters for agents with tools. In one benchmark of tool-using agents, instructions hidden in tickets and logs made agents take unsafe actions 82.5% of the time with no defence. Prompt-level defences left 10 to 26% unsafe; only a policy gate enforced at the tool call reached zero while still letting approved changes through. That is why EDDI enforces its rules in the engine, at the tool boundary, where injected text cannot argue its way past them. The evidence page lists the studies.

Hardening Log

Security work is continuous, and we publish what it finds. Recent rounds:

• September 2026 (6.5.0): A review round of about 30 fixes across template injection, SSRF on outbound calls, vault key handling, secret scoping, workspace authorization, channel identity and the Manager's security UI, each with a regression test
• August 2026 (6.3.0, 6.4.0): Outbound credentials unified under Connections, tool results carry provenance and directive-shaped text is redacted, and vault grants to agents are enforced
• July 2026 (6.2.0): Tool-result caches scoped per identity, secrets redacted from the live tool trace, and a constant-time audit HMAC comparison

Governance & Compliance Integration

Security capabilities feed directly into EDDI's compliance framework. The immutable audit trail supports EU AI Act record-keeping requirements (Art. 12), pipeline tracing provides AI decision transparency (Art. 13), and the Management UI enables human oversight with emergency stop capabilities (Art. 14). The same infrastructure supports GDPR, HIPAA, SOC 2, and 15+ additional regulatory frameworks, all through one unified API.