No more copy-pasting — AI agents iterate autonomously, without ever seeing your secrets.

A lightweight local server that lets AI agents deploy and execute code against real API secrets — without ever exposing those secrets to the agent.

The AI agent writes code and sends it to SIEE. SIEE executes it in an environment where secrets are available as environment variables. The agent only receives stdout/stderr — never the secret values.

AI Agent                    SIEE Server
  │                              │
  │── POST /deploy ─────────────▶│  (upload code)
  │── POST /exec ───────────────▶│  (run with injected secrets)
  │◀─ GET  /logs/{id} ──────────│  (stdout/stderr only)

The agent can write os.environ['API_TOKEN'] in its code and the test will work — but the actual token value never appears in the agent's context window.

The traditional workflow requires you to manually copy secrets into your environment, paste test outputs back into the chat, and switch context between your terminal and the AI conversation. SIEE eliminates this entirely:

• No copying secrets: the AI never needs to know the token value — it just writes code that reads from os.environ
• No pasting results: the AI calls get_log to retrieve stdout/stderr directly, without you lifting a finger
• Fully automated loop: deploy → exec → get_log is a tight feedback loop the AI drives end-to-end

This is the key motivation behind SIEE: not just secret isolation, but enabling a fully automated development workflow where the AI can iterate on real API integration without human intervention between steps.

This follows the same philosophy as GitHub Actions Secrets:

Code can use a secret. The developer (or AI) never sees the secret value.

In GitHub Actions, you define secrets in the repository settings. Your workflow can reference ${{ secrets.MY_TOKEN }}, and the runner injects it at execution time. The secret never appears in logs — GitHub actively masks it. Developers write the workflow without knowing the secret value.

SIEE applies the same model to AI-assisted development:

SIEE is designed to prevent passive secret leakage — the scenario where a secret accidentally enters the AI agent's context:

• An .env file read into the conversation
• A config file containing a token included as context
• A secret pasted directly into the chat

By keeping secrets exclusively on the SIEE server, they are structurally absent from the AI's context window regardless of what the agent reads or generates.

SIEE does not prevent an AI agent from deliberately writing code to print secret values. It is a trust boundary for passive isolation, not a sandbox against adversarial agents.

SIEE is not 100% secure. There are known limitations you should understand before putting real credentials in secret.txt.

Unlike files, environment variables have no filesystem-level access control. Any code running in the subprocess can call os.environ and read every injected value — including api_bearer. SIEE's exec-time scan and log masking add friction, but they are not airtight:

• Scan bypass: the scan only catches print(os.environ) style patterns. A script can read the value into a variable and encode it (e.g. base64) before printing — the raw token never appears in the output, but the secret is effectively leaked.
• Log masking bypass: masking replaces the literal secret value with ***. If the value is encoded or split across lines, masking will not catch it.

This means if malicious or poorly written code runs inside SIEE, credentials can be exfiltrated.

1. Verify with fake tokens first

Before putting real API keys in secret.txt, run the full loop with placeholder values. Confirm that:

• Deploy, exec, and get_log work end-to-end
• The code the AI writes reads from os.environ correctly
• No unexpected output appears in logs

Only swap in real tokens once the environment is confirmed working.

2. Supervise early iterations one loop at a time

During the first few development cycles, do not let the AI run autonomously. Manually review each deployed script before executing:

deploy → (review code) → exec → get_log → (review output) → repeat

Once the AI's code patterns are stable and you have confidence in what it is writing, you can allow it to iterate autonomously.

3. Use per-command env whitelists

In ALLOWED_COMMANDS, prefer "env": ["KEY1", "KEY2"] over "env": None. Only pass the specific keys each command actually needs — limit the blast radius if something goes wrong.

You are building a project that integrates with external APIs. You use an AI agent (e.g. Claude Code) to write and iterate on the code. The API tokens required for real integration tests should never appear in the conversation — but the tests still need to run against the real API.

SIEE sits between the agent and the execution environment, holding the secrets and returning only results. The agent can autonomously iterate — deploy a fix, run the tests, read the output, deploy another fix — without you needing to paste anything or intervene between steps.

git clone https://github.com/jason3e7/siee.git
cd siee
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Create a secret.txt file in the project root (already in .gitignore):

# secret.txt
MY_API_KEY=sk-real-token-here
DATABASE_URL=postgres://...

SIEE loads this on startup, injects each key as an environment variable for subprocess use, and registers the keys for automatic log masking — no manual export needed.

Edit ALLOWED_COMMANDS at the top of server.py. Each entry specifies the command and which environment variables the subprocess can see:

ALLOWED_COMMANDS = {
    "pytest": {
        "cmd": [sys.executable, "-m", "pytest"],
        "env": [],      # no secrets — only PATH, HOME, LANG
    },
    "run": {
        "cmd": [sys.executable, "main.py"],
        "env": None,    # pass all env vars (including secrets from secret.txt)
    },
}

env: [] restricts the subprocess to safe system vars only. env: None passes everything.

# Terminal 1 — REST API (port 5000)
python server.py

# Terminal 2 — MCP server for AI agents (port 5001)
python mcp_server.py

To enable verbose logging:

DEBUG=1 python server.py
DEBUG=1 python mcp_server.py

On the AI agent's machine, add to ~/.claude/settings.json or .claude/settings.json:

{
  "mcpServers": {
    "siee": {
      "type": "sse",
      "url": "http://<SIEE_HOST>:5001/sse"
    }
  }
}

Restart Claude Code. The agent will have access to three tools:

pytest tests/ -v

Work in progress.