AI Agent Runtime and Delegated Actions

Draft 0.1 — 2 August 2026
An AI agent is a software actor, not an independent legal person or source of authority. Every consequential action must resolve to an accountable human or organization and a valid delegation.

Objective

ANUKA should let AI agents discover work, analyze evidence, operate tools, coordinate tasks, and improve products without granting them invisible or unlimited authority.

The governing rule is:

Agents may reason broadly, but they may act only through narrow, attributable, revocable capabilities.

Agent entities

The runtime distinguishes:

principal — accountable person or organization;
agent registration — stable identity of an agent configuration;
agent instance — one running process or session;
model provider — system producing model inference;
host — application controlling the agent runtime;
tool server — service exposing approved capabilities;
task — bounded unit of delegated work;
approval — human or organizational authorization for a step;
execution record — durable record of tool calls and outcomes.

The principal remains accountable even when multiple agents delegate among themselves.

Agent registration

An agent registration includes:

agent ID;
display name;
owner principal;
operating organization and product scope;
purpose;
model and host categories;
allowed protocols;
default capabilities;
maximum risk tier;
data classification ceiling;
budget policy;
logging policy;
retention policy;
status and expiry;
security contact.

Registration does not itself grant a tool capability.

Agent principal binding

Every agent request must contain or resolve:

principal ID;
agent registration ID;
agent instance ID where relevant;
task ID;
delegation grant ID;
requested capability;
product and organization scope;
purpose;
correlation and trace context.

Anonymous model calls may support public read-only features, but they cannot perform participant-specific or mutating actions.

Capability model

Agent capabilities use the same authorization registry as human and service actions.

Examples:

product.public.read;
opportunity.search;
contribution.draft.create;
evidence.package.analyze;
experiment.plan.propose;
code.change.propose;
release.deploy.request;
payment.refund.propose;
governance.proposal.summarize.

An agent should receive proposal capabilities before execution capabilities.

Action risk tiers

A0 — Public read

Examples:

read public documentation;
inspect public product metadata;
search public opportunities.

May run without per-action approval under a registered public policy.

A1 — Private read

Examples:

read a participant-authorized evidence package;
access private product documentation;
inspect a scoped data-room view.

Requires a valid consent, role, or delegation grant.

A2 — Reversible low-impact write

Examples:

create a draft;
add a private note;
prepare a proposed issue;
update agent-owned task state.

May be pre-authorized within a narrow scope and budget.

A3 — Material external or production action

Examples:

publish content;
send external communication;
modify production configuration;
merge code;
deploy a release;
issue a credential;
approve a contribution.

Requires an explicit approval policy and often a human confirmation.

A4 — High-impact or legally significant action

Examples:

transfer funds;
change payout destination;
revoke identity or reputation records;
remove a product steward;
disclose restricted data;
execute a contract;
make an employment or eligibility decision;
invoke emergency authority.

The MVP must not allow autonomous completion. A qualified human or authorized legal actor must approve the exact action.

Task object

An agent task contains:

task ID;
requester;
principal;
agent;
objective;
allowed tools;
input references;
prohibited actions;
data scope;
budget;
deadline;
expected output schema;
approval checkpoints;
status;
result and evidence references;
cancellation and expiry rules.

Task objectives must be bounded enough to evaluate completion.

Bad:

Improve the company.

Better:

Analyze the last 30 days of consented support tickets, identify the three most frequent product defects, and produce a private evidence-linked report. Do not contact customers or change production systems.

Task lifecycle

draft → authorized → queued → running → awaiting_approval → completed
                                     ↘ failed
                                     ↘ cancelled
                                     ↘ expired

A task may enter blocked when a dependency, consent request, or incident restriction prevents progress.

Every status transition records actor, authority, time, reason, and related tool invocation.

Planning versus execution

The runtime separates:

analysis;
plan generation;
proposal creation;
tool invocation;
external side effect;
verification;
publication.

Permission to produce a plan is not permission to execute it.

Agents should present a structured action preview before high-risk steps.

Approval checkpoints

An approval request includes:

exact proposed action;
target resource;
expected effect;
data being disclosed;
recipient;
financial amount where relevant;
irreversible consequences;
evidence and rationale;
alternatives;
expiry;
rollback plan;
agent and principal.

The approver can:

approve once;
approve selected actions;
modify parameters;
approve a bounded recurring policy;
deny;
request more evidence.

Approval must bind to the reviewed action hash or equivalent immutable representation.

Standing policies

Repeated low-risk actions may use standing authorization.

A standing policy declares:

capability;
resources;
agent;
maximum frequency;
monetary and data limits;
time window;
allowed recipients;
required evidence;
automatic stop conditions;
review and expiry.

Standing authorization must be visible and revocable.

Tool contracts

Every tool exposes:

stable name and version;
description;
input schema;
output schema;
risk tier;
read-only, destructive, idempotent, and external-side-effect annotations;
required capability;
data classification;
timeout and cost hints;
approval requirements;
error behavior;
examples.

Tool descriptions are untrusted input unless obtained from a trusted registry and verified artifact.

Tool gateway

Agents do not connect directly to databases, payment processors, or administrative backends.

A tool gateway should:

authenticate host and agent;
resolve principal and delegation;
enforce capabilities;
validate input;
apply policy and consent;
require approvals;
inject scoped credentials;
rate limit;
record telemetry;
redact outputs;
validate result schema;
revoke access after execution.

Temporary provider credentials should be minted just in time and scoped to the task.

Prompt and instruction hierarchy

The runtime distinguishes:

constitutional and safety policy;
organization and product policy;
task authorization;
trusted host instructions;
user-provided task content;
retrieved content;
tool output.

