Orqestria Download
← Back to Next.js SaaS foundation team

Skill · Version 1.0.0

Tenant-isolated AI agents

Keeps AI conversations, retrieval, tool actions and usage budgets inside verified workspace boundaries throughout an agent run.

tenant-aware-ai-agents

Team members using this skill

See how it helps

When is it useful?

Use it when multiple customers share agent infrastructure and any memory, cache or tool could become a cross-tenant path.

What does it help you do?

  • Filters retrieval by verified workspace before similarity search.
  • Scopes conversations, memory, checkpoints and prompt caches.
  • Binds tool authorization server-side and enforces tenant budgets.

Try asking this

Verify two workspaces cannot share retrieved documents or cached agent context. Ask the same question in two workspaces containing different confidential documents. Retrieval, cached answers and tool calls must remain scoped to the requesting workspace.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Tenant-Aware AI Agents

When to Use

Use when designing, building, or reviewing LLM integrations, AI agents, RAG / vector search pipelines, conversation memory, or tool-calling execution in a multi-tenant SaaS application.

Why AI Agents Are High-Risk Cross-Tenant Vectors

An AI agent combines untrusted text inputs, semantic retrieval (where embeddings have no built-in access control), external tool execution, and long-running background state. A single unscoped vector query or tool handler allows prompt injection or semantic similarity to pull Tenant B's confidential data into Tenant A's response.

Five Mandatory AI Tenant Isolation Controls

1. RAG & Vector Database Isolation (pgvector, Qdrant, Pinecone, Milvus)
  • Pre-Filter Before Similarity Search:
    • Every vector chunk stored must include tenant_id (and workspace-internal ACL metadata where applicable).
    • Wrap the vector query client so tenant_id = ctx.tenantId is injected automatically from the verified server TenantContext as a hard pre-filter (or dedicated per-tenant namespace/collection)—never let the LLM or user prompt supply or override tenantId in a search tool call!
  • Ingestion & Re-Indexing Hygiene:
    • When a document is moved, permission-restricted, or deleted in a workspace, immediately update or purge its vector chunks so stale embeddings cannot be retrieved.
2. Conversation Memory, Checkpoints & Prompt Caches
  • Scope all conversation threads, agent checkpoints, long-term memory facts, and semantic response caches strictly by (tenant_id, thread_id).
  • When using provider prompt caching, ensure system/workspace context prefixes never mix data from different tenants in a shared cache key.
3. Tool Calling & MCP / CLI Execution Guardrails (Zero Trust for LLM Arguments)
  • Never Accept tenantId from LLM Tool Arguments:
    • When an LLM invokes a tool (get_customer_invoice({ invoiceId }), search_projects({ query }), run_sql), bind tenantId and actorId from the server-side TenantContext inside the tool executor—never expose tenant_id as a parameter the model can choose or hallucinate!
  • Dual Authorization on Tool Calls:
    • A tool call acting on behalf of a user in a workspace must enforce both the workspace's tenant boundary and the invoking user's role/permission within that workspace (e.g., a viewer cannot use an AI agent to trigger a write/delete tool that the viewer could not call via the REST API).
  • Isolated Workspace Sandboxes:
    • If agents execute CLI commands or read/write files, scope their working directory and credentials strictly to the target workspace's sandbox and tenant-owned integration tokens.
4. Per-Tenant Token Quotas, Rate Limits & Kill Switches
  • Track LLM input/output tokens, tool calls, and dollar cost per tenant_id.
  • Enforce per-workspace concurrency limits and budget ceilings so a runaway agent loop in one workspace cannot exhaust the platform's global LLM provider quota.

Included files 1

  • SKILL.md