Resources · Integration patterns
Guarded LLM provider adapter
Model access goes through an adapter with limits, output validation and a fallback.
Integration status: Available adapter
Available adapter: the AI advisor calls Anthropic when a key is configured; otherwise it runs on a local mock.
Description
Applications do not call the provider directly: the adapter applies a budget and limits, masks data, validates the output against a schema and returns a safe fallback on problems.
Prerequisites
- A provider key in a secrets store.
- A schema of the expected output.
- Fallback behaviour.
When to use it
- Every application that calls an AI model.
- The provider may change.
- Cost and data control.
When not to use it
- A one-off local experiment without data.
- When a feature the adapter lacks is needed — extend it rather than bypass it.
Reference diagram
An illustration of the components and the flow — not a running system.
01Application
- Request with a purpose
02Adapter
- Budget and limits
- Masking
- Output validation
03Provider
- Model
- Fallback answer
The diagram as a list
| Stage | Components |
|---|---|
| Application | Request with a purpose |
| Adapter | Budget and limits, Masking, Output validation |
| Provider | Model, Fallback answer |
Security controls
- The key is neither in the browser nor in code.
- Output is validated before use.
- Budget and request limits.
Observability
- Response time and errors.
- Tokens used.
- Share of fallback answers.
Failure modes
| Failure | Mitigation |
|---|---|
| Provider not responding | Fallback answer and a retry. |
| Invalid output | Refusal and a safe fallback. |
| Budget exceeded | Blocking and a notification. |