← Laravel SaaS alapok csapata adatlapja

Skill · 1.0.0 verzió

Ügyfélre elkülönített AI-ágensek

Ellenőrzött munkatérhatáron tartja az AI-beszélgetést, visszakeresést, eszközt és használati keretet a teljes ágensfutásban.

tenant-aware-ai-agents

Ezt a skillt használó csapattagok

Nézd meg, miben segít

Mikor hasznos?

Akkor használd, ha több ügyfél közös ágensinfrastruktúrát használ, és memória, cache vagy eszköz átjárást jelenthet.

Miben segít neked?

  • Hasonlósági keresés előtt ellenőrzött munkatérre szűkíti a visszakeresést.
  • Elkülöníti a beszélgetést, memóriát, ellenőrzőpontot és promptcache-t.
  • Szerveren köti az eszközjogot és érvényesíti az ügyfélkeretet.

Például ezt kérheted

Igazold, hogy két munkatér nem oszt visszakeresett dokumentumot vagy ágenscache-t. Két munkatér eltérő bizalmas dokumentumaival tedd fel ugyanazt a kérdést. A keresés, gyorsítótárazott válasz és eszközhívás maradjon saját hatókörben.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

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.

Csomagban lévő fájlok 1

  • SKILL.md