GovernSecurity
Resource Policy ACL
Org-level resource access rules · RBAC / Policy / ACL three-layer stack
Resource policies are org-level global rules that complement RBAC and workspace ACL, handling complex cross-workspace scenarios.
Three-Layer Stack
If any layer denies → denied.
Policy Subjects
| Subject | Example |
|---|---|
| User | Alice |
| Role | "Finance audit" |
| Department | "Marketing" |
Policy Objects
| Object | Example |
|---|---|
| Agent / Workflow / Chatflow | One or many |
| Knowledge base / Data source | One or many |
| Tool / Skill / Model | One, or grouped by type |
| Credential | A specific credential |
Policy Actions
| Action | Description |
|---|---|
| View | See the resource exists |
| Use | Call / trigger |
| Edit | Modify |
| Manage | + ACL management / delete |
When to Use Resource Policy vs Workspace ACL
| Scenario | Use |
|---|---|
| "Marketing dept read-only on all org KBs" | Resource policy (cross-workspace) |
| "Agent X usable only by user_a / user_b" | Workspace ACL (single resource) |
| "New-hire role can't use any production tool" | Resource policy (across tool types) |
| "Finance can't edit any R&D workspace resource" | Resource policy (cross-workspace) |
A Composite Example
→ Even after Alice (Finance) joins the Marketing workspace, she can only view.
Coordination with RBAC
Final experience for Alice in Workspace X: all resources visible except Agent A.
Anti-Patterns
- Using a resource policy to substitute workspace ACL — single-resource concerns belong in the workspace
- Overly complex policies (5 nested conditions) — split into multiple simple policies, easier to audit
- Not maintaining a policy-change log — query in audit logs
Next Steps
- Configure credentials → Credential management
- Refine inside a workspace → Workspace · Members & permissions