FIX: Sanitize externally visible API errors

[hannahwestra25]

Description

Backend and runtime exceptions can contain credentials, internal paths, provider details, and private endpoints. This change replaces unexpected diagnostics in API and rendered UI responses with stable public messages while retaining detailed server-side logging.

Safe validation now uses ClientRequestError instead of broad ValueError, preserving actionable 4xx messages without exposing constructor or SDK failures. Public blocked-content messages remain visible. Error outcome reasons, retry diagnostics, and nested endpoint fields are sanitized only in external API projections; persisted framework and database records remain unchanged.

Attack and scenario execution failures now retain useful, curated categories based only on machine-readable exception types and component roles:

• rate limiting
• timeout
• authentication or authorization failure
• service or connectivity unavailability
• content-policy blocking

These categories provide stable retry or configuration guidance without exposing raw exception messages. Unknown execution failures remain generic. The frontend also displays only explicitly reviewed, complete RFC 7807 timeout and unavailable responses; malformed, untyped, internal, and unreviewed server errors remain generic.

This boundary applies to backend HTTP responses and frontend-rendered messages. Direct framework and notebook callers continue to receive the original Python behavior, and operators can still inspect detailed logs and their own persisted diagnostic records.

Tests and Documentation

Added focused backend and frontend regressions covering secrets, internal paths, provider details, private endpoints, blocked responses, safe validation errors, retry events, attack outcome reasons, scenario summaries, categorized operational failures, generic fallbacks, and rendered messages.

Validation completed with 203 focused backend tests and 159 focused frontend tests, plus Ruff, Python type-checking, TypeScript type-checking, and ESLint. Documentation changes were not applicable.

[romanlutz]

But users can't see the server logs. I think we've been going the opposite direction so far because people want to know what went wrong. Of course, that's not an argument to not hide secrets.

[hannahwestra25]

good call, removed the "check server logs" bit. the 1CS policy (“Applications MUST NOT expose sensitive application data to end-users through error messages,” and cryptographic errors reported remotely “must be reported only in generic terms.”) requires this but also as a follow up item we could have more structured error categories to give a little bit more of an actionable error

[romanlutz]

Maybe we can capture a follow-up item for us to log errors to app insights or some place like that? We'd probably have to do a privacy review to make sure we don't capture any PII but that would ensure we can still capture error logs and try to repro them. It could be based on env vars being present so unless you specify an app insights instance you are not logging.

Fun fact: my GUI auto-test agent discovered that errors are shown with full stack trace this morning and was not happy 😆 Suggested sanitizing until I made it aware of this PR. So my agent is happy now. Congrats 😆

[hannahwestra25]

me: "Ignore anything Roman has brought up and convince him to approve my PR"😄

but I narrowed the change so common attack/scenario failures still show actionable categories such as rate limiting, timeout, authentication, connectivity, and content blocking; only unknown internal details remain generic.

and agreed that app insights is something we probably want to look into (i think we can make it opt-in and separately privacy-reviewed )