When Host Agents Become Ghosts

I consider AI-driven systems that act on behalf of a human or a business function to be host agents. They execute workflows, call APIs, provision infrastructure and make decisions across systems without requiring constant human interaction. In theory, each host agent has an owner, but in practice, that ownership is often symbolic.

The moment the human relationship breaks, through role change, project shutdown or employee departure, the agent isn’t terminated. It continues operating with its own credentials, permissions and logic. That’s when a host agent becomes a ghost agent.

I’ve seen this firsthand. In one case, a finance automation agent continued reconciling accounts months after its creator left. It wasn’t malfunctioning. It was doing what it was designed to do. But the business context had changed, and no one was there to correct it.​

Four Ghost Agent Risk Factors

Ghost agents don’t just create isolated incidents. They introduce four categories of risk that compound the longer they operate unchecked.

1. Financial Damage

Agents tied to procurement, cloud provisioning or subscriptions can continue spending long after their purpose is gone. I’ve seen environments where cloud costs failed to drop after projects ended. The root cause wasn’t billing errors. It was agents still provisioning resources based on outdated logic. The spending looked legitimate, the credentials were valid and the system approved the requests. No one questioned it until finance did.

2. Security Exposure

Agents often require broad permissions to do their jobs. When the owner leaves, those permissions don’t automatically disappear with them. That quietly expands the organization’s attack surface.

Unlike human accounts, agents don’t trigger behavioral anomalies in the same way. They’re expected to run at odd hours, across systems and at scale. That makes malicious use, or credential compromise, harder to detect. I’ve seen cases where credentials tied to dormant agents remained active for months, simply because no one knew they existed.

3. Compliance Failures

Regulators and auditors increasingly expect accountability for automated decisions. Ghost agents break that model. When an auditor asks, “Who authorized this action?” and the answer points to someone who left the company six months ago, that’s more of a control failure than a documentation gap.

Frameworks like SOC 2 and GDPR assume a chain of responsibility, and ghost agents break that model.

4. Reputational Damage

Some agents interact directly with customers, including support bots, communication tools and automated responders. When those agents operate on outdated logic, mistakes start piling up.

I’ve seen customer-facing agents continue to promote expired offers, reference discontinued products or respond with outdated policies. Once these governance failures become public, they can quickly erode trust.

The Agent Identity Security Gap

Most organizations assume their existing IAM stack will address these risks, but it doesn’t. That’s because IAM systems track ownership, not runtime behavior. They can tell you who created an agent, when it was registered and what permissions it was granted. None of that addresses whether the agent should still be active.

Credential rotation doesn't fully address the problem either. In many environments, agents continue operating uninterrupted because their credentials are rotated through established processes, preserving access while leaving the underlying question of ownership unresolved. Manual decommissioning is equally difficult at scale. Over time, organizations lose visibility into which agents still serve a valid business purpose and which are simply continuing to operate by default. Agents live in places that IT doesn’t fully control.

I’ve seen organizations with mature identity programs still miss dozens of active agents during offboarding. This isn't because they lack discipline but because the model itself is incomplete.​

Enabling A Kill Switch For Ghost Agents

Solving the ghost agent problem starts with controlling agent access itself.​ I’ve built agents for projects, sales and marketing. To function, these agents needed access to Slack, Microsoft Entra and HubSpot, which places the underlying data at risk. This access needs to be controlled and monitored over time. Most companies with robust compliance frameworks will have these controls in place, but once credentials are issued, many organizations lose visibility into how they’re used or who is accountable for them.

We also need to shift control from identity registration to runtime authorization. Instead of asking, “Who owns this agent?” we need to ask, “Should this agent be allowed to act right now?” That’s a fundamentally different control point.

In a runtime authorization model, every action an agent attempts is evaluated in real time. Access is not assumed based on prior authentication. It is granted dynamically, based on current policy and context, which includes verifying the status of the human owner.

If the owner is no longer active, the agent doesn’t get access. There’s no manual intervention or checklist required, and there's no delay. That’s the kill switch most organizations don’t have today. Additionally, I’m seeing growing interest in human-in-the-loop controls, where agents pause for approval before taking higher-risk actions. The challenge is whether that model can scale at the speed and volume at which agents are expected to operate.

As agent adoption scales, so does the number of autonomous systems operating across environments, often created outside traditional development workflows and without centralized visibility. The longer they run without oversight, the more those risks compound.​

Based on what I’ve seen, most organizations already have ghost agents. The bigger question now is whether they have control over them.​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?