Subscribe to the Non-Human & AI Identity Journal

Signed Call Chain

A cryptographically verifiable sequence of agent-to-agent instructions that preserves who asked for what, when, and under which scope. For multi-agent incidents, it is the primary evidence for attribution because execution logs alone do not prove intent or legitimacy.

Expanded Definition

A signed call chain is the authenticated record of a sequence of agent-to-agent or service-to-service instructions, where each handoff is cryptographically bound to the caller, the scope, and the moment of execution. In NHI security, it is not just a log format; it is a trust artifact that helps prove whether an agent acted under valid delegation or under abuse of authority. That distinction matters because autonomous systems can trigger downstream actions faster than humans can review them, and the evidence needs to survive replay, tampering, and cross-system handoffs. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames the control expectations around auditability, accountability, and access enforcement, even though it does not name signed call chains explicitly. Industry usage is still evolving, so some vendors treat this as part of agent telemetry while others treat it as a chain-of-custody mechanism for delegated actions. The most common misapplication is treating ordinary execution logs as equivalent to a signed call chain, which occurs when organizations record events without cryptographically binding the requesting identity, scope, and delegation path.

Examples and Use Cases

Implementing signed call chains rigorously often introduces latency and integration overhead, requiring organisations to weigh stronger attribution against the cost of signing, verification, and key lifecycle management.

  • Agent A requests a data pull from Agent B, and each hop signs the request so investigators can reconstruct the full delegation path during an incident.
  • A customer support agentic workflow invokes payment or ticketing tools, while the call chain proves which upstream agent authorized the action and under what scope.
  • During cross-domain orchestration, the signed chain preserves evidence when multiple NHIs, APIs, and brokers participate in one decision path, reducing ambiguity about which identity initiated the action.
  • The pattern is especially important when attackers abuse exposed credentials, as described in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research and in NIST guidance on logging and traceability.
  • In vendor-neutral agent architectures, teams may pair the concept with SPIFFE-style workload identity and signed assertions so downstream systems can verify both origin and scope before executing sensitive tasks.

The strongest practical use cases appear when the call chain must answer not only what happened, but who asked for it, which agent relayed it, and whether the request stayed within approved delegation boundaries. NHIMG’s DeepSeek breach analysis shows how exposed data and weak control boundaries can quickly complicate attribution when systems are operating at machine speed.

Why It Matters in NHI Security

Signed call chains matter because NHI incidents often become attribution problems before they become technical containment problems. When credentials are abused, when an agent is coerced into invoking the wrong tool, or when a downstream service cannot tell whether a request was delegated or injected, the organisation loses the ability to separate legitimate automation from malicious action. That is why the control value is broader than forensics. It supports least privilege, delegated authority review, incident reconstruction, and policy enforcement across autonomous workflows. The reporting published by NHIMG in The State of Secrets in AppSec is a reminder that secret exposure and fragmented controls remain common, which makes post-incident provenance even more important. Pairing signed call chains with logging, key management, and access control aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls helps organisations preserve trustworthy evidence instead of relying on reconstructed intent after the fact. Organisations typically encounter the need for signed call chains only after a delegated action is disputed, at which point provenance becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-04 Call-chain integrity supports attribution and non-repudiation for agent actions.
OWASP Agentic AI Top 10 A-03 Agent handoff integrity is central to preventing unauthorized tool execution.
NIST CSF 2.0 PR.AA Identity and access assurance depend on trustworthy provenance of actions.
NIST SP 800-53 Rev 5 AU-2 Audit records are needed to reconstruct delegated actions and accountability.
NIST Zero Trust (SP 800-207) SC-23 Zero trust requires verified identity and context for every request path.

Sign and verify each delegated agent hop so provenance survives incident response and dispute.