Original-caller Attribution

Expanded Definition

Original-caller attribution is the chain-of-custody problem for delegated execution: when an AI agent, service, or middleware layer acts on behalf of another subject, the system must still preserve evidence of who initiated the action and under what authority. It is closely related to audit logging, token exchange, and delegation controls, but it is not the same as simple request tracing. Tracing shows where a request flowed; attribution proves who first authorised the action.

In NHI operations, this matters when an API key is exchanged for a short-lived token, when an agent invokes tools through MCP, or when a workflow is re-authenticated by multiple services before execution. Industry usage is still evolving, and no single standard governs this yet, so organisations often combine identity claims, signed delegation metadata, and immutable logs. The NIST Cybersecurity Framework 2.0 frames the broader governance expectation for traceable access decisions, while NHI-specific guidance from Ultimate Guide to NHIs explains why visibility and lifecycle control are prerequisites for trustworthy attribution. The most common misapplication is treating downstream service identity as proof of the original caller, which occurs when delegated requests lose their initiator context during token exchange or queue handoff.

Examples and Use Cases

Implementing original-caller attribution rigorously often introduces extra metadata handling and signing overhead, requiring organisations to weigh stronger accountability against more complex service-to-service integration.

• An AI agent submits a ticket on behalf of an employee, and the system records the employee as the original caller even though the agent used its own service credential to execute the task.
• A CI/CD pipeline assumes a deployment role, but the audit record preserves which engineer approved the pipeline run before the change reached production.
• A federated service exchanges tokens across multiple hops, and each hop retains the initiator claim so that investigators can reconstruct who authorized data access.
• A secrets-management workflow rotates credentials after a delegated action, and the log chain ties the rotation back to the originating automation job rather than the intermediate worker service.
• A policy engine blocks a high-risk API call because the original caller lacked approval, even though a downstream orchestrator had sufficient privilege to make the request.

These patterns align with the identity traceability expectations discussed in Ultimate Guide to NHIs and with the access governance emphasis in NIST Cybersecurity Framework 2.0. Where teams rely on agent-to-agent workflows, original-caller data should survive delegation boundaries rather than being inferred later from logs.

Why It Matters in NHI Security

Without original-caller attribution, delegated actions become hard to govern, hard to investigate, and easy to misrepresent. That creates a practical gap in policy enforcement because a privileged service can appear to be the actor of record even when a less-privileged subject initiated the request. In NHI environments, that gap is especially dangerous because service accounts, API keys, and agent credentials often outnumber human identities and are frequently overprivileged. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts.

Original-caller attribution therefore supports incident reconstruction, insider-risk review, and enforcement of approval workflows across agentic systems. It also helps determine whether a delegated action was legitimate, excessive, or replayed. For governance teams, the issue is not merely logging more data, but preserving identity continuity across hops, exchanges, and execution boundaries. Practitioner insight: organisations typically encounter this control failure only after a disputed action, at which point original-caller attribution becomes operationally unavoidable to resolve accountability.

For broader NHI governance context, see Ultimate Guide to NHIs and the control expectations in NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• NHI Ownership Attribution
• Why is NHI ownership attribution important for incident response?
• What problem does ownership attribution solve for service accounts and API keys?
• How should security teams govern AI agents that outlive their original purpose?