What should organisations do first after discovering unmanaged AI agents?

Organisations should first isolate the credentials, tool connections, and data paths attached to the unmanaged agent before expanding use further. Then they should decide whether the system is approved, remediated, or retired. That sequence limits hidden authority and reduces the chance of an unseen workflow becoming an attack path.

Why This Matters for Security Teams

Discovering an unmanaged ai agent is not just a shadow IT issue. It means an autonomous workload may already hold secrets, tool permissions, and data access without an owner who can explain its scope. That is a different risk profile from a forgotten service account because the agent can act, chain actions, and spread access faster than a manual review can keep up. Current guidance from the OWASP Top 10 for Agentic Applications 2026 treats unmanaged autonomy as a first-order security concern, and NHIMG research shows why: in the AI Agents: The New Attack Surface report, 80% of organisations reported agents acting beyond intended scope.

The first task is containment, not policy writing. Security teams need to freeze the agent’s authority, identify every credential path and integration, and determine whether the system can be brought under governance without recreating the same exposure. In practice, many security teams encounter agent-driven data access only after the workflow has already touched systems that were never meant to be reachable.

How It Works in Practice

The immediate response should treat the agent like an active workload identity, not a named user. Isolate the identity, revoke or rotate connected secrets, and suspend tool access until the full graph of permissions is known. That includes API keys, OAuth grants, service accounts, webhooks, file stores, ticketing systems, and any downstream automation the agent can trigger. The control objective is to break hidden authority chains before they can be reused.

Then classify the agent into one of three states: approved, remediated, or retired. Approved means the business owner is identified, the data scope is documented, and access is reduced to the minimum necessary. Remediated means the agent stays offline until secret hygiene, logging, and approval boundaries are fixed. Retired means the workflow is too opaque, too risky, or too embedded to recover safely. This triage aligns with the lifecycle approach in the NHI Lifecycle Management Guide and with broader lifecycle thinking in the Ultimate Guide to NHIs.

For autonomous systems, static RBAC alone is usually insufficient. Best practice is evolving toward context-aware authorization, just-in-time credential issuance, and policy evaluation at request time, as described in the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework. The practical test is whether the agent can be forced to prove what it is, what it is trying to do, and why that action is permitted right now.

• Inventory every secret, token, certificate, and trust relationship attached to the agent.
• Disable broad standing access before expanding the agent’s use case.
• Require an owner, a purpose statement, and a rollback path before re-enabling any tool.
• Log the agent’s actions so investigators can reconstruct the full decision path.

These controls tend to break down when agents are embedded inside SaaS automation, where the identity chain is fragmented and no single team can revoke every downstream permission quickly.

Common Variations and Edge Cases

Tighter containment often increases operational friction, so organisations have to balance speed against the risk of preserving hidden authority. That tradeoff is most visible when a discovered agent is already supporting production workflows, because an immediate shutdown may disrupt customer-facing processes while leaving the organisation exposed if nothing is done.

There is no universal standard for this yet, but current guidance suggests treating unmanaged agents differently from ordinary orphaned accounts. If the agent can create follow-on tasks, call external APIs, or use memory across sessions, then the response should be closer to incident containment than routine access cleanup. In high-change environments, such as development sandboxes and code-generation pipelines, the agent may legitimately need short-lived credentials, but those credentials should still be ephemeral and tightly bounded. NHIMG research on the Top 10 NHI Issues and the AI LLM hijack breach shows how quickly weak identity controls can turn a convenience workflow into an incident path.

The hardest edge case is an agent created by a business team rather than security or IT. Those systems often have no formal owner, no clean access inventory, and no clear retirement path. In that situation, the safest choice is usually to pause the agent, capture evidence, and decide whether the value justifies rebuilding it under proper governance.

Related resources from NHI Mgmt Group

• What should organisations do first when securing LLMs and AI agents?
• What should organisations do first when AI agents and shadow integrations are spreading?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?