All Products
Search
Document Center

Tablestore:Configure access permissions

Last Updated:Sep 24, 2026

AgentStorage Knowledge Storage and Memory Storage support fine-grained access control through RAM policies along two dimensions: Action (API) and Resource. You can scope authorization down to a knowledge base subspace or a memory scope to isolate access across multiple business lines, teams, and tenants.

Scope

The authorization rules described in this topic apply to the following two categories of APIs.

  • Knowledge Storage APIs: manage Knowledge Storage, Documents, Chunks, and knowledge retrieval (Retrieve).

  • Memory Storage APIs: manage Memory Storage, Memories, memory messages and requests, Memory Tasks, and Dream Tasks.

Authorization syntax and elements

RAM policy consists of four elements: Effect, Action, Resource, and Condition. For the general syntax, see RAM policy syntax. This topic covers only the parts specific to Knowledge Storage and Memory Storage, namely the allowed values for Action and the resource ARN format for Resource.

Action

The Action element takes the format ots:<API name> and supports the wildcard *. For example, ots:*KnowledgeBase matches all Knowledge Storage management operations, and ots:*Memory* matches all memory-related operations. The following tables list all authorizable APIs, grouped by function.

Knowledge Storage

Function group

Action

Knowledge Storage 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 Storage

Function group

Action

Memory Storage 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

All resource ARNs are prefixed with the instance. The overall structure is as follows.

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

Placeholder

Description

$region

The region ID of the instance, for example cn-hangzhou. Use * to allow all regions.

$accountId

The UID of the Alibaba Cloud account 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 Knowledge Storage or Memory Storage, constructed according to the rules below.

Knowledge Storage

Knowledge Storage resources support three authorization levels, from coarsest to finest as follows.

Authorization level

Resource format

Scope matched

Instance level

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

All Knowledge Storage under the instance. Operations that do not target a specific knowledge base, such as ListKnowledgeBase, match this level.

Knowledge base level

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

A single specified knowledge base, including all of its documents and chunks.

Subspace level

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

A single subspace within the specified knowledge base.

The resource keywords knowledgebase and subspace are fixed values. $knowledgeBaseName and $subspace are taken from the fields of the same name in the request. The authorization level is determined by the following rules:

  • When the request does not carry knowledgeBaseName (typically a list operation), authorization is enforced at the instance level .../instance/$instanceName/*.

  • When the request carries a single subspace, authorization is enforced at the subspace level. When a single request involves multiple subspaces, authorization falls back to the parent knowledge base level .../knowledgebase/$knowledgeBaseName.

  • To allow access to all subspaces under a knowledge base, use the wildcard .../knowledgebase/$knowledgeBaseName/subspace/*, or authorize at the knowledge base level (which covers all subspaces).

Memory Storage

Memory Storage resources support three authorization levels, from coarsest to finest as follows.

Authorization level

Resource format

Scope matched

Instance level

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

All Memory Storage under the instance. Operations that do not target a specific memory store, such as ListMemoryStores, match this level.

Memory store level

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

All memories under the specified memory store. When the request does not carry scope, authorization is enforced at this level.

Scope level

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

Memories within the specified scope of the specified memory store. When the request carries scope, authorization is enforced at this level.

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

Scope default values

When the request carries scope but omits a given field, that field defaults 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__

When you leave certain scope dimensions unrestricted in a RAM policy, you must use the wildcard * (for example, .../agentid/*/runid/*) as an explicit placeholder. Do not omit the corresponding level, otherwise it will match __default__ rather than all values.

Common authorization scenarios

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

Read-only access to a specific knowledge base

The following policy allows retrieval and queries against the knowledge base product_docs_kb and denies all write operations.

{
  "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/*"
      ]
    }
  ]
}

Isolating write access by subspace

The following policy allows read and write operations on documents and chunks within the team_a subspace of the knowledge base product_docs_kb. Other subspaces are unaffected.

{
  "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"
    }
  ]
}

Isolating memory access by application

The following policy allows read and write access to all memories with appId=app_a in the memory store agent_mem (regardless of tenant, agent, and run). Memories of other appIds are not accessible.

{
  "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/*"
    }
  ]
}

The unrestricted tenantid, agentid, and runid dimensions must be explicitly opened with * and cannot be omitted. For the reason, see the scope default values note above.

Full administration within an instance

The following policy allows all operations on all related resources 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/*"
    }
  ]
}

Notes

  • The resource prefix is always the instance: Resource ARNs must begin with acs:ots:$region:$accountId:instance/$instanceName/. Neither Knowledge Storage nor Memory Storage has a cross-instance resource form.

  • Parent covers child: A higher-level resource inherently covers its sub-resources. Authorizing at the knowledge base level covers all of its subspaces; authorizing at the memory store level memorystore/$store/* covers all of its scopes. For finer control, drill down to the subspace level or scope level.

  • The primary account is not bound by policies: The policies above apply only to RAM users and roles. The primary account (Root) retains full permissions on its own resources by default.