Trusted context
What the PEP writes in context.chokepoint and why no mapping can change it.
A mapping can come from the schema of a third-party tool. So Xokepoint treats the mapping as untrusted input: it decides what the resource is, but it does not decide who is asking or which tool is being called. That information comes from places the PEP already verified, and the PEP writes it in context.chokepoint after the projection, overwriting anything the mapping put there.
The actor is the agent from act.sub. The tool is the MCP server and tool name pair of the validated call. The arguments are the original ones, already checked against the approved schema. The limits are the instance limits (context.chokepoint.limits): they come from the authorization_details of the verified token (RFC 9396), only from the entry for the tool of this call. With them go the workspace and environment of the call, the subject's identity connection and the catalog revisions used in validation.
Two values say how the token was obtained:
| Field | Values | Source |
|---|---|---|
context.chokepoint.subject.presence | headless (token exchange) or interactive (harness login) | Written by the AS from the grant that issued the token, never from a client value |
context.chokepoint.binding | dpop or none | dpop when the token has cnf.jkt and the call carried a valid DPoP proof |
A call condition can read them, for example to allow a destructive tool only with a person present (Conditions).
The actor and the tool are what the PDP uses to ask OpenFGA whether the agent can call the tool. If a mapping could change the tool, a malicious schema would make the question be about a harmless tool while execution calls another one. That is why the tool of the tool#can_call relation always comes from the validated call, never from the mapping.
AuthZEN keeps its standard meaning: subject is the subject, resource is the resource. The actor, the tool and the limits stay in the context, controlled by the backend.