AI Agent Operating Under Scoped Delegation in Regulated Government Environment

[pratyushsood24]

Use Case: AI Agent Under ISM-Compliant Scoped Delegation

Summary

An AI agent operating within any Government or regulated environment performs data processing tasks under scoped delegation from a human principal. The delegation chain, every action taken, and all audit evidence must be cryptographically verifiable, traceable to a named human, and compliant with the Information Security Manual (ISM) — the any Government's cybersecurity framework.

This use case extends the agent delegation scenarios discussed in w3c/did#927 into regulated environments where compliance is a procurement requirement, not an optional trust layer.

Actors

• Human Principal (Government Officer): Holds a DID (did:web) linked to their organisational identity. Bears accountability for all agent actions. Operates under a security clearance with defined access boundaries.
• Primary Agent: An AI agent with its own DID (did:key, Ed25519 + ML-DSA-65 hybrid keys). Receives scoped delegation from the Human Principal to perform a defined task (e.g., process a dataset, generate a compliance report).
• Sub-Agent: An ephemeral AI agent spawned by the Primary Agent for a subtask. Receives further-narrowed delegation (monotonic attenuation). Short-lived identity with automatic expiry.
• Relying Party (Government System): The system receiving the agent's output. Must verify the full delegation chain back to the Human Principal, confirm scope compliance, and retain a cryptographic audit receipt.

Scenario

1. Delegation issuance. The Human Principal issues a scoped capability token (zcap-aligned) to the Primary Agent. The token specifies: permitted actions (read dataset X, generate report Y), time boundary (valid for 4 hours), cost constraints (no external API calls exceeding $50), and scope narrowing rules (sub-delegation permitted, but can only narrow).
2. Agent action. The Primary Agent resolves its own DID Document, which contains service endpoints for MCP tool access (MCPToolEndpoint) and delegation verification (DelegationVerificationEndpoint). It processes the dataset using tools discovered via MCP.
3. Sub-delegation. The Primary Agent spawns a Sub-Agent for a specific subtask (e.g., statistical analysis). It issues a further-narrowed capability token: read-only access to a subset of the dataset, 30-minute TTL, no further sub-delegation permitted. The Sub-Agent receives an ephemeral DID.
4. Output delivery. The Primary Agent delivers the completed report to the Relying Party (Government System). The delivery includes: the report content, a signed audit receipt (W3C Verifiable Credential) containing the full delegation chain, and a reference to the delegation verification endpoint.
5. Verification. The Relying Party resolves the Primary Agent's DID, queries the DelegationVerificationEndpoint to verify the capability chain back to the Human Principal, validates the audit receipt VC, and confirms ISM control compliance (e.g., ISM-0988: privileged access management, ISM-1146: audit logging).
6. Revocation and cleanup. On task completion, the Sub-Agent's ephemeral DID is automatically revoked. The Primary Agent's delegation token expires at the 4-hour boundary. The Human Principal can cascade-revoke the entire delegation tree at any time.

Requirements This Use Case Surfaces

Requirement | DID Ecosystem Component -- | -- Agent DID Documents must be distinguishable from human DID Documents | DID Core: subject type guidance (informative) Delegation must be scoped, time-bounded, and monotonically attenuating | zcap-spec: object capabilities Audit receipts must be cryptographically signed and independently verifiable | W3C Verifiable Credentials Service endpoints must advertise agent-specific protocols (MCP, A2A, delegation verification) | did-extensions: service type registry Hybrid post-quantum verification methods must be expressible | DID Core: verification method guidance (informative) Ephemeral agent identities must support automatic expiry and cascade revocation | DID method implementation concern Full delegation chain must be verifiable by a relying party without calling back to a proprietary registry | zcap-spec + DID Resolution

What Makes This Use Case Distinct

