Delegated Agents - Research

Overview

As large language models evolve from chat interfaces into autonomous agents capable of executing multi-step workflows, a critical challenge emerges: how do we delegate real-world authority to an AI system without relinquishing control?

This paper proposes a Delegated Agent Framework—a set of architectural patterns and security primitives that allow a human principal to grant bounded, revocable authority to an AI agent. The framework ensures every action is auditable, every credential is isolated, and every delegation chain terminates at a well-defined trust boundary.

Problem

Current agent architectures suffer from several fundamental issues when deployed in production environments:

Ambient authority — agents inherit the full credential set of the user, far exceeding the permissions needed for any single task.
Opaque action chains — multi-step workflows produce side effects that are difficult to trace back to a specific delegation decision.
No revocation path — once an agent is granted access, there is no standard mechanism to narrow or revoke that access mid-task.
Trust transitivity — agents that call sub-agents propagate trust implicitly, creating unbounded delegation chains.

These problems compound as agent autonomy increases. A booking agent that can read your calendar, send emails, and charge your credit card holds more ambient authority than most human assistants—yet operates with fewer guardrails.

Proposed Solution

The Delegated Agent Framework introduces three core primitives:

1. Delegation Tokens

Short-lived, scoped credentials that encode exactly what an agent is allowed to do. Each token specifies permitted actions, target resources, time-to-live, and maximum cost. Tokens are cryptographically signed by the delegating principal.

2. Action Ledger

An append-only log of every action taken by every agent in a delegation chain. Each entry references the delegation token that authorized it, creating a full audit trail from principal decision to system side-effect.

3. Trust Boundaries

Explicit checkpoints where delegation chains must be re-authorized. When an agent needs to call a sub-agent, the trust boundary enforces scope narrowing—the sub-agent can never receive more authority than its parent holds.

Architecture

The system is composed of four layers:

Principal Layer

The human user (or an authorized system) that initiates a task and creates the root delegation token. This layer owns the master credentials and defines the maximum authority envelope.

Orchestration Layer

A coordination service that receives delegation tokens, spawns agent instances, and manages the action ledger. It enforces token validation before any agent can execute.

Agent Layer

Individual agent instances that perform specific tasks. Each agent receives a scoped delegation token and can only interact with resources permitted by that token. Agents may request sub-delegations through the orchestration layer.

Resource Layer

External systems (APIs, databases, file systems) that validate delegation tokens before granting access. Resources enforce the principle of least privilege at the boundary.

Principal
    |
    v
[Delegation Token: scope=calendar.read, ttl=300s]
    |
    v
Orchestrator  -->  Action Ledger
    |
    v
Agent-A (calendar.read)
    |
    +--[Sub-delegation: scope=email.draft, ttl=60s]
    |       |
    |       v
    |   Agent-B (email.draft)
    |
    v
Resource Layer (Calendar API, Email API)

Security Considerations

The framework addresses several threat models:

Token Theft

Delegation tokens are short-lived and scoped. Even if intercepted, a stolen token can only perform the specific actions it was issued for, within its TTL window. Tokens include a binding to the agent instance ID, preventing replay from a different context.

Privilege Escalation

The trust boundary layer enforces monotonic scope narrowing. A sub-agent cannot request permissions beyond what its parent holds. The orchestrator validates every sub-delegation request against the parent's active token.

Prompt Injection

Because agents operate with scoped tokens rather than ambient credentials, a successful prompt injection is limited to the authority granted by the current token. The action ledger provides forensic data to detect and investigate anomalous behavior.

Audit & Compliance

The append-only action ledger satisfies common audit requirements. Each entry includes timestamp, agent ID, delegation token hash, action type, target resource, and result status. The ledger can be exported to SIEM systems for real-time monitoring.

Roadmap

Development of the Delegated Agent Framework follows a phased approach:

Phase 1 — Specification: Formalize the delegation token schema, action ledger format, and trust boundary protocol. Publish as an open specification.
Phase 2 — Reference Implementation: Build a reference orchestrator and SDK libraries (Python, TypeScript) for agent developers.
Phase 3 — Integration Pilots: Partner with agent framework providers to integrate delegation primitives into existing platforms.
Phase 4 — Ecosystem: Develop tooling for token inspection, ledger visualization, and compliance reporting.

Appendix

A. Delegation Token Schema (Draft)

{
  "version": "0.1.0",
  "issuer": "principal:mike@mfniv.com",
  "subject": "agent:booking-agent-01",
  "scope": ["calendar.read", "email.draft"],
  "resources": ["calendar:primary", "email:drafts"],
  "max_cost_usd": 0,
  "ttl_seconds": 300,
  "issued_at": "2026-02-07T12:00:00Z",
  "nonce": "a1b2c3d4",
  "signature": "..."
}

B. Related Work

OAuth 2.0 Scoped Tokens (RFC 6749)
SPIFFE / SPIRE for workload identity
Google Zanzibar for relationship-based access control
Capability-based security (E language, Capsicum)

C. Glossary

Principal — The entity that initiates delegation (typically a human user).
Agent — An autonomous process that acts on behalf of a principal.
Delegation Token — A scoped, time-limited credential authorizing specific actions.
Action Ledger — An append-only audit log of all agent actions.
Trust Boundary — A checkpoint where delegation chains must be re-authorized.