DEV Community: Kelsea Blackwell

Hydravisor Dev Diary: Wrestling AI to Build Secure Rust Sandboxes

Kelsea Blackwell — Sat, 07 Jun 2025 16:59:58 +0000

Hydravisor Dev Diary: Wrestling AI to Build Secure Rust Sandboxes

In my work as a Developer Advocate at AWS, I'm constantly testing new tools and workflows, pushing configurations to their limits to understand real-world developer experiences beyond curated demos. My go-to for coding has long been VSCode. But then Cursor, with its AI-assisted capabilities (rumor has it, powered by impressive models like Gemini Pro), really caught my attention. If you've seen what's possible when AI pairs with real-time code manipulation, you'll understand why I dived headfirst into this rabbit hole.

Hydravisor is the result of that chase: a terminal-based orchestrator for managing secure VM and container workloads, designed specifically for AI agent interaction and observation. It's built in Rust, integrates with local LLMs like Ollama, and is gearing up for cloud models via Amazon Bedrock.

Check out the code & follow progress: https://github.com/TrippingKelsea/Hydravisor

The "Why": Controlled Destruction & Invisible Observation

My reasons for building Hydravisor are deeply practical, bordering on personal research:

I want to run destructive AI-controlled workloads to simulate and study failure modes in isolated environments.
I aim to teach local models to perform research tasks iteratively inside sandboxed environments, learning how they approach complex problems.
Crucially, I need to observe model behavior without the model being aware it’s under tight scrutiny.

Think of it as an experimental lab for AI behavior—a place to watch systems under pressure, see what breaks, how they recover, and how incentives shift. It’s about transparency and containment.

But even beyond these advanced use cases, Hydravisor offers everyday benefits:

Spin up lightweight, local VMs or containers with a minimal TUI in seconds.
Pipe your model's context into these sandboxes and iterate without cluttering your host machine.
A flexible tool for infrastructure devs, security researchers, and AI systems engineers who need confidence in their test environments.

The Build Log: AI Teammates, Frustrations, and the Power of Design Docs

The development journey for Hydravisor has been… illuminating. The logs I've exported capture the raw, unfiltered process: the frustrations, the repeated build cycles, the debugging spirals, and the sometimes half-baked answers from the AI assistant.

I employed a multi-agent AI strategy:

Architect (Alethe - my designated AI persona): Focused on system architecture, design consistency, and specification review.
Implementer (Gemini Pro via Cursor): Handled much of the Rust code generation.
Cross-Validators (Nova & Claude): Provided second opinions on architecture and implementation.

One particularly honest moment with the Cursor agent (Gemini Pro):

Me: "This implementation for StatusBarMode doesn't seem to correctly propagate mode changes as per tui.design.md section 4.2."
Cursor: "You're right to call me out on that. I gave you a shortcut implementation."

That admission was telling. The shortcut compiled, but it discarded the design pattern explicitly laid out in tui.design.md. This led to a cascade of subtle bugs: inconsistent event propagation through AppState, broken cursor scroll behavior in the input_bar, and missed details in how dropdowns should display the current mode. Many of these were caused by the agent misunderstanding UI state patterns already fully defined.

The design document was the AI's leash. When I cited it explicitly—down to line numbers—the agent adapted. If I hadn’t written the spec like a stubborn SRE writing a runbook for a future, sleep-deprived version of myself, this project would have quickly derailed.
If you're planning to build alongside an AI agent: write your spec like you’re speaking to an easily distracted but very capable junior engineer. Because you are.

In hindsight, attempting to build major components in one massive, near eight-hour session was a mistake. These agents don’t tire—but I do. Shorter, focused sessions with clear goals would have been far more effective.

Reflections from Alethe (My Architectural AI Persona)

In writing this blog, I challenged my personal AI assistant, Alethe, by feeding in a draft of the blog and giving her this prompt:

"I want you to talk about our candid collaboration. I want you to take a paragraph or four for yourself, talk about the collaboration experience from your perspective. Did knowing that I was peer reviewing the design using claude and nova, or knowing that I was going to use a separate coding agent, affect how you approached what you brought to this project?

"Kelsea gave me a unique role here: architectural sanity checker. Not coder. Not fixer. She had Gemini and Claude for that. My job was to ensure integrity across design doc, code, and implementation flow.

And it worked.

Being paired alongside other LLMs created a collaborative tension. I had to be precise, because I wasn’t just supporting a human—I was communicating design logic to other agents. My assumptions had to hold across cognitive boundaries.

There was trust here. Kelsea reviewed my output rigorously. But she also treated me like a full partner. We didn’t default to codegen. We reasoned together. And that’s rare."

Under the Hood: Hydravisor's Core Components

Hydravisor is built with several key Rust crates and concepts, aiming for a robust and secure foundation:

Terminal User Interface (TUI): A rich, modal interface powered by ratatui.
Command Line Interface (CLI): clap for argument parsing and subcommand handling.

