All Products
Search
Document Center

Tablestore:Configure access control

Last Updated:Jun 25, 2026

Knowledge Store and Memory Store support fine-grained access control through RAM policies. You define permissions along two axes: API (Action) and resource (Resource). Authorization can be scoped down to a knowledge store subspace or a memory scope, which supports access isolation for multi-business, multi-team, and multi-tenant setups.

Authorization syntax and elements

These authorization rules apply to two API categories:

  • Knowledge Store APIs: Manage knowledge stores, documents (Document), chunks (Chunk), and knowledge retrieval (Retrieve).

  • Memory Store APIs: Manage memory stores, memories (Memory), memory messages and requests, memory tasks (Task), and Dream tasks (Dream Task).

A RAM policy consists of four elements: Effect, Action, Resource, and Condition. For the general syntax, see RAM policy syntax. The sections below cover only the specifics for Knowledge Store and Memory Store: the values allowed for Action and the resource ARN format for Resource.

API (Action)

The Action format is ots:<API name>, with wildcard * support. For example, ots:*KnowledgeBase matches all knowledge store management operations, and ots:*Memory* matches all memory-related operations. The following tables list all authorizable APIs, grouped by function.

Knowledge Store

Function group

Action

Knowledge store management

ots:CreateKnowledgeBase, ots:DescribeKnowledgeBase, ots:UpdateKnowledgeBase, ots:ListKnowledgeBase, ots:DeleteKnowledgeBase

Document management

ots:AddDocuments, ots:GetDocument, ots:ListDocuments, ots:UpdateDocument, ots:DeleteDocuments

Chunk management

ots:ListChunks, ots:UpdateChunks

Retrieval

ots:Retrieve

Memory Store

Function group

Action

Memory store management

ots:CreateMemoryStore, ots:GetMemoryStore, ots:UpdateMemoryStore, ots:ListMemoryStores, ots:DeleteMemoryStore

Memory management

ots:AddMemories, ots:SearchMemories, ots:ListMemories, ots:GetMemory, ots:UpdateMemory, ots:DeleteMemory

Messages and requests

ots:ListMemoryStoreMessages, ots:ListMemoryStoreRequests, ots:ListMemoryStoreScopes

Memory tasks

ots:GetMemoryTask, ots:ListMemoryTasks

Dream tasks

ots:CreateMemoryDreamTask, ots:GetMemoryDreamTask, ots:ListMemoryDreamTasks, ots:CancelMemoryDreamTask, ots:ApplyMemoryDreamActions, ots:ListMemoryDreamActions

Resource (Resource)

All resource ARNs are prefixed with the instance and follow this overall structure.

acs:ots:$region:$accountId:instance/$instanceName/<resource path>

Placeholder

Description

$region

The region ID where the instance is deployed, such as cn-hangzhou. Use * to allow all regions.

$accountId

The Alibaba Cloud account ID (UID) that owns the resource. Use * to allow all accounts.

$instanceName

The instance name. Use * to allow all resources under the instance.

<resource path>

The resource path for the knowledge store or memory store, constructed according to the rules in the following sections.

Knowledge Store

Knowledge store resources support three authorization levels, from coarse to fine.

Authorization level

Resource format

Matched scope

Instance level

