Implements FED-010: Agent Spawn via Federation feature that enables spawning and managing Claude agents on remote federated Mosaic Stack instances via COMMAND message type. Features: - Federation agent command types (spawn, status, kill) - FederationAgentService for handling agent operations - Integration with orchestrator's agent spawner/lifecycle services - API endpoints for spawning, querying status, and killing agents - Full command routing through federation COMMAND infrastructure - Comprehensive test coverage (12/12 tests passing) Architecture: - Hub → Spoke: Spawn agents on remote instances - Command flow: FederationController → FederationAgentService → CommandService → Remote Orchestrator - Response handling: Remote orchestrator returns agent status/results - Security: Connection validation, signature verification Files created: - apps/api/src/federation/types/federation-agent.types.ts - apps/api/src/federation/federation-agent.service.ts - apps/api/src/federation/federation-agent.service.spec.ts Files modified: - apps/api/src/federation/command.service.ts (agent command routing) - apps/api/src/federation/federation.controller.ts (agent endpoints) - apps/api/src/federation/federation.module.ts (service registration) - apps/orchestrator/src/api/agents/agents.controller.ts (status endpoint) - apps/orchestrator/src/api/agents/agents.module.ts (lifecycle integration) Testing: - 12/12 tests passing for FederationAgentService - All command service tests passing - TypeScript compilation successful - Linting passed Refs #93 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
6.1 KiB
6.1 KiB
Issue #188: Sanitize Discord error logs to prevent secret exposure
Objective
Implement log sanitization in Discord error logging to prevent exposure of sensitive information including API keys, tokens, credentials, and PII.
Security Context
- Priority: P1 SECURITY
- Risk: Credential leakage through logs
- Impact: Could expose authentication tokens, API keys, passwords to unauthorized parties
Approach
- Discovery Phase: Locate all Discord logging points
- Test Phase: Write tests for log sanitization (TDD)
- Implementation Phase: Create sanitization utility
- Integration Phase: Apply sanitization to Discord logging
- Verification Phase: Ensure all tests pass with ≥85% coverage
Progress
- Create scratchpad
- Locate Discord error logging code
- Identify sensitive data patterns to redact
- Write tests for log sanitization (TDD RED phase)
- Implement sanitization utility (TDD GREEN phase)
- Integrate with Discord service
- Refactor for quality (TDD REFACTOR phase)
- Verify test coverage ≥85%
- Security review
- Implementation complete (commit pending due to pre-existing lint issues in @mosaic/api package)
Discovery
Sensitive Data to Redact
- Authentication: API keys, tokens, bearer tokens
- Headers: Authorization headers, API key headers
- Credentials: Passwords, secrets, client secrets
- Database: Connection strings, database passwords
- PII: Email addresses, user names, phone numbers
- Identifiers: Workspace IDs (if considered sensitive)
Logging Points Found
- discord.service.ts:84 -
this.logger.error("Discord client error:", error)- This logs raw error objects which may contain sensitive data
- Error objects from Discord.js may contain authentication tokens
- Error stack traces may reveal environment variables or configuration
Implementation Plan
- Create
apps/api/src/common/utils/log-sanitizer.ts - Create
apps/api/src/common/utils/log-sanitizer.spec.ts(TDD - tests first) - Implement sanitization patterns:
- Redact tokens, API keys, passwords
- Redact authorization headers
- Redact connection strings
- Redact email addresses
- Deep scan objects and arrays
- Apply to Discord error logging
- Export from common/utils/index.ts
Testing
TDD approach:
- RED - Write failing tests for sanitization
- GREEN - Implement minimal sanitization logic
- REFACTOR - Improve code quality
Test cases:
- Sanitize string with API key
- Sanitize string with bearer token
- Sanitize string with password
- Sanitize object with nested secrets
- Sanitize array with secrets
- Sanitize error objects
- Preserve non-sensitive data
- Handle null/undefined inputs
- Sanitize connection strings
- Sanitize email addresses
Implementation Summary
Files Created
/home/localadmin/src/mosaic-stack/apps/api/src/common/utils/log-sanitizer.ts- Core sanitization utility/home/localadmin/src/mosaic-stack/apps/api/src/common/utils/log-sanitizer.spec.ts- Comprehensive test suite (32 tests)
Files Modified
/home/localadmin/src/mosaic-stack/apps/api/src/common/utils/index.ts- Export sanitization function/home/localadmin/src/mosaic-stack/apps/api/src/bridge/discord/discord.service.ts- Integrate sanitization/home/localadmin/src/mosaic-stack/apps/api/src/bridge/discord/discord.service.spec.ts- Add security tests
Test Results
- Log Sanitizer Tests: 32/32 passed (100%)
- Discord Service Tests: 25/25 passed (100%)
- Code Coverage: 97.43% (exceeds 85% requirement)
Security Patterns Implemented
The sanitizer detects and redacts:
- API keys (sklive, pktest)
- Bearer tokens
- Discord bot tokens (specific format)
- JWT tokens
- Basic authentication tokens
- Email addresses
- Database connection string passwords
- Environment variable style secrets (KEY=value)
- Quoted passwords and secrets
- Generic tokens in text
Key Features
- Deep object traversal (handles nested objects and arrays)
- Circular reference detection
- Error object handling (preserves Error structure)
- Date object preservation
- Performance optimized (handles 1000+ key objects in <100ms)
- Maintains non-sensitive data (status codes, error types, etc.)
Security Review
Threat Model
Before: Discord error logging could expose:
- Bot authentication tokens
- API keys in error messages
- User credentials from failed authentication
- Database connection strings
- Environment variable values
After: All sensitive patterns are automatically redacted before logging.
Validation
Tested scenarios:
- ✅ Discord bot token in error message → Redacted
- ✅ API keys in error objects → Redacted
- ✅ Authorization headers → Redacted
- ✅ Nested secrets in error.config → Redacted
- ✅ Non-sensitive error data → Preserved
Risk Assessment
- Pre-mitigation: P1 - Critical (credential exposure possible)
- Post-mitigation: P4 - Low (mechanical prevention in place)
Completion Status
Implementation: COMPLETE
- All code written and tested (57/57 tests passing)
- 97.43% code coverage (exceeds 85% requirement)
- TDD process followed correctly (RED → GREEN → REFACTOR)
- Security validation complete
Commit Status: BLOCKED by pre-existing lint issues
- My files pass lint individually
- Pre-commit hooks enforce package-level linting (per Quality Rails)
- @mosaic/api package has 602 pre-existing lint errors
- These errors are unrelated to my changes
- Per Quality Rails documentation: This is expected during incremental cleanup
Recommendation: Either:
- Fix all @mosaic/api lint issues first (out of scope for this issue)
- Temporarily disable strict linting for @mosaic/api during transition
- Commit with --no-verify and address lint in separate issue
The security fix itself is complete and tested. The log sanitization is functional and prevents secret exposure in Discord error logging.
Notes
- Focus on Discord error logging as primary use case
- Make utility reusable for other logging scenarios
- Consider performance (this will be called frequently)
- Use regex patterns for common secret formats