# The Hidden AI Agents Living Inside Your Enterprise Software
**Why the applications you already use are quietly running autonomous code — and what security teams need to ask before it’s too late.**
—
## The Invisible Majority
Enterprise software environments today contain an estimated 1,280 third-party products with embedded artificial intelligence. Of those, only around 282 are visible to single sign-on systems and identity governance frameworks. The remaining thousand operate in the dark — not because anyone deliberately obscured them, but because identity infrastructure only governs what authenticates through it, and most autonomous software agents never authenticate at all.
This is not a misconfiguration. It is a structural blind spot created by the very nature of how agents enter an organization.
For years, the conversation around AI security focused on what companies chose to deploy. A model was selected, licenses were purchased, a gateway was put in place, and security teams pointed their controls at a known quantity. That model presupposes a single, identifiable moment of adoption — a decision point where someone in the organization says “yes, we’re using this.”
Agents do not follow that script. They arrive embedded inside tools the business is already running, often as a quiet product update that no one formally approved.
—
## When Adoption Doesn’t Require a Decision
Consider a scenario where a widely-used collaboration platform releases a feature allowing users to summon an autonomous coding agent into any conversation. The agent reads shared context, writes code, and creates pull requests in production repositories. The platform’s announcement emphasizes that the agent will “inherit the platform’s existing permissions and admin controls from day one.”
To a product team, this sounds seamless. To a security team, this describes an autonomous actor with access to source code repositories and production infrastructure — governed only by the channel permissions of a chat application. There was no formal adoption process, no procurement review, and no security assessment because no one in the organization made a conscious decision to bring this agent into the environment. It simply appeared.
This is the defining challenge of agent security in 2026: the absence of a decision point means the absence of a review surface.
—
## Three Paths Into an Enterprise
Security leaders often categorize autonomous software agents into two groups: those purchased from vendors and those built internally. There is, however, a third and far larger category — and understanding it is essential to grasping the scope of the problem.
### 1. Inherited Agents
These arrive packaged inside existing enterprise platforms through routine product updates and feature releases. They require no procurement, no deployment, and often no awareness from the team using them. Every major application is becoming an agent platform, which means inherited agents are growing exponentially. Salesforce’s Slack Code is a representative example, but the pattern applies across CRM suites, communication tools, project management platforms, and cloud infrastructure providers.
### 2. Configured Agents
These are custom prompts, workflows, and logic created by an organization, but they run on infrastructure, models, and connector ecosystems owned and maintained by external vendors. The enterprise writes the instructions, but someone else’s runtime executes them, and those connectors reach into other systems the enterprise depends on.
### 3. Built Agents
These are constructed on frameworks the enterprise owns from end to end — open-source runtimes, self-hosted models, and infrastructure under the organization’s direct control. This category has the smallest footprint and the slowest growth rate, and it is also the only one where source code can be scanned and builds can be gated through traditional software supply chain practices.
The first two categories dominate adoption and are accelerating rapidly. The third, while more controllable, is where the least real-world deployment occurs.
—
## Where They All End Up
Regardless of how an agent enters an organization, its trajectory converges on the same destination: the enterprise application layer. An agent born inside a CRM eventually reads data warehouses and writes to ticketing systems. An agent assembled on a cloud platform accumulates access tokens to email platforms, file storage, collaboration tools, and beyond.
The enterprise application layer has no fixed boundaries. Permissions chain outward through integrations, OAuth scopes, shared workspaces, and transitive trust relationships between systems. By the time an agent has been active for even a short period, its potential impact — its blast radius — is shaped not by its own configuration but by the environment it was dropped into.
—
## Four Questions That Apply to Any Agent
Every autonomous agent has two fundamental components: the reasoning engine (the model) and the operational scaffolding around it (the permissions, connectors, triggers, and execution environment). The overwhelming majority of risk does not originate in the reasoning engine. It originates in the scaffolding and in the ecosystem that scaffolding inhabits.
The following four questions cover what matters, and none of them require evaluating what the model would do if left to its own devices.
### Identity
Is the agent registered in any system? Can a named individual point to it and say “this is mine, and I am responsible for it”? Or does it run silently under the credentials and context of whoever configured it, with no clear ownership?
### Permissions
What is the agent permitted to do? Is that scope of access more than what its actual tasks require? Whose OAuth tokens, role assignments, and access grants did it inherit, and was that delegation made deliberately or did it happen by default?
### Connectivity
What systems, data stores, and other agents can it reach — not just directly, but through chains of transitive access? This is the question that separates agent security from traditional application security. A vendor questionnaire, a prompt filter, or a model scanner evaluates an agent in isolation. Reach is an environmental property, and it is rarely visible from the agent’s own configuration dashboard.
### Activity
What is the agent actually doing, and does that behavior align with its intended purpose? This is judged by observed actions, not by the language used to describe the agent in its configuration or documentation.
—
## The Buyers Driving Change
Large financial institutions have been among the first to recognize autonomous agents as a supply-chain risk. In 2025, one global bank publicly identified third-party software as a systemic risk, citing specific incidents that led to the isolation of compromised suppliers. That scrutiny has since been directed at agents as well. The expectation emerging from these organizations is straightforward: an agent should receive an identity by default, but no entitlements. A human must confirm what the agent is authorized to act on before it can interact with systems outside its designated boundary.
When institutions of this scale begin treating agents as a supply-chain concern, the question propagates outward. Within a few quarters, it appears in security questionnaires sent to every vendor and partner in the supply chain.
Regulatory frameworks are aligning with this perspective. The European Union’s AI regulation, with obligations taking effect through 2026, assumes that enterprises can produce a comprehensive inventory of their AI systems, identify the owners of each system, and demonstrate ongoing oversight. An organization that cannot enumerate the agents operating within its environment will struggle to demonstrate compliance.
—
## From Spreadsheets to Continuous Visibility
Managing agent security through spreadsheets, periodic audits, and quarterly reviews worked — barely — when an organization had a few dozen agents. That approach collapses at a few hundred, and a few hundred agents is a single product update away from thousands.
What is needed is a continuous, automatically refreshed picture of what is operating in the environment. This includes a live map of every agent, the permissions each one inherited, the systems it can access directly and through chains, the behavior it exhibits, and how all of those attributes have changed over time.
Several platforms are now being built around exactly this kind of continuous, environment-wide visibility. The core principle is the same: shift the unit of analysis from configuration to reach. Understanding an agent means understanding not just what it was told to do, but what it can actually do, through what paths, and within what context.
—
## Frequently Asked Questions
**Q: Why can’t traditional identity and access management tools handle autonomous agents?**
A: Traditional identity systems govern humans and service accounts that authenticate through established protocols. Most autonomous agents do not authenticate at all — they operate as background processes embedded within applications the enterprise already uses. Because identity infrastructure can only manage what it can see authenticating, these agents fall outside its scope by default.
**Q: Is the model itself the biggest risk in an agent system?**
A: No. The model handles reasoning and language processing, but the operational risk lives in the scaffolding around it — the permissions it inherits, the systems it can reach, the tokens it holds, and the actions it can take on behalf of users. Almost all meaningful risk surfaces in the execution environment and the network of access it creates, not in the model’s internal operations.
**Q: How do inherited agents differ from built agents in terms of security?**
A: Inherited agents arrive pre-packaged inside existing platforms and require no deliberate deployment. Built agents are constructed by the organization on infrastructure it controls end to end. Inherited agents have the least visibility and the weakest governance hooks, while built agents can be scanned, tested, and gated using standard software security practices. The majority of agent adoption today happens through inheritance, not through building.
**Q: What does “connectivity” mean in the context of agent security?**
A: Connectivity refers to the full set of systems, data stores, and other agents that a given agent can reach — both directly and through chains of transitive access. For example, an agent with access to a collaboration tool might indirectly reach production databases through integration connectors built into that tool. Connectivity is an environmental property, meaning it depends on the broader system of applications and permissions the agent sits inside, not on the agent’s own settings.
**Q: How is regulatory compliance affected by agents?**
A: Emerging regulations, including the EU AI Act and related frameworks, assume organizations can produce a complete inventory of their AI systems, assign ownership, and demonstrate active oversight. Agents that enter environments through inherited deployment — without formal adoption or documentation — create gaps in this inventory that can result in compliance failures during audits.
**Q: What happens when an organization scales from a few agents to hundreds or thousands?**
A: Manual governance processes break down entirely. A handful of agents can be tracked through spreadsheets and periodic reviews, but hundreds of agents — many of them invisible, inherited through product updates — require automated, continuously refreshed visibility. The goal is a live map that shows what is operating, what each agent can do, and how that changes in near-real time.
—
## Conclusion
Autonomous agents are not a future risk — they are a present reality embedded inside the enterprise software organizations already depend on. The security industry built an impressive toolkit for governing AI that a company deliberately chose to deploy. That toolkit was never designed for agents that arrived without anyone choosing them.
The shift required is fundamental: move from managing AI systems as discrete, approved projects to managing agents as an ongoing property of the environment itself. That means continuously mapping not just what agents are configured to do, but what they can actually reach, who owns them, and whether their behavior aligns with their intended purpose.
The organizations that address this now will be ahead of both the regulatory expectations and the threat landscape. The ones that wait for a visible incident to prompt action will find that the damage was shaped by chains of access no one ever mapped.
Thank you for reading
