Skip to main content

Valmis: Analysis of a Security-Centered AI Agent Platform

· 7 min read
p4r4d0xb0x
p4r4d0xb0x
Rustacean, AI, OSS Enthusiast

Valmis is an open-source project designed to operate AI agents for work in cloud environments. The submitted repository—its README and related files—reveals these central points: agents run in independent containers, while credentials and external requests pass through a host-side proxy so that the LLM and agent runtime cannot access sensitive keys directly. It also supports multistep workflows, more than 100 business integrations, browser automation, and memory and embeddings based on pgvector.

This article organizes the core design and operational considerations based on the repository README, screenshots, and main passages. It interprets and summarizes the original evidence. As the supplied evidence does not fully establish every detail of the code and operations, such as security-audit results and operational monitoring configuration, those areas are explicitly marked as uncertain.

The repository header screenshot above presents the project's purpose and key message, clearly announcing its "security-centered design" and "container-based agents" at the introductory level. This screen provides evidence for assessing the platform's work-oriented, security-first philosophy.

The sections below provide an architecture-centered technical analysis.

Architecture Highlights​

  • Agent runtime: each agent runs in isolation with a separate filesystem and container. This design separates resource and file access between runtimes.
  • Proxy-based access: an agent cannot access credentials themselves. Instead, it makes a proxy call with a credential ID, and the host performs the actual API request. LLM calls also pass through the proxy.
  • Integration ecosystem: more than 100 integrations, including Google Workspace, Slack, Notion, and HubSpot, are managed through YAML-based definitions for extensibility.
  • Workflows and automation: multistep workflows can be triggered by cron, webhooks, and application events, while conditions, loops, and schema definitions control data flow.
  • Memory and embeddings: agent memory is classified as episodic, semantic, procedural, and working memory, with pgvector and text embeddings used for semantic search.
Term explainer: proxy system

Plain definition: an intermediary that prevents an agent from directly accessing sensitive credentials such as API keys and instead has the host perform requests with those credentials on the agent's behalf. Everyday example: rather than giving out a company password, you ask an assistant to "send this email," and the assistant logs in and sends it for you.

Technical Meaning of the Security Design​

The advantage of the proxy design is that the LLM or agent process never accesses raw credentials such as plain API keys. According to the README, credentials are encrypted with AES-256-GCM and stored in the database. The agent delegates a request by sending a credential ID to the host. This pattern reduces the risk of internal data leakage, but the proxy itself and the host's permission domain must be strongly protected.

Term explainer: container isolation

Plain definition: a method in which each agent runs with files, processes, and networks separated from other agents and the host system. Everyday example: several offices may share one building, but each office has a locked door that prevents its documents from being read directly by another office.

What Container Isolation Protects​

  • Filesystem separation: each agent has its own filesystem, as stated in the README. This can restrict access to host files and files belonging to other agents.
  • Network control: the documentation states that "the agent's internet access can theoretically be disabled," suggesting that an egress-control network policy can block external connections and require communication through the proxy alone.

The README states that Valmis uses pgvector to store memory as embeddings and perform semantic search. Its memory types—episodic, semantic, procedural, and working—classify mechanisms for conversational continuity and state management from a design perspective.

Term explainer: pgvector

Plain definition: a PostgreSQL extension that stores vectors, or arrays of numbers, in a database and enables fast similarity search. Everyday example: it resembles representing song characteristics as numerical vectors to find "tracks similar to this one" in a music application.

Term explainer: embedding

Plain definition: text or a document transformed into a fixed-length numerical vector to represent meaning, or semantic similarity, numerically. Everyday example: it resembles converting sentences with different emotions into coordinates so that sentences with similar emotions occupy nearby positions.

Workflows and Automation​

The workflow screenshot above presents the concept of a multistep automation canvas. Workflows can define conditions, loops, and schemas. Credentials and tools can also be restricted at each step, allowing the principle of least privilege to be applied.

Operational considerations:

  • Permission boundaries: separating the credentials available to each workflow step can strengthen permission isolation.
  • Input and output schemas: defining each step's output schema improves data mapping and the safety of subsequent steps.
  • Human in the loop (HITL): the README states that a mechanism allows an agent to ask a person for confirmation on important decisions. This is an important safety net for automation.

Headless Browsers and Browsing-Session Management​

The browser-automation screenshot shows that an agent can navigate pages, fill forms, and take screenshots through a host-managed browser session. The key point is that the browser is also managed by the host and the agent controls it only through a proxy interface.

Term explainer: headless browser

Plain definition: a browser mode that can automatically load and manipulate web pages without a graphical user interface. Everyday example: rather than a person manually clicking and entering information in a browser, a script performs the work in the background.

Security and operational considerations for headless browsers:

  • Session and cookie management: sessions and cookies must be managed separately for each agent to prevent cross-agent leakage.
  • Sensitivity of screenshots and logs: screenshots and logs produced by automation may contain sensitive information and therefore require access control.
  • Resource isolation: the host must manage resources if browser instances consume excessive capacity.

Supported LLM and Embedding Providers​

According to the README, nearly 200 models from approximately 20 providers are supported, including major providers such as OpenAI, Anthropic, Google, Mistral, and Cohere. This provides the flexibility to assign a mix of low-cost and high-performance models to different agents.

Operations and Deployment: Docker Compose and Initial Setup​

The repository's "Getting started" section recommends launching the entire stack—the frontend, backend, pgvector-enabled PostgreSQL, and Docker socket proxy—from a single Docker Compose file. It provides an example .env file and methods for generating the minimum secrets: CREDENTIAL_ENCRYPTION_KEY, JWT_SECRET, and PROXY_TOKEN_SECRET. This is suitable for quickly configuring a local or private demonstration environment.

Limitations and Remaining Uncertainty​

  • Security audits: the README emphasizes security by design, but the supplied evidence does not mention an external security audit or vulnerability-scan results.
  • Operating scale and multitenancy: the documentation states container isolation and permission boundaries, but does not specifically address resource control, cost management, or orchestration strategy for large-scale multitenant operation with hundreds or thousands of agents.
  • Proxy trust boundary: the proxy protects credentials, but proxy and host privileges create a new trust anchor. The supplied material does not provide complete information on the host and proxy attack surface, including privilege escalation and log exposure.

Conclusion and Practical Recommendations​

Valmis has a clear design direction for securely operating AI agents for work. Proxy-based credential protection, container isolation, step-level permission restrictions, and HITL satisfy fundamental requirements for applying automation to real work. Additional reviews recommended before practical adoption include:

  • Conduct security audits and penetration tests against the proxy and host
  • Establish credential-encryption key management through KMS and a key-rotation policy
  • Configure per-agent resource limits and monitoring, including host-level metrics and cost tracking
  • If multitenancy is required, review network and storage isolation and related policies

Note: this article is based on the README, included screenshots, and public descriptions in the valmishq/valmis repository. It does not cover every code and operational detail. Repository configuration and actual deployment architecture must be verified through direct review of the source.

Sources​

// COMMENTS

Comments