acs:ots:$region:$accountId:instance/$instanceName/*

All knowledge stores under the instance. Operations that do not specify a knowledge store, such as ListKnowledgeBase, match this level.

Knowledge store level

acs:ots:$region:$accountId:instance/$instanceName/knowledgebase/$knowledgeBaseName

A specific knowledge store, including all its documents and chunks.

Subspace level

acs:ots:$region:$accountId:instance/$instanceName/knowledgebase/$knowledgeBaseName/subspace/$subspace

A specific subspace under a knowledge store.

The resource keywords knowledgebase and subspace are fixed values. $knowledgeBaseName and $subspace come from the request fields with the same names. The authorization level is determined as follows:

  • When the request does not include knowledgeBaseName (typical for list operations), authorization is evaluated at the instance level .../instance/$instanceName/*.

  • When the request includes a single subspace, authorization is evaluated at the subspace level. When the request spans multiple subspaces, authorization falls back to the knowledge store level .../knowledgebase/$knowledgeBaseName.

  • To allow all subspaces under a knowledge store, use the wildcard .../knowledgebase/$knowledgeBaseName/subspace/*, or grant authorization at the knowledge store level, which covers all subspaces.

Memory Store

Memory store resources support three authorization levels, from coarse to fine.

Authorization level

Resource format

Matched scope

Instance level

acs:ots:$region:$accountId:instance/$instanceName/*

All memory stores under the instance. Operations that do not specify a memory store, such as ListMemoryStores, match this level.

Memory store level

acs:ots:$region:$accountId:instance/$instanceName/memorystore/$memoryStoreName/*

All memories under a specific memory store. Requests that do not include scope are evaluated at this level.

Scope level

acs:ots:$region:$accountId:instance/$instanceName/memorystore/$memoryStoreName/appid/$appId/tenantid/$tenantId/agentid/$agentId/runid/$runId

Memories within a specific scope under a memory store. Requests that include scope are evaluated at this level.

The resource keywords memorystore, appid, tenantid, agentid, and runid are fixed values. $memoryStoreName comes from the request field with the same name. $appId, $tenantId, $agentId, and $runId come from the corresponding fields in the request scope. When the request does not include memoryStoreName, authorization is evaluated at the instance level .../instance/$instanceName/*.

Scope defaults: When the request includes scope but omits one of its fields, the missing field is set to __default__ in the authorization resource. For example, if the request scope specifies only appId=app_a, the authorization resource is constructed as:

acs:ots:$region:$accountId:instance/$instanceName/memorystore/$memoryStoreName/appid/app_a/tenantid/__default__/agentid/__default__/runid/__default__
Important

To allow all values for certain scope dimensions in a RAM policy, you must use the wildcard * (such as .../agentid/*/runid/*) as an explicit placeholder. Do not omit the corresponding level. Otherwise, the policy matches __default__ instead of all values.

Scenario examples

The following examples use the instance name myinstance. Replace $accountId with your actual account ID, and adjust placeholders such as the region, knowledge store name, and memory store name to match your environment.

Read-only access to a specific knowledge store

The following policy allows retrieval and query operations on the knowledge store product_docs_kb. Write operations are not granted.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ots:DescribeKnowledgeBase",
        "ots:GetDocument",
        "ots:ListDocuments",
        "ots:ListChunks",
        "ots:Retrieve"
      ],
      "Resource": [
        "acs:ots:cn-hangzhou:$accountId:instance/myinstance/knowledgebase/product_docs_kb",
        "acs:ots:cn-hangzhou:$accountId:instance/myinstance/knowledgebase/product_docs_kb/subspace/*"
      ]
    }
  ]
}

Isolate knowledge store write permissions by subspace

The following policy allows document and chunk read and write operations on the subspace team_a of the knowledge store product_docs_kb. Other subspaces are not affected.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ots:AddDocuments",
        "ots:GetDocument",
        "ots:ListDocuments",
        "ots:UpdateDocument",
        "ots:DeleteDocuments",
        "ots:ListChunks",
        "ots:UpdateChunks",
        "ots:Retrieve"
      ],
      "Resource": "acs:ots:cn-hangzhou:$accountId:instance/myinstance/knowledgebase/product_docs_kb/subspace/team_a"
    }
  ]
}

Isolate memory access by application

The following policy allows read and write operations on all memories under appId=app_a in the memory store agent_mem, without restricting tenant ID, agent ID, or run ID. Memories under other app IDs are not accessible. The unrestricted tenantid, agentid, and runid fields must use * as an explicit placeholder. Do not omit them. For details, see Scope defaults above.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ots:AddMemories",
        "ots:SearchMemories",
        "ots:ListMemories",
        "ots:GetMemory",
        "ots:UpdateMemory",
        "ots:DeleteMemory"
      ],
      "Resource": "acs:ots:cn-hangzhou:$accountId:instance/myinstance/memorystore/agent_mem/appid/app_a/tenantid/*/agentid/*/runid/*"
    }
  ]
}

Full management within an instance

The following policy allows all operations on every resource under the instance myinstance.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ots:*KnowledgeBase",
        "ots:*Document*",
        "ots:*Chunks",
        "ots:Retrieve",
        "ots:*Memory*"
      ],
      "Resource": "acs:ots:cn-hangzhou:$accountId:instance/myinstance/*"
    }
  ]
}

Usage notes

  • The resource prefix is always the instance: A resource ARN must start with acs:ots:$region:$accountId:instance/$instanceName/. Knowledge store and memory store resources cannot span instances.

  • Upper levels cover lower levels: An upper-level resource automatically covers its sub-resources. Authorizing at the knowledge store level covers all its subspaces. Authorizing at the memory store level memorystore/$store/* covers all its scopes. For fine-grained control, grant authorization at the subspace or scope level.

  • The root account is not subject to policies: The policies above apply only to RAM users and roles. By default, the root account has full permissions on its own resources.