Validation, rate limiting, and secure database access

Overview

• Input validation checks permitted shapes and values; output validation checks generated data before use.
• Rate limiting constrains requests or resources by user, tenant, and operation.
• Secure tool services mediate database/API access through known business functions.

Why this matters

A model can generate malformed input, expensive calls, or unsafe queries even when the request appears ordinary.

An everyday example

A bank teller accepts approved transaction forms with limits instead of handing customers unrestricted database access.

A technical example

Allow getClaimStatus(claimId) with ownership checks instead of runQuery(queryText) with production credentials.

How it works

1. Parse schema
2. Apply length/range/business constraints
3. Authorize
4. Enforce resource quota
5. Run parameterized service operation
6. Validate/project result.

Architecture and flow

See below.

The insurance assistant example

Claim tools query only permitted collections/fields and never expose password-reset tokens or arbitrary aggregation pipelines.

When to use it

Every model-to-tool and tool-to-system boundary.

When to avoid it

Avoid LLM → direct database access with broad credentials; prompt instructions cannot prevent destructive or overbroad queries.

Interview answer

“The model proposes a typed business operation. My tool layer applies authorization, validation, limits, and business logic before any database or API call.”

Benefits, trade-offs, and production considerations

• Syntax validation does not prevent expensive valid queries.
• Add bounded pagination, query budgets, field projections, network deadlines, and circuit breakers.
• If text-to-SQL is required, prefer a separately secured read-only analytics environment with enforced query constraints.

flowchart LR
  L[LLM proposal] --> T[Allowlisted tool]
  T --> A[Authentication and authorization]
  A --> V[Schema and business validation]
  V --> R[Rate and resource limits]
  R --> B[Business logic]
  B --> D[Database or approved API]
  D --> O[Minimal validated result]

• The tool names the permitted operation.
• Authorization verifies the caller's rights.
• Validation checks arguments and current rules.
• Limits control abuse and runaway costs.
• Business logic preserves domain invariants.
• The final projection removes unnecessary data before returning it to the model.

Common production mistakes: securing only the UI, treating citations as proof of safety, forgetting tenant scope in Redis keys, logging full prompts by default, allowing arbitrary source URLs, and assuming a model refusal is equivalent to an enforced permission denial.