Ghost Calling

Expanded Definition

Ghost calling describes an observability and accountability failure in agentic AI and tool-using systems: an action occurs, but the system does not preserve a clear chain of custody for who or what initiated it, why it was allowed, and what context drove the decision. It is not simply “missing logs.” It is the breakdown of traceability across prompts, model reasoning, tool invocation, policy checks, and downstream execution. In practice, the term sits alongside broader AI governance concerns covered by the NIST Cybersecurity Framework 2.0, especially where auditability, governance, and accountability are required for automated actions.

Definitions vary across vendors because some teams use ghost calling to describe silent tool execution, while others use it more narrowly for actions that cannot be reconstructed after the fact. NHIMG treats it as a security-relevant failure mode, not a feature request, because the risk is highest when a model has execution authority over secrets, identity workflows, or operational tools. The distinction matters: a system can be functionally correct and still be unsafe if investigators cannot explain how the action happened. The most common misapplication is treating a sparse application log as sufficient evidence of control, which occurs when the log records the API call but omits the model output, policy decision, and user or agent context.

Examples and Use Cases

Implementing ghost-calling resistance rigorously often introduces more logging, policy instrumentation, and storage overhead, requiring organisations to weigh operational visibility against cost and latency.

• An AI agent opens a privileged ticketing action, but only the final status update is logged, not the policy check that approved it or the prompt that triggered it.
• A workflow agent rotates a secret after detecting “suspicious activity,” yet the system cannot show whether the detection came from a genuine alert, a hallucinated interpretation, or injected instructions.
• A support copilot triggers a password reset or account lockout, but reviewers cannot reconstruct the exact user request, tool arguments, or confirmation step.
• An orchestration agent sends a command to a cloud or identity system, but the audit trail captures the API endpoint and timestamp only, not the agent identity, policy decision, or trace ID linking the call to the originating session.
• Security teams investigate an incident after the fact and discover that a model changed configuration, but no replayable record exists to explain which retrieval source, tool response, or guardrail outcome led to the action.

For governance-oriented reference points, teams often map traceability requirements to the NIST AI Risk Management Framework and, where identity assurance is involved, to NIST SP 800-63 concepts for binding actions to a verified actor. The core lesson is that an AI action is not trustworthy merely because it completed successfully.

Why It Matters for Security Teams

Ghost calling matters because it creates a blind spot between detection and accountability. When an AI system can act without an explainable record, security teams lose the ability to prove whether an event was authorized, maliciously influenced, or simply misrouted through automation. That undermines incident response, forensic review, access governance, and change control. In identity-heavy environments, the problem becomes more serious when agents can touch credentials, privileged accounts, or NHI workloads, because a missing decision trail can hide misuse of secrets or unauthorized privilege escalation.

Security practitioners should treat ghost calling as a design flaw in auditability, not as an after-the-fact logging problem. Controls from frameworks such as NIST Cybersecurity Framework 2.0 and ISO/IEC 27001 become relevant when the organisation needs demonstrable governance over automated decisions and system actions. Organisations typically encounter the operational pain only after an investigation stalls, at which point ghost calling becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between shadow agents and ghost identities?
• What is the difference between function calling and MCP for enterprise security?
• When does MCP make more sense than function calling?
• What breaks when authorization ignores the calling application?