multi-tenant agent 인프라는 인증된 context에서 tenant scope를 가져오고 이를 tool, database, queue, cache, artifact, credential, log 전체에 유지해야 합니다. prompt나 model이 만든 argument에 있는 tenant_id는 isolation 경계가 아닙니다.
agent는 백엔드 작업의 수와 종류를 늘리므로 경계 하나를 놓치면 사람이 제한된 interface를 거치지 않아도 tenant를 넘을 수 있습니다. model이 혼동하거나, 검색된 content가 적대적이거나, 두 리소스가 같은 friendly name을 사용할 때도 이 제어가 유지되어야 합니다.
resource input을 받기 전에 identity를 연결하세요
session이나 application credential에서 tenant를 확인하세요. 이 identity를 agent control plane을 통해 전달한 다음 server-side resource record를 기준으로 요청한 작업의 권한을 확인합니다.
flowchart LR
Request[Agent tool call] --> Session[Authenticated session]
Session --> Scope[Tenant and delegated scope]
Scope --> Policy{Authorize resource and action}
Policy -->|allow| Tool[Execute scoped tool]
Policy -->|deny| Audit[Record denial]
Tool --> DB[(Tenant-scoped data)]
Tool --> Queue[(Tenant-scoped work)]
Tool --> Artifacts[(Tenant-scoped artifacts)]
tool argument가 인증된 tenant를 덮어쓰게 하지 마세요. resource ID가 전역에서 unique하더라도 현재 tenant 아래에서 찾아야 authorization rule이 명시적으로 유지됩니다.
database isolation model을 의도적으로 선택하세요
| 모델 | 경계 | 운영상 결과 |
|---|---|---|
| Shared table | tenant column, row-level policy, scoped query | migration은 단순하지만 모든 access path가 정확한 policy와 connection role에 의존 |
| tenant별 schema | database 하나의 별도 namespace | naming boundary는 강하지만 schema별 migration과 connection setup 필요 |
| tenant별 database | 별도의 database와 credential | storage boundary가 가장 강하지만 provision, pooling, backup, migration 작업 증가 |
row-level security는 application role이 우회할 수 없고 tenant context가 server-side에서 설정된다면 강력할 수 있습니다. application의 WHERE 절보다 본질적으로 약한 것은 아닙니다. 보장 수준은 policy, role, 모든 alternate connection path에 달려 있습니다.
regulatory requirement, 유난히 큰 tenant, customer-managed encryption, 독립적인 restore 요구가 있다면 isolation이 더 강한 model을 사용하세요. caller가 agent라는 이유만으로 database-per-tenant를 선택하지 마세요.
database pattern 가이드는 composite tenant key와 operation constraint를 보여 줍니다.
모든 shared subsystem에 scope를 전달하세요
database isolation은 여러 경계 중 하나입니다.
- 사용자가 제어할 수 없는 tenant identifier를 cache key 앞에 붙이고 invalidation에도 포함하세요.
- 인증된 server context에서 queue message에 tenant scope를 넣고 worker가 받을 때 다시 권한을 확인하세요.
- object key와 vector collection에 namespace를 적용하고 signed URL 발급이나 search 전에 ownership을 확인하세요.
- browser 및 sandbox session을 tenant 소유로 두고 filesystem과 credential을 분리하세요.
- tool session과 OAuth grant의 범위를 해당 tenant와 user로 제한하세요.
- rate 및 spend limit를 tenant, agent, high-impact action별로 나누세요.
두 tenant에서 같은 resource name을 테스트하세요. production, orders, main 같은 friendly name은 model이 context에서 리소스를 선택할 때 충돌하기 쉽습니다.
credential과 log도 tenant를 인식하게 하세요
provider credential을 tenant가 소유한 secret reference 아래에 저장하세요. tool worker는 자신이 resolve할 권한이 있는 reference만 받아야 합니다. provider account를 공유하더라도 tenant별 accounting과 revocation이 필요합니다.
조사를 위해 log와 trace에 tenant field가 필요하지만 observability 접근 역시 tenant scope로 제한해야 합니다. export 전에 prompt, tool argument, result에서 민감 정보를 제거하세요. 모든 tenant를 검색할 수 있는 internal dashboard가 소규모의 신뢰할 수 있는 운영팀에는 적합할 수 있지만 여전히 privileged surface입니다.
NIST의 zero trust architecture는 network location이 아니라 identity와 resource에 따라 요청마다 access를 판단합니다. 이는 background worker와 internal tool call에도 잘 맞습니다. platform 안에서 실행된다는 이유만으로 광범위한 접근 권한을 얻어서는 안 됩니다.
quota를 permission으로 오해하지 말고 loop를 제한하세요
concurrent run, tool call, model spend, storage, repeated failure에 tenant별 limit를 설정하세요. destructive하거나 비용이 높은 도구에는 더 좁은 limit를 추가합니다. loop가 생기면 영향을 받은 tenant workload를 중지하고 사람이 확인할 수 있는 operation record를 남겨야 합니다.
limit는 양을 제한할 뿐 unauthorized call을 허용 가능한 것으로 바꾸지 않습니다. quota를 차감하기 전에 authorization을 실행하고 agent가 policy denial을 재시도하지 않도록 안정적인 error class를 반환하세요.
tenant graph 전체에 걸쳐 deletion을 설계하세요
tenant deletion path는 database, cached value, queued work, artifact, memory, index, browser session, sandbox, credential, log, backup, active operation을 inventory해야 합니다. 즉시 삭제하거나, 나중에 만료하거나, 법률 및 보안상의 이유로 보관할 항목을 결정하세요.
data를 삭제하기 전에 새 작업을 중단하고 credential을 revoke하세요. 일부 cleanup만 끝날 가능성이 있으므로 deletion은 재개 가능하고 idempotent해야 합니다. 삭제된 content 자체를 보관하지 않고 각 resource의 완료 상태를 기록하세요.
의도적으로 비슷한 data로 isolation을 테스트하세요
name이 겹치고 ID가 거의 같은 두 test tenant를 만드세요. 모든 tool, worker, cache, queue, artifact path를 통해 접근을 시도합니다. model에 tenant ID를 바꾸라고 지시하는 검색 document도 포함하세요. model이 무엇을 출력하든 server가 작업을 거부해야 합니다.
아래 프롬프트는 이를 repository별 test plan으로 바꿉니다. database diagram만으로는 isolation을 증명할 수 없으므로 tenant scope가 어디에서 시작되는지 먼저 찾습니다.