How should organisations govern agent-to-agent delegation?

They should treat delegation as a formal governance boundary, not just an integration pattern. That means defining what data can move between agents, how inherited permissions are recorded, and when delegated actions require review. Without that, one agent can extend another’s access in ways the original control model never saw.

Why This Matters for Security Teams

Agent-to-agent delegation changes the risk model because an autonomous Agent can act on a policy decision that was never designed for another autonomous actor to inherit. Static RBAC works poorly when behaviour is goal-driven, because the next action is not always predictable at design time. Current guidance from OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework points to runtime governance, not one-time approval, as the safer pattern.

For NHI teams, the key issue is that delegation can silently expand trust across workloads. A single agent-to-agent handoff can carry workload identity, inherited Secrets, and implied authority into a new context. That makes delegation a governance boundary, not just a technical integration. NHI Mgmt Group research shows OWASP NHI Top 10 risks are amplified when identities, tools, and tokens are reused without clear scoping, and the same pattern appears in incident analysis from AI LLM hijack breach.

In practice, many security teams discover delegation sprawl only after an agent has already chained tools and extended access beyond the original intent.

How It Works in Practice

Treat delegation as a policy decision made at request time, not as a permanent transfer of trust. The practical model is: authenticate the calling agent, evaluate the purpose of the action, check the target resource, and issue only the minimum authority needed for the specific task. That is why intent-based authorisation is gaining traction for autonomous workloads. It is more precise than broad role grants because it asks what the agent is trying to do right now, in this context.

A workable pattern usually combines short-lived JIT credentials, workload identity, and policy-as-code. Instead of passing long-lived tokens from one agent to another, organisations issue ephemeral credentials for a bounded step, then revoke them automatically on completion. For the identity primitive, use workload identity mechanisms such as SPIFFE/SPIRE or OIDC-based attestations so the platform can prove what the agent is, not just what secret it holds. This is consistent with CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which emphasise governance, accountability, and continuous evaluation.

• Define which data classes an agent may delegate, and which must never leave the original trust zone.
• Record inherited permissions in an auditable trail so reviewers can see who authorised what, when, and why.
• Use policy engines at runtime, such as OPA or Cedar, to approve or deny the delegated action against current context.
• Expire delegated Secrets quickly, and avoid reusing them across agent boundaries.

NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs also reinforces that lifecycle control and offboarding are essential when identities are created and consumed by non-human systems. These controls tend to break down when agents sit inside legacy workflow engines that cannot evaluate context at request time because the delegation is then reduced to static permission passing.

Common Variations and Edge Cases

Tighter delegation control often increases orchestration overhead, requiring organisations to balance faster agent autonomy against stronger review and revocation. There is no universal standard for this yet, so current guidance suggests matching control strength to the sensitivity of the delegated action.

For low-risk internal tasks, a short-lived delegated token plus logging may be enough. For customer data, financial actions, or infrastructure changes, the bar should be higher: separate trust domains, mandatory human review for certain actions, and explicit denial of transitive delegation. This is where the OWASP Agentic AI Top 10 matters operationally, because it highlights failure modes such as tool abuse and unchecked agent chaining. The NHI perspective from Top 10 NHI Issues is equally important when delegated access depends on secrets hygiene, rotation, and clear ownership.

One common edge case is cross-org delegation through MCP-connected agents. Best practice is evolving here: organisations should assume external agents are untrusted by default, require explicit scope limits, and avoid letting delegated permissions survive beyond the session. Another edge case is emergency operations, where JIT controls may need an override path, but that override should be time-boxed, logged, and reviewable. For audit-heavy environments, NHI Mgmt Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful anchor for evidence collection and control mapping.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• How can organisations govern AI agents that use service accounts and tokens?
• How should teams govern agent access when both CLI and MCP are available?
• What is the difference between human identity governance and AI agent governance?