Authentication, authorization, least privilege, and tenant isolation

Overview

• Authentication verifies identity.
• Authorization decides allowed objects and actions.
• Least privilege grants only required capabilities; tenant isolation keeps one organization's data and operations separated from others.

Why this matters

An agent can propose an identifier it should not access, accidentally or through attack.

An everyday example

A hotel guest can access their room, not every room with a similar number.

A technical example

Query by both server-derived tenantId and claimId, then verify customer ownership and action rights.

How it works

1. Verify session/token
2. Derive principal
3. Authorize tool and object
4. Apply tenant filters
5. Execute
6. Audit identity and outcome.

Architecture and flow

Verified principal → permission checks → tenant-scoped service → data.

The insurance assistant example

Changing C42 to C43 in chat must not expose another customer's claim.

When to use it

All private retrieval, tools, memory, caches, approval/resume endpoints, and downloads.

When to avoid it

Do not let a prompt, model output, or client-supplied tenant field determine access.

Interview answer

“Tenant and object permissions are enforced by services using verified identity. The model never decides who is authorized.”

Benefits, trade-offs, and production considerations

• Recheck access after permission changes, cache invalidation, and approval waits.
• Test cross-tenant access through vector search, parent expansion, checkpoints, object URLs, and semantic caches, not only normal database routes.