Shadow AI agent with inherited credentials

The scenario

A developer on the growth team builds a small agent to answer questions about feature usage. They connect a model to an MCP server that wraps the analytics warehouse, the ticketing system and the company chat, then run it on a spare virtual machine under their own credentials because that was the quickest way to get it working. It is genuinely useful, so colleagues start messaging it. Within a month it is answering questions from sales, support and finance, and someone has added a tool that can update ticket fields so it can triage. Nobody registered it anywhere, because it was a side project.

Security learns about it when the warehouse team notices an unfamiliar query pattern and traces it to the developer's credentials, by which time the developer is on leave. Nobody can say which tools the agent holds, what data it has read, who can message it, whether its prompt has changed, or whether the MCP server is the one the developer installed or a later version from a fork.

Why it happens

• Agents are built, not procured. An engineer with a model API key and a package manager can stand up an agent in an afternoon; no purchasing, provisioning or access-request process is involved.
• Inherited credentials are the path of least resistance. Running under a developer's identity avoids creating a service account, so the agent's authority is whatever the developer's authority is.
• MCP servers multiply tools quietly. Each connected server adds capabilities that no access review sees as permissions, and the server's own provenance is rarely checked.
• Usefulness spreads faster than governance. By the time anyone asks who owns the agent, it already has users who depend on it.

How Trustivan helps

• Discovering agents from how they behave is not built. No connector discovers an agent, and endpoint telemetry is refused by design. An identity typed as an AI agent that lacks a profile raises shadow_agent_unprofiled.

  Not built

• Give the agent its own credential. Nothing observes an agent borrowing a developer's credentials. An agent in the inventory presents its own runtime credential instead: minted by a person, valid 1–90 days, revocable.

  Available

• Inventory its tools and MCP servers. The MCP connector records each server and the tools it lists, with the effect its publisher declares. Which agent may use which tool is a tool entitlement an operator declares, never an observation.

  Available

• Establish provenance. An agent's configuration history and the humans who changed it are not captured, by design: no connector reads an agent's configuration, and agent lineage reports as unavailable rather than guessed.

  Not built

• Give it an owner and a decision. An agent already in the inventory can be given an owner, or quarantined inside the platform, and the gate then denies it every action.

  Available

What the evidence looks like

The record this problem calls for is an inventory entry that should have existed from day one, with the human it borrows authority from made explicit. Illustrating the problem:

Related capabilities

• Agent Discovery — MCP tools and servers from the MCP connector; agents are not discovered
• MCP Security — which servers are connected, what they expose and where they came from
• Agent Identity — a governed identity for every agent instead of a borrowed human one
• Agent Provenance — why agent lineage reports as unavailable rather than guessed
• AI & MCP environments — the solution view for agent and MCP estates