Deliverd compared with Permit.io

Permit.io decides if it may.
Deliverd asks who must say yes.

Permit.io is authorisation as a service: one check for role-, attribute- and relationship-based policy, policy kept as Rego or Cedar in your own repository, and a decision point that runs beside your app. For agents it adds a gateway in front of MCP servers and an access-request MCP server. Deliverd starts where a policy answer should not be the end of it: the action a named person has to own, and the record that they did.

Free to start · Approvers never need a seat · No card required

Human-in-the-loop infrastructure for AI agents. An agent asks a person for an approval, a review or an answer, and carries on when they respond. Below is how that compares with Permit.io, and where the two work together.

Credit where it is due

What Permit.io does well.

One check, three policy models

The same check covers role-, attribute- and relationship-based access, so the policy model can change without the calling code changing.

Policy in your own repository

Policies are generated as Rego or Cedar and pushed to your own Git repository, with a Terraform provider and a CLI for working through Git.

A decision point beside your app

The decision point runs as a container next to your service, so checks stay local, and it keeps answering from its local copy if the control plane cannot be reached.

A gateway in front of MCP servers

Deny by default, tools sorted into read, write and destructive, upstream sign-in tokens held by the gateway, and each decision logged with the person, the agent, the tool and the result.

The boundary

Where a person comes in.

  • An approval is a role change

    In the access-request MCP server, approving an operation gives the requester an _Approved_ role on the resource. To make it one-time, the documentation says your tool removes the role after the action succeeds.

  • Finding the request

    A reviewer finds a request in an embedded element or by listing requests through the API. The documentation does not describe reaching them by email, Slack, Teams or phone.

  • Who may approve

    An access request can be approved by asking an agent to call the approve tool, so keeping agents out of the decision is something your configuration has to do.

  • Approval at the gateway

    The gateway's documentation lists requiring a person's approval for high-risk tool calls, without describing who is asked, how they are reached, or what happens when nobody answers.

Every point above was read from Permit.io's page for developers, Permit.io's Access Request MCP overview and Permit.io's MCP Gateway documentation on 25 October 2026. Products change; if something here is out of date, tell us and we will correct it.

Where Deliverd fits

What Deliverd adds.

A named person, reached where they are

The request goes to a named person or group by email, browser push, Slack and Teams, and opens on a page built for a phone.

An agent never decides

An agent may not approve anything, and the requester is removed from their own request's approvers. Both are refused by the service.

Silence and absence handled

A request nobody answers escalates to more people and then expires, and a colleague can cover someone's approvals while they are away.

Allowed, refused, or a person decides

An agent declares an action at a gate. Rules on Business Starter, Business and Enterprise allow or refuse it on its arguments, and an action no rule settles goes to a person.

Proof the tool can check

A call the gate let through can carry a signed decision token, which the tool verifies with the SDK before acting, so arguments nobody agreed to are refused.

Evidence a regulator reads

Every decision exports in a signed evidence pack, beside an AI system register and the DORA register of information for AI providers.

Working together

Permit.io for permissions, Deliverd for the yes.

Keep Permit.io deciding what each agent may do across your application. Where the answer should be a person — a payment, a deploy, a message to a client — have the agent declare the action at a Deliverd gate or ask a named person directly. They are reached where they are, the agent carries on with their answer, and the decision is kept.

Questions.

  • Can Deliverd replace Permit.io?

    Not for application authorisation. Deliverd's rules are about consequential actions an agent declares, with conditions on their arguments. It is not a general role- or relationship-based permission system; use an authorisation engine for that.

  • Can Permit.io ask a person?

    Its access-request MCP server lets a user ask for access or a one-time operation and a reviewer approve it. Deliverd is built around that step: who is asked, how they are reached, what happens when nobody answers, and the record.

  • Does Deliverd run a decision point beside our app?

    No. Deliverd's gate is a hosted API. A tool can verify a signed decision token locally, without calling it.

  • Do approvers need a seat?

    No. Being asked never needs a seat, on any plan.

Ask the right person before the agent acts.

Approvals, reviews and requests from any agent, with the record kept. Free to start. No credit card.