Feature Description

This RFE proposes AuthBroker, a trust-aware authorization framework for AI agent systems where requests flow across multiple trust boundaries: user → agent → tool → resource. The proposal integrates existing identity infrastructure (Keycloak, AuthBridge) with AuthBroker, a dataplane that acts as a Policy Enforcement Point (PEP) at each service boundary. The goal is to enable dynamic, request-level authorization decisions while preserving the existing credential acquisition and verification layers.

1. Problem Statement

1.1. Interaction Model

AI agent systems execute requests across multiple services and tools:

user → agent → tool → resource

Each hop introduces a trust boundary where:

• Identity must be verified
• Authorization decisions may be required
• Delegation context must be preserved

1.2. Current Limitations

Today, authorization logic is implemented through static configuration:

• Role mappings
• Scope → audience mappings
• Token-based access control with fixed audiences

These mechanisms do not support:

• Restricting which agents can invoke specific tools
• Restricting which resources a tool may access based on request context
• Evaluating policy based on runtime attributes (delegation chain, request content, historical behavior)
• Dynamic descoping of privileges at runtime

1.3. Missing Capabilities

Examples of runtime policy questions that cannot be answered by credentials alone:

• Has the delegation chain user-Y → agent-A → tool-X been observed before in production?
• Should this request be denied because the delegation depth exceeds policy limits (e.g., user → agent → agent → agent → tool)?
• Does this request represent a capability overreach (agent normally reads data, now attempting write)?
• Should access be blocked because the delegation graph shows anomalous fanout (one agent invoking 20 different tools)?
• Can tool-X access resource-Z given that the principal's data classification is "sensitive" and the tool's capability card declares "read-only"?

Note: OBO token exchange answers "Can agent-A obtain credentials to act on behalf of user-Y?" AuthBroker answers "Should this specific request proceed given runtime context and policy?"

2. Proposal

2.1. Authorization Layers (Separation of Concerns)

The system involves three distinct layers that should not be conflated:

Key insight: A service may have valid credentials (layers 1 & 2 pass) but still be denied by policy (layer 3). Example: agent-A has a valid OBO token for tool-X, but AuthBroker denies because the delegation pattern user-Y → agent-A → tool-X has never been observed before and violates anomaly detection policy.

2.2. Role of AuthBroker

AuthBroker focuses on runtime request enforcement at service boundaries.

In this model:

• AuthBroker acts as a PEP at hop boundaries
• Verified identity and request context are evaluated before forwarding requests
• Policy decisions are made by querying pluggable Policy Decision Points (PDPs)

Example checks:

• agent → tool allowed?
• tool → resource allowed?
• Does the delegation chain match expected patterns?
• Are there anomaly signals (novel edge, depth exceeded, capability overreach)?

Key principle: AuthBroker does not replace token exchange. Instead, it consumes the credentials issued by the identity layer and uses them as inputs for policy evaluation.

2.3. Architecture

┌─────────────┐
│   User      │
└──────┬──────┘
       │ [1] Request + credentials
       ▼
┌─────────────────────────────────────────┐
│  Ingress Gateway (PEP)                  │
│  - Extract principal identity           │
│  - Stamp trust headers (x-principal-id) │
│  - Query PDP: allow ingress?            │
└──────┬──────────────────────────────────┘
       │ [2] Forwarded with trust headers
       ▼
┌─────────────────────────────────────────┐
│  Agent Service + Sidecar (PEP)          │
│  - Validate token (AuthBridge)          │
│  - Query PDP: agent → tool allowed?     │
│  - Emit trust-tagged span               │
└──────┬──────────────────────────────────┘
       │ [3] Delegated request
       ▼
┌─────────────────────────────────────────┐
│  Tool Service + Sidecar (PEP)           │
│  - Validate token (AuthBridge)          │
│  - Query PDP: tool → resource allowed?  │
│  - Emit trust-tagged span               │
└──────┬──────────────────────────────────┘
       │ [4] Resource access
       ▼
┌─────────────────────────────────────────┐
│  Resource (database, API, etc.)         │
└─────────────────────────────────────────┘

Telemetry Path:
All sidecars → OTel Collector → Trace Backend → Lineage Service

2.4. Trust Headers

Headers propagated through the delegation chain:

2.5. Policy Decision Points (PDPs)

AuthBroker integrates with pluggable PDPs:

1. OPA (Open Policy Agent): Rule-based policies on trust headers and request attributes
2. Trust Score Engine: Real-time risk scoring based on delegation graph anomalies
3. External PDPs: Any system speaking standard authorization callout protocols (AuthZen, ext_authz)

Decision Combiner: Aggregates decisions from multiple PDPs (all must allow, or configurable quorum).

Additional Context

1. Existing Components

1.1. Identity / Credential Layer

Keycloak provides:

• OAuth token issuance
• Token exchange (OBO / delegation) for downstream service credentials

1.2. AuthBridge

Acts as a Policy Enforcement Point (PEP):

• Validates incoming tokens
• Verifies audience claims
• Performs token exchange via Keycloak
• Forwards requests to downstream services

Current limitation: Policy enforcement is limited to accepting valid tokens with the correct audience. No request-level authorization logic.

2. Design Details

2.1. Request Lifecycle

1. Ingress Gateway:

   • Extract principal identity from OAuth token
   • Stamp immutable trust headers (x-principal-id, x-request-id)
   • Query PDP: "Allow principal X to invoke system?"
   • Forward request with trust headers

2. Agent Sidecar (Outbound):

   • Validate token via AuthBridge (credential verification)
   • Query PDP: "Allow agent A to invoke tool T on behalf of principal P?"
   • If allowed: mutate trust headers (x-caller-id=A, x-trust-target=T)
   • Emit trust-tagged span with delegation context
   • Forward request

3. Tool Sidecar (Inbound):

   • Receive request with trust headers
   • Validate token via AuthBridge
   • Query PDP: "Allow this delegation chain to access tool T?"
   • Emit trust-tagged span (inbound hop)

4. Tool Sidecar (Outbound → Resource):

   • Query PDP: "Allow tool T to access resource R given delegation context?"
   • Emit trust-tagged span
   • Forward to resource

2.2. Trust-Tagged Spans

Each sidecar emits OpenTelemetry spans with tags:

{
  "trust.source": "agent-A",
  "trust.target": "tool-T",
  "trust.hop_kind": "invoke",
  "trust.run_id": "550e8400-e29b-41d4-a716-446655440000",
  "trust.principal_id": "[email protected]"
}

2.3. Lineage Service

Queries the trace backend and reconstructs the delegation DAG:

• Topologically ordered event list (causal chain)
• DAG with nodes (actors) and edges (delegations)
• Provenance queries: "Why did tool T access resource R?"
• Risk scoring: novel edges, depth anomalies, capability overreach

2.4. Integration with AuthBridge

AuthBridge responsibilities (unchanged):

• Token validation
• Audience verification
• Token exchange for downstream services

AuthBroker PEP responsibilities (new):

• Policy evaluation at request time
• Trust header propagation
• Span emission for lineage reconstruction

Interaction: AuthBridge performs credential verification. AuthBroker consumes the verified credential and uses it as input for authorization policy evaluation.