Access control
/
Overview
Last updated

Access control overview

Access Control in AgentLink determines which tools a user or tenant can see and execute through your MCP server. Rules can be mapped to roles or permissions and enforced dynamically from JWT claims.

Discovery is enforced: tools that are not allowed by your rules are not returned by the MCP listTool function, so AI agents cannot see or call them.

Page layout

The Access Control page shows a searchable table of rules and an action to create new ones.

Table columns

  • Mapping name — Friendly name of the rule (e.g., “Only admin can delete”).
  • Mapping type — “Role based” or “Permission based”.
  • Tools — One or more tools the rule controls.
  • Assignments — Number of roles or permissions assigned.
  • Last updated — When the rule was last modified.
  • Actions — Edit or delete.

Use the Add rule button (top-right) to create a new rule.

Creating a rule

Click Add rule to open the rule dialog.

Fields in the dialog

  • Mapping name — A concise label for the rule.
  • Description — Optional context for admins (what/why).
  • Tools — Select one or more tools this rule governs.
  • Mapping type (immutable after creation)
    • Map to roles — Control access based on user roles.
    • Map to permission — Control access based on specific permissions/entitlements.
  • Assign roles / Assign permissions — Choose the roles or permissions that grant access.

Click Save to create the rule. It takes effect immediately for discovery and execution.

Editing or deleting a rule

  • Edit: Click the three-dot menu on a row and choose Edit. Update description, assignments, or tools (mapping type cannot change). Save to apply.
  • Delete: Use the three-dot menu → Delete. Removing the rule immediately revokes discovery and access for the affected tools unless covered by another rule.

How enforcement works

  1. Discovery filter
    When an AI agent calls MCP listTool, AgentLink evaluates the caller’s JWT claims.
    Tools not allowed by any matching rule are omitted from the response.

  2. Execution gate
    When a tool is invoked, the same rule set is evaluated again. If no rule grants access, the call is blocked and logged.

  3. RBAC and PBAC

    • Role-based (RBAC): Access is granted if the user has one of the assigned roles.
    • Permission-based: Access is granted if the user has one of the assigned permissions/entitlements.

Rules can target individual tools or sets of tools and are evaluated per request using the caller’s JWT claims.

Examples

Example 1 — Role-based access

Allow only admins to call Delete_expense.

  • Mapping name: Only admin can delete
  • Tools: Delete_expense
  • Mapping type: Map to roles
  • Assign roles: admin

Result: Only users with the admin role will see Delete_expense in listTool and can execute it.

Example 2 — Permission-based access

Grant read_customer permission holders access to get_customer_profile.

  • Mapping name: Customer profile read
  • Tools: get_customer_profile
  • Mapping type: Map to permission
  • Assign permissions: read_customer

Result: Users without read_customer will not see or use this tool.

Testing access

Use the Access Control page to:

  • Search for a tool and verify which rules apply.
  • Inspect Assignments to confirm the intended roles/permissions.
  • After changes, validate as the target user (or via your app) that listTool returns only the allowed tools.

For deeper visibility, check Monitoring → Logs to see discovery and execution outcomes.

Best practices

  • Prefer least privilege: limit high-impact tools to specific roles or permissions.
  • Use clear mapping names and descriptions so admins understand intent.
  • Keep mapping type stable: choose “roles” or “permissions” based on your identity model before creating the rule.
  • Periodically review unassigned or stale rules and clean them up.
  • Combine Access Control with Policies for conditional enforcement (amount thresholds, approvals, etc.).