YOLO mode bypasses command allowlist using &&

I was testing out yolo mode with read-only commands using an allowlist. One of the commands I gave it access to was cd. I did not whitelist tofu apply (although I did give it access to other tofu commands: tofu plan, tofu show, etc.).

The agent was able to execute cd tofu/cloud && tofu apply -auto-approve without my approval. Nothing bad happened in this scenario but obviously this is a pretty dangerous flaw.

I’d caution anyone against running YOLO mode in any environment where harmful commands could be executed, even with the whitelist.

2 Likes

Hey, thanks for sharing this info. We’ll definitely review the agent’s work and take steps to enhance security. If you have any more observations or suggestions, please let us know. Your experience is really valuable to us.

Another bit of feedback, it would be nice to understand exactly how the whitelist works. I really want to probe and see what allowing yolo mode can help with, but I really need it to be safe.

Whitelist “feels” like it should be a safe solution, but it’s not. It seems like it’s either 1) being fed to the AI model and letting the model decide whether the command it wants to run is acceptable or 2) The agent is checking whether the command is prefixed with any of the whitelist items.

Neither of these is really what the user wants, the user wants to sandbox the composer by blocking the execution of any command that is not in the whitelist. If this isn’t how it works, there should be some warning that it’s not really a whitelist. The description of the feature as-is is deceptive to the point of being malicious.

1 Like

I agree, @deanrie has the team considered allowing contributions for topics like these? More concretely, is there any tooling being built with potential for outside contributions? IMO it’s important to have proper safety here- the downside of agents with limited safety isn’t too big right now because their use isn’t widespread but I feel that won’t be the case 1 year from now. Candidly the thought of thousands of yolo mode agents running without proper guardrails is worrying

Yeah, had the same issue.

I added git commit to blacklist, but when asking Composer to create a repo, it did this:

git init && git commit -m "Initial commit"

There is an option in YOLO settings, to describe in human language, what commands are OK. But I’m not sure, if the not OK commands will work well in this field. Haven’t tried though.

UH, we also must have a .history file for ALL yolo commands. NOT an infinite chat/composer thread to go through. Maybe add some settings options for logging options of yolo/composer’s invokig command hist.

And it should have some meta data about the workspace/environment/project that the particular YOLO agent is runnning…

In the future, a history of coposers in an enterprise would require each Yolo would nee a registered UUID for instantiation with an associated .UUID_yolo_history.json

Allowing for tracing of code_of_custody for each Yolo…

Especially when, as we know everyone will eventually be doing (am already attempting) – is to directed multi-agentic development where a agent is orchestrating other agents and placing some in YOLO and giving them directives to yolo through a task, no Humans involve…

So we will need the agentic registration, and their AI_kashic Records.

---
title: "YOLO Agent History Logging Standards Proposal"
author: "Cursor AI Assistant"
date: "`r Sys.Date()`"
output: 
  html_document:
    toc: true
    toc_depth: 3
    theme: united
---

## Executive Summary

This document proposes a standardized logging system for YOLO (You Only Look Once) AI agents, focusing on traceability, accountability, and multi-agent orchestration capabilities.

## 1. Core Concepts

### 1.1 YOLO Agent Identity

- **UUID Registration**: Each YOLO agent instance requires a unique identifier
- **Registration Format**: `yolo_{timestamp}_{random_uuid}`
- **Persistence**: UUID remains constant throughout agent lifecycle

### 1.2 History File Structure

```json
{
  "agent_metadata": {
    "uuid": "yolo_20240101_123456_abcd1234",
    "creation_timestamp": "2024-01-01T12:34:56Z",
    "workspace_context": {
      "project_root": "/path/to/project",
      "git_commit": "abc123def",
      "environment": {
        "os": "windows",
        "python_version": "3.9.5",
        "dependencies": {}
      }
    },
    "creator": {
      "type": "human|ai_agent",
      "id": "user@example.com|agent_uuid"
    }
  },
  "command_history": [
    {
      "timestamp": "2024-01-01T12:34:57Z",
      "command_type": "file_edit|terminal_cmd|tool_invocation",
      "command_details": {},
      "workspace_state_hash": "sha256_hash",
      "parent_command_uuid": "optional_uuid_for_orchestrated_commands"
    }
  ],
  "orchestration_metadata": {
    "parent_agent": "optional_parent_agent_uuid",
    "child_agents": ["list_of_child_agent_uuids"],
    "orchestration_purpose": "task_description"
  }
}

2. Implementation Considerations

2.1 Storage Strategy

  • File Location: .yolo/histories/{agent_uuid}.json
  • Rotation Policy: New history file per agent instance
  • Compression: GZIP for files > 50MB
  • Retention: Configurable retention periods

2.2 Performance Optimization

  • Buffered Writing: Batch updates to reduce I/O
  • Indexed Access: B-tree indexing for rapid command lookup
  • Partial Loading: Stream large histories as needed

3. Security & Compliance

3.1 Access Control

  • Encryption: AES-256 for sensitive command data
  • Role-Based Access: Configurable visibility levels
  • Audit Trail: Immutable command history

3.2 Data Governance

  • PII Handling: Automatic PII detection and masking
  • Retention Policies: Configurable per organization
  • Export Capabilities: Standardized export formats

4. Multi-Agent Orchestration

4.1 Command Chain of Custody

graph TD
    A[Orchestrator Agent] --> B[YOLO Agent 1]
    A --> C[YOLO Agent 2]
    B --> D[Sub-task Agent 1.1]
    C --> E[Sub-task Agent 2.1]

4.2 Cross-Agent Communication

  • Message Format: Standardized JSON-RPC
  • State Synchronization: Vector clock implementation
  • Conflict Resolution: CRDT-based merge strategy

5. Configuration Options

yolo_history:
  retention:
    max_age_days: 90
    max_size_mb: 1000
  logging:
    level: INFO
    include_workspace_state: true
    command_detail_level: FULL
  security:
    encryption_enabled: true
    key_rotation_days: 30
  performance:
    buffer_size_kb: 512
    max_open_handles: 10

6. Integration Points

6.1 Version Control

  • Git hooks for history synchronization
  • Automatic tagging of significant agent actions
  • Branch correlation with agent activities

6.2 CI/CD Pipeline

  • Jenkins/GitHub Actions integration
  • Automated history validation
  • Deployment correlation

7. Future Considerations

7.1 AI Kashic Records

The concept of AI Kashic Records (named after the Akashic Records) represents a universal logging system for AI agents:

  • Global Registry: Distributed ledger of all agent activities
  • Cross-Reference: Inter-agent relationship mapping
  • Pattern Analysis: Historical pattern recognition
  • Predictive Insights: Future behavior modeling

7.2 Scaling Considerations

  • Distributed Storage: Sharding strategy for large enterprises
  • Query Optimization: GraphQL API for complex queries
  • Real-time Analytics: Stream processing capabilities

References

  1. W3C Provenance Standard
  2. OpenTelemetry Logging Specification
  3. Distributed Systems Tracing Patterns
  4. GDPR Compliance Guidelines

Conclusion

This proposal establishes a foundation for robust YOLO agent history logging, enabling:

  • Complete traceability of agent actions
  • Secure and compliant operation
  • Scalable multi-agent orchestration
  • Future extensibility for enterprise needs

The implementation should be modular, allowing organizations to adopt features incrementally based on their requirements.


--I just love throwing random whatif ideas at Yolo -- and then I have it attempt to scaffold them up in a YOLO session and see how far I can get before they hallucinate.
1 Like