6.1 Identity must support attribution and constrained delegation
NIST's September identity work moves toward implementation demonstrations in DevSecOps, with additional use cases still to be scoped. The inspected material is project and consultation output, not a completed agent-identity certification regime. It supports the identity and delegation responsibilities explained in the H-DES and H-MAS practices in Appendix B. [S25, S26]
Proposed practice. Distinguish the agent service identity, initiating human or business principal, delegated child identity, and actual resource credential. Preserve the relationships without granting children a parent's full authority. The effective grant is the intersection of the parent's grant, the child's mandate, current resource policy, and unexpired approval.
Figure 5. Proposed delegation pattern. Every child inherits a constrained authorization context and must pass resource-level enforcement. Child identities remain attributable. The independent policy and evidence services are outside the agents' authority to modify.
| Authorization field | Purpose | Failure to test |
|---|---|---|
| Subject and initiating principal | Attribute action and business authority. | Shared identity obscures who delegated a grant. |
| Mandate and resource scope | Bound allowable purpose, target, and operation. | Valid credential used for an unauthorized task or customer. |
| Delegation lineage | Preserve parent, child, depth, and remaining budget. | Child receives broader authority or resets limits. |
| Expiry, revocation, and audience | Restrict duration and intended recipient. | Expired, revoked, or wrong-audience token accepted. |
| Action and approval digest | Bind consent to the actual execution. | Agent changes beneficiary, payload, tool, or amount after review. |
| Policy and configuration version | Establish rules applied to the action. | Old approval reused after material policy or deployment change. |
6.2 Approval is a transaction with a bounded meaning
Proposed practice. Show the reviewer the initiating request, proposed effect, relevant evidence, affected resources, applicable limits, and recovery options. The approval record should bind a specific action digest or a defined batch, expiry, reviewer identity, and permitted scope. A batch approval must specify every dimension over which variation is authorized.
Recheck policy after review. If the execution payload differs materially, require a new decision. Prevent the agent from granting approval, using a child's approval to authorize its parent, or interpreting an unrelated conversation as transactional consent. Measure review quality using planted failures and normal cases under realistic workload, not only a count of approvals.
6.3 Model Context Protocol (MCP) 2026-07-28 requires a migration-specific review
The inspected MCP release adopts a stateless protocol core, changes discovery and metadata handling, and introduces authorization hardening including issuer validation. Application state can still persist through explicit handles. The security specification requires intended-audience checks and prohibits token passthrough. Protocol-compliant authentication does not establish business authorization for each tool action. [S27, S28]
| Migration surface | Enterprise acceptance test | Related handbook families |
|---|---|---|
| Header routing and request body | Reject inconsistent method/tool declarations; enforce the same decision through every route. | H-RUN practices (Appendix B), H-TPR practices (Appendix B) |
| Explicit state handles | A handle cannot cross customer or tenant boundaries or restore revoked authority. | H-DES practices (Appendix B), H-MAS practices (Appendix B) |
| Issuer, audience, and client metadata | Wrong issuer/audience fails; remote metadata fetches cannot reach internal-only resources. | H-DES practices (Appendix B), H-TPR practices (Appendix B) |
| Caches and tool catalogs | Changes to tool behavior or schema invalidate approval and relevant evaluation evidence. | H-DES practices (Appendix B), H-EVL practices (Appendix B), H-TPR practices (Appendix B) |
| Multi-round-trip input | Confirmation is attributable, bound to scope, and cannot be satisfied by attacker-controlled content. | H-RUN practices (Appendix B) |
| Legacy coexistence | Version negotiation and older clients cannot downgrade the applicable authorization control. | H-TPR practices (Appendix B), H-ASR practices (Appendix B) |
6.4 The Agent Control Standard (ACS) is an integration candidate that still needs enforcement proof
OWASP's Agent Control Standard supplies hooks and a declarative control interface. The inspected repository exposes version 0.1.0 and explicitly limits one demonstration to two live hook methods. This is useful implementation infrastructure; it is not evidence of universal hook coverage or framework interoperability. [S29, S30]
Proposed practice. Create an adapter conformance matrix for each adopted framework: supported hook, enforced action surface, failure behavior, bypass route, evidence emitted, and regression test. Include shell subprocesses, background jobs, browser actions, network libraries, child agents, and raw database clients. A registered hook earns control credit only on the routes where it actually mediates effects.