AuthZEN MCP Profile Proposal

[embesozzi]

AuthZEN MCP Profile

Author: @embesozzi
Status: Draft
Type: Feature Proposal
Created: 2026-02-04

Context

The Model Context Protocol (MCP) enables AI assistants to discover and invoke tools, resources, and prompts from MCP Servers. MCP Servers and MCP Gateways are natural AuthZEN Policy Enforcement Points (PEPs).

An MCP Gateway executes authorization filters before forwarding the MCP request to the target MCP Server, and can execute filters before returning the response to the caller. AuthZEN filters are meant to execute with very low latency, since they are in the execution path of every MCP request. The purpose of an AuthZEN filter in the MCP context is to translate between the MCP JSON-RPC Information Model and the AuthZEN Evaluation Request format.

This profile provides a standardized mapping that developers can use to enable MCP Servers and Gateways to become AuthZEN clients.

Scope

This profile focuses on the MCP JSON-RPC transport, specifically the standard MCP methods:

• tools/call - Invoke a tool
• tools/list - List available tools
• resources/read - Read a resource
• resources/list - List available resources
• resources/subscribe - Subscribe to resource changes
• resources/unsubscribe - Unsubscribe from resource changes
• prompts/get - Get a prompt
• prompts/list - List available prompts

This profile primarily addresses the tools/call method with detailed examples, and provides mappings for other methods.

Scenarios

This profile covers two authorization scenarios for MCP:

Medium-Grained Authorization

Answering the question: "Can this subject invoke this MCP tool?"

In this scenario, the gateway authorizes access to the tool based on its identity without considering the specific arguments. This provides defense-in-depth by ensuring users can only access tools they are authorized to use, regardless of input parameters.

Fine-Grained Authorization

Answering the question: "Can this subject invoke this MCP tool with these specific arguments?"

In this scenario, the gateway extracts the tool arguments and includes them in the AuthZEN evaluation request, enabling the PDP to make context-aware decisions based on resource attributes, environmental factors, and dynamic policy conditions.

MCP Information Model

The MCP JSON-RPC protocol defines the following semantically important elements that need to be mapped to the AuthZEN information model:

• JSON-RPC method name (e.g., tools/call, resources/read)
• Request parameters:
  • Tool/resource/prompt name
  • Arguments/parameters
  • Session context
• Connection metadata
• Authentication tokens (OAuth Access Token)

Since MCP has adopted OAuth 2.1 as the security standard, I’m assuming that the MCP Server or Gateway acts as an OAuth Resource Server.

Mappings

AuthZEN's information model defines a subject, action, resource, and context for a well-formed AuthZEN payload. The mappings for MCP are given below.

Subject

An authenticated MCP call typically contains an Authorization header with an OAuth 2.1 Bearer token (JWT). The subject of the authorization request is identified by claims in that token.

Subject: Case Human (On-Behalf-Of User)

The MCP Server / MCP Gateway validates the JWT in the Authorization header as part of its request processing and extracts claims such as sub, preferred_username, etc.

The gateway formats the subject in the AuthZEN request as follows

{
  "subject": {
    "type": "user", // or identity
    "id": "<JWT.sub or JWT.preferred_username>"
  }
}

Another example for adding standard claims, such as Authentication Context Reference (acr) and Authentication Mechanism Reference (amr), to the AuthZEN request as follows:

{
  "subject": {
    "type": "user",  // or identity
    "id": "<JWT.sub or JWT.preferred_username>",
    "properties": {
      "acr": "<JWT.acr>",
      "amr": ["<JWT.amr>"]
    }
  }
}

Subject JWT Mapping

JWT Claim	AuthZEN Field	Description
sub	subject.id	Subject identifier
preferred_username	subject.id	Human-readable username (preferred over sub)
acr	subject.properties.acr	Authentication Context Class Reference
amr	subject.properties.amr	Authentication Methods References

Subject: Case Non-Human Identity (NHI)

