Agent with secrets - full walkthrough

Goal: Build a customer-support AI agent in a MIOSA sandbox that calls OpenAI and reads GitHub issues. Wire up vault-managed secrets for both credentials. Watch the audit trail in real time. Lock down egress to only those two hosts. Then rotate the OpenAI key while the agent is mid-run - no restart, no redeploy.

What you’ll use: Sandboxes, Secrets, Connect Accounts, Audit Log, Network Allowlist

What you’ll build

Your backend
  └─ creates sandbox
  └─ sets OpenAI API key in vault           → sandbox sees $OPENAI_API_KEY (placeholder)
  └─ connects GitHub via OAuth              → sandbox sees $GITHUB_TOKEN (placeholder)
  └─ runs agent code                        → proxy swaps placeholders on egress
  └─ tails audit log (live stream)          → every outbound call visible
  └─ locks down to api.openai.com + api.github.com
  └─ rotates OpenAI key while agent runs    → next request silently picks up new key

Prerequisites

• MIOSA API key (msk_live_*) - see API Keys
• OpenAI API key (sk-proj-*)
• GitHub account (for the OAuth step)
• Python 3.11+ or Node 22+

Step 1 - Install and configure

Step 2 - Create the sandbox

Step 3 - Add the OpenAI key to the vault

The real key never enters the sandbox. The sandbox sees only an opaque placeholder that the MIOSA proxy swaps on the way out.

Verify it landed:

Step 4 - Connect GitHub via OAuth

Step 5 - Write and run the agent

Now write a simple agent that reads open GitHub issues and drafts replies via OpenAI. The code uses both env vars exactly as it would on a bare machine - no MIOSA-specific client code inside the sandbox.

Step 6 - Watch the audit log in real time

Open a second process (or a second async task) to tail the audit log while the agent runs. You’ll see every outbound call as it happens.

Expected output while the agent runs:

[audit] allow    api.github.com   HTTP 200  secrets=none
[audit] allow    api.openai.com   HTTP 200  secrets=openai_key
[audit] allow    api.github.com   HTTP 200  secrets=none
[audit] allow    api.openai.com   HTTP 200  secrets=openai_key

The secrets=openai_key column confirms the proxy is swapping the placeholder with the real key on each OpenAI call.

Step 7 - Lock down the network

After observing what the agent actually calls, lock it to exactly those two hosts.

Run the agent again. It still works. Now try to reach anything else:

# Inside the sandbox after lockdown:
curl -s https://pypi.org/simple/requests/
# → blocked: 403 MIOSA-Egress-Deny

Bonus - Rotate the OpenAI key while the agent is running

Rotate mid-run without restarting anything. The next request automatically uses the new key.

The agent does not restart. The placeholder token in $OPENAI_API_KEY doesn’t change. The proxy simply starts looking up the new real value on the next request that carries the placeholder.

What you learned

• sandbox.secrets.set keeps the real credential out of the VM entirely.
• OAuth Connect handles token refresh transparently - no retry logic needed in the agent.
• sandbox.audit.tail() gives a live stream of every outbound call with secret attribution.
• sandbox.network.lockdown() hardens the sandbox to exactly the hosts it needs.
• sandbox.secrets.rotate() updates the real value mid-run - the placeholder and the agent code are unaffected.

Next