Every customer onboarding engagement our team runs starts the same way. We deploy Onyx and run the first scan of their environment. What we get back rarely matches what they believe their AI inventory to be.
The gap between what an organization believes is running and what is actually running tends to land somewhere between two and five times. Five times is not unusual. We have seen it at enterprises that had already run formal discovery exercises, at organizations with mature security programs, and at companies whose CISOs had specifically put AI governance on their priority list before we engaged. The inventory gap is not a sign of a careless security team. It is a structural characteristic of how AI agents enter organizations.
Our job in customer success is to make sure that gap does not turn into a program failure. The first 72 hours of a new deployment is the most important window in the onboarding cycle. This post is what we see in that window, and what security leaders need to understand before they walk into it.
What the First AI Agent Scan Finds in Week One
A pattern we documented in one recent deployment represents what we see consistently across our customer base.
The customer was in the hospitality sector. Before we deployed, their security team provided an inventory of AI agents they had approved, procured, and were actively tracking. Their count was reasonable. Their process for maintaining it was standard for an enterprise of their size.
When our platform ran the first inventory scan, the number that came back was more than five times what they had submitted.
The gap broke down in predictable ways. Several hundred agents had been stood up through vendor products where AI capability was embedded in software the company already licensed. No separate procurement motion had occurred because from IT's perspective nothing new had been purchased. Engineering teams had configured agents to automate internal workflows and had treated the process the way developers have always treated local tooling: quickly, to solve the problem, without a formal ticket. End users had activated agents through SaaS platforms that had added agentic features to their standard interfaces without prominent announcement.
Of the total agent population we surfaced, twelve were flagged as high-risk on initial review. Two required urgent remediation. One was a publicly accessible agent with operational scope well outside what any reasonable authorization would have covered. The other held access to HR records that included names, salary data, roles, and tenure information. Neither had been the subject of a security review. Both carried significant remediation cost and meaningful exposure if they had been reached before discovery.
The detail our team flagged to that customer's CISO: the high-risk agents had arrived through procurement paths that were technically legitimate. The software was licensed. The vendor had enabled the AI feature as a product update. No one had flagged the update as introducing a new security object. The security team had unknowingly expanded their agent surface without realizing it.
This pattern plays out the same way it played out with shadow SaaS and with OAuth application grants. The number you believe is rarely the number you have. The question is whether that gap becomes visible in week one of an onboarding engagement or in week one of an incident response.
Three Lessons from Week One
Our onboarding framework moves customers through seven phases: kickoff and discovery, environment setup, technical deployment, configuration, validation, training, and operationalization. Discovery is where we consistently encounter the same three structural challenges.
The inventory you submitted is a starting point, not a baseline.
The inventories customers submit before deployment are not wrong. They reflect what was formally tracked. But AI agents reach environments through paths that formal tracking processes were not designed to capture.
There are agents that were sanctioned by one team and never registered centrally. There are agents embedded in licensed products where no separate agent procurement occurred. There are agents built by engineering to automate processes that were treated as code artifacts rather than security objects. There are agents activated by individual users through SaaS interfaces that added agentic capability to tools already in use.
Each of these paths produces agents that are not unauthorized, exactly, but are invisible to the central inventory. Their permissions were never reviewed. Their access scope was never right-sized. No one has mapped what they can reach.
The work of week one is getting an honest count. An honest count requires querying the environment directly rather than accepting what was submitted to the security team. The gap between those two numbers is where the risk lives, and closing it is the first objective of a successful onboarding engagement.
Identity attribution is the problem you have not solved yet.
Non-human identity governance has a long history of getting deprioritized. Service accounts proliferated across enterprise environments for years, accumulated permissions that nobody audited, and outlived the contexts that originally justified them. As of 2024, the ratio of non-human to human identities in most enterprise environments exceeded 20,000 non-human identities for every 1,000 human identities. That ratio has only continued to climb as cloud, SaaS, and API-driven architectures have matured.
Agents inherit that problem and add a new dimension that service accounts did not have.
When an agent acts, the action is frequently attributed in logs to the credential the agent holds, which is often a human credential that was shared, borrowed, or inherited at setup time. The audit trail says a person did something. The thing that actually happened was an agent. In an incident, that distinction matters enormously for understanding blast radius and for any reconstructive analysis.
The attribution problem compounds in multi-agent architectures. When Agent A delegates a task to Agent B, and Agent B takes an action against a credential that traces back to a human employee, the accountability chain is broken at every handoff. You cannot govern what you cannot trace.
Getting identity attribution right for agents belongs in the early configuration phase of any deployment, before an incident forces the issue.
The inventory you run in week one is the start of a program, not the end of a project.
The customers who get the most value from their deployment are the ones who arrived in the onboarding engagement having already made this distinction internally. The customers who struggle treat week-one discovery as the deliverable.
The project-mindset approach has a consistent failure mode. A team runs the inventory, produces a report, presents the findings. Six months later, the environment has changed substantially: new agents deployed, existing agents reconfigured, and the report is no longer accurate. The organization has the documentation of a governance program without the operational reality of one.
Continuous AI visibility is an operational capability, not a one-time audit. It requires ongoing investment comparable to a vulnerability management program or an identity governance program. The customers who build this well treat agent inventory as an always-on function with ownership, escalation paths, and regular review cycles.
The agents you do not see are the agents that will create the largest surprises. The week-one inventory gives you a baseline. The program keeps that baseline accurate.
What a Successful Program Looks Like at 90 Days
The customers at the 90-day mark who are in the strongest position are not the ones who ran the cleanest week-one discovery. They are the ones who used week one as the foundation for a continuous practice.
A mature AI agent governance program is not about whether to let agents run. The question is whether the organization knows what those agents are doing when they run, has the controls to redirect agent behavior when policy requires it, and has the audit trail to answer the questions a regulator or a board member will eventually ask.
The first step is deciding to look.
Ready to see your real number? Get a demo and find out what's actually running in your environment.
