Should `context.agent` be trust-anchored when derived from the validated token?

[arjun2075]

I’m working through an MCP authorization scenario where policy needs to evaluate both:

• the human principal on whose behalf an operation is being performed, and
• the specific agent/client performing that operation.

This seems adjacent to #492 and #483, but I think the question here is specifically about the trust semantics of the acting-agent identity rather than whether that identity should be represented.

COAZ-MCP models the two identities cleanly:

• subject.id represents the principal on whose behalf access is requested.
• context.agent represents the acting agent/client and may be populated from $token.?client_id.

For example, a declared mapping could contain:

{
  "subject": {
    "type": "identity",
    "id": "$token.sub"
  },
  "context": {
    "agent": "$token.?client_id"
  }
}

My understanding of the current trust model is:

• subject.id is the trust-anchored field in the COAZ-MCP binding.
• For a declared mapping, action, resource, context, and subject attributes other than verified subject.id are not authoritative for identity or privilege unless independently established by the PDP/PEP.

That leaves me unsure about the intended handling of context.agent.

Suppose the PEP has validated the access token and context.agent is derived specifically from the validated token’s client_id.

Should a PDP be able to use that value authoritatively for a policy such as:

Allow this user to perform the operation only when the acting agent/client is X.

Or is context.agent intentionally still considered untrusted under the declared-mapping model, requiring the PDP to obtain the agent/client identity independently from another trusted source?

The COAZ Framework appears to allow a binding to designate multiple trust-anchored fields. If the intent is for policies to reason about both principal identity and acting-agent identity, would it make sense for COAZ-MCP to trust-anchor context.agent when it is derived from an agreed validated-token claim such as client_id, with the PEP verifying or substituting it similarly to subject.id?

The distinction seems important for zero-trust agent authorization because the policy question can be:

May Alice perform this action?

and separately:

May Alice perform this action through this particular acting agent/client?

I may be missing an existing mechanism or intended pattern here, so clarification would be helpful before assuming that an additional trust anchor is needed.