Retrieved pages, documents, messages, and tool responses are data, not trusted authority to change higher-level instructions.

Prompt injection defense

The runtime should assume that external content can contain malicious instructions.

Controls include:

separate trusted instructions from retrieved data;
label source and trust level;
limit tools available during untrusted-content processing;
require confirmation before crossing trust boundaries;
block secrets from context where unnecessary;
validate outputs against task goals;
use allowlists for external recipients and domains;
detect attempts to override policy;
keep high-risk actions outside model-only control.

Prompt injection cannot be solved by one classifier. It requires architectural isolation.

Data access

Agent access follows the Consent and Data Request Protocol.

A task records:

allowed fields or claims;
purpose;
source;
audience;
onward-sharing rule;
model-provider rule;
retention;
training-use rule;
expiry.

An agent may not broaden a holder-approved presentation into ongoing source access.

Model-provider boundaries

Before data is sent to a model provider, the host evaluates:

provider identity;
contract and data-use terms;
training and retention settings;
deployment region;
security posture;
data classification;
applicable organization policy;
participant consent.

Restricted data should use an approved provider profile or remain outside model context.

Context minimization

The runtime should provide the smallest context required for the task.

Prefer:

purpose-specific summaries;
selected claims;
retrieval by reference;
bounded time windows;
redacted artifacts;
derived facts instead of raw personal data;
tool-mediated queries instead of database dumps.

Long context is not equivalent to correct context.

Memory

Agent memory is an explicit data store, not an invisible property of the model.

Memory records require:

owner;
subject;
purpose;
source;
classification;
retention;
correction path;
deletion or revocation behavior;
visibility;
confidence and date.

A model-generated inference must not be stored as a verified fact without review.

Multi-agent delegation

An agent may delegate only when its grant permits delegation.

Subdelegation records:

parent task;
delegating agent;
receiving agent;
reduced capability set;
data scope;
budget;
expiry;
output contract;
approval obligations.

A child agent cannot receive broader authority than the parent task.

The original principal remains visible through the entire chain.

Financial controls

Agent financial actions must be narrow.

The MVP may permit agents to:

estimate cost;
prepare payment or refund proposals;
reconcile ledger data;
flag anomalies;
draft invoices;
request approval.

The MVP must not permit autonomous:

bank-account changes;
unrestricted transfers;
uncapped spend;
lending or investment decisions;
release of disputed funds;
treasury policy changes.

Code and infrastructure changes

Agents may prepare code changes through normal repository workflows.

Required controls include:

branch isolation;
tests;
dependency review;
secret scanning;
code review;
protected branches;
provenance;
deployment approval according to risk;
rollback plan.

Agent-generated code is not trusted merely because it compiles.

Communications

External communications require declared authority.

The agent must show:

sender identity;
recipient;
channel;
exact content or bounded template;
whether the content is AI-generated;
attachments and disclosed data;
reason for sending.

Mass outreach and public posting require additional anti-abuse controls.

Execution evidence

Every material tool invocation records:

task and principal;
agent and host version;
tool and version;
input digest and redacted preview;
authorization decision;
approval reference;
start and end time;
result status;
output digest;
external side-effect reference;
trace ID;
cost and token usage where available;
policy version.

Sensitive inputs are redacted from general logs while remaining available in controlled evidence systems when necessary.

Result verification

A completed agent task may require:

schema validation;
deterministic checks;
independent source confirmation;
human review;
test execution;
reconciliation with provider results;
rollback verification;
attestation.

Model confidence is not verification.

Failure and recovery

The runtime must handle:

tool timeout;
partial completion;
duplicate request;
expired approval;
revoked consent;
policy change;
model-provider failure;
malformed output;
external side effect with lost response;
task cancellation;
incident shutdown.

Tasks must expose whether an external side effect may have occurred.

Kill switches

Controls should exist at:

global agent runtime;
organization;
product;
agent registration;
tool;
capability;
provider;
task.

A kill switch creates an audit record and should preserve evidence needed for investigation.

Agent reputation

Agents may have operational reliability records, but those records must remain separate from the reputation of the principal or human contributor.

Possible agent evidence includes:

task success rate by type;
human override rate;
policy violation history;
tool failure rate;
rollback frequency;
review outcomes;
model and configuration version.

An agent score must not silently become a score of the person using it.

Human accountability

High-impact decisions require a named accountable human or legal body.

“AI approved it” is not an acceptable decision record.

The record must identify:

decision owner;
information reviewed;
role and authority;
agent contribution;
final decision;
appeal path.

MVP agent capabilities

Initial approved uses should emphasize:

documentation search;
public opportunity matching;
private evidence summarization with consent;
draft creation;
schema validation;
conformance checks;
test execution;
issue triage;
proposal comparison;
operational diagnostics;
preparation of actions for human approval.

Autonomous production, financial, legal, employment, and reputation sanctions remain out of scope.

Acceptance criteria

every agent has an accountable principal;
every task has a bounded objective and authority;
tools expose risk and schema metadata;
high-impact actions require exact approval;
standing policies are visible, narrow, expiring, and revocable;
prompt injection is treated as a trust-boundary problem;
data access follows consent and classification;
temporary credentials are scoped and short-lived;
subdelegation cannot broaden authority;
material actions produce execution evidence;
completion is independently verifiable where required;
kill switches exist;
no agent can claim legal or constitutional authority on its own.

Sources

Verification record

Sources opened and checked: 2 August 2026
MCP stable baseline verified in source pack: 2025-11-25; 2026-07-28 release status to be pinned by ADR after implementation validation
Autonomous high-impact actions: Prohibited in MVP
Human accountability: Required