Issue-1640: Create delegation object and add it into ai_operation profile

[Aniak5]

Summary

Introduces a delegation object describing the durable authorization context under which an autonomous AI agent acts, and makes it consumable from data-plane events via the ai_operation profile. This is the authorization-context layer of the agentic-AI work tracked in #1640, complementing the agent-identity work in #1641.

A delegation is the grant a principal issues to an agent ("act on my behalf, within these bounds"). It persists independently of any single trace, session, or workflow instance, so the same delegation can be referenced across many events. Delegations reference a parent, forming a directed acyclic graph (DAG) that supports lineage queries across multi-agent compositions (re-delegation, sub-agent spawning).

What this adds

1. objects/delegation.json — the delegation object:

   • uid (required) — stable identifier for the delegation, minted by a trusted boundary (gateway/orchestrator) rather than asserted by the agent. All events under this delegation share it.
   • parent_uid (optional) — parent delegation, for re-delegation / sub-agent spawning. The transitive closure of parent references forms the ancestry DAG.
   • created_time (recommended) — when the delegation was issued.
   • issuer_uid (recommended) — the trusted boundary that minted the delegation; supports binding-integrity checks and correlates with metadata.product.uid on the corresponding delegation lifecycle event.

2. profiles/ai_operation.json — adds an optional delegation attribute so any AI-bearing data-plane event (tool call, file op, process launch, etc.) can be linked to the authority it was performed under. Enables queries like "show me everything this delegation did."

3. dictionary.json — adds the delegation (type delegation) and issuer_uid attributes. uid, parent_uid, and created_time already exist and are reused.

Scope notes

• This PR intentionally covers only the delegation object and its data-plane wiring. The lineage-graph objects (delegation_node, delegation_lineage) and control-plane events (delegation_activity, agent_activity) are deliberately out of scope here, since they depend on the ai_agent object from Add ai_agent object and extend ai_operation profile coverage #1641. They can follow once that lands.

[github-actions]

Schema Description Review

Automated suggestions for improving description clarity for LLM consumption. These are advisory — not required changes.

Looking at the current PR state compared to my previous review:

Previous Review Status

✅ All previous suggestions have been addressed: The descriptions for uid, parent_uid, and issuer_uid in the delegation object now use clearer language ("generated by a trusted system component", "parent-child relationship", "authorized component") instead of the previous technical jargon.

Current Review

Suggestions

1. Object/Class: ai_operation profile
   Attribute: delegation
   Issue: Description contains vague reference "this action" without clear domain context
   Current: "The delegation under whose authority this action was performed. Links the event to a durable authorization context independent of traces and sessions. Enables queries like 'show me everything this delegation did.'"
   Suggested: "The delegation under whose authority this AI operation was performed. Links the event to a durable authorization context independent of traces and sessions. Enables queries like 'show me everything this delegation did.'"

2. Dictionary: issuer_uid
   Attribute: issuer_uid
   Issue: "trusted boundary" is less precise than the resolved object-level description
   Current: "The unique identifier of the trusted boundary that issued a delegation or credential."
   Suggested: "The unique identifier of the trusted system component that issued a delegation or credential."

Summary

The delegation object descriptions are now much clearer after addressing the previous technical jargon. Only minor refinements needed: replacing "this action" with "this AI operation" for domain specificity, and aligning dictionary terminology with the resolved object descriptions.

[mikeradka]

I like the direction here. delegation fills a gap that is distinct from authorization, session, and iam_role: it represents the durable grant/mandate under which later events occur.

One consideration is that the object is currently described as a principal-to agent authorization context, but the fields only capture uid, parent_uid, created_time, and issuer_uid. issuer_uid identifies the trusted system that minted the delegation, not necessarily the principal whose authority was delegated. As written, producers can
correlate events to a delegation ID, but consumers cannot tell who/what delegated authority, who/what received it, or what bounds/scopes applied.

I’d also suggest making the core object wording less AI-specific. Delegation is broadly useful across cybersecurity events: OAuth delegated consent, cloud STS/AssumeRole, service-account automation, sudo/setuid/impersonation, scheduled jobs, SOAR/RPA actions, and AI agents. The ai_operation profile can keep the AI-specific description, but the dictionary/object description should probably describe a generic delegated authorization grant.

One additional placement thought: adding delegation only to ai_operation is fine for AI work, especially if #1641 broadens that profile coverage. But for general cybersecurity use, the natural long-term home may be actor.delegation or a generic delegated-authority profile, not only ai_operation.