[Feature Request] Add 'delegation_chain' to Subject for AI Agent and Multi-Actor Scenarios

Problem Statement

With the rise of AI agents and multi-actor systems, authorization decisions increasingly need to consider delegation chains — where one entity acts on behalf of another. Current AuthZen Subject structure cannot adequately express:

1. AI Agent scenarios: An AI agent (e.g., MCP server, browser automation tool) performs actions on behalf of a human user
2. Service-to-service delegation: Service A calls Service B on behalf of User X
3. Multi-agent orchestration: Agent A delegates to Agent B, which delegates to Agent C, all ultimately acting for a human user

Real-World Examples

Scenario	Chain	Current AuthZen Limitation
MCP Server	User → Claude → MCP Tool	Only one subject can be expressed
Browser Use	User → AI Agent → Browser	Cannot trace back to original user
Agentic Workflow	User → Orchestrator → Worker Agent	No way to enforce "human-in-the-loop" policies

---

Proposed Solution

Add an optional delegation_chain field to the Subject object:

{
  "subject": {
    "type": "agent",
    "id": "mcp-filesystem-server",
    "properties": {
      "agent_type": "mcp_tool"
    },
    "delegation_chain": [
      {
        "type": "user",
        "id": "alice@example.com",
        "properties": {
          "auth_time": "2024-12-29T10:00:00Z",
          "auth_method": "webauthn"
        }
      },
      {
        "type": "agent", 
        "id": "claude-assistant",
        "properties": {
          "model": "claude-3-opus",
          "session_id": "sess_abc123"
        }
      }
    ]
  }
}

Key Design Points

1. Optional field — Backward compatible, existing implementations unaffected
2. Ordered array — First element is the original actor (usually human), subsequent elements are delegates
3. Reuses existing Subject structure — Each chain element has the same type, id, properties structure
4. Aligns with RFC 8693 — Similar to OAuth Token Exchange act claim for delegation

---

Use Cases Enabled

1. Human-in-the-Loop Policy Enforcement

POLICY: "AI agents can only delete files if delegation_chain includes a human with role=admin"

2. Audit Trail

ACTION: File deleted
ACTOR: mcp-filesystem-server  
DELEGATION: alice@example.com → claude-assistant → mcp-filesystem-server

3. Scope Attenuation

POLICY: "Each delegation step can only have equal or lesser permissions than the previous"

4. Chain Depth Limits

POLICY: "Deny requests with delegation_chain.length > 3"

---

Relationship to Existing Standards

Standard	Concept	AuthZen Alignment
RFC 8693 (Token Exchange)	act claim for actor chain	delegation_chain serves similar purpose
XACML	Subject attributes	Extends Subject with delegation context
SPIFFE/SPIRE	Workload identity	Can be used as id in chain elements
OAuth 2.0	on_behalf_of flow	Delegation chain captures this relationship

---

Questions for the Working Group

1. Should delegation_chain be a top-level field in Subject or nested under properties?
2. Should there be a standardized type vocabulary (e.g., "user", "agent", "service", "device")?
3. How should PDPs handle missing delegation_chain — treat as single-actor or require explicit opt-in?
4. Should we define standard properties for chain elements (e.g., delegation_time, delegation_scope)?

---

References

• RFC 8693 - OAuth 2.0 Token Exchange — See act claim
• Model Context Protocol (MCP) — AI agent tool calling
• Anthropic's Computer Use — Browser automation agents
• OpenAI Agents — Multi-agent orchestration

No implementation files or tests are named. Start by reviewing the proposed Subject structure and the RFC 8693, XACML, SPIFFE/SPIRE, and OAuth references, then work through the listed design questions. Done means the working group has agreed on the field location, chain semantics, type vocabulary, and handling of missing chains.