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 |
|
|
Document management |
|
|
Chunk management |
|
|
Retrieval |
|
Memory Store
|
Function group |
Action |
|
Memory store management |
|
|
Memory management |
|
|
Messages and requests |
|
|
Memory tasks |
|
|
Dream tasks |
|
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 |
|
|
The region ID where the instance is deployed, such as |
|
|
The Alibaba Cloud account ID (UID) that owns the resource. Use |
|
|
The instance name. Use |
|
|
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 |
|
All knowledge stores under the instance. Operations that do not specify a knowledge store, such as |
|
Knowledge store level |
|
A specific knowledge store, including all its documents and chunks. |
|
Subspace level |
|
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 |
|
All memory stores under the instance. Operations that do not specify a memory store, such as |
|
Memory store level |
|
All memories under a specific memory store. Requests that do not include |
|
Scope level |
|
Memories within a specific scope under a memory store. Requests that include |
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__
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.