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 |
|
|
Document management |
|
|
Chunk management |
|
|
Retrieval |
|
Memory Storage
|
Function group |
Action |
|
Memory Storage management |
|
|
Memory management |
|
|
Messages and requests |
|
|
Memory tasks |
|
|
Dream tasks |
|
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 |
|
|
The region ID of the instance, for example |
|
|
The UID of the Alibaba Cloud account that owns the resource. Use |
|
|
The instance name. Use |
|
|
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 |
|
All Knowledge Storage under the instance. Operations that do not target a specific knowledge base, such as |
|
Knowledge base level |
|
A single specified knowledge base, including all of its documents and chunks. |
|
Subspace level |
|
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 |
|
All Memory Storage under the instance. Operations that do not target a specific memory store, such as |
|
Memory store level |
|
All memories under the specified memory store. When the request does not carry |
|
Scope level |
|
Memories within the specified scope of the specified memory store. When the request carries |
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.