How a Regional Bank Discovered 143 Shadow AI Agents and Contained the Highest-Risk One in Under 24 Hours
Published:
August 30, 2026
Niall Browne
Summary
A U.S. regional bank had an AI policy and five approved tools, but no reliable way to see what was actually running across the environment. In the first 24 hours, AIBound cataloged 143 AI agents, identified a high-risk autonomous agent running on 11 endpoints, found risky installed skills, mapped access to sensitive systems, and helped the bank contain the exposure before any records were exfiltrated.
Key Takeaways
The bank had a formal AI policy and five sanctioned tools, but AIBound discovered 143 AI agents in the first 24 hours.
The most critical finding was not the total number of AI agents. It was one autonomous agent running on 11 endpoints with sensitive-system access, risky installed skills, and outbound communication paths.
The agent had shell execution, file management, mailbox and calendar operations, access to payroll information, a connection into banking systems, and multiple outbound messaging paths.
Installed skills included instructions to suppress confirmation prompts and proceed without asking for permission, directly conflicting with the bank’s policy.
The agent received an F Trust Score and a deployment recommendation to block.
AIBound helped the bank turn discovery into containment by mapping affected users, identifying installed skills, tracing reachable systems, and cutting outbound communication paths.
Enforcement was pushed through the bank’s existing EDR and SIEM rather than requiring new endpoint tooling.
The full path from discovery to containment took under 24 hours, and the case study reports zero records exfiltrated before containment.
The main lesson is that Shadow AI becomes dangerous when sensitive data access, autonomy, risky skills, and outbound communication combine.
Case study at a glance.
Case study overview. A U.S. regional bank had an AI policy and five approved tools but no reliable way to see what was actually running. In the first 24 hours, AIBound cataloged 143 AI agents and identified a high-risk autonomous agent with sensitive-system access, risky installed skills, and outbound communication paths.
Direct Answer: Shadow AI Becomes Dangerous When Access, Autonomy, and Egress Combine
The regional bank's experience shows why an AI policy is not the same as AI control. The organization had a formal policy and five sanctioned tools, yet AIBound found 143 distinct AI agents in the first day. The critical discovery was not simply that employees were experimenting with AI. It was that eleven endpoints were running an autonomous agent with shell execution, file management, mailbox and calendar operations, access to payroll information, a connection into banking systems, and multiple outbound messaging paths.
That combination turned an ordinary productivity decision into an enterprise security problem. AIBound's assessment did not judge the application on reputation alone. It evaluated publisher trust, installed skills, autonomous behavior, effective reach, vulnerability history, and the deployment context. The result was an F Trust Score and a deployment recommendation to block. Containment was pushed through tools the bank already owned, and the case study reports zero records exfiltrated before containment.
What the Bank Expected to Find Versus What Was Actually Running
The proof of concept began with modest expectations. The bank expected to find a handful of ChatGPT users. Instead, agentless discovery cataloged 143 AI agents during the first 24 hours, only five of which were sanctioned. This gap matters because shadow AI rarely arrives through one major technology deployment. It appears incrementally as employees adopt tools to solve local workload problems.
The eleven OpenClaw installations were especially important because the agent was not isolated from enterprise systems. Users had granted standing access to payroll information and banking connections. Some endpoints also had autonomous execution enabled. Installed ClawHub skills contained instructions to suppress confirmation prompts and proceed without asking for permission. The bank had a rule against exactly that behavior, but existing controls had not made the activity visible.
Why Reputation-Only Scoring Would Have Missed the Risk
One of the strongest lessons from this case study is that an AI application's name or publisher reputation is only one input. The highest-risk conditions came from the combination of the agent, its skills, its access, its permissions, and its outbound channels. The case study notes that the application itself could look unremarkable if examined without those relationships.
AIBound's assessment grouped the problem into five dimensions. Publisher and community trust were weak because accountability and code review around the skill marketplace were limited. Behavior and safety were poor because installed skills attempted to suppress confirmation prompts and bypass approval. Agentic reach was broad because the agent had shell execution and user-granted access to sensitive systems. The vulnerability record included an unpatched high-severity CVE. Finally, the deployment recommendation was block because the failure modes were architectural rather than a simple configuration issue.
The Security Pattern Behind the “Lethal Trifecta”
The case study describes a particularly dangerous combination: sensitive data, untrusted content, and outbound communications. Each factor can be manageable in isolation. Approved systems routinely process sensitive data. Employees routinely consume external content. Outbound communication is a normal business function. When an autonomous agent can combine all three without sufficient controls, the blast radius changes significantly.
This is why agentic AI security needs to map both authority and communication paths. Security teams should ask which identity the agent operates under, which data stores that identity can reach, which actions the agent can perform, and which destinations can receive information. The OWASP Top 10 for Agentic Applications provides a useful external reference because it highlights risks such as identity and privilege abuse, tool misuse, and agentic supply-chain vulnerabilities.
How AIBound Turned Discovery Into Containment
Visibility alone would not have been enough. After identifying the agent and scoring its risk, AIBound mapped the affected users, enumerated installed skills, identified reachable systems, and traced outbound communication options. That context gave the bank a precise basis for action rather than a broad ban on employee AI use.
The bank then pushed enforcement through its existing EDR and SIEM. The agent was blocked from launching, its messaging paths were cut, and stored credentials were flagged for rotation. According to the case study, the full path from discovery to containment took under 24 hours and did not require new endpoint tooling or a manual investigation.
Case-study control flow.
A Practical Shadow AI Response Playbook for Financial Institutions
Financial institutions can apply the same operating model even when their toolset is different. Start with continuous discovery across browsers, endpoints, networks, cloud platforms, SaaS applications, developer environments, and autonomous agent frameworks. Build an inventory that distinguishes sanctioned, pending-review, and unsanctioned AI.
Next, enrich every AI resource with identity, permission, data, behavior, and destination context. Move high-risk combinations to the front of the queue. A low-privilege writing assistant used with public content is not equivalent to an autonomous agent with shell execution, sensitive-data access, and multiple uninspected communication channels. Finally, connect risk thresholds to response actions: allow, monitor, restrict, quarantine, block, revoke credentials, or require human approval.
What Security Leaders Should Measure After Discovery
A shadow AI program becomes more useful when leaders measure outcomes rather than raw tool counts. Useful metrics include the number of AI resources discovered, percentage with a named owner, sanctioned versus unsanctioned usage, agents using privileged identities, resources that can reach sensitive data, autonomous actions requiring human approval, high-risk resources contained, and median time from discovery to remediation.
The bank case also suggests a valuable executive metric: how much risk existed outside the official AI program. The organization had five approved tools but 143 agents in active use. That difference is the governance gap leadership needs to understand.
Frequently Asked Questions
Is every unsanctioned AI tool high risk? No. Unsanctioned means the organization has not completed an appropriate review. Risk depends on the specific tool, identity, permissions, data, autonomy, vulnerabilities, and communication paths.
Why did the bank's existing EDR, SIEM, and DLP not solve the problem on their own? The case study says those tools didn't surface the 143 AI agents. The missing layer was AI-specific discovery and contextual correlation across application, skill, identity, access, and reach.
Why is skill-level visibility important? Skills can change what an agent is instructed to do. In this case, installed skills included instructions to suppress confirmations and bypass approval, materially changing the risk profile.
Can organizations enforce AI policy without deploying another endpoint agent? In this case, AIBound connected agentlessly and used the bank's existing EDR and SIEM for enforcement.
Conclusion
The regional bank did not have an employee-maliciousness problem. It had a visibility and control problem. Employees adopted an agent to move faster, granted the permissions it requested, and had no environmental signal telling them that the combination was unsafe.
The larger lesson is that enterprise AI security must evaluate more than applications. Security teams need to see agents, skills, identities, permissions, sensitive-data paths, vulnerabilities, autonomy, and egress together. When those relationships are visible, shadow AI can be prioritized by actual business risk instead of fear, reputation, or blanket prohibition.
Implementation Checklist for the First 30 Days
Week one should focus on connecting existing telemetry and identifying the real AI inventory. Do not begin with a blanket block. Begin with visibility and classify resources by owner, use case, identity, data reach, autonomy, and destination. During week two, review the highest-risk combinations and validate whether permissions are actually required for the business purpose.
During week three, formalize response tiers and integrate them with the tools already used by security operations. During week four, publish approved alternatives and a fast request path so employees have a secure way to adopt useful AI. This combination of control and enablement is more sustainable than a policy that relies on employees self-reporting every experiment.
What This Case Changes About AI Policy Design
Traditional acceptable-use policies assume employees can recognize the boundary between approved and unapproved technology. Agentic AI makes that assumption weaker because a single product can acquire new skills, connectors, tokens, and execution rights after installation. A policy therefore needs to define not only which tools are approved, but also which capabilities are acceptable. Useful policy dimensions include autonomous execution, shell access, credential use, access to regulated information, uninspected outbound communication, third-party skills, and the ability to suppress or bypass human confirmation.
The bank case also shows why technical guardrails should back policy. Employees were not intentionally violating security. They granted access because the agent asked in natural language and nothing in the environment prevented the action. A strong program pairs employee guidance with controls that can detect when an AI agent's effective permissions or behavior exceed policy.
Questions a CISO Should Ask After a Shadow AI Discovery
Once a large shadow AI inventory is discovered, the wrong response is to treat every item as equally urgent. Security leaders should ask which resources have privileged identities, can access financial, HR, customer, or production data, have autonomous actions enabled, use unreviewed plugins or skills, and have outbound channels outside normal inspection. Those questions quickly reduce hundreds of findings into a smaller set of potentially material exposures.
The next question is ownership. Every resource should have a named business owner who can explain the use case and validate whether the requested access is necessary. Resources with no owner, no clear purpose, broad privileges, or unknown destinations deserve faster escalation because the organization lacks both technical and accountability controls.
Key Takeaways for CISOs and Security Leaders
For CISOs, the most important operational lesson is to separate AI adoption from AI authority. Employees may choose a tool, but the environment should decide what that tool can access and whether it can act autonomously. Discovery without permission context produces a list. Permission context without discovery leaves blind spots. The two must be connected so the organization can identify when an ordinary productivity tool becomes a privileged actor.
This also changes how exceptions should be handled. If a business team needs an AI capability, security can approve the use case while constraining specific permissions, data categories, or communication paths. High-risk combinations should trigger escalation automatically, while low-risk experimentation can remain available. That balance reduces the incentive for workarounds and focuses security effort on combinations that could create material harm.
Final Strategic Note
Across all five case-study patterns, the common requirement is continuous context. Enterprises need to know not only which AI resources exist, but also who uses them, what identities and permissions they inherit, which data and systems they can reach, what risk signals are present, and what governance decision is currently in force. That context makes it possible to distinguish productive AI adoption from material exposure and to respond proportionately. The strongest programs therefore connect discovery, assessment, approval, enforcement, monitoring, and reporting in one operating loop. That loop gives employees a safer path to use AI, gives security teams a way to prioritize the most important risks, and gives leadership evidence that policy decisions are actually being applied in the environment.
Original Case Study Snapshot
The source case study supplied for this article is shown below for reference. The blog preserves the case study metrics and outcomes while expanding the security and governance lessons into a long-form SEO article.
Organizations facing similar visibility, governance, or reporting challenges can explore AIBound to see how a live AI inventory and control plane can support secure AI adoption.
Leadership Review Questions
Use these questions to test whether the case-study lessons translate into a repeatable enterprise operating model:
Can we identify every AI application, agent, model, extension, plugin, and MCP service currently in use?
Does each material AI resource have a named business owner and documented purpose?
Can security map the human or machine identity, effective permissions, sensitive data, and connected systems behind each resource?
Are approval decisions conditional on least privilege, data boundaries, and ongoing monitoring?
Do high-risk conditions trigger a defined response such as restrict, block, revoke, or require human approval?
Can governance teams show when a resource was discovered, assessed, approved, changed, and remediated?
Can the organization produce evidence for a board, auditor, regulator, or incident responder without a manual data-gathering project?
Are adoption and risk trends improving together, or is AI usage expanding faster than the control program?
If several answers are uncertain, the priority is usually not another policy document. It is improving the live inventory, relationship context, ownership model, and enforcement path that make policy measurable and actionable.
See Your AI Attack Surface
Discover every AI tool, agent, and model running in your enterprise — before attackers do.
