🚀Transform your business with AI-powered process optimization
📋 Architecture Decision Records
🔐 ADR-003: IDM and Agent Identity Separation

ADR-003: IDM and Agent Identity Separation

Status

✅ Accepted

Date

2024-01-15

Context

A critical architectural question arose about the relationship between centralized Identity & Access Management (IDM) systems and the Agent Identity component, particularly regarding:

  1. Provisioning and Deprovisioning: Who controls the agent lifecycle?
  2. Master Data Ownership: Which system is the source of truth for what data?
  3. Integration Boundaries: How do these systems work together without overlap?

The Question

"does the provisioning and deprovisioning process impact the agent's life cycle? IDM holds the master data about the ai agent?"

The Confusion

There was initially uncertainty about whether:

  • IDM should manage agent identity completely
  • Agent Identity component was redundant with IDM
  • The relationship between access control and agent characteristics

Decision

Establish clear separation of concerns between IDM and Agent Identity, with each system owning distinct aspects of agent management while working together through well-defined integration points.

Responsibility Boundaries

IDM (Identity & Access Management) - Master of Access:

  • Authentication (who can access)
  • Authorization (what can be accessed)
  • Access provisioning and deprovisioning
  • Security policies and compliance
  • Audit logs for access events

Agent Identity Component - Master of Agent Characteristics:

  • Agent intrinsic properties (type, capabilities, version)
  • Operational lifecycle state
  • Agent-specific configuration and metadata
  • Performance and behavioral data
  • Agent operational history

Rationale

Why Separation Makes Sense

  1. Different Problem Domains:

    • IDM solves "access control" problems
    • Agent Identity solves "operational identity" problems

  2. Different Data Types:

    • IDM: Permissions, roles, credentials, access policies
    • Agent Identity: Capabilities, configurations, operational state, performance metrics

  3. Different Lifecycle Concerns:

    • IDM: Security lifecycle (provision access → monitor → revoke)
    • Agent Identity: Operational lifecycle (requested → active → retired)

  4. Different Performance Requirements:

    • IDM: Security-first, audit-focused
    • Agent Identity: Performance-first, operations-focused

Real-World Analogy

Think of an employee in a company:

  • IDM = Access Badge: Employee ID, building access, system permissions
  • Agent Identity = Job Description: Role, skills, current projects, performance

Both are essential, but they serve different purposes and contain different information.

Consequences

Integration Pattern

Coordinated but Independent Systems:

Lifecycle Integration

Provisioning Flow:

  1. Business requests new agent
  2. Agent Identity: Creates agent record (state: "Requested")
  3. Agent Identity: Requests IDM provisioning
  4. IDM: Creates service account and permissions
  5. IDM: Notifies Agent Identity "provisioning complete"
  6. Agent Identity: Transitions to "Configuring" → "Active"

Deprovisioning Flow:

  1. Business requests agent retirement
  2. Agent Identity: Transitions to "Retiring"
  3. Agent Identity: Completes operational cleanup
  4. Agent Identity: Notifies IDM "ready for deprovisioning"
  5. IDM: Revokes access and removes account
  6. Agent Identity: Transitions to "Decommissioned"

Master Data Distribution

No Single Master: Each system owns its domain

IDM Master Data:
  - Service account credentials
  - Role assignments
  - Permission matrices
  - Access audit logs
  - Compliance records
 
Agent Identity Master Data:
  - Agent type and capabilities
  - Operational configuration
  - Performance metrics
  - Task execution history
  - Component health data

Event-Driven Synchronization

Bidirectional Communication:

IDM → Agent Identity Events:
  - "provisioning_started"
  - "provisioning_complete"  
  - "access_revoked"
  - "emergency_lockout"
 
Agent Identity → IDM Events:
  - "agent_ready_for_access"
  - "maintenance_mode_entered"
  - "ready_for_deprovisioning"
  - "operational_failure"

Positive Outcomes

✅ Clear Boundaries: Each system has well-defined responsibilities ✅ Security Without Complexity: IDM focuses on security, Agent Identity on operations ✅ Independent Evolution: Systems can evolve at their own pace ✅ Proper Specialization: Each system optimizes for its domain ✅ Failure Isolation: Problems in one system don't break the other

Implementation Details

Data Binding Pattern

// Agent Identity links to IDM but doesn't duplicate IDM data
pub struct AgentIdentity {
    // Agent-specific data (owned by Agent Identity)
    pub agent_id: AgentId,
    pub agent_type: AgentType,
    pub capabilities: Vec<Capability>,
    pub lifecycle_state: LifecycleState,
    
    // IDM binding (reference, not data duplication)
    pub external_identities: HashMap<String, ExternalIdentity>,
}
 
pub struct ExternalIdentity {
    pub system: String,           // e.g., "corporate_ldap"
    pub identity: String,         // e.g., "svc-agent-001"
    pub binding_type: BindingType,
    pub status: BindingStatus,
    // No credential data stored here
}

State Synchronization Rules

Synchronization Rules:
  idm_provisioning_started:
    agent_state: "Requested" → "Provisioning"
    
  idm_provisioning_complete:
    agent_state: "Provisioning" → "Configuring"
    
  agent_ready:
    agent_state: "Configuring" → "Active"
    
  idm_access_revoked:
    agent_state: any → "Suspended"
    
  agent_retiring:
    trigger: "idm_deprovisioning_request"

Follow-up Actions

Completed

  • ✅ Created comprehensive IDM and Agent Identity Integration guide
  • ✅ Defined clear responsibility boundaries
  • ✅ Documented integration patterns and data flows
  • ✅ Established event-driven communication model

Architecture Design

  • 📋 Design IDM connector interface in Agent Identity component
  • 📋 Define event schemas for IDM ↔ Agent Identity communication
  • 📋 Create failure handling procedures for integration issues

Documentation

  • 📋 Update all component architectures to reflect this separation
  • 📋 Create integration testing guidelines
  • 📋 Document operational procedures for both systems

Lessons Learned

  1. Clarifying Questions Are Crucial: The user's questions led to much clearer architecture
  2. Avoid Functional Overlap: Different systems should solve different problems
  3. Integration ≠ Duplication: Systems can work together without duplicating responsibilities
  4. Event-Driven Integration: Loose coupling through events provides flexibility

Impact on System Design

Agent Identity Component

  • Focused Mission: Purely operational agent concerns
  • Performance Optimized: No security overhead in identity operations
  • Simplified Data Model: No credential or permission data

IDM Integration

  • Standard Patterns: Uses established enterprise IDM integration patterns
  • Security Focused: Specialized for access control and compliance
  • Enterprise Ready: Fits into existing security infrastructure

Overall Architecture

  • Separation of Concerns: Clean boundaries between security and operations
  • Scalability: Each system can scale independently
  • Maintainability: Easier to maintain and evolve separate systems

Related Decisions

  • ADR-002: Agent Identity Scope Limitation (removed relationships, now removes IDM overlap)
  • ADR-004: Configuration Management (similar separation of concerns principle)

This decision established the foundational principle that different systems should own different types of data and solve different problems, even when they need to work together closely.

🆔 ADR-002: Agent Identity Scope Limitation⚙️ ADR-004: Centralized Configuration Management