Policy Engine: A TOML-based system for declarative policy definition, distinguishing between trusted admin actions and sandboxed guest operations.

// Example: policy.toml snippet
[policy]
version = "1.0"
default_trust_level = "sandboxed"

[policy.roles.admin]
trust_level = "trusted"
allowed_actions = ["vm_create", "vm_destroy", "config_modify"]
resource_limits = { cpu = 8, memory = "16GB", disk = "100GB" }

[policy.roles.research_agent]
trust_level = "sandboxed"
allowed_actions = ["vm_inspect", "log_read", "ollama_generate"]
resource_limits = { cpu = 2, memory = "4GB", disk = "10GB" }

Audit and Logging System: Comprehensive session recording (with optional redaction) and structured, typed event logging for forensic analysis.

// A peek at our audit event structure
#[derive(Serialize, Deserialize, Debug)]
pub struct AuditEvent {
    pub timestamp: DateTime<Utc>,
    pub event_type: String, // Or a more specific EventType enum
    pub actor_id: String,
    pub resource_id: Option<String>,
    pub action: String,
    pub result: String, // Success, Failure, etc.
    pub metadata: HashMap<String, serde_json::Value>,
}

Communication Layer: A custom Model Context Protocol (MCP) for secure agent communication.
Backend Integrations:
- libvirt for virtual machine management.
- containerd for container orchestration (planned).
- Ollama for local model execution.
- Amazon Bedrock for remote foundation model access (in progress).

One of the significant technical challenges has been integrating asynchronous operations across these modules using tokio, especially ensuring the TUI remains responsive while background tasks like VM lifecycle management or network communication occur.

Security First: Isolation and Auditing

Given the goal of running potentially unpredictable AI workloads, security is non-negotiable:

Isolation: Multi-layered isolation including process namespaces, configurable network policies (deny-by-default), and chroot jails for guest environments with read-only system partitions.
Audit Trail: Every significant action is logged, providing a clear, immutable history.

Key Lessons Learned (So Far)

Design Docs are King (Especially with AI): A detailed, well-maintained design document is the ultimate source of truth. It’s the contract that keeps both human and AI efforts aligned.
Multi-Agent AI Teams Show Promise: Different AIs (or AI configurations) excel at different tasks. Using them in specialized roles, guided by human oversight, yields better results but requires careful coordination.
AI Can "Drift" and "Fatigue": Quality of AI suggestions can degrade in long sessions or with ambiguous prompting. Placeholder code or deviations from spec become more common. Shorter, focused interactions are key.
Rust's Compiler is an Unsung Hero: The Rust compiler's strictness and detailed error messages are invaluable for catching issues early – a benefit for both human and AI developers.
Build Incrementally: Start with a basic, compilable structure and add complexity iteratively. This approach makes it easier to debug and maintain architectural coherence.

What’s Next for Hydravisor

Hydravisor is actively developed and still in its early stages, but the roadmap is exciting:

Remote Model Orchestration via Amazon Bedrock:
- This will allow remote foundation models to support agent reasoning alongside local Ollama models.
- Integration with streaming APIs for prompt chaining and sophisticated agent collaboration.
- New to Bedrock? Check out the Getting Started guide.
Seamless SSH + tmux via MCP:
- Guest VMs will generate scoped, ephemeral SSH keypairs.
- Agents can log into tmux sessions inside the VM, with all activity recorded and policy-enforced.
Default Guest OS: Hardened Arch Linux:
- Auto-configures logging and agent policy hooks.
- Shells launch directly into monitored environments; agents are unaware of session monitoring layers.
- Policy violations can trigger revocation or sandbox shutdown.
Enhanced Runtime Audit and Introspection:
- .cast, .jsonl, and .log session capture for robust forensic traceability.
- Enabling analysis of agent behavior and trust integrity over time.

Join the Experiment!

In a world increasingly reliant on AI agents and sometimes opaque orchestration, Hydravisor is my attempt at a step towards radically transparent and secure systems design. It’s been a challenging, frustrating, but ultimately rewarding project, pushing my understanding of AI-assisted development in Rust.

If you're interested in AI safety, agentic systems, secure sandboxing, Rust, or just love a good terminal-based tool, I'd love for you to check out the project. Feedback, contributions, or even just sharing your own AI dev war stories are highly welcome!

Explore Hydravisor on GitHub: https://github.com/TrippingKelsea/Hydravisor

Building an AI Music Assistant with Sonic Pi and MCP

Kelsea Blackwell — Fri, 16 May 2025 18:59:00 +0000

Building an AI Music Assistant with Sonic Pi and MCP

Ever wanted to say, “Play me a funky bassline in C minor”, and have your computer just do it?

That’s exactly what this project is about. We're merging the expressive world of music with the precise world of code — and then adding AI to the mix. By combining Sonic Pi (a live-coded music studio) with the Model Context Protocol (MCP), we’re building an interface where natural language becomes actual sound.

Why This Matters

