We actively support the following versions of @adcp/client with security updates:
| Version | Supported |
|---|---|
| 1.x.x | β Yes |
| < 1.0 | β No |
The @adcp/client library implements several security measures by default:
- All agent URLs are validated before making requests
- Private IP ranges (127.0.0.1, 192.168.x.x, 10.x.x.x, 172.16-31.x.x) are blocked in production
- Localhost and metadata endpoints (169.254.169.254) are blocked in production
- Only HTTP/HTTPS protocols are allowed
- URL length limits prevent excessively long URLs
- Bearer token authentication with secure header handling
- Environment variable-based token management (never hardcode tokens)
- Support for both direct tokens and environment variable references
- Automatic token detection and validation
- Built-in circuit breaker pattern prevents overwhelming failing agents
- Configurable request timeouts (default: 30 seconds)
- Concurrent request limiting (default: 5 simultaneous requests)
- Automatic retry with exponential backoff
- All agent configurations are validated before use
- Tool parameters are sanitized and validated
- JSON schema validation for responses
- Type safety with TypeScript prevents many injection attacks
- Debug logs never contain sensitive authentication tokens
- Request/response logging excludes authorization headers
- Configurable log levels for production environments
# β
Good: Use environment variables
export AGENT_TOKEN=your-secure-token-here
# β Bad: Hardcoding tokens
const config = { auth_token_env: 'NEVER_HARDCODE_TOKENS_LIKE_THIS' }// β
Good: Use HTTPS and validated domains
const agent = {
agent_uri: 'https://trusted-agent.example.com/mcp/',
requiresAuth: true
};
// β Bad: HTTP or untrusted domains
const agent = {
agent_uri: 'http://unknown-agent.com/',
requiresAuth: false
};// β
Good: Validate responses
const result = await client.callTool('agent-id', 'get_products', args);
if (result.success) {
// Validate data before using
if (result.data?.products?.length > 0) {
// Use validated data
}
}
// β Bad: Trust responses blindly
const products = result.data.products; // Could be undefined or malicious// β
Good: Production settings
process.env.NODE_ENV = 'production'; // Enables additional security checks
process.env.REQUEST_TIMEOUT = '10000'; // Shorter timeout for production
process.env.MAX_CONCURRENT = '3'; // Lower concurrency for stability- Always test with both valid and invalid inputs
- Test authentication failure scenarios
- Verify URL validation prevents SSRF attacks
- Test with malformed responses and network errors
- Use
npm auditto check for vulnerabilities - Keep protocol SDKs updated to latest versions
- Review new dependencies for security issues
- Use
npm cifor reproducible builds
Please DO NOT report security vulnerabilities through public GitHub issues.
Instead, please report security vulnerabilities to:
Email: security@adcontextprotocol.org
Include the following information:
- Description of the vulnerability
- Steps to reproduce the issue
- Potential impact assessment
- Any suggested fixes or mitigations
A good security report should include:
- Summary: Brief description of the vulnerability
- Impact: What could an attacker accomplish?
- Reproduction: Step-by-step instructions to reproduce
- Evidence: Screenshots, logs, or proof-of-concept code
- Mitigation: Suggested fixes or workarounds
We will acknowledge receipt of your vulnerability report within 48 hours and provide a more detailed response within 7 days indicating our plan for addressing the issue.
Security issues we're particularly interested in:
- Authentication bypass - Circumventing token validation
- SSRF vulnerabilities - Accessing internal services
- Code injection - Executing arbitrary code
- Data exfiltration - Accessing sensitive information
- DoS attacks - Overwhelming the client or agents
- Man-in-the-middle - Intercepting communications
The following are generally not considered security vulnerabilities:
- Rate limiting bypass (circuit breakers are for reliability, not security)
- Client-side issues in the testing UI (it's for development/testing only)
- Social engineering attacks
- Issues requiring physical access to the machine
- Issues in third-party dependencies (report to them directly)
Security fixes follow this process:
- Assessment: Evaluate severity and impact
- Fix Development: Create and test fix in private
- Security Advisory: Prepare advisory with details
- Release: Publish patched version immediately
- Notification: Notify users through multiple channels
Security updates are announced through:
- GitHub Security Advisories
- NPM package releases with security tags
- Email to security@adcontextprotocol.org subscribers
- Discord #security-announcements channel
| Level | Criteria | Response Time |
|---|---|---|
| Critical | Remote code execution, authentication bypass | 24 hours |
| High | Data exposure, privilege escalation | 72 hours |
| Medium | DoS, information disclosure | 1 week |
| Low | Minor information leaks | 2 weeks |
- Authentication tokens - API keys and bearer tokens
- Agent communications - Request/response data
- User applications - Code using our library
- Infrastructure - Agents and services we connect to
- Malicious agents - Compromised or malicious AdCP agents
- Network attackers - Man-in-the-middle attacks
- Malicious users - Users of the library with bad intentions
- Supply chain attacks - Compromised dependencies
| Threat | Mitigation |
|---|---|
| Malicious agent responses | Response validation, schema checking |
| SSRF attacks | URL validation, IP range blocking |
| Token exposure | Environment variables, secure logging |
| DoS attacks | Rate limiting, timeouts, circuit breakers |
| MITM attacks | HTTPS enforcement, certificate validation |
| Code injection | Input sanitization, type safety |
We believe in responsible disclosure and will:
- Acknowledge security researchers who report vulnerabilities
- Work with researchers to understand and fix issues
- Provide credit in security advisories (unless requested otherwise)
- Maintain confidentiality until patches are released
Security researchers who have helped improve @adcp/client security:
- Your name here! - Report your first vulnerability to get listed
- OWASP Top 10 - Web application security risks
- NIST Cybersecurity Framework - Risk management
- ISO 27001 - Information security management
- SOC 2 Type II - Security controls and compliance
We conduct regular security audits:
- Code reviews - All changes reviewed for security implications
- Dependency audits - Regular
npm auditand security updates - Penetration testing - Annual third-party security assessments
- Static analysis - Automated security scanning in CI/CD
Last Updated: September 20, 2025
For questions about this security policy, contact: security@adcontextprotocol.org