Delegated AI agent task policy

The control gap

A verified agent should not convert one human delegation into standing authority for unrelated runs, resources, or purposes.

A delegation is an authorization statement from a logged-in person or service owner to one registered agent. The signed proof should include principal, project, delegator, task, session, run, purpose, and expiry. The agent cannot edit these fields during exchange. Choose an expiry that covers the run without creating an informal standing role.

This template still requires approval for the final issue creation because verified delegation and action approval answer different questions. Delegation proves that the agent may work on the task; approval reviews the exact repository, title, and side effect. Lower-risk actions can be automatically allowed under the same identity conditions when owners have validated them.

Create task identifiers in the system that owns the work: a ticket, incident, release, or support case. The signed delegation should reference that immutable identifier and a bounded purpose rather than copying its editable title. Endram can then connect the action receipt to the source of authority without trusting model narration.

If an orchestrator delegates to a child agent, preserve the entire chain and enforce monotonic narrowing. The child cannot add tools, repositories, customer accounts, or lifetime beyond the parent's grant. Cap chain depth so a deeply nested workflow cannot make human accountability impossible to reconstruct.

Test the task boundary with plausible adjacent work. A delegation for release 428 must not cover release 429; an incident investigation must not permit a general customer export. Closing or cancelling the upstream work item should revoke unfinished authority even when its original expiration time has not arrived.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "create_issue" rather than every operation exposed by the tool.
• Scope the target to the task and purpose approved by a human delegator and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

Delegated AI agent task policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: delegated-agent-task
match:
  identity_verified: true
  delegator: ["user:release-owner@example.com"]
  task: release-428
  purpose: "Create release follow-up issues"
  tool: github.create_issue
decision: require_approval

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted create_issue, including denied requests.
• The exact the task and purpose approved by a human delegator selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?