knowledge(agents): clarify task permission intersection

community/knowledge/agents/agent-permissions-intersect-with-assigner.bad.al

@@ -1,3 +1,7 @@
+// Assign these sets separately to the agent and scheduling user in the task's company.
+// Wrong: the agent's Sales Header grant lets the task modify orders even if the user cannot.
+// Wrong: the user's Customer grant lets the task modify customers even if the agent cannot.
+// Wrong: adding user-administration rights lets the agent manage users.
 permissionset 50100 "SALES REVIEW AGENT"
 {
     Assignable = true;
@@ -6,6 +10,19 @@ permissionset 50100 "SALES REVIEW AGENT"
         tabledata Customer = R,
         tabledata User = RIMD,
         tabledata "Access Control" = RIMD,
+        table "Sales Header" = X,
+        table Customer = X,
         page "Sales Order" = X,
         page "User Card" = X;
 }
+
+permissionset 50101 "SALES TASK USER"
+{
+    Assignable = true;
+    Permissions =
+        tabledata "Sales Header" = R,
+        tabledata Customer = RM,
+        table "Sales Header" = X,
+        table Customer = X,
+        page "Sales Order" = X;
+}

community/knowledge/agents/agent-permissions-intersect-with-assigner.good.al

@@ -1,8 +1,24 @@
+// Assign these sets separately to the agent and scheduling user in the task's company.
+// Assume no additional grants. Effective tabledata rights are R on both tables:
+// the user lacks Sales Header modification, and the agent lacks Customer modification.
 permissionset 50100 "SALES REVIEW AGENT"
 {
     Assignable = true;
     Permissions =
         tabledata "Sales Header" = RIM,
         tabledata Customer = R,
+        table "Sales Header" = X,
+        table Customer = X,
+        page "Sales Order" = X;
+}
+
+permissionset 50101 "SALES TASK USER"
+{
+    Assignable = true;
+    Permissions =
+        tabledata "Sales Header" = R,
+        tabledata Customer = RM,
+        table "Sales Header" = X,
+        table Customer = X,
         page "Sales Order" = X;
 }

community/knowledge/agents/agent-permissions-intersect-with-assigner.md

@@ -1,30 +1,40 @@
 ---
 bc-version: [27..]
 domain: agents
-keywords: [permissions, assigner, intersection, user-card, least-privilege]
+keywords: [permissions, assigner, intersection, task-scheduler, user-intervention, company-scope, user-card, least-privilege]
 technologies: [al]
 countries: [w1]
 application-area: [all]
 ---
 
-# Agent permissions intersect the assigner's; agents cannot configure users
+# Agent task permissions intersect the scheduling user's permissions
 
 ## Description
 
-An agent is a user, but it cannot configure users or other agents, and it cannot open sensitive pages such as user cards or permission-set assignment. Effective rights are the intersection of the assigning user's permissions and the agent's permission sets. Granting the agent a wide set does not bypass the assigner's limits, and a wide assigner still cannot give the agent user-admin powers the platform forbids.
+An agent task runs with the intersection of the agent's permissions and those of the user who schedules the task, not automatically those of the agent's creator or the administrator who assigned its permission sets. An operation must be permitted on both sides; permissions are not combined as a union. After a user responds to an intervention request, the task continues using that responding user's permission context, which can differ from the original task creator's. For a task in a particular company, the intersection considers permissions assigned for that company or for all companies.
 
 ## Best Practice
 
-Document that intersection. Give the agent only the table and page rights its tasks need. Do not add user-setup or permission-assignment pages to the agent profile or permission sets; those operations will fail by design.
+Give the agent only the table and page rights its tasks need, and verify that the scheduling user has the required rights in the task's company. If the agent can modify sales headers but the user can only read them, the task cannot modify them; if the user can modify customers but the agent can only read them, the task cannot modify customers either. Test both directions with restricted users, including continuation after an intervention answered by a different user; do not validate only with SUPER.
+
+When diagnosing an access failure, check both permission contexts and company scope rather than widening only the agent's permission set. A permission set designed for a shared agent need not be a subset of every potential scheduling user's permissions: the platform applies the intersection per task. A profile controls the visible UI, not a grant of missing permissions. Do not add user-setup or permission-assignment pages to the agent profile or permission sets; agents cannot configure users or other agents, and platform restrictions still apply even when both permission sets are broad.
 
 See sample: [`agent-permissions-intersect-with-assigner.good.al`](agent-permissions-intersect-with-assigner.good.al).
 
 ## Anti Pattern
 
-Permission sets or profiles that include User card, Permission Set Assignment, or agent-admin pages, or comments that the agent runs as SUPER regardless of who assigned it. Detection signal: default access controls or profile including user-administration objects.
+Assuming the agent inherits its creator's or administrator's rights, treating user and agent grants as a union, or adding SUPER to the agent to bypass a scheduling user's missing rights. Also avoid assuming that the original task creator remains the permission context after another user answers an intervention, or that a grant in one company applies in another.
+
+Detection signals include comments promising operations that only one side permits, or default access controls and profiles exposing User Card, Permission Set Assignment, or agent-administration pages. The absence of a hand-written intersection check in AL is not itself a defect; enforcement is provided by the platform.
 
 See sample: [`agent-permissions-intersect-with-assigner.bad.al`](agent-permissions-intersect-with-assigner.bad.al).
 
 ## See also
 
-`get-default-access-controls-least-privilege.md` covers the permission sets assigned when an agent instance is created.
+- [Default agent access controls](get-default-access-controls-least-privilege.md) covers the permission sets assigned when an agent instance is created.
+- [Agent-specific profiles](agent-profile-narrows-visible-ui.md) covers reducing visible UI independently of permission grants.
+
+## References
+
+- [Microsoft Learn: Agent permissions - effective permissions and per-company access controls](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/ai-development-toolkit-permissions#access-controls---effective-permissions-of-an-agent)
+- [Microsoft Learn: Set up agent permissions and profiles](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/ai-development-toolkit-permissions-profiles#effective-permissions)

community/knowledge/agents/get-default-access-controls-least-privilege.md

@@ -11,7 +11,7 @@ application-area: [all]
 
 ## Description
 
-`IAgentFactory.GetDefaultAccessControls` fills a temporary `Access Control Buffer` used when an instance is created. Permission sets that exist only as user-created sets in a sandbox are missing in the next environment. Granting `D365 BUS FULL ACCESS` or SUPER gives the agent a user-sized blast radius. Effective rights are still the intersection with the assigning user's permissions.
+`IAgentFactory.GetDefaultAccessControls` fills a temporary `Access Control Buffer` used when an instance is created. Permission sets that exist only as user-created sets in a sandbox are missing in the next environment. Granting `D365 BUS FULL ACCESS` or SUPER gives the agent a user-sized blast radius. Effective task rights are still the intersection with the scheduling user's permissions, or the responding user's permission context after an intervention.
 
 ## Best Practice
 
@@ -27,4 +27,4 @@ See sample: [`get-default-access-controls-least-privilege.bad.al`](get-default-a
 
 ## See also
 
-`agent-permissions-intersect-with-assigner.md` explains the platform limits that still apply after default access controls are assigned.
+[Agent task permission intersection](agent-permissions-intersect-with-assigner.md) explains the platform limits that still apply after default access controls are assigned.