TechPrufer
Get started
DataRobot
DataRobot logoDataRobot · Feature trail

Credential Broker for Agent Egress

1 post · Jul 2026

What this trail covers

The Credential Broker for Agent Egress system has been enhanced to support delegation chains, ensuring that the original principal's identity is preserved throughout multi-hop agent calls. This is achieved by adhering to RFC 8693 token exchange standards, specifically utilizing `sub` and `act` claims to maintain the original requester's identity and track the acting agent at each step. The system now actively prevents the 'confused deputy' problem by avoiding flattened tokens and enforcing scope. This post highlights the critical security implications of agents inheriting human credentials, leading to privilege escalation, lack of scoping, attribution issues, and difficult revocation. It argues for a shift from static, passport-like identity models to dynamic, runtime-decided authority for non-deterministic agents, emphasizing the need for a new IAM category to address this gap.

All DataRobot trails
  1. Credentials should never reach the modelIntroduced the concept of a credential broker as a security mechanism for agents. The broker acts as an intermediary, holding sensitive credentials and enforcing scoped access for agent outbound calls. This prevents raw tokens from ever reaching the model process, thereby mitigating credential exfiltration risks associated with prompt injection. The post outlines the broker's function, contrasts it with less secure patterns, and emphasizes the importance of treating the egress path as an enforcement point.
  2. Delegation chains, the confused deputy, and the protocols you actually deployThis post details the implementation of delegation chain preservation within the agent system, directly addressing the 'confused deputy' problem. It explains how the system now uses RFC 8693 token exchange with `sub` and `act` claims to track the original principal and nested actors across agent-to-agent and agent-to-tool calls. The post highlights the critical role of the Model Context Protocol (MCP) and Agent Cards in enforcing scoped, per-tool authorization, preventing over-granting of permissions by ensuring tools authorize against the original principal's context rather than just the immediate agent's.
  3. Your agents are using your credentials, and that is the problemThis post identifies a critical security flaw in current agent deployments: agents inheriting human credentials, leading to privilege escalation, lack of scoping, attribution problems, and complex revocation. It argues that traditional IAM models, designed for stable human or service accounts, are ill-suited for non-deterministic agents. The core technical contribution is the articulation of the problem and the conceptual shift required: moving from static, design-time identity grants to dynamic, runtime-decided authority for agents. It highlights the failure modes of common workarounds like key rotation and service accounts, and points towards the need for a new IAM category that can handle agents as distinct, non-deterministic actors.
  4. Your identity stack was built for two kinds of actor. Agents are a third.This post introduces the concept of a third actor type for identity and access management: agents. It highlights the security risks of agents borrowing human credentials and outlines a series of posts that will detail a solution involving distinct agent identities, secure credential management, auditable delegation chains, and lifecycle management. The post also provides immediate checks for existing systems: identifying human API keys used by non-human processes, verifying audit log separation of agent and human actions, and confirming independent agent revocation capabilities.