Agentic AI Governance: Managing Delegated Authority

As AI transitions from static text generation to autonomous systems that reason, call tools, retrieve confidential data, and modify external database states, ordinary output filtering or post hoc monitoring becomes insufficient.

Autonomous action requires runtime mediation based on delegated authority, not model capability.

The AI Governance and Evidence Infrastructure (AGEI) addresses this by dividing runtime control into Five Governance Planes and mandating Pre-Action Proof-Carrying Tool Execution.

No high-risk tool invocation proceeds without a valid, scoped, unexpired, action-bound proof bundle.

3. Delegated Authority in AGEI

Your proposed concept of agentic delegated authority—where a child agent can temporarily inherit or act under a parent agent's authority while remaining strictly restricted to its own scoped system access, with all spawning and delegation events tracked by the Lazy Capsule Materialization (LCM) process—is a core tenet of the AI Governance and Evidence Infrastructure (AGEI) architecture.

A delegated agent may exercise only the minimum authority jointly permitted by its delegation grant, its own immutable execution boundary, the active policy decision, and the target resource’s current state. Delegation cannot create, transfer, or amplify privileges that the delegating principal does not possess.

In your papers and diagrams, this exact relationship is modeled through several explicit layers and database schema contracts.

Access vs. Authority (The Core Boundary)

Your framework explicitly addresses the design constraint that "an agent may act under an agent's authority but has only the access that it has". Your architecture makes a sharp distinction between access and authority:

• The Access Blind Spot: Traditional security models look only at technical access (e.g., API keys, data connections) but ignore context. Just because an agent technically has access to read customer data does not mean it has the institutional authority to modify records or initiate transactions.
• The Authority Principle: Under your Proof-Carrying Dynamic Authority Model, an agent never operates with ambient system power. It must borrow bounded authority from a delegating principal. Even if a parent agent has high-level permissions, any child agent it delegates to remains constrained by its own tool sandbox and scoped tokens.

Relational Schema for Parent-Child Delegation

The database schema tracks these hierarchical relationships using first-class relational tables in the Agentic Governance family:

• agent_sessions: This table represents the runtime boundary of an agent session. It maps the acting agent via agent_principal_id and binds it directly to the spawning or delegating actor via delegating_principal_id. This defines the exact parent-child context for the session.
• agent_delegations: This table maps the scoped delegation chain. It cryptographically binds the delegating principal (the parent agent/user) and the agent principal (the child agent), recording the authority scope, purpose, validity window, and delegation token hash. This ensures that the parent agent’s list of created/delegated sub-agents is fully queryable and audit-ready.

Orchestration Agents and Agent-to-Agent Controls

In your Agent Classification and Governance Model, you categorized agents into nine functional classes. You specifically designed a category called the Orchestration Agent to govern multi-agent systems:

• Purpose: Coordinates multiple sub-agents, tools, systems, or workflows.
• Governance Focus: Centers heavily on authority inheritance, agent-to-agent controls, lineage preservation, and composite evidence. Your research notes that as delegation chains grow more complex, the evidence model must represent "inter-agent handoffs and chain-of-command" so that downstream actions remain attributable to the root request.

End-to-End Tracking via the LCM Process

The Lazy Capsule Materialization (LCM) process ensures that these nested agent actions do not choke the system with heavy logs while maintaining absolute verifiability:

1. Lightweight Footprints: As parent agents spawn child agents and initiate tool calls, the system continuously commits lightweight lifecycle receipts and delegation records (agent_delegations) containing canonicalized hashes of the session context.
2. Pre-Action Proof: Before a delegated agent executes a sensitive action, a pre_action_proof_bundle must be generated. This bundle binds the delegation_id, gate_evaluation_id, and context_hash. If the required proof bundle is missing or invalid, the tool execution is blocked.
3. Triggered Materialization: If an incident or audit occurs, the system uses receipt_links and ai_lifecycle_object_links to traverse the graph backwards, pulling together the complete, materialized evidence capsule—proving exactly which parent agent delegated what authority, to which child agent, under which policy version, and what action was ultimately executed.

4. Classifying Agents by Authority, Not Capability

We categorize agents into nine functional categories to apply proportionate, risk-based governance controls. Capability is irrelevant; what matters is their delegated authority to change state or access sensitive data.