In the case of NHI, an OAuth token can be issued to an agent, negotiated using client credentials or SPIFFE. In this scenario, the MCP server / gateway validates the JWT, it will have extracted claims such as `sub.

{
  "subject": {
    "type": "agent", // or ?
    "id": "<JWT.sub>"
  }
}

[TBD: In some cases, it can be useful to know that we are evaluating an agent rather than a user]

Action

The action.name field is required for an AuthZEN request. A compliant MCP Gateway passes the MCP method name as the action.name.

The MCP method name corresponds to the JSON-RPC method being invoked:

MCP Method	AuthZEN action.name
tools/call	tools/call
resources/read	resources/read
resources/list	resources/list
prompts/get	prompts/get
prompts/list	prompts/list

Example for tools/call:

{
  "action": {
    "name": "tools/call"
  }
}

Resource

The resource.type and resource.id fields are required for an AuthZEN request.
In the case of tool execution MCP Gateway maps the tool name.

MCP Element	AuthZEN Field	Value
-	resource.type	"mcp-tool", "mcp-resource", or "mcp-prompt"
Tool name	resource.id

[TBD: We should review the use cases for resources or prompts]
[TBD Not sure if we really need the syntax resource.type to be mcp-xxxx]

For example, if invoking the tool fintech_approve_expense:

{
  "resource": {
    "type": "mcp-tool",
    "id": "fintech_approve_expense"
  }
}

Resource Properties

The following information SHOULD be provided in resource.properties:

MCP Element	AuthZEN Field	Type	Description
Tool arguments	resource.properties.arguments	Object	Arguments passed to the tool
Resource parameters	resource.properties.parameters	Object	Parameters for resource access

Example with arguments:

{
  "resource": {
    "type": "mcp-tool",
    "id": "fintech_approve_expense",
    "properties": {
      "arguments": {
        "expense_id": "exp-123",
        "amount": 5000
      }
    }
  }
}

Context

An MCP request includes session and connection metadata that MAY be relevant for authorization. An MCP Gateway that complies with this profile MAY provide additional context in the context object.

MCP Element	AuthZEN Field	Description
Client information	context.client	Information about the MCP client
Connection metadata	context.connection	Connection metadata from handshake
Request timestamp	context.timestamp	When the request was received

Example:

{
  "context": {
    "client": {
      "name": "Claude Desktop",
      "version": "1.0.0"
    },
    "connection": {
      "transport": "http",
      "session_id": "session-abc123"
    }
  }
}

Complete Example: tools/call

MCP Request

POST /mcp HTTP/1.1
Host: mcp-gateway.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiZW1haWwiOiJqb2huLmRvZUBhY21lY29ycC5jb20iLCJuYW1lIjoiSm9obiBEb2UiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiYW5hbHlzdCJdfSwib3JnYW5pemF0aW9uIjoiZmluYW5jZS1kZXB0IiwiYWNyIjoiaW5oZXJlbmNlIiwiYW1yIjpbInBhc3NrZXlzIl19.k4SjE4EeFX9QVZx7YnB1TQ
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "request_12345",
  "method": "tools/call",
  "params": {
    "name": "fintech_approve_expense",
    "arguments": {
      "expense_id": "exp-123",
      "amount": 5000
    }
  }
}

JWT Payload

{
  "sub": "1234567890",
  "email": "john.doe@acmecorp.com",
  "preferred_username": "john doe",
  "name": "John Doe",
  "realm_access": {
    "roles": ["analyst"]
  },
  "organization": "finance-dept",
  "acr": "inherence",
  "amr": ["passkeys"],
  "iat": 1516239022
}

AuthZEN Evaluation Request

{
  "subject": {
    "type": "user",
    "id": "1234567890",
    "properties": {
      "preferred_username": "john doe",
      "email": "john.doe@acmecorp.com",
      "roles": ["analyst"],
      "tenant": "finance-dept",
      "acr": "inherence",
      "amr": ["passkeys"]
    }
  },
  "action": {
    "name": "tools/call"
  },
  "resource": {
    "type": "mcp-tool",
    "id": "fintech_approve_expense",
    "properties": {
      "arguments": {
        "expense_id": "exp-123",
        "amount": 5000
      }
    }
  },
  "context": {
    "client": {
      "name": "Claude Desktop",
      "version": "1.0.0"
    },
    "connection": {
      "session_id": "session-abc123"
    }
  }
}

AuthZEN Evaluation Response

{
  "decision": true
}

Additional Examples

Example: resources/read

MCP Request

{
  "jsonrpc": "2.0",
  "id": "request_67890",
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/docs-server/documents/annual-report-2024.pdf"
  }
}

AuthZEN Evaluation Request

{
  "subject": {
    "type": "user",
    "id": "embesozzi",
    "properties": {
      "roles": ["analyst"],
      "tenant": "finance-dept"
    }
  },
  "action": {
    "name": "resources/read"
  },
  "resource": {
    "type": "mcp-resource",
    "id": "file:///project/src/docs-server/documents/annual-report-2024.pdf",
    "properties": {
      "parameters": {}
    }
  }
}

Example: prompts/get

MCP Request

{
  "jsonrpc": "2.0",
  "id": "request_11111",
  "method": "prompts/get",
  "params": {
    "name": "finance_summary",
    "arguments": {
      "period": "Q4-2024",
      "department": "sales"
    }
  }
}

AuthZEN Evaluation Request

{
  "subject": {
    "type": "user",
    "id": "xxxxxxx",
    "properties": {
      "roles": ["analyst"],
      "tenant": "finance-dept"
    }
  },
  "action": {
    "name": "prompts/get"
  },
  "resource": {
    "type": "mcp-prompt",
    "id": "finance_summary",
    "properties": {
      "arguments": {
        "period": "Q4-2024",
        "department": "sales"
      }
    }
  }
}

Example: tools/list

MCP Request

{
  "jsonrpc": "2.0",
  "id": "request_22222",
  "method": "tools/list"
}

AuthZEN Evaluation Request

{
  "subject": {
    "type": "user",
    "id": "xxxxxxx",
    "properties": {
      "roles": ["analyst"],
      "tenant": "finance-dept"
    }
  },
  "action": {
    "name": "tools/list"
  },
  "resource": {
    "type": "mcp-tool",
    "id": "*"  // ?
  }
}

Example: resources/list

MCP Request

{
  "jsonrpc": "2.0",
  "id": "request_33333",
  "method": "resources/list"
}

AuthZEN Evaluation Request

{
  "subject": {
    "type": "user",
    "id": "embesozzi",
    "properties": {
      "roles": ["analyst"],
      "tenant": "finance-dept"
    }
  },
  "action": {
    "name": "resources/list"
  },
  "resource": {
    "type": "mcp-resource",
    "id": "*"  // ?
  }
}

When decision is true, the MCP Gateway forwards the request to the target MCP Server. When decision is false, the MCP Gateway MUST return a JSON-RPC error response:

{
  "jsonrpc": "2.0",
  "id": "request_12345",
  "error": {
    "code": -32000,
    "message": "Request denied due to authorization policy"
  }
}

References

• AuthZEN Authorization API 1.0
• Model Context Protocol Specification

[embesozzi]

Another option I considered is to use the MCP params.name as the AuthZEN action.name and the MCP params.arguments as the AuthZEN properties.

[baboulebou]

Thanks Martin, this is a great start. The tricky part here is indeed the semantics of the authzen call. I'm actually working now on smthg similar for A2A, which uses very similar JSON-RPC messaging.

The trick/pb is: your actions include the actual resource type, e.g., tools/call and then in resource: type": "mcp-tool", -> we know the type is tool because of the action. It's fine conceptually, but may seem redundant.

Another thing to consider, given the reliance of MCP (and A2A) on OAuth, we could imagine using scope for the requests. For example, a client may request scopes: mcp-tool:fintech_approve_expense", mcp-prompt:finance-summary,... these would then translate nicely to resource objects, with a generic action invoke for example...

One last thing: to me the "Get Tool List" call is not an evaluate but a Resource Search (i.e., get me the list of all the tools I have access to).

Anyway we should discuss all these semantics with the group, but this provides a good basis for these talks.

[embesozzi]

Hi @baboulebou, thanks for the feedback. Some comments below:

The trick/pb is: your actions include the actual resource type, e.g., tools/call and then in resource: type": "mcp-tool", -> we know the type is tool because of the action. It's fine conceptually, but may seem redundant.

Yes, I agree. We should review that point.

Another thing to consider, given the reliance of MCP (and A2A) on OAuth, we could imagine using scope for the requests. For example, a client may request scopes: mcp-tool:fintech_approve_expense", mcp-prompt:finance-summary,... these would then translate nicely to resource objects, with a generic action invoke for example...

Yes, it could be an option. Another approach is to add the information as properties and let the PDP decide based on them (evaluating, for example, in the same call, the scopes and possibly additional user claims) , while keeping the mapping as simple as possible.

One last thing: to me the "Get Tool List" call is not an evaluate but a Resource Search (i.e., get me the list of all the tools I have access to).

Yesterday, in the meeting (and thanks to the AuthZEN members for taking the time to review the proposal), I tried to clarify that when I started writing the proposal, I was mainly thinking about an MCP Gateway profile.
As the work progressed, I realized there are many common points between an MCP Gateway and an MCP Server (keeping in mind that the MCP Server offers more flexibility), so I ended up describing both cases.
Focusing back on the MCP Gateway case: protecting MCP methods such as tools/call, resource/get, and prompts/get is more straightforward. The /list methods are more of a gray area for an MCP Gateway, since they are not easy to protect. In the proposal, I used "id": "*" as an example, though it’s not clear how much value that actually provides. I also tried not to add search functionality in order to keep things simple.

Nevertheless, this is just an initial proposal, and it would be great to continue the conversation within the WG.

[julioauto]

As I mentioned on the most recent call, I think there should be a parameter that helps identify the MCP server somehow. If we take the API Gateway profile as inspiration, this could be resource.properties.hostname or even resource.properties.URI. We probably need to be careful there because MCP has a concept of "local" servers using stdio, thus being transport agnostic, but I'm hoping we can still agree on identifiers for any case; I'm just not well-versed enough in MCP to fully flush out a suggestion 🙂