COAZ-MCP mapping
The standard that says how the arguments of an MCP tool become the resource of the AuthZEN question.
The default mapping treats the tool as the resource. That is enough for "can this agent call list_issues?", but not for "can this agent open an issue in acme/payments?". The real resource is in an argument, and only someone who knows the tool knows which one. COAZ-MCP is the standard that records this information: a mapping, written in CEL, that projects tool call arguments into the fields of the AuthZEN question.
A mapping that makes the repository the resource of a GitHub tool looks like this:
{
"resource": {
"type": "github_repository",
"id": "$params.arguments.repository"
}
}With it, create_issue with repository = acme/payments becomes a question about the github_repository resource with id acme/payments. The type tool keeps the meaning "there is no concrete resource": in that case the PDP only checks whether the agent can call the tool. Any other type also requires access to the resource. The type follows the format ^[a-z][a-z0-9_]{1,79}$, and the id must be a non-empty string; a missing id or one of another type blocks the call.
Where the mapping comes from
The mapping comes from the server itself, in the tool schema (inputSchema.x-authzen-mapping). When the reviewed schema declares none, the COAZ-MCP default applies:
The server declaration applies only after the administrator reviews the tool schema. If the mapping fails to evaluate, the call is blocked. Xokepoint does not fall back to the default: a broken mapping that fell back to the default would replace a resource check with a tool-only check, and that would open access.
Why CEL
CEL is an expression language with no side effects and no network access, with a bounded evaluation cost. The projection reads the token and the message and does nothing else. It does not fetch data, which is the job of the PIP, and it does not change the arguments that will be executed.