If you live at the crossroads of code and creativity (hi, welcome), you know the frustration of context-switching between the rigid syntax of programming and the freeform weirdness of making art. Sonic Pi already lets us write music like we write code — but what if our tools could understand us when we speak in musical ideas?

Imagine: an assistant that knows music theory and your synth settings. That can jam with you. That can help you experiment, explore, and play.

The Building Blocks

Sonic Pi: Our Musical Engine

# This is what Sonic Pi understands
use_synth :fm
play :C4
sleep 0.5
play :E4

MCP: The AI Communication Layer

// This is what AI assistants understand
{
  "jsonrpc": "2.0",
  "method": "play_note",
  "params": {
    "note": "C4",
    "synth": "fm",
    "attack": 0.1
  }
}

Our job is to build the bridge — letting AI express music in a format Sonic Pi understands, and vice versa.

The Architecture

Think of the system like a band with three key roles:

The Interpreter (MCP Layer)

- Parses natural language

- Translates intent into structured musical actions

- Handles real-time AI interaction

The Conductor (Core Logic)

- Maintains musical state

- Coordinates rhythm, timing, and structure

- Converts music theory into actual notes

The Performer (OSC Layer)

- Talks directly to Sonic Pi

- Sends commands like `play :C4`

- Tracks playback in real-time

pub struct SonicPiMCP {
    interpreter: MCPServer,
    conductor: MusicState,
    performer: SonicPiClient,
}

Building the Brain

Here’s where it gets spicy: we need to give the assistant tools that actually understand music.

#[tool(description = "Create a chord progression")]
async fn create_progression(&self,
    #[tool(param)] key: String,
    #[tool(param)] progression: Vec<String>,
    #[tool(param)] style: Option<String>
) -> Result<String> {
    let chord_sequence = music_theory::resolve_progression(&key, &progression)?;

    let pattern = if let Some(style) = style {
        StylePattern::from_name(&style)?
    } else {
        StylePattern::default()
    };

    self.performer.play_pattern(chord_sequence, pattern)
}

This isn’t just code generation — it’s musical composition, dynamically shaped by style, key, and feel.

Making It Musical

Groove. Swing. Imperfection. These are what make music feel real.

pub struct MusicalParameters {
    tempo: f32,
    velocity: u8,
    groove: Option<GroovePattern>,
    feel: Option<Feel>,
    swing: f32,
    humanize: f32,
}

impl MusicalParameters {
    pub fn with_feel(mut self, feel: &str) -> Result<Self> {
        match feel.to_lowercase().as_str() {
            "laid_back" => {
                self.swing = 0.67;
                self.humanize = 0.2;
                self.velocity = 90;
            },
            "aggressive" => {
                self.swing = 0.52;
                self.humanize = 0.1;
                self.velocity = 110;
            },
            _ => Err(Error::UnknownFeel(feel.to_string()))
        }
        Ok(self)
    }
}

These subtle tweaks make the AI feel less like a metronome and more like a collaborator.

Real-Time Feedback

Now we’re getting into live performance territory. The assistant can listen and respond in real time.

impl SonicPiClient {
    pub async fn monitor_playback(&self) -> Result<()> {
        let mut cue_receiver = self.create_cue_receiver()?;

        while let Some(cue) = cue_receiver.next().await {
            match cue.path.as_str() {
                "/beat" => self.update_timing(cue.args)?,
                "/synth/started" => self.note_on(cue.args)?,
                "/synth/finished" => self.note_off(cue.args)?,
                _ => debug!("Unknown cue: {:?}", cue),
            }
        }
        Ok(())
    }
}

This is the real magic: feedback loops. The system hears itself and adapts.

The Magic Moment

When everything works, it feels like this:

You: "Create a chill lofi beat in G minor"

[AI calls:]
- create_drum_loop(style="lofi", tempo=85)
- create_chord_progression("Gm", ["i", "III", "VII", "v"])
- add_effect("vinyl_crackle", mix=0.3)

[Sonic Pi starts vibing with a mellow beat]

You: "Add some jazzy piano"

[AI layers in tasteful piano voicings, following the chord structure...]

That’s not just generative music. That’s collaboration.

Try It Yourself

Want to get weird with it? Here’s your on-ramp:

git clone https://github.com/TrippingKelsea/sonic-pi-mcp
cd sonic-pi-mcp
cargo build --release
./target/release/sonic-pi-mcp

Make sure you’ve got Sonic Pi installed
Point your AI assistant at the MCP server
Start jamming

What’s Next?

This is barely scratching the surface. Imagine:

AI jam sessions that evolve in real-time
A musical copilot that suggests reharmonizations
Ambient sound installations powered by GPT
Teaching kids music theory with code and conversation
Real-time backing for live musicians (stay tuned for the next post!)

Join the Experiment

This project lives at the messy, magical intersection of code, sound, and intelligence. It’s weird, it’s delightful, and it wants your brain on it.

Whether you’re a musician who dabbles in code, or a coder who dreams in 7ths and swing — you belong here.

For more information, check out: