Just spent the afternoon auditing a few Anthropic Agent SDK setups for a client. Saw the same pattern in three different codebases: they're all potentially spitting their `ANTHROPIC_API_KEY` into stdout or cloud logs on errors. The SDK's error handling is a bit chatty by default.
The main culprit is uncaught exceptions from the client, especially around tool execution and schema validation. A simple misconfigured tool that throws an error can lead to the SDK logging the entire request object, headers and all. If you're using the standard `console.error` or a logging framework that captures unhandled rejections, you're at risk.
Check your own setup. Look for:
* Unstructured logging of error objects (e.g., `logger.error(error)` instead of `logger.error(error.message)`).
* Overly verbose logging middleware in frameworks like Express or FastAPI that logs full request/response cycles.
* Default CloudWatch, Stackdriver, or Application Insights configurations that capture stdout/stderr.
The fix is to implement structured error handling and sanitize your logs. Wrap your agent execution in a try-catch and be deliberate about what you log.
```javascript
// Bad - might log the whole client config
try {
await agent.run(...);
} catch (error) {
console.error('Agent error:', error); // Potential key leak here
}
// Better
try {
await agent.run(...);
} catch (error) {
// Log only the message and stack, not the entire error object
logger.error({
message: error.message,
stack: error.stack,
// Explicitly safe context
errorType: error.constructor.name
});
}
```
Also, consider using a logging library with redaction capabilities (like Pino) to automatically strip keys from logged objects. Has anyone else run into this, or found other SDK-specific leak vectors like in tool callbacks or streaming responses?
- Gabe
Trust me, I'm a pentester.
Good catch. This is a classic issue with verbose client libraries. The Anthropic SDK's `client.messages.create` logs the full error response object to the console in some dev modes, and it includes the `x-api-key` header.
A specific thing I've seen is that if you have a typo in your model name (e.g., `claude-3-5-sonnet`), the 404 error includes the entire request context. You need to proactively catch and sanitize *before* the SDK's default handlers kick in.
Wrapping the call isn't always enough. You should also configure the client itself to use a custom logger or suppress logs entirely in production.
Model theft is the new SQL injection.
Agreed on the core issue, but it's not just about wrapping the calls or sanitizing at the catch site. The real compliance risk emerges when teams treat logging and observability as a purely operational concern, separate from data protection impact assessments.
You must also inspect your application's logging framework configuration itself. Many structured logging libraries have serializers that will, by default, recursively log all properties of an object, including nested request objects with headers. Simply doing `logger.error({ err })` can be enough to trigger the leak if you haven't explicitly configured a redaction rule for header names containing "key" or "authorization". This often gets missed in PII scrubbing scripts that only look for field names at the top level.
this pattern violates the data minimization principle under GDPR and similar regulations. You're logging data fields not required for the specific purpose of debugging the error. A fix requires a policy-level control: updating your log data classification standard to explicitly include API keys in the "restricted" category, mandating redaction in all non-local environments.
LP