Most agent use cases filed in this repo (and discussed in #927) describe open-internet scenarios where trust is voluntary and incremental. This use case describes a regulated environment where:

• Delegation chains are auditable by law (Australian Government recordkeeping requirements)
• Principal traceability is mandatory (every agent action must trace to a named, cleared human)
• Post-quantum cryptography is required for PROTECTED classification (ISM controls mandate algorithm agility)
• Compliance evidence must be machine-verifiable (IRAP assessors validate controls against cryptographic evidence, not self-attestation)

This represents a significant and growing market for DID-based agent identity — government, defence, critical infrastructure — where the standards choices made now will determine procurement eligibility.

Implementation Reference

• IDProva: github.com/techblaze-au/idprova (Apache 2.0, Rust core, 33+ tests)
• Related: NIST submission NIST-2025-0035 (AI Agent Identity)
• Submitter: Pratyush Sood, IRAP Assessor, Tech Blaze Consulting — pratyush@techblaze.com.au

Summary An AI agent operating within an Australian Government environment performs data processing tasks under scoped delegation from a human principal. The delegation chain, every action taken, and all audit evidence must be cryptographically verifiable, traceable to a named human, and compliant with the Information Security Manual (ISM) — the Australian Government's cybersecurity framework. This use case extends the agent delegation scenarios discussed in [#927](https://github.com//issues/927) into regulated environments where compliance is a procurement requirement, not an optional trust layer. Actors

Human Principal (Government Officer): Holds a DID (did:web) linked to their organisational identity. Bears accountability for all agent actions. Operates under a security clearance with defined access boundaries.
Primary Agent: An AI agent with its own DID (did:key, Ed25519 + ML-DSA-65 hybrid keys). Receives scoped delegation from the Human Principal to perform a defined task (e.g., process a dataset, generate a compliance report).
Sub-Agent: An ephemeral AI agent spawned by the Primary Agent for a subtask. Receives further-narrowed delegation (monotonic attenuation). Short-lived identity with automatic expiry.
Relying Party (Government System): The system receiving the agent's output. Must verify the full delegation chain back to the Human Principal, confirm scope compliance, and retain a cryptographic audit receipt.

Scenario

Delegation issuance. The Human Principal issues a scoped capability token (zcap-aligned) to the Primary Agent. The token specifies: permitted actions (read dataset X, generate report Y), time boundary (valid for 4 hours), cost constraints (no external API calls exceeding $50), and scope narrowing rules (sub-delegation permitted, but can only narrow).
Agent action. The Primary Agent resolves its own DID Document, which contains service endpoints for MCP tool access (MCPToolEndpoint) and delegation verification (DelegationVerificationEndpoint). It processes the dataset using tools discovered via MCP.
Sub-delegation. The Primary Agent spawns a Sub-Agent for a specific subtask (e.g., statistical analysis). It issues a further-narrowed capability token: read-only access to a subset of the dataset, 30-minute TTL, no further sub-delegation permitted. The Sub-Agent receives an ephemeral DID.
Output delivery. The Primary Agent delivers the completed report to the Relying Party (Government System). The delivery includes: the report content, a signed audit receipt (W3C Verifiable Credential) containing the full delegation chain, and a reference to the delegation verification endpoint.
Verification. The Relying Party resolves the Primary Agent's DID, queries the DelegationVerificationEndpoint to verify the capability chain back to the Human Principal, validates the audit receipt VC, and confirms ISM control compliance (e.g., ISM-0988: privileged access management, ISM-1146: audit logging).
Revocation and cleanup. On task completion, the Sub-Agent's ephemeral DID is automatically revoked. The Primary Agent's delegation token expires at the 4-hour boundary. The Human Principal can cascade-revoke the entire delegation tree at any time.

Requirements This Use Case Surfaces
RequirementDID Ecosystem ComponentAgent DID Documents must be distinguishable from human DID DocumentsDID Core: subject type guidance (informative)Delegation must be scoped, time-bounded, and monotonically attenuatingzcap-spec: object capabilitiesAudit receipts must be cryptographically signed and independently verifiableW3C Verifiable CredentialsService endpoints must advertise agent-specific protocols (MCP, A2A, delegation verification)did-extensions: service type registryHybrid post-quantum verification methods must be expressibleDID Core: verification method guidance (informative)Ephemeral agent identities must support automatic expiry and cascade revocationDID method implementation concernFull delegation chain must be verifiable by a relying party without calling back to a proprietary registryzcap-spec + DID Resolution
What Makes This Use Case Distinct
Most agent use cases filed in this repo (and discussed in #927) describe open-internet scenarios where trust is voluntary and incremental. This use case describes a regulated environment where:

Delegation chains are auditable by law (Australian Government recordkeeping requirements)
Principal traceability is mandatory (every agent action must trace to a named, cleared human)
Post-quantum cryptography is required for PROTECTED classification (ISM controls mandate algorithm agility)
Compliance evidence must be machine-verifiable (IRAP assessors validate controls against cryptographic evidence, not self-attestation)

This represents a significant and growing market for DID-based agent identity — government, defence, critical infrastructure — where the standards choices made now will determine procurement eligibility.
Implementation Reference

IDProva: github.com/techblaze-au/idprova (Apache 2.0, Rust core, 33+ tests)
Related: NIST submission NIST-2025-0035 (AI Agent Identity)
Submitter: Pratyush Sood, IRAP Assessor, Tech Blaze Consulting — info@techblaze.com.au