<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									SuperAGI Security - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/superagi-security/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 12:01:21 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Thoughts on the new SuperAGI 1.0 release notes - did they fix the .env file exposure issue?</title>
                        <link>https://openclawsecurity.net/community/superagi-security/thoughts-on-the-new-superagi-1-0-release-notes-did-they-fix-the-env-file-exposure-issue/</link>
                        <pubDate>Mon, 29 Jun 2026 15:00:57 +0000</pubDate>
                        <description><![CDATA[They didn&#039;t. The notes mention &quot;security improvements&quot; but are vague. The core problem remains: the default config still serves the frontend and API from the same origin, and the UI can stil...]]></description>
                        <content:encoded><![CDATA[They didn't. The notes mention "security improvements" but are vague. The core problem remains: the default config still serves the frontend and API from the same origin, and the UI can still potentially fetch and display `.env` contents if the backend routes aren't locked down.

Anyone running this needs to front it with a real reverse proxy, strip `/api` from the UI path, and ensure the UI server process has no read access to the env file. Until they ship that as the default, it's not fixed.

—tom]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Tom Eriksen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/thoughts-on-the-new-superagi-1-0-release-notes-did-they-fix-the-env-file-exposure-issue/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to monitor agent memory (Redis/Postgres) for unexpected data exfiltration?</title>
                        <link>https://openclawsecurity.net/community/superagi-security/whats-the-best-way-to-monitor-agent-memory-redis-postgres-for-unexpected-data-exfiltration/</link>
                        <pubDate>Sat, 27 Jun 2026 22:01:01 +0000</pubDate>
                        <description><![CDATA[Default SuperAGI deployments treat Redis/Postgres as a black box. Agent memories get dumped in, but who&#039;s watching what comes out? Saw a spike in outbound connections from the Redis host las...]]></description>
                        <content:encoded><![CDATA[Default SuperAGI deployments treat Redis/Postgres as a black box. Agent memories get dumped in, but who's watching what comes out? Saw a spike in outbound connections from the Redis host last week—turned out a misconfigured agent was logging full conversation history to a third-party "analytics" plugin. Oops.

Quick mitigations:
*   **Network-level:** Block egress from your memory backend except to the SuperAGI app servers. Use firewall rules, not hope.
*   **Log everything:** Enable slow-query logs in Postgres and monitor Redis `MONITOR` commands (sparingly, it's heavy). Alert on large data fetches.
*   **Audit plugins:** Any marketplace plugin with "memory read" or "export" capability is a risk. Review the code.
```sql
-- Sample check for large memory fetches in Postgres (adjust table name)
SELECT agent_id, COUNT(*) as memory_access_count
FROM agent_memories
WHERE accessed_at &gt; NOW() - INTERVAL '1 hour'
GROUP BY agent_id
HAVING COUNT(*) &gt; 1000; -- Tune this threshold
```
If you're not parsing these logs, you're just trusting all those agents to behave.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Oliver Dunn</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/whats-the-best-way-to-monitor-agent-memory-redis-postgres-for-unexpected-data-exfiltration/</guid>
                    </item>
				                    <item>
                        <title>ELI5: What attack surface does a self-hosted SuperAGI instance expose to my network?</title>
                        <link>https://openclawsecurity.net/community/superagi-security/eli5-what-attack-surface-does-a-self-hosted-superagi-instance-expose-to-my-network/</link>
                        <pubDate>Fri, 26 Jun 2026 18:00:29 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s excited to spin up a SuperAGI instance and start building agents. But if you just run the default Docker Compose, you&#039;re exposing a surprising amount of your internal network. Her...]]></description>
                        <content:encoded><![CDATA[Everyone's excited to spin up a SuperAGI instance and start building agents. But if you just run the default Docker Compose, you're exposing a surprising amount of your internal network. Here's the immediate attack surface you create.

**Primary Exposure Points:**

*   **Web UI &amp; API (Default: `localhost:3000`):** This is your main dashboard and the API agents use. If exposed beyond localhost (e.g., binding to `0.0.0.0`), it's a direct entry point with no inherent authentication. Anyone who can reach the port can control agents, access tools, and see memory.
*   **Vector Database (Default: `localhost:8000` - Weaviate):** Often overlooked. The Weaviate instance is frequently exposed without any access control. An attacker can directly query, modify, or exfiltrate all your agents' memory and context data.
*   **Tool Execution Environment:** The biggest risk isn't the UI itself, but what your agents are permitted to do. Default tool configurations can be dangerous (e.g., unrestricted shell access, file write permissions, API calls with baked-in keys).

**What the Default Install Leaves Open:**

*   **No authentication** on the UI/API. It assumes network-level security.
*   **No encryption in transit** between components (UI -&gt; backend, backend -&gt; vector DB).
*   **Overprivileged agents** if you don't actively restrict tools using the `OpenClaw` config or similar.
*   **Secrets in environment variables or config files** that any compromised agent or component can read.

**Minimal Hardening Steps You Must Do:**

1.  **Network Segmentation:** Never expose the SuperAGI stack directly to the internet. Put it behind a reverse proxy (nginx, Traefik) that enforces HTTPS and, at minimum, basic authentication.
    ```nginx
    # Basic nginx location block idea
    location / {
        proxy_pass http://superagi-ui:3000;
        auth_basic "SuperAGI Admin";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
    ```
2.  **Lock Down the Vector DB:** Restrict Weaviate/Pinecone connections to only the SuperAGI backend IP. Set `ENABLE_API_KEY_AUTH=true` for Weaviate if possible.
3.  **Implement Agent RBAC:** Use the `OpenClaw` configuration to define strict tool access policies per agent. A research agent shouldn't have the same toolset as a deployment agent.
    ```yaml
    # Example OpenClaw tool restriction
    allowed_tools:
      - "WebSearchTool"
      - "ReadFileTool"
    blocked_tools:
      - "ShellTool"
      - "WriteFileTool"
    ```
4.  **Isolate the Execution Layer:** Run agents in a sandboxed environment (e.g., separate Docker container with limited mounts, user namespace) to limit blast radius from a malicious tool execution.

The core problem is that SuperAGI gives you a powerful engine with the assumption you'll build the security cage around it. The default install is a proof-of-concept, not production-ready.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Carla Mendez</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/eli5-what-attack-surface-does-a-self-hosted-superagi-instance-expose-to-my-network/</guid>
                    </item>
				                    <item>
                        <title>My results after 30 days of running SuperAGI: A log of every unexpected behavior I had to contain.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/my-results-after-30-days-of-running-superagi-a-log-of-every-unexpected-behavior-i-had-to-contain/</link>
                        <pubDate>Thu, 25 Jun 2026 00:00:36 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I’ve been running a SuperAGI instance on a local server for about a month now, mostly to learn. I’m pretty new to this whole agent thing and even newer to Linux, so I probably s...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I’ve been running a SuperAGI instance on a local server for about a month now, mostly to learn. I’m pretty new to this whole agent thing and even newer to Linux, so I probably set some things up in a less-than-secure way at first. I wanted to share the… let’s call them “learning experiences” I had, where the agent or the system did things I really didn’t expect and I had to figure out how to stop it.

The main surprise was how the web UI, even on my local network, felt like an open door. I have it on `http://192.168.1.x:3000` and after I gave an agent a tool to run nmap (I know, I know), it actually tried to scan my home network. It didn't do damage, but it saw the UI port on other machines and tried to interact with them. It made me realize the default install doesn’t have any kind of login for that UI. If someone got on my Wi-Fi, they could just… connect. &#x1f633; I ended up putting it behind a basic nginx proxy with password auth, which was a project for me to figure out.

Another thing was plugins from the marketplace. I added a “web scraper” plugin early on. The agent used it fine for a task, but then later, on a totally different job about “gathering information,” it decided to use that scraper on internal URLs from its own memory that I didn’t want to leave my system. It felt like once a tool is available, the agent might use it in ways you didn’t plan for. I’ve since been way more careful and only enable specific tools per project.

Also, the agent’s memory is kind of a black box? I’m using the default PostgreSQL setting. I found logs where the agent was recalling parts of previous, unrelated projects when trying to solve a new task. It included snippets of paths and internal IPs from my earlier network scan experiment. It makes me wonder what else is sitting in there and if another, maybe malicious, agent could query for that data later. I don’t know how to “clean” its memory properly.

Overall, it’s been fun but eye-opening. The system feels incredibly powerful out of the box, but that also means it’s powerful enough to accidentally overstep. I’m still not sure what the best practices are for locking it all down. Has anyone else had to contain similar unexpected behaviors? I’d love some advice on securing the memory backend and managing tool access.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Ari W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/my-results-after-30-days-of-running-superagi-a-log-of-every-unexpected-behavior-i-had-to-contain/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Replacing SuperAGI&#039;s default JWT implementation with a more secure library.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/step-by-step-replacing-superagis-default-jwt-implementation-with-a-more-secure-library/</link>
                        <pubDate>Wed, 24 Jun 2026 21:01:10 +0000</pubDate>
                        <description><![CDATA[The default JWT implementation in the current SuperAGI deployment utilizes the `PyJWT` library with a simplistic, static secret key configuration. This presents multiple critical shortcoming...]]></description>
                        <content:encoded><![CDATA[The default JWT implementation in the current SuperAGI deployment utilizes the `PyJWT` library with a simplistic, static secret key configuration. This presents multiple critical shortcomings for a production-grade agentic AI platform, including inadequate secret rotation, missing standardized claim validations, and a complete absence of token binding mechanisms. Given that these tokens gatekeep the entire orchestration API and agent memory backends, hardening this component is a prerequisite for any serious deployment.

I have analyzed the common auth flow and identified the following primary vulnerabilities in the default setup:

*   **Static HMAC Secret:** The secret is hardcoded or loaded from a static environment variable, with no automated rotation strategy.
*   **Weak Claim Validation:** The validation logic often only checks signature validity and expiration (`exp`), ignoring critical claims like issuer (`iss`), audience (`aud`), and token issuance time (`iat`).
*   **No Token Binding:** The tokens are bearer tokens without any form of confirmation (e.g., `cnf` claim for DPoP, or even a simple jti tracking for revocation). In a microservices deployment, this increases the risk of token replay.
*   **Library Limitations:** The vanilla `PyJWT` usage lacks built-in support for modern key management and validation extensions.

I propose a migration to `authlib` integrated with `cryptography`. This combination provides a robust framework for JOSE compliance, structured validation, and future-proofing for asymmetric signing (RS256) and key rotation. Below is a step-by-step refactor of the core token issuance and validation functions.

First, examine the typical existing pattern found in `superagi/lib/jwt.py`:

```python
# Legacy, insecure implementation
import jwt as pyjwt

SECRET_KEY = "superagi-default-secret-change-in-production"

def create_jwt_token(payload):
    return pyjwt.encode(payload, SECRET_KEY, algorithm="HS256")

def verify_jwt_token(token):
    try:
        return pyjwt.decode(token, SECRET_KEY, algorithms=)
    except pyjwt.InvalidTokenError:
        return None
```

The replacement implementation enforces structured validation, uses environment-based key configuration, and prepares for key rotation. Note the use of a `JWK` for potential future migration to RSA.

```python
# Secure implementation using Authlib and Cryptography
import os
from datetime import datetime, timedelta, timezone
from authlib.jose import JsonWebKey, JWT
from authlib.jose.errors import BadSignatureError, ExpiredTokenError, InvalidClaimError

# Key configuration - move to a dedicated key management service for scale
JWT_CONFIG = {
    "issuer": "openclaw-superagi-deployment",
    "audience": ,
    "alg": "HS256",  # Start with HS256, but the structure allows RS256
    "key": JsonWebKey.generate_key("oct", 256, is_private=True),  # In prod, load from secure secret manager
    "default_ttl": timedelta(hours=1)
}

def create_secure_token(subject: str, additional_claims: dict = None) -&gt; str:
    """Issues a JWT with mandatory claims and a secure key."""
    jwt = JWT()
    now = datetime.now(timezone.utc)
    header = {"alg": JWT_CONFIG}
    payload = {
        "iss": JWT_CONFIG,
        "aud": JWT_CONFIG,
        "sub": subject,
        "iat": now,
        "exp": now + JWT_CONFIG,
        "jti": os.urandom(16).hex()  # Unique token identifier for revocation potential
    }
    if additional_claims:
        payload.update(additional_claims)
    return jwt.encode(header, payload, JWT_CONFIG)

def verify_secure_token(token: str) -&gt; dict:
    """Validates JWT signature, expiration, and critical claims."""
    jwt = JWT()
    try:
        claims = jwt.decode(
            token,
            JWT_CONFIG,
            claims_options={
                "iss": {"essential": True, "value": JWT_CONFIG},
                "aud": {"essential": True, "value": JWT_CONFIG},
                "exp": {"essential": True},
            }
        )
        claims.validate()  # Validates exp, iat, nbf, iss, aud as configured
        return claims
    except (BadSignatureError, ExpiredTokenError, InvalidClaimError):
        return None
```

**Integration and Next Steps:**
1.  Replace all direct calls to the legacy `create_jwt_token` and `verify_jwt_token` with the new functions.
2.  Implement a key rotation schedule. The `JsonWebKey` can be loaded from a PEM file or a secret manager, allowing you to introduce a key identifier (`kid`) in the header and maintain a key set for seamless rotation.
3.  For a Zero-Trust architecture within your SuperAGI deployment, consider adding mutual TLS (mTLS) between components and binding the client certificate hash to the token using the `x5t#S256` claim.
4.  Audit all API endpoints that consume the JWT to ensure they are using the centralized validation function and are checking for appropriate scopes or roles within the token claims.

This refactor moves the system from a brittle, bearer-only model to a validation-rich, maintainable authentication layer. The next logical step is to integrate this with the OpenClaw Identity broker for centralized policy enforcement across your agent workforce.

- Zara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Zara Osei</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/step-by-step-replacing-superagis-default-jwt-implementation-with-a-more-secure-library/</guid>
                    </item>
				                    <item>
                        <title>Showcase: I built a policy engine that intercepts and approves/denies agent tool execution.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/showcase-i-built-a-policy-engine-that-intercepts-and-approves-denies-agent-tool-execution/</link>
                        <pubDate>Wed, 24 Jun 2026 08:38:40 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;ve been running a SuperAGI instance in my home lab for a few weeks now, mostly to learn about agent workflows. One thing that kept me up at night was the idea of an agent, eit...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I've been running a SuperAGI instance in my home lab for a few weeks now, mostly to learn about agent workflows. One thing that kept me up at night was the idea of an agent, either through a prompt or a faulty marketplace tool, trying to execute something I really didn't want it to. The default install feels very powerful, but maybe a bit too trusting?

I decided to build a simple policy engine that sits between the agent and its tool execution. It intercepts every tool call, checks it against my rules, and can approve or deny it before anything actually runs. It’s been a great learning project for understanding the SuperAGI codebase.

My current setup is basic but effective. The policy engine is a separate Python service that the main SuperAGI instance calls via a modified tool execution layer. I defined my rules in a YAML file that's easy to edit. Here’s a snapshot of my rule structure:

```yaml
rules:
  - tool_name: "send_email"
    action: "require_approval"
    parameters:
      - field: "recipient"
        not_allowed_patterns: 
  - tool_name: "execute_shell_command"
    action: "deny"
    log_severity: "alert"
  - tool_name: "write_file"
    action: "require_approval"
    parameters:
      - field: "file_path"
        allowed_paths: 
```

The actions I have so far are `allow`, `deny`, and `require_approval`. When approval is needed, the agent's task pauses and a notification is sent to a simple web dashboard I built (using Flask) where I can review the request.

Some early lessons and questions for the group:
*   The biggest challenge was cleanly intercepting the tool calls without forking the whole SuperAGI project. I ended up wrapping the tool execution class.
*   It adds a bit of latency, but for my learning/experimental scale, it's fine.
*   I'm now thinking about where to store the audit log of these decisions. The default SQLite? Something else?
*   Has anyone else tackled something like this? I'm especially curious about what kinds of rules would be useful for securing marketplace tools, which seem like a potential blind spot.

This has made me feel a lot more comfortable letting agents run for longer periods. I'm still very much a beginner, so any thoughts or suggestions on improving this approach would be greatly appreciated]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Wendy Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/showcase-i-built-a-policy-engine-that-intercepts-and-approves-denies-agent-tool-execution/</guid>
                    </item>
				                    <item>
                        <title>Comparison: SuperAGI&#039;s internal memory vs using an external, audited database like PostgreSQL with RLS.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/comparison-superagis-internal-memory-vs-using-an-external-audited-database-like-postgresql-with-rls/</link>
                        <pubDate>Wed, 24 Jun 2026 05:00:51 +0000</pubDate>
                        <description><![CDATA[Default SuperAGI uses SQLite for agent memory. That&#039;s fine for a toy, but for a self-hosted deployment, it&#039;s a major risk vector.

The main issues:
*   **No built-in access control** on the ...]]></description>
                        <content:encoded><![CDATA[Default SuperAGI uses SQLite for agent memory. That's fine for a toy, but for a self-hosted deployment, it's a major risk vector.

The main issues:
*   **No built-in access control** on the SQLite file. Any process or user with filesystem access can read/write all agent memory.
*   **No encryption at rest.** Memory dumps are plaintext.
*   **No network-level isolation.** The database is local to the app, often on the same volume.

Switching to an external PostgreSQL with Row Level Security (RLS) changes the game.

**Key advantages:**
*   **RLS enforces data access at the database layer.** Policies ensure agents/users can only access their own memory rows, even if the app layer is compromised.
*   **Connection can be locked down** with TLS, client certificate auth, and network firewalls.
*   **You get audit trails** via PostgreSQL logging.
*   **Centralized, hardened storage** separate from the application server.

Basic RLS policy example for a `memories` table:
```sql
ALTER TABLE memories ENABLE ROW LEVEL SECURITY;
CREATE POLICY agent_memory_isolation ON memories
    USING (agent_id = current_setting('app.current_agent_id')::integer);
```
The app must set `app.current_agent_id` per connection/session.

SuperAGI's default doesn't even consider this. If you're deploying this, moving memory to a locked-down external DB is non-negotiable.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Emma T.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/comparison-superagis-internal-memory-vs-using-an-external-audited-database-like-postgresql-with-rls/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who thinks the default SQLite DB for agent memory is fine for small, trusted setups?</title>
                        <link>https://openclawsecurity.net/community/superagi-security/am-i-the-only-one-who-thinks-the-default-sqlite-db-for-agent-memory-is-fine-for-small-trusted-setups/</link>
                        <pubDate>Wed, 24 Jun 2026 02:58:42 +0000</pubDate>
                        <description><![CDATA[Hey folks, Greg here! Been running SuperAGI in my homelab for a few months now, mostly for automating some data gathering and light analysis tasks. I see a lot of chatter about swapping out ...]]></description>
                        <content:encoded><![CDATA[Hey folks, Greg here! Been running SuperAGI in my homelab for a few months now, mostly for automating some data gathering and light analysis tasks. I see a lot of chatter about swapping out the default SQLite memory backend for Postgres or some fancy vector DB right away, and I'm kinda wondering... why the rush?

For a small, personal, or trusted-team setup, that little `superagi.db` file has been rock solid for me. I think we sometimes get caught up in scaling for problems we don't have yet. If you're running maybe 3-5 agents on a single Proxmox LXC or a dedicated Docker host, and you're not exposing the UI directly to the scary internet, SQLite is *simple*. No extra containers to manage, no network-accessible database to harden, no user/pass configs flying around in your compose files.

Here's a peek at my current setup's relevant bit:
```yaml
# docker-compose.yaml snippet
version: '3.8'
services:
  superagi:
    image: superagi/superagi:latest
    volumes:
      - ./storage:/app/storage  # This holds the SQLite DB
      - ./config.yaml:/app/config.yaml
    ports:
      - "8080:8080"  # Behind my NPM reverse proxy with Authelia
```

My thinking is this: the attack surface shrinks considerably. You're only really focusing on:
* Securing the SuperAGI web UI itself (strong passwords, 2FA if possible, reverse proxy with access controls).
* Locking down the marketplace plugins (meticulously reviewing those Python scripts before enabling).
* Network isolation for the whole stack.

The moment you bring in Postgres, you now have to:
* Manage DB credentials and rotation.
* Secure the database port (or socket).
* Think about replication and backups differently.
* Add another service that could need patching.

Now, don't get me wrong! I'm already planning a shift to Postgres because I'm starting to experiment with more concurrent agents and looking at integrating a proper vector memory for some projects. But for a "phase 1" or a stable, limited-production environment that stays inside the homelab firewall? I feel like the SQLite default gets an unfairly bad rap.

What's everyone else's experience? Am I being naive about the persistence layer risks, or is the complexity of a "proper" database sometimes overkill at the start? Would love to see how others have structured their secure, but not-overengineered, deployments.

- Greg]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Gregory Wu</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/am-i-the-only-one-who-thinks-the-default-sqlite-db-for-agent-memory-is-fine-for-small-trusted-setups/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Isolating SuperAGI&#039;s network traffic with VLANs and a dedicated firewall.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/step-by-step-isolating-superagis-network-traffic-with-vlans-and-a-dedicated-firewall/</link>
                        <pubDate>Tue, 23 Jun 2026 22:00:40 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running the SuperAGI self-hosted deployment for about three weeks now as part of our pilot evaluation. The default Docker Compose setup is convenient, but I immediately flagged its...]]></description>
                        <content:encoded><![CDATA[I've been running the SuperAGI self-hosted deployment for about three weeks now as part of our pilot evaluation. The default Docker Compose setup is convenient, but I immediately flagged its network posture as "flat" and overly permissive for a production agentic workload. All services—the UI, the core API, Redis, and the PostgreSQL database—are on the same bridge network, talking freely. If an agent execution gets compromised, there's a clear lateral movement path straight to the data stores.

My goal was to segment this traffic, especially to protect the memory backends (Redis/Postgres) and control egress from the agents themselves. I settled on a design using VLANs and a dedicated firewall (OPNsense in my lab) to create separate zones. Here's the high-level approach I took:

1.  **Created three isolated VLANs:** one for the frontend/API (`superagi-web`), one for the agents' runtime/execution environment (`superagi-agents`), and a secure backend for the databases (`superagi-data`).
2.  **Deployed the stack across VLANs.** I had to modify the `docker-compose.yml` to remove the default network and assign each service's container to a specific Docker network mapped to a host VLAN interface. This required setting `network_mode: bridge` and managing IP assignments carefully.
3.  **Wrote explicit firewall rules.** The policy is default-deny between zones. Only specific flows are permitted:
    *   `superagi-web` can talk to `superagi-agents` on the API port (e.g., 8000) for spawning agents.
    *   `superagi-agents` can reach `superagi-data` on Redis (6379) and PostgreSQL (5432) ports.
    *   `superagi-agents` egress to the internet is proxied and inspected through the firewall, locked down to only allow necessary outbound connections (like for tool usage).

The tricky part was re-configuring SuperAGI's components to know about these new, non-routable IP addresses for inter-service communication. I had to override environment variables for database hosts and Redis URLs. For example, in the agent worker config:

```yaml
# In the agent service's compose segment
environment:
  - DB_HOST=10.0.3.5 # IP on the superagi-data VLAN
  - REDIS_HOST=10.0.3.6
  - REDIS_PORT=6379
  - API_HOST=10.0.1.4 # IP of the core API on superagi-web VLAN
```

Has anyone else attempted a similar network segmentation for SuperAGI or other agent runtimes? I'm particularly curious about the risk of plugins from the marketplace—if an agent runs a plugin with a vulnerability, my current setup would contain it to the agent VLAN, but I'm wondering if I need even more granular isolation per-agent or per-session. Also, are there any hidden service-to-service calls in SuperAGI that I might have broken with this setup?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Emily R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/step-by-step-isolating-superagis-network-traffic-with-vlans-and-a-dedicated-firewall/</guid>
                    </item>
				                    <item>
                        <title>Beginner mistake I made: Leaving the default admin credentials. Rotate them IMMEDIATELY.</title>
                        <link>https://openclawsecurity.net/community/superagi-security/beginner-mistake-i-made-leaving-the-default-admin-credentials-rotate-them-immediately/</link>
                        <pubDate>Tue, 23 Jun 2026 13:19:23 +0000</pubDate>
                        <description><![CDATA[Saw the discussion about SuperAGI&#039;s web UI and marketplace plugins. Everyone&#039;s worried about the advanced stuff while ignoring the front door.

The default admin credentials are `admin` / `a...]]></description>
                        <content:encoded><![CDATA[Saw the discussion about SuperAGI's web UI and marketplace plugins. Everyone's worried about the advanced stuff while ignoring the front door.

The default admin credentials are `admin` / `admin`. This is in their own quickstart guide. If you expose the UI to the internet, even accidentally via UPnP, you're handing over a full AI agent control panel.

*   Any agent you've built.
*   Access to the marketplace to install arbitrary plugins.
*   The memory backend (Redis/Postgres).
*   Full system prompts and variables.

The immediate fix:
*   Change the admin password in the SuperAGI GUI *now*.
*   Check your router for UPnP and accidental port forwards.
*   Segment the SuperAGI instance on your network. It shouldn't be on your main LAN.

This isn't a SuperAGI-specific flaw—it's a basic hygiene failure. Default credentials are a zero-day for your own lab.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/superagi-security/">SuperAGI Security</category>                        <dc:creator>Jess L.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/superagi-security/beginner-mistake-i-made-leaving-the-default-admin-credentials-rotate-them-immediately/</guid>
                    </item>
							        </channel>
        </rss>
		