Skip to main content
Noorle uses a role-based access control (RBAC) system combined with resource-level and action-level permissions. This allows granular control over who can do what.

​
Role Hierarchy

Noorle has four account-level roles:

​
Role Permissions Matrix

What each role can do:
ActionOwnerAdminDeveloperMember
Create gateway✓✓✓✗
Modify gateway✓✓Own only✗
Delete gateway✓✓Own only✗
Execute agent✓✓✓✓
View all agents✓✓✓Shared only
Create user✓✓✗✗
Manage billing✓✗✗✗
Delete account✓✗✗✗
Rotate API keys✓✓Own only✗
Manage OAuth apps✓✓✗✗

​
Assigning Roles

​
During Account Creation

Welcome to Noorle!

Account: Acme Corp
Owner: alice@acme.com (you)

Next: Invite team members

​
Inviting Team Members

Console → Settings → Team
├─ Add Member
│  ├─ Email: bob@acme.com
│  ├─ Role: Developer
│  │  (choose: Owner, Admin, Developer, Member)
│  └─ [Send Invite]
│
└─ Bob receives email
   ├─ Click to accept
   ├─ Automatically has Developer role
   └─ Can now create agents, gateways, etc.

​
Resource-Level Permissions

Beyond role, permissions are also scoped to resources: 
User: Developer
Role: Developer (can create agents)

Agent: Research Bot (created by this user)
├─ Permissions: Full (create, read, update, delete)

Agent: Support Bot (created by someone else)
├─ Permissions: Execute only
   (can run it, but not modify)

Gateway: Public Research (shared)
├─ Permissions: Read, Execute
   (can see tools, run them, but not attach capabilities)

​
Permission Model

Noorle uses: Principal + Resource + Action → Allow/Deny

​
Permission Scopes

​
Account Scope

Permission applies to entire account: 
Role: Admin
Scope: account
Permissions: create_agent, delete_agent, manage_users

→ Can create/delete any agent in account
→ Can manage all users

​
Resource Scope

Permission applies to specific resource: 
User: Developer
Resource: Agent "DataBot"
Permissions: execute, read

→ Can run DataBot
→ Can view DataBot
→ Cannot modify DataBot

​
Group Scope

Permission applies to group of resources: 
Team: Data Team
Resources: All agents tagged "data-pipeline"
Permissions: read, execute

→ All Data Team members can see/run these agents
→ Cannot modify (would need manage permission)

​
Action Types

​
Admin Actions

Only owners can perform:
  • Delete account
  • Change account plan
  • Transfer account ownership
  • Manage billing

​
Management Actions

Admin, Developer (own), or Owner can perform:
  • Create/delete agents
  • Create/delete gateways
  • Upload plugins
  • Manage API keys
  • Configure capabilities

​
Execution Actions

Any authenticated user can perform (if permitted):
  • Execute agent
  • Call tool
  • Read chat history
  • View results

​
Read-Only Actions

Viewer role can perform:
  • List agents/gateways
  • View agent specifications
  • View execution history
  • View memory/knowledge bases

​
Custom Permissions

For fine-grained control, create custom permission sets: 
Console → Settings → Team → Custom Roles

Create Role: "Pipeline Engineer"
├─ Can create agents (scope: tagged with "pipeline")
├─ Can execute agents
├─ Can manage API keys (own only)
├─ Cannot delete agents
├─ Cannot access customer data
└─ [Save]

Assign role to: charlie@acme.com

​
API Key Scoping

API keys inherit from creator’s permissions but can be further scoped: 
API Key created by: alice (Admin)

Scope: entire account
├─ Permissions: all

Can be scoped to:
├─ Single gateway
├─ Single agent
├─ Specific actions (read, execute, manage)
├─ Time-limited (expires after N days)
Example: 
API Key: databot-read-only
├─ Creator: alice (Admin)
├─ Scope: Agent "DataBot"
├─ Permissions: read, execute
├─ Expires: 2024-06-30
│
→ Can only read/execute DataBot
→ Cannot create/modify anything
→ Automatically expires

​
OAuth Client Permissions

Third-party apps get permissions based on user and requested scope: 
User: bob (Developer)
App: "Analytics Dashboard"
Requested scope: read offline_access

Effective permissions:
├─ Can read only (inherited from user)
├─ Cannot execute (not in scope)
├─ Cannot create (not in scope)
│
→ Even if bob is Admin, app only gets "read"

​
Share and Collaboration

Share specific resources with team members: 
Agent: "Customer Analysis"
Owner: alice

Share with:
├─ bob@acme.com (Execute, Read)
├─ data-team@acme.com (Execute, Read)
└─ finance-team@acme.com (Read only)

Permissions:
├─ bob can run agent and view results
├─ data-team can run agent and view results
├─ finance-team can only view results (read-only)

​
Permission Inheritance

Permissions flow down: 
Account Level
├─ alice (Owner) → Full control

Gateway Level
├─ Research Gateway
   ├─ alice (inherited: Owner)
   ├─ bob (Developer, shared)
   └─ charlie (Member, shared)

Capability Level
├─ Web Search (attached to Research Gateway)
   ├─ alice can manage/execute
   ├─ bob can execute
   └─ charlie can execute

Agent using Gateway + Capability
├─ alice full control
├─ bob can execute (via gateway + agent share)
├─ charlie can execute (via gateway + agent share)

​
Audit Trail

All permission changes are logged: 
Audit Log:
├─ 2024-03-22 10:00 | alice | added bob as Admin
├─ 2024-03-22 10:05 | alice | shared Agent "DataBot" with charlie
├─ 2024-03-22 10:10 | bob | created Agent "Report"
├─ 2024-03-22 10:15 | alice | removed charlie from "Data Team"
├─ 2024-03-22 10:20 | bob | executed Agent "DataBot"
└─ 2024-03-22 10:25 | alice | rotated API key

Full history preserved. Searchable by:
├─ User
├─ Action type
├─ Resource
├─ Time range

​
Best Practices

Principle of Least Privilege

Assign minimum role needed. New hires: Developer. Interns: Member.

Regular Audits

Monthly: Review who has access to what. Remove inactive users. Revoke old API keys.

Use Groups

Assign permissions to groups, not individuals. Easier to manage.

Document Permissions

Keep a record of why each person has their role. Useful for audits.

​
Common Scenarios

​
New Developer Joins

1. Create account with Developer role
2. Can create own agents and gateways
3. Cannot see others' resources initially
4. Grant read access to shared agents if needed

​
Contractor/Consultant

1. Create account with Member role
2. Share specific agent to execute
3. They can run agent, view results
4. They cannot create or modify anything
5. Revoke access when done

​
Team Lead

1. Create account with Admin role
2. Can manage team members
3. Can view all resources
4. Can create agents on behalf of team
5. Can moderate access

​
Rotating Team Member Out

1. List all resources owned by person
2. Transfer ownership to another team member
3. Remove their account access
4. Revoke API keys
5. Verify in audit log

​
Troubleshooting

ProblemSolution
”Permission denied”Check your role. Ask owner for higher role if needed.
Can’t see shared agentConfirm resource was shared with you. Owner may need to re-share.
API key works for some calls, not othersCheck API key scope. May be limited to specific resource.
Can’t find audit logOwner/Admin only. Ask owner to check audit log.
You’ve completed the Learn tab! All 20 pages cover Noorle’s architecture, core concepts, and security model. Next, explore the Use tab for practical guides.