aitbc/docs/security/remediation-plan.md

Security Remediation Plan

This document provides a prioritized action plan for addressing security findings identified during the AITBC security audit.

Executive Summary

The security audit identified 20 security findings across the following categories:

• Critical: 3 findings
• High: 10 findings
• Medium: 7 findings

Remediation Status (Updated 2026-05-11)

Completed (8 findings)

• Critical (3): All resolved

  • Missing ECDSA verification in receipt.circom - Mitigated (moved to API layer)
  • Mock ZK proof verification in zk_proofs.py - Resolved (actual Groth16 implemented)
  • Unlimited token minting in AIToken.sol - Resolved (supply cap + cooldown added)

• High (5): 5 resolved, 5 deferred

  • Incorrect learning rate constraint - Resolved
  • Incorrect verification logic - Resolved
  • Empty learning rate validation - Resolved
  • Mock ZK proof generation - Mitigated (disabled by default)
  • Weak proof validation - Mitigated (disabled by default)
  • Missing input validation - Mitigated (disabled by default)
  • Weak commitment scheme - Documented
  • Demo implementations - Resolved (disabled by default)
  • Smart contract economic security (5 findings) - Deferred to dedicated sprint

• Medium (0): 0 resolved, 7 deferred

  • All Medium findings require smart contract upgrades - Deferred

Deferred to Dedicated Smart Contract Security Sprint (8 findings)

Rationale: All smart contract fixes require:

• Extensive contract development and testing
• Migration strategy for existing deployments
• Security review of new contract logic
• Potential contract upgrades requiring governance approval

Deferred findings:

• Phase 2 High (5): Slashing mechanism, oracle protection, AMM security
• Phase 3 Medium (3): Escrow security, voting thresholds, rate limiting

The findings span:

• Circom circuits (5 findings)
• ZK proof implementation (6 findings)
• Smart contracts (9 findings)

Priority Matrix

Immediate (Critical - Fix Within 1 Week)

Finding	Component	Risk	Effort
Missing ECDSA Verification Implementation	receipt.circom	Complete security compromise	Medium
Mock ZK Proof Verification in Production Code	zk_proofs.py	Complete security compromise	Low
Unlimited Minting Capability in AIToken	AIToken.sol	Hyperinflation, rug pull	Low

Total Effort Estimate: 2-3 days

High Priority (High Severity - Fix Within 2 Weeks)

Finding	Component	Risk	Effort
Incorrect Learning Rate Constraint	ml_training_verification.circom	Circuit non-functional	Low
Incorrect Verification Logic	ml_inference_verification.circom	False positives	Low
Mock ZK Proof Generation	zk_memory_verification.py	No security guarantees	Medium
Weak Proof Validation	zk_applications.py	Bypass membership checks	Low
Missing Input Validation	zk_proofs.py	Circuit failures, injection	Medium
No Slashing Mechanism	AgentStaking.sol	Economic manipulation	High
Lack of Oracle Manipulation Protection	AgentStaking.sol	Performance manipulation	Medium
AMM Vulnerable to Flash Loan Attacks	AIServiceAMM.sol	Liquidity drain	High
No Front-Running Protection	AIServiceAMM.sol	MEV extraction	Medium
Emergency Withdraw Without Timelock	AIServiceAMM.sol	Rug pull risk	Low

Total Effort Estimate: 1-2 weeks

Medium Priority (Medium Severity - Fix Within 1 Month)

Finding	Component	Risk	Effort
Empty Learning Rate Validation	modular_ml_components.circom	Invalid learning rates	Low
Missing Input Validation	receipt.circom	Invalid timestamps/rates	Low
Weak Commitment Scheme	zk_applications.py	Privacy weak	Medium
Demo Implementation in Production	zk_applications.py	Misleading security	Low
Oracle Single Point of Failure	EscrowService.sol	Oracle compromise	Medium
No Minimum Voting Threshold	EscrowService.sol	Arbiter collusion	Low
No Rate Limiting	AgentStaking.sol	Spam attacks	Low

Total Effort Estimate: 1-2 weeks

Detailed Remediation Plan

Phase 1: Critical Fixes (Week 1)

1.1 Fix Missing ECDSA Verification in receipt.circom

File: apps/zk-circuits/receipt.circom

Action:

• Remove placeholder ECDSA verification
• Implement proper EdDSA verification using circomlib circuits
• Add proper public key and signature validation
• Test with real signatures

Owner: Smart Contract Team Deadline: Day 3 Acceptance Criteria:

• ECDSA verification uses circomlib circuits
• Proof verification passes with valid signatures
• Proof verification fails with invalid signatures
• Unit tests added

1.2 Fix Mock ZK Proof Verification in zk_proofs.py

File: apps/coordinator-api/src/app/services/zk_proofs.py

Action:

• Remove mock verification in verify_proof method (lines 125-134)
• Use the actual verification logic from lines 339-389
• Ensure verification key is properly loaded
• Add proper error handling

Owner: Backend Team Deadline: Day 2 Acceptance Criteria:

• Mock verification removed
• Actual Groth16 verification implemented
• Verification fails on invalid proofs
• Unit tests added

1.3 Fix Unlimited Minting in AIToken.sol

File: contracts/contracts/AIToken.sol

Action:

• Add hard cap on total supply (e.g., 1 billion tokens)
• Add time lock on minting (e.g., 24 hours)
• Consider governance approval for minting
• Add transparency events

Owner: Smart Contract Team Deadline: Day 5 Acceptance Criteria:

• Total supply cap implemented
• Time lock on minting added
• Governance integration (if applicable)
• Smart contract tests added

Phase 2: High Priority Fixes (Weeks 2-3)

2.1 Fix Circom Circuit Constraints

Files:

• apps/zk-circuits/ml_training_verification.circom
• apps/zk-circuits/ml_inference_verification.circom
• apps/zk-circuits/modular_ml_components.circom

Action:

• Replace incorrect learning rate constraint with proper range validation
• Replace incorrect verification logic with proper comparison circuits
• Re-implement learning rate validation with efficient circuits
• Add missing input validation in receipt circuit

Owner: ZK Research Team Deadline: Week 2 Acceptance Criteria:

• All constraints mathematically correct
• Test vectors pass
• Circuit compilation succeeds
• Constraint count reasonable

2.2 Fix ZK Proof Implementation Security

Files:

• apps/coordinator-api/src/app/services/zk_memory_verification.py
• apps/coordinator-api/src/app/routers/zk_applications.py
• apps/coordinator-api/src/app/services/zk_proofs.py

Action:

• Replace mock proof generation with actual ZK proofs
• Implement proper proof validation (not just length checks)
• Add input validation for all proof generation functions
• Disable or properly implement demo endpoints

Owner: Backend Team Deadline: Week 2 Acceptance Criteria:

• No mock implementations in production code
• Proof validation uses cryptographic verification
• Input validation schemas defined
• Demo endpoints clearly marked or removed

2.3 Fix Smart Contract Economic Security

Files:

• contracts/contracts/AgentStaking.sol
• contracts/contracts/AIServiceAMM.sol

Action:

• Implement slashing mechanism in AgentStaking
• Add oracle authorization for performance updates
• Add TWAP protection to AMM
• Implement commit-reveal or batch auction for swaps
• Add time lock to emergency withdraw

Owner: Smart Contract Team Deadline: Week 3 Acceptance Criteria:

• Slashing mechanism functional
• Oracle manipulation prevented
• Flash loan protection in place
• Front-running mitigation implemented
• Emergency withdraw has time lock

Phase 3: Medium Priority Fixes (Week 4)

3.1 Enhance Escrow Security

File: contracts/contracts/EscrowService.sol

Action:

• Implement multi-oracle verification with threshold
• Add percentage-based voting threshold
• Implement arbiter staking to prevent sybil attacks
• Add time delay after oracle verification

Owner: Smart Contract Team Deadline: Week 4 Acceptance Criteria:

• Multi-oracle verification implemented
• Voting threshold percentage-based
• Arbiter staking mechanism in place
• Time delays added

3.2 Add Rate Limiting and Enhanced Commitments

Files:

• contracts/contracts/AgentStaking.sol
• apps/coordinator-api/src/app/routers/zk_applications.py

Action:

• Add rate limiting to staking operations
• Implement Pedersen commitments for identity
• Add minimum stake amounts and maximum stakes per user
• Add cooldown periods

Owner: Smart Contract Team + Backend Team Deadline: Week 4 Acceptance Criteria:

• Rate limiting functional
• Pedersen commitments implemented
• Stake limits enforced
• Cooldown periods working

Testing Strategy

Unit Testing

• All circuit fixes must have test vectors
• All smart contract changes need comprehensive unit tests
• All API changes need unit tests with mock data

Integration Testing

• Test ZK proof generation and verification end-to-end
• Test smart contract interactions with local blockchain
• Test escrow flows with multi-oracle verification

Security Testing

• Run enhanced security scanning workflow on all changes
• Perform manual code review for all critical changes
• Consider third-party audit for smart contracts

Regression Testing

• Run existing test suite after each fix
• Ensure no breaking changes to existing functionality
• Monitor for performance degradation

Deployment Strategy

Deployment Order

1. Deploy circuit fixes (no breaking changes)
2. Deploy API fixes (can be rolled back)
3. Deploy smart contract upgrades (require careful testing)

Rollback Plan

• Maintain previous versions of all components
• Document rollback procedures
• Test rollback process before deployment

Monitoring

• Add monitoring for ZK proof verification failures
• Monitor smart contract events for unusual activity
• Set up alerts for security-related metrics

Success Metrics

Quantitative

• All Critical findings resolved within 1 week
• All High findings resolved within 2 weeks
• All Medium findings resolved within 1 month
• Security scanning workflow passes on all changes
• Zero critical vulnerabilities in production

Qualitative

• Third-party audit (if pursued) passes
• Team confidence in security posture improved
• Documentation updated with security best practices
• Security review process integrated into development workflow

Ongoing Security Practices

Development

• Security review required for all circuit changes
• Security review required for all smart contract changes
• Code review checklist includes security items
• Security testing in CI/CD for all changes

Operations

• Regular security scanning (weekly)
• Dependency updates monitored
• Security alerts monitored and responded to
• Incident response plan maintained

Governance

• Security findings tracked in project management
• Regular security reviews with stakeholders
• Security budget allocated for tools and audits
• Security training for development team

Related Documents

• Security Audit Findings
• Threat Model
• Economic Analysis
• Security Architecture
• Security Best Practices

Appendix: Finding Summary

by Severity

• Critical: 3
• High: 10
• Medium: 7

by Component

• Circom circuits: 5
• ZK proof implementation: 6
• Smart contracts: 9

by Effort Estimate

• Low (< 1 day): 8
• Medium (1-3 days): 8
• High (> 3 days): 4

Total Effort

• Estimated: 3-4 weeks
• Team size: 3-4 developers
• Recommended: Dedicated security sprint