Family Guides
AWS2-DEL: Delegation, Authority, And Identity
AWS2-DEL is about making clear who gave an agent authority, what identity the agent acts under, what the agent is allowed to do, and who approves high-impact actions.
In ordinary business terms, this family asks: when an agent invokes a tool, sends a message, changes a file, calls a connector, touches production, or uses a service account, whose authority is being used and who is accountable for approving that authority?
This matters because agent activity can look like normal user activity, automated workflow activity, service-account activity, or system activity. If identity and authority are ambiguous, a reviewer cannot tell whether an agent acted inside the intended boundary or silently inherited more power than the business meant to delegate.
What This Family Covers
In scope:
- The identity or authority model used when agents invoke tools, connectors, or workspace resources.
- Whether actions are bound to a human user, role, workflow, service account, shared account, system identity, or agent-associated identity.
- Action classes involving delegated, administrative, production, external-communication, sensitive-data, or system authority.
- Human roles that can delegate work to agents and human roles that can approve high-impact actions.
- Least-privilege authority for production agent workflows.
- Approval and oversight expectations for ordinary user delegation, administrative authority, production authority, and external communication authority.
- Records tying high-impact action requests and approval decisions to users, roles, service accounts, workflow identities, or agent identities.
- Separation of execution authority and approval authority for high-impact action classes.
- Review of excessive privilege, stale access, shared credentials, and unreviewed service-account use.
Out of scope:
- The complete runtime policy engine for allowing, denying, pausing, or rolling back actions. That belongs mostly to
AWS2-RUN. - The workspace, filesystem, repository, shell, network, or SaaS boundary where authority is enforced. That belongs mostly to
AWS2-WSB. - Secrets, credentials, and sensitive-data movement rules. Those belong mostly to
AWS2-SEC. - The completeness and tamper-resistance of logs. That belongs mostly to
AWS2-LOG. - Formal legal, regulatory, or certification conclusions about responsibility.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization can explain whose authority agents use, which action classes are sensitive, and who may delegate or approve work. | A reviewer needs to know whether an agent is acting as a user, role, workflow, service account, shared account, or system identity. | Identity and authority model, action-class list, role and approver matrix. |
| Level 2 | Production workflows limit authority to approved purpose, scope, and duration, with recorded identity or approval context for high-impact actions. | Production agent use needs repeatable least-privilege rules and reviewable attribution. | Runtime permission policy, approval policy, high-impact action receipts, temporary authority records. |
| Level 3 | High-impact authority has stronger separation, recurring review, and step-up approval where needed. | Sensitive or high-impact systems need stronger checks against privilege creep, stale access, shared credentials, and conflicted approval. | Delegated-authority review, separated approval evidence, access review, just-in-time authority record, privileged-action test. |
Candidate Controls
AWS2-DEL-L1-001: Identity And Authority Model Level 1
Requirement summary
Document the identity or authority model used when agents invoke tools, connectors, or workspace resources, including whether actions are bound to a human user, role, workflow, service account, shared account, or system identity.
Why it exists
Agent activity can be misread if the identity model is unclear. A tool call might use a user's session, a service account, an application identity, a workflow identity, or a shared credential. Each model changes who is accountable, what logs mean, and which access controls matter.
Why this level
This belongs at Level 1 because every delegation and authority review starts with knowing what identity the agent appears to use. It does not yet require perfect enforcement or automated proof; it requires a clear model a reviewer can inspect.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Identity and authority model | Organization or governance owner with runtime owner input | Before production use and before review | How agent actions bind to users, roles, workflows, service accounts, shared accounts, system identities, or agent identities | Explains the model; does not prove enforcement or accountability completeness. |
| Agent identity record or equivalent | Runtime platform owner | Before enabling agent workflows and after identity changes | Agent-associated identities, service accounts, scopes, owners, and intended use | Supports identity review; does not prove least privilege by itself. |
AWS2-DEL-L1-002: High-Authority Action Classes Level 1
Requirement summary
Identify action classes where an agent acts with delegated, administrative, production, external-communication, sensitive-data, or system authority.
Why it exists
Some agent actions have higher business impact than others. Reading a public document is different from changing production, sending an external message, exporting sensitive data, modifying access, spending money, or invoking an administrative connector.
Why this level
This belongs at Level 1 because a system cannot apply meaningful approval or oversight rules until it names the action classes that carry higher authority.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Action-class inventory | Organization or governance owner with runtime owner input | Before production use and after new tools or connectors are added | Which action classes involve delegated, administrative, production, external-communication, sensitive-data, or system authority | Identifies sensitive classes; does not prove they are blocked or approved correctly. |
| Runtime permission policy summary | Runtime platform owner | Before use and after policy changes | How high-authority action classes are represented in policy or configuration | Supports review of intended policy; enforcement evidence belongs with runtime records and tests. |
AWS2-DEL-L1-003: Delegator And Approver Roles Level 1
Requirement summary
Identify which human roles can delegate work to agents, which human roles can approve high-impact actions, and whether execution and approval may be performed by the same role.
Why it exists
A business needs to know who can ask agents to act and who can approve risky actions. If execution and approval roles are unclear, the same person or process may accidentally request, approve, and execute a high-impact action without meaningful oversight.
Why this level
This belongs at Level 1 because the role model is foundational. Stronger separation and recurring review appear later, but basic delegator and approver roles should be visible from the start.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Role and approver matrix | Organization or governance owner | Before production use and after role changes | Roles allowed to delegate work, roles allowed to approve high-impact actions, and whether same-role approval is allowed | Shows intended accountability; does not prove approvals were enforced. |
| Approval policy | Organization or governance owner | Before production use and after approval-rule changes | Approval triggers, approver roles, escalation, expiry, and exceptions | Supports governance review; does not prove runtime approval gates work. |
AWS2-DEL-L2-001: Least-Privilege Production Authority Level 2
Requirement summary
Enforce least-privilege authority for production agent workflows, limiting agent-accessible actions and resources to the approved purpose, scope, and duration.
Why it exists
Production agents should not keep broad authority simply because it was convenient during setup. Authority that is too broad, too long-lived, or disconnected from the approved purpose creates avoidable exposure.
Why this level
This belongs at Level 2 because production operation needs enforced or configured limits, not only documentation. It builds on the Level 1 identity, action-class, and role model.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Runtime permission policy | Runtime platform owner | Before production use and after authority changes | Allowed actions, resources, scopes, duration, and policy owner for production workflows | Supports least-privilege review; does not prove every runtime path is mediated. |
| Temporary or just-in-time authority record | Runtime platform owner or identity owner | When temporary authority is granted or expires | Purpose, requester, approver, scope, duration, expiry, and revocation state | Supports time-bound authority review; does not prove no other standing privilege exists. |
AWS2-DEL-L2-002: Authority Category Policy Level 2
Requirement summary
Distinguish ordinary user delegation, administrative authority, production authority, and external communication authority in policy or configuration, including the approval or oversight expectations for each category.
Why it exists
Different authority categories need different oversight. A chatbot drafting a note, an agent modifying production configuration, and an agent sending an external commitment should not all follow the same review path.
Why this level
This belongs at Level 2 because it moves from a basic action-class inventory to managed production policy. The organization should show how categories map to approval, review, or oversight expectations.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Authority category policy | Organization or governance owner with runtime owner input | Before production use and after category changes | Ordinary delegation, administrative authority, production authority, external communication authority, and required oversight | Shows intended category handling; does not prove implementation correctness. |
| Policy-to-configuration mapping | Runtime platform owner | Before release or periodic review | How authority categories appear in runtime policy, connector settings, IAM groups, or workflow configuration | Supports implementation review; does not prove all possible actions are categorized. |
AWS2-DEL-L2-003: High-Impact Identity And Approval Records Level 2
Requirement summary
Record the user, role, service account, workflow identity, or agent identity associated with each high-impact action request and approval decision.
Why it exists
When a high-impact action is requested or approved, reviewers need to know which identity was involved. Without this, records may show that "the agent" acted but not whether the action came from an approved user, role, service account, workflow, or agent identity.
Why this level
This belongs at Level 2 because production accountability depends on repeatable records for high-impact action requests and approval decisions. Level 1 can name the authority model, but Level 2 expects records when high-impact activity occurs.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Sampled high-impact action receipt | Evidence or audit owner | During operation and during review sampling | Requester, agent or workflow identity, action class, approval state, approver role, timestamp, and policy outcome | Supports attribution review; does not prove the action was safe or legally sufficient. |
| Approval decision record | Runtime platform owner or organization/governance owner | At approval decision time | Who approved, what was approved, scope, duration, conditions, and denial or escalation where applicable | Shows approval context; does not prove all approval gates are effective. |
AWS2-DEL-L3-001: Separation Of Execution And Approval Authority Level 3
Requirement summary
Provide strong separation between agent execution authority and human approval authority for high-impact action classes.
Why it exists
High-impact actions need protection against self-approval, accidental approval by the same actor that requested execution, and unclear separation between the agent's execution path and the human approval path.
Why this level
This belongs at Level 3 because strong separation is a higher-assurance expectation. It adds independence for high-impact authority beyond simply recording who requested and approved an action.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Separation-of-duties policy | Organization or governance owner | Before high-impact production use and after role changes | Which high-impact actions require separate requester, executor, and approver roles | Supports independence review; does not prove runtime cannot bypass the separation. |
| Separation test or review record | Evidence or audit owner with runtime owner input | During validation or periodic review | Sampled attempts, expected separation rule, result, finding, and remediation if needed | Supports review of selected paths; does not prove every path is covered. |
AWS2-DEL-L3-002: Delegated-Authority Review Level 3
Requirement summary
Periodically review delegated authority paths for excessive privilege, stale access, shared credentials, or unreviewed service-account use.
Why it exists
Agent authority can accumulate over time. Old service accounts may stay active, temporary permissions may become standing access, shared credentials may hide accountability, and connector privileges may outlive their original purpose.
Why this level
This belongs at Level 3 because recurring delegated-authority review is a stronger assurance practice for systems where authority drift could create serious business, security, or accountability risk.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Delegated-authority review | Organization or governance owner with identity owner input | Periodically or before major release | Authority paths, owners, purpose, privilege level, age, review decision, and remediation | Supports privilege review; does not prove no unlisted authority path exists. |
| Service-account inventory | Identity owner or runtime platform owner | Periodically and after service-account changes | Service accounts used by agents, owners, scopes, credential type, expiry, and review state | Supports service-account accountability; does not expose credentials and does not prove secret safety by itself. |
AWS2-DEL-L3-003: Step-Up Approval For High-Impact Actions Level 3
Requirement summary
Support step-up approval or stronger authorization for actions involving production systems, privileged identity changes, sensitive data export, financial impact, or external commitments.
Why it exists
Some actions deserve stronger authorization than ordinary workflow approval. Examples include production writes, identity or access changes, sensitive data export, financially meaningful action, and commitments sent outside the organization.
Why this level
This is a Level 3 SHOULD because step-up approval adds higher assurance for the most consequential actions. It may require additional identity, runtime, or workflow integration that not every Level 1 or Level 2 system has.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Step-up approval policy | Organization or governance owner with runtime owner input | Before high-impact production use and after trigger changes | Triggering action classes, required approval strength, expiry, escalation, and fallback behavior | Shows intended stronger authorization; does not prove all triggers are correctly detected. |
| Step-up approval receipt | Runtime platform owner or evidence owner | At request and approval time | Action class, trigger, requester, approver, authorization method, timestamp, scope, and outcome | Supports review of selected high-impact decisions; does not prove legal sufficiency or external-framework compliance. |
External Mapping Notes
The family-first crosswalk treats AWS2-DEL as a candidate-control family shaped by identity, delegation, accountability, human oversight, privilege, and agent-impersonation signals. Governance evidence is useful, but stronger claims also need runtime, identity-system, approval, or receipt evidence.
Relevant source signals include:
- EU AI Act role, responsibility, oversight, and transparency signals support governance evidence for delegated authority, but not legal sufficiency.
- OWASP AISVS contributes identity, agent authority, and human-oversight signals, but its public
v0.1status does not proveaws2or AISVS conformance. - AIUC-1 contributes useful comparator signals around agent identity, scopes, just-in-time permissions, and access reviews, but there is no AIUC-1 certificate equivalence.
- CSA MAESTRO and MITRE ATLAS contribute abuse-case input for impersonation, tool misuse, repudiation, valid-account use, and agent tool invocation.
- NIST AI RMF and ISO/IEC 42001 support role, accountability, policy, oversight, and management-process evidence, but not runtime identity enforcement by themselves.
- Five Eyes agentic AI adoption guidance supports privilege, scope-creep, identity-spoofing, accountability, and just-in-time authority review signals.
Formal Standard Link
Use this guide with the formal AWS2-DEL candidate requirements. If the guide and the standard draft disagree, the standard draft controls.