CalvinBackup/fuzzforge_ai
1
0
Fork 0
mirror of https://github.com/FuzzingLabs/fuzzforge_ai.git synced 2026-02-12 22:32:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
fd21a5e7b1d551fcd96aa2ed625bbb8181e1f6b1
fuzzforge_ai/ai
History
Songbird99 a2c760ea2b Feature/litellm proxy (#27) 
* feat: seed governance config and responses routing

* Add env-configurable timeout for proxy providers

* Integrate LiteLLM OTEL collector and update docs

* Make .env.litellm optional for LiteLLM proxy

* Add LiteLLM proxy integration with model-agnostic virtual keys

Changes:
- Bootstrap generates 3 virtual keys with individual budgets (CLI: $100, Task-Agent: $25, Cognee: $50)
- Task-agent loads config at runtime via entrypoint script to wait for bootstrap completion
- All keys are model-agnostic by default (no LITELLM_DEFAULT_MODELS restrictions)
- Bootstrap handles database/env mismatch after docker prune by deleting stale aliases
- CLI and Cognee configured to use LiteLLM proxy with virtual keys
- Added comprehensive documentation in volumes/env/README.md

Technical details:
- task-agent entrypoint waits for keys in .env file before starting uvicorn
- Bootstrap creates/updates TASK_AGENT_API_KEY, COGNEE_API_KEY, and OPENAI_API_KEY
- Removed hardcoded API keys from docker-compose.yml
- All services route through http://localhost:10999 proxy

* Fix CLI not loading virtual keys from global .env

Project .env files with empty OPENAI_API_KEY values were overriding
the global virtual keys. Updated _load_env_file_if_exists to only
override with non-empty values.

* Fix agent executor not passing API key to LiteLLM

The agent was initializing LiteLlm without api_key or api_base,
causing authentication errors when using the LiteLLM proxy. Now
reads from OPENAI_API_KEY/LLM_API_KEY and LLM_ENDPOINT environment
variables and passes them to LiteLlm constructor.

* Auto-populate project .env with virtual key from global config

When running 'ff init', the command now checks for a global
volumes/env/.env file and automatically uses the OPENAI_API_KEY
virtual key if found. This ensures projects work with LiteLLM
proxy out of the box without manual key configuration.

* docs: Update README with LiteLLM configuration instructions

Add note about LITELLM_GEMINI_API_KEY configuration and clarify that OPENAI_API_KEY default value should not be changed as it's used for the LLM proxy.

* Refactor workflow parameters to use JSON Schema defaults

Consolidates parameter defaults into JSON Schema format, removing the separate default_parameters field. Adds extract_defaults_from_json_schema() helper to extract defaults from the standard schema structure. Updates LiteLLM proxy config to use LITELLM_OPENAI_API_KEY environment variable.

* Remove .env.example from task_agent

* Fix MDX syntax error in llm-proxy.md

* fix: apply default parameters from metadata.yaml automatically

Fixed TemporalManager.run_workflow() to correctly apply default parameter
values from workflow metadata.yaml files when parameters are not provided
by the caller.

Previous behavior:
- When workflow_params was empty {}, the condition
  `if workflow_params and 'parameters' in metadata` would fail
- Parameters would not be extracted from schema, resulting in workflows
  receiving only target_id with no other parameters

New behavior:
- Removed the `workflow_params and` requirement from the condition
- Now explicitly checks for defaults in parameter spec
- Applies defaults from metadata.yaml automatically when param not provided
- Workflows receive all parameters with proper fallback:
  provided value > metadata default > None

This makes metadata.yaml the single source of truth for parameter defaults,
removing the need for workflows to implement defensive default handling.

Affected workflows:
- llm_secret_detection (was failing with KeyError)
- All other workflows now benefit from automatic default application

Co-authored-by: tduhamel42 <tduhamel@fuzzinglabs.com>
2025-10-26 12:51:53 +01:00
..
agents/task_agent
Feature/litellm proxy (#27)
2025-10-26 12:51:53 +01:00
proxy
Feature/litellm proxy (#27)
2025-10-26 12:51:53 +01:00
src/fuzzforge_ai
Feature/litellm proxy (#27)
2025-10-26 12:51:53 +01:00
.gitignore
Initial commit
2025-09-29 21:26:41 +02:00
llm.txt
Initial commit
2025-09-29 21:26:41 +02:00
pyproject.toml
chore: Bump version to 0.7.0
2025-10-16 12:23:56 +02:00
README.md
feat: Complete Temporal migration cleanup and fixes
2025-10-14 15:02:52 +02:00

README.md

FuzzForge AI Module

FuzzForge AI is the multi-agent layer that lets you operate the FuzzForge security platform through natural language. It orchestrates local tooling, registered Agent-to-Agent (A2A) peers, and the Temporal-powered backend while keeping long-running context in memory and project knowledge graphs.

Quick Start

  1. Initialise a project 
    cd /path/to/project
fuzzforge init
  2. Review environment settings – copy .fuzzforge/.env.template to .fuzzforge/.env, then edit the values to match your provider. The template ships with commented defaults for OpenAI-style usage and placeholders for Cognee keys. 
    LLM_PROVIDER=openai
LITELLM_MODEL=gpt-5-mini
OPENAI_API_KEY=sk-your-key
FUZZFORGE_MCP_URL=http://localhost:8010/mcp
SESSION_PERSISTENCE=sqlite
    Optional flags you may want to enable early: 
    MEMORY_SERVICE=inmemory
AGENTOPS_API_KEY=sk-your-agentops-key   # Enable hosted tracing
LOG_LEVEL=INFO                          # CLI / server log level
  3. Populate the knowledge graph 
    fuzzforge ingest --path . --recursive
# alias: fuzzforge rag ingest --path . --recursive
  4. Launch the agent shell 
    fuzzforge ai agent
    Keep the backend running (Temporal API at FUZZFORGE_MCP_URL) so workflow commands succeed.

Everyday Workflow

  • Run fuzzforge ai agent and start with list available fuzzforge workflows or /memory status to confirm everything is wired.
  • Use natural prompts for automation (run fuzzforge workflow …, search project knowledge for …) and fall back to slash commands for precision (/recall, /sendfile).
  • Keep /memory datasets handy to see which Cognee datasets are available after each ingest.
  • Start the HTTP surface with python -m fuzzforge_ai when external agents need access to artifacts or graph queries. The CLI stays usable at the same time.
  • Refresh the knowledge graph regularly: fuzzforge ingest --path . --recursive --force keeps responses aligned with recent code changes.

What the Agent Can Do

  • Route requests – automatically selects the right local tool or remote agent using the A2A capability registry.
  • Run security workflows – list, submit, and monitor FuzzForge workflows via MCP wrappers.
  • Manage artifacts – create downloadable files for reports, code edits, and shared attachments.
  • Maintain context – stores session history, semantic recall, and Cognee project graphs.
  • Serve over HTTP – expose the same agent as an A2A server using python -m fuzzforge_ai.

Essential Commands

Inside fuzzforge ai agent you can mix slash commands and free-form prompts:

/list                     # Show registered A2A agents
/register http://:10201   # Add a remote agent
/artifacts                 # List generated files
/sendfile SecurityAgent src/report.md "Please review"
You> route_to SecurityAnalyzer: scan ./backend for secrets
You> run fuzzforge workflow static_analysis_scan on ./test_projects/demo
You> search project knowledge for "temporal status" using INSIGHTS

Artifacts created during the conversation are served from .fuzzforge/artifacts/ and exposed through the A2A HTTP API.

Memory & Knowledge

The module layers three storage systems:

  • Session persistence (SQLite or in-memory) for chat transcripts.
  • Semantic recall via the ADK memory service for fuzzy search.
  • Cognee graphs for project-wide knowledge built from ingestion runs.

Re-run ingestion after major code changes to keep graph answers relevant. If Cognee variables are not set, graph-specific tools automatically respond with a polite "not configured" message.

Sample Prompts

Use these to validate the setup once the agent shell is running:

  • list available fuzzforge workflows
  • run fuzzforge workflow static_analysis_scan on ./backend with target_branch=main
  • show findings for that run once it finishes
  • refresh the project knowledge graph for ./backend
  • search project knowledge for "temporal readiness" using INSIGHTS
  • /recall terraform secrets
  • /memory status
  • ROUTE_TO SecurityAnalyzer: audit infrastructure_vulnerable

Need More Detail?

Dive into the dedicated guides under ai/docs/advanced/:

  • Architecture – High-level architecture with diagrams and component breakdowns.
  • Ingestion – Command options, Cognee persistence, and prompt examples.
  • Configuration – LLM provider matrix, local model setup, and tracing options.
  • Prompts – Slash commands, workflow prompts, and routing tips.
  • A2A Services – HTTP endpoints, agent card, and collaboration flow.
  • Memory Persistence – Deep dive on memory storage, datasets, and how /memory status inspects them.

Development Notes

  • Entry point for the CLI: ai/src/fuzzforge_ai/cli.py
  • A2A HTTP server: ai/src/fuzzforge_ai/a2a_server.py
  • Tool routing & workflow glue: ai/src/fuzzforge_ai/agent_executor.py
  • Ingestion helpers: ai/src/fuzzforge_ai/ingest_utils.py

Install the module in editable mode (pip install -e ai) while iterating so CLI changes are picked up immediately.

Reference in New Issue View Git Blame Copy Permalink