Skip to main content

Access Request MCP overview

Learn how the Permit.io Access Request MCP server lets an AI agent ask for access or for approval of a sensitive action, and leaves the decision to a human reviewer. This page is for AI agent builders who decide whether their agent needs human approval, and how the server fits into the agent.

Why AI agents need human approval​

AI agents trigger workflows, change infrastructure, and read sensitive resources. That autonomy adds risks:

  • An agent can hallucinate an action or act beyond the permissions its user intended.
  • A vague or misleading prompt can lead to an action nobody wanted.
  • An action can run without an audit trail or a human decision.

A human-in-the-loop (HITL) workflow adds checkpoints where a human reviewer must approve a critical action before the agent performs the action. The Access Request MCP server implements these checkpoints with Permit policies and Permit Elements. The server covers the secure external access perimeter of the Four-Perimeter Framework.

What the Access Request MCP server does​

The Access Request MCP server is an open-source Model Context Protocol (MCP) server, permitio/permit-mcp. The server gives an agent tools that call the Permit API to:

  • Create, list, approve, and deny access requests: a user asks for a role on a resource, for example read access to a restaurant's menu.
  • Create, list, approve, and deny operation approvals: a user asks for one-time approval of an action on a resource, for example ordering an expensive dish.
  • List the resource instances of a resource type, so the agent can pass a valid instance key to the other tools.

For the parameters of each tool, see the tool reference.

How an access request flows through Permit​

  1. A user asks the agent for something the user isn't allowed to do. A permit.check() call in your tool returns a denial from the policy decision point (PDP), and the agent tells the user that access is required.
  2. The agent calls the create_access_request tool with the user, the role, the resource instance, and a reason. Permit stores the request in a User Management element.
  3. A reviewer approves or denies the request: in the embedded element, through the Permit API, or by asking an agent to call approve_access_request or deny_access_request.
  4. If the reviewer approves, Permit assigns the requested role to the user. The next permit.check() for that user and resource allows the action.

How an operation approval flows through Permit​

  1. The agent calls the create_operation_approval tool with the user, the resource instance, and a reason.
  2. A user with the _Reviewer_ role on the resource instance sees the request in the Approval Management element or lists the request with the list_operation_approvals tool.
  3. If the reviewer approves, Permit assigns the requesting user the _Approved_ role on the resource instance, which grants the operate permission. See Operation Approval.
  4. Your tool checks the operate permission before the action runs. To make the approval one-time, your tool unassigns the _Approved_ role after the action succeeds.

When to use the Access Request MCP server​

Use the Access Request MCP server when your agent:

  • Runs in an environment where sensitive actions must be logged and approved by a person.
  • Serves several users or roles, and each decision needs an accountable reviewer.
  • Needs permissions that change at runtime, based on user identity, context, or policy.
  • Isn't trusted to act on its own in production.

Common use cases:

  • Coding or security assistants that request elevated access for developers or security engineers.
  • Customer support agents that make account-level changes.
  • Internal assistants that trigger infrastructure updates.

To authorize every tool call between MCP clients and your MCP servers, without adding approval tools to the agent, use Permit MCP Gateway.

Next steps​

Contents

Edit this page

Need help?