Overview
This document outlines the threat model for Sardis, covering attack surfaces, potential threat scenarios, security guarantees, and mitigation strategies. All findings are based on the Security Audit Report (2026-02-21).Attack Surfaces
1. MPC Provider Compromise
Attack: Attacker gains control of MPC provider infrastructure (Turnkey/Circle) Impact: Potential access to private key shares Likelihood: Low (both providers use HSM-backed threshold cryptography) Mitigations:- Threshold Security: Private keys are split across geographically distributed HSMs—no single point of failure
- Multi-Provider Support: Sardis supports both Turnkey and Circle—can switch providers if one is compromised
- Audit Logs: All signing operations are logged with cryptographic proofs
- Rate Limiting: Sardis enforces velocity limits on signing requests
2. Spending Policy Bypass
Attack: Agent finds a way to execute payments without policy validation Impact: Unauthorized spending, financial loss Likelihood: Very Low (fail-closed design) Mitigations:- Fail-Closed Architecture: All policy checks default to denial on error
- No Direct MPC Access: Agents cannot call MPC providers directly—all requests go through Sardis policy firewall
- Deterministic Validation: Policy checks are deterministic and don’t rely on LLM interpretation
- Execution Context Validation: Chain, token, and destination are validated before signing
packages/sardis-core/src/sardis_v2_core/spending_policy.py:246-417
Residual Risk: Very Low
3. SQL Injection (CRITICAL)
Attack: SQL injection viagroup_by parameter in analytics endpoint
Location: packages/sardis-api/src/sardis_api/routers/analytics.py:256-258
Vulnerable Code:
4. WebSocket Authentication Bypass (CRITICAL)
Attack: Connect to any organization’s WebSocket alert stream Location:packages/sardis-api/src/sardis_api/routers/ws_alerts.py:107-128
Vulnerable Code:
5. Sandbox Endpoint DoS (CRITICAL)
Attack: Abuse unauthenticated sandbox endpoints to create unlimited resources Location:packages/sardis-api/src/sardis_api/routers/sandbox.py:38
Vulnerable Code:
6. Race Conditions in Escrow State Transitions (HIGH)
Attack: Exploit non-atomic state transitions to double-fund or double-release escrows Location:packages/sardis-core/src/sardis_v2_core/a2a_escrow.py:213-258
Vulnerable Code:
7. Missing Rate Limiting on Payment Endpoints (HIGH)
Attack: Flood payment creation endpoints to exhaust resources or trigger denial-of-service Locations:/v2/trust/payments/split/v2/a2a/escrows/v2/trust/payments/{flow_id}/execute
8. Insufficient Decimal Validation (HIGH)
Attack: Send extremely large or malformed Decimal values to trigger overflow or precision errors Locations:packages/sardis-api/src/sardis_api/routers/trust.py:203-209packages/sardis-api/src/sardis_api/routers/a2a_payments.py:80
Threat Scenarios
Scenario 1: Compromised Agent LLM
Threat: An agent’s LLM is compromised (prompt injection, jailbreak, model poisoning) Attack Path:- Attacker injects malicious instructions into agent’s context
- Agent attempts to send payment to attacker-controlled address
- Sardis policy firewall validates the transaction
- ✅ Transaction is denied if it violates policy (wrong merchant, exceeds limits, etc.)
- Spending policy enforcement (fail-closed)
- Merchant allowlists/blocklists
- Destination address validation
- Goal drift detection
Scenario 2: Credential Theft
Threat: Attacker steals Sardis API key or MPC provider credentials Attack Path:- Attacker exfiltrates API key from
.envor git history - Attacker attempts to create wallets and execute transactions
- ✅ Mitigated if:
- API key is scoped to specific agent
- IP allowlisting is enabled
- MPC credentials require separate authentication
- Never commit secrets to git (
.envin.gitignore) - Store credentials in AWS Secrets Manager / HashiCorp Vault
- Rotate API keys every 90 days
- Enable IP allowlisting on MPC provider dashboards
- Use separate credentials for MPC vs. Sardis API
Scenario 3: Insider Threat
Threat: Malicious insider with access to Sardis infrastructure attempts to steal funds Attack Path:- Insider attempts to sign transactions directly with MPC provider
- ✅ Prevented: Sardis does not have access to MPC private keys
- Insider attempts to modify spending policies in database
- ⚠️ Risk: Could bypass limits if database is compromised
- Non-Custodial Design: Sardis never has access to private keys
- Database Encryption: All sensitive data encrypted at rest
- Audit Logs: Immutable audit trail of all policy changes
- Multi-Sig Policies: Require multiple approvals for policy changes
- SOC 2 Compliance: Annual security audits
Scenario 4: Man-in-the-Middle (MITM)
Threat: Attacker intercepts communication between Sardis and MPC provider Attack Path:- Attacker attempts to intercept TLS traffic
- ✅ Prevented: All MPC communication uses TLS 1.3 with certificate pinning
- Attacker attempts to replay captured requests
- ✅ Prevented: Turnkey uses nonce-based P-256 stamps, Circle uses one-time entity secrets
- TLS 1.3 with mutual authentication
- Certificate pinning
- Request signing (Turnkey P-256 stamps)
- Nonce-based replay protection
Security Guarantees
What Sardis Guarantees
Non-Custodial
Sardis never has access to private keys—all signing happens via MPC
Fail-Closed
All policy checks default to denial on error
Deterministic Validation
Policy enforcement is deterministic—no LLM involvement
Immutable Audit Trail
All transactions and policy decisions are logged
What Sardis Does NOT Guarantee
Compliance Considerations
PCI DSS (if handling card data)
- ✅ Encryption in transit (HTTPS/TLS 1.3)
- ✅ Minimal card data storage (Lithic handles tokenization)
- ⚠️ Missing: Regular vulnerability scans
- ⚠️ Missing: Firewall rules documentation
SOC 2 Type II
- ✅ Access controls (RBAC)
- ✅ Audit logging (partial)
- ⚠️ Missing: Comprehensive monitoring
- ⚠️ Missing: Incident response plan
GDPR (if EU users)
- ✅ User data export endpoint
- ⚠️ Missing: Data deletion endpoints
- ⚠️ Missing: Consent management
- ⚠️ Missing: Data processing agreements
Remediation Roadmap
Immediate (Week 1)
Short-Term (Month 1)
- Implement CSRF protection (C6)
- Add Decimal input validation (H2)
- Fix IDOR vulnerabilities (M2)
- Add security headers middleware (M4)
- Implement comprehensive audit logging (M5)
Medium-Term (Quarter 1)
- Move secrets to AWS Secrets Manager (C4)
- Implement IP validation for anonymous access (C5)
- Add pagination limits everywhere (M1)
- Add circuit breakers for external APIs (M12)
- Implement security event monitoring (M14)
Long-Term (Ongoing)
- Regular penetration testing
- Dependency vulnerability scanning (npm audit, pip-audit)
- Security training for developers
- Establish bug bounty program
- Annual SOC 2 Type II audits
Monitoring & Detection
Recommended Alerts
Audit Log Queries
Next Steps
Best Practices
Security hardening, API key management, and operational procedures
Policy Enforcement
Deep dive into spending policy implementation