Skip to main content

Authorization & Trust

This page is for operators and security teams who design egress access for AI agents. It explains how the HTTP Egress Proxy decides whether an agent's outbound request is allowed, how a person delegates access to an agent, and how revocation works.

An outbound request passes through two independent gates, and both must allow it. The same model governs Model Context Protocol (MCP) tool calls in the Permit MCP Gateway, and both use the same Permit policy environment.

On this page, the proxy is the HTTP Egress Proxy, the component that decides each outbound request. The gateway is the Permit MCP Gateway that hosts the proxy and holds the host configuration, the workflows, and the stored credentials.

The two authorization gates​

For an agent a person delegated access to, the proxy also applies that person's trust ceiling after the Permit policy check.

Gate 1: Workflow match​

Every proxy access token is bound to one API workflow. The proxy resolves the token's workflow, checks the request's target host against the workflow's domains, and finds the rules that match the request's path and method. The proxy denies a request that matches no rule, before any policy evaluation.

The workflow match is the operator-controlled allow-list: it decides which domains, paths, and methods an agent can request at all.

Gate 2: Permit.io policy​

For a request that matches a rule, the proxy asks your Permit.io policy whether the agent holds a role that authorizes the rule. Each rule is a Permit action on the workflow resource.

The rule declares the trust level a request must meet (its required trust). The method class decides only which rules a request can match. When you set required trust to Auto, the method class also sets the default level.

Each gateway host maps to a Permit environment, so you manage egress policies in the same place as your MCP policies. See Permit.io integration.

With two gates, an operator defines a workflow's domains and rules, and your central Permit policy decides which of those rules each agent may use.

One request through both gates​

Take the ship_pr workflow from Workflows and rules. Its *.github.com domain has three rules: open_tunnel (method class all, no path, low trust), read_repo (read, low trust), and push_commit (write, medium trust). An agent holds a token bound to ship_pr, delegated by a person whose ceiling on ship_pr is medium, and the person consented at medium.

The agent sends POST https://api.github.com/repos/acme/app/git/refs:

  1. Gate 1, workflow match. api.github.com matches the *.github.com domain. POST is in the write method class, so the request matches the push_commit rule. On an HTTPS domain in intercept mode, the open_tunnel rule authorizes the connection first, and the proxy then matches the decrypted request against push_commit.
  2. Gate 2, Permit.io policy. The proxy asks the Permit policy whether the agent holds a role that authorizes push_commit. The person's consent at medium granted that role, so the policy allows it.
  3. Trust ceiling. The requested level, medium, is not above the person's medium ceiling, so the proxy forwards the request to GitHub. An admin sets that ceiling per person and per workflow, as Trust ceilings describes.

Now take a person whose ceiling on ship_pr is low. Their consent caps at low, so the agent they authorize does not hold a role that authorizes the medium-trust push_commit rule, and gate 2 denies the same POST with HTTP 403. A DELETE to that host matches no rule at all and is denied at gate 1, before any policy evaluation. For the exact request commands, response headers, and deny codes, see Two requests against one workflow.

An agent often acts on behalf of a person. Egress requests use the same delegation model the gateway uses for MCP tool calls: a person explicitly authorizes an agent to make egress calls for them on one workflow, and a trust ceiling caps the access the agent gets through that person.

Trust ceilings​

An admin sets, per person and per workflow, the maximum trust level that person may delegate: low, medium, or high. Set that ceiling in the Permit MCP Gateway dashboard in either place:

  • On the workflow's detail page under CLIs / APIs, in the Authorized humans card: select Grant workflow access, choose the person, and set Max trust.
  • On the person's detail page under Humans, in the API workflow access card: add the workflow and set its max trust.

The per-workflow ceiling is separate from the per-MCP-server max trust level that step 6 of Host setup sets. The per-server level caps MCP tool calls; the per-workflow ceiling caps egress requests. A person needs a ceiling on a workflow before they can authorize any agent for it.

When a person consents to an agent, the agent receives the lower of two levels: the level the person grants and the admin's ceiling. A person cannot delegate more than their ceiling allows.

An agent that acts for several people does not combine their ceilings. Each person's ceiling caps only that person's delegation, so one person's grant cannot raise the access another person delegated.

To let a person delegate egress access to an agent, run the consent flow with the agent's client ID and the workflow slug:

asg proxy authorize <agent-client-id> --workflow charge_customers

asg proxy authorize opens a browser where the person completes these steps:

  1. Sign in. The person authenticates.
  2. Review the workflow. The consent screen shows the workflow's domains and rules that the agent requests.
  3. Choose an access level. The screen defaults to the lowest level and caps the choice at the admin's ceiling for that person and workflow.
  4. Approve. The Consent Service records the grant in Permit and issues a short-lived token for the agent, bound to the person and the workflow.

When the person approves, asg proxy authorize returns the token. If the person denies access or the flow times out, the command exits with code 1.

Two options change what the person is asked to delegate:

  • --workflow <slug> names the workflow. Omit it and the consent screen shows a picker of the workflows that person may delegate.
  • --trust low|medium|high lowers the cap offered on the screen below the person's ceiling. Omit it and the screen defaults to the lowest level and caps at the ceiling.

If the person has no ceiling on the workflow, or asks for a level above their ceiling, the Consent Service rejects the request with 403. For the remaining options, such as writing the token to a file, run asg proxy authorize --help or see the asg proxy command tree.

The resulting token's access depends on that person's consent, and the person can revoke it.

Revocation​

A person can revoke an agent's delegated access from the Your authorized agents page at /my-agents in their account at any time. Revocation removes the agent's policy assignment, so new authorization decisions for that agent fail.

A proxy token issued before the revocation stays valid until it expires, unless the person also selects Also deny tokens already in flight. That option denies every token minted before the revocation for the rest of the token's lifetime. Use it for a lost device or a compromised agent.

The proxy checks revocation only on requests it inspects. Traffic inside an open passthrough HTTPS tunnel is not re-checked, and continues until the client closes the tunnel or the idle timeout ends it. If revocation must stop an in-progress HTTPS connection, use intercept mode for that domain.

How automated agents differ​

Some agents, such as a CI job or a backend service, do not act for a person. Issue an agent like that a token directly with asg proxy token create --workflow <slug>, and skip the consent flow.

A directly issued token is not bound to a person, so no trust ceiling applies. The workflow's rules and the agent's own Permit policy govern its access.

Use direct tokens for machine-to-machine automation. Use the consent flow when a person is accountable for what the agent does.

Next steps​

Contents

Edit this page

Need help?