How we work: what onboarding actually reveals
Before we turn anything on, someone on our team reviews what the customer already has: which tools are connected through MCP (the Model Context Protocol agents use to reach them), who can use each one, and how that access is used versus how it was granted. We do this by hand. The useful findings are almost never in a clean list. They sit in the gap between a permissions spreadsheet and what a person says once we start asking. Nearly every onboarding turns up something nobody had fully mapped: a trial integration still live, a grant that outlived its project, a tool three teams each think they own. PagerDuty's 2026 survey found 98% of organizations already have employees using AI tools nobody approved, and about 55% cannot say which employees. This is exactly why we start with a review.
What happens first?
Nothing gets configured. Before an access policy or a new integration, we sit down and go through what is already connected, who has it, and how it is used day to day. It is the least glamorous part of onboarding, and it shapes almost everything we configure after.
A company does not arrive with a blank slate. It arrives with however many integrations different teams set up, granted whatever seemed reasonable at the time, used however people found useful. A policy written against a tidy version of that is wrong from day one. Nobody notices until something breaks.
What does the review turn up?
A gap between the spreadsheet and the person. The list says a tool is scoped to one team. On the call, someone mentions that another team has been using it for months through a shared login nobody flagged. A trial that ended is still connected, because turning it off was never anyone's job. None of this is in the documentation. It shows up when you compare what people say with what is on paper.
Why do this manually?
A scan can tell you an integration exists and which scopes it was granted. It cannot tell you the person who set it up left eight months ago, or that a tool the list calls read-only is triggering a workflow nobody remembers approving, or that two teams both think they own the same integration and neither has touched it in months. Those are conversations, not scan results. We run automated checks too. The surprises come from asking the people who touch the systems and comparing that to the paper.
Is an unmanaged integration unusual?
No. Writing this as if it were would be dishonest. PagerDuty's 2026 Shadow AI Workplace Survey covered 1,250 office professionals at companies with $500 million or more in revenue, across the US, UK, Australia, and Japan. 66% have used an AI tool at work that was not approved. 98% of the organizations already have this happening somewhere. About 55% cannot say which employees. Engineering teams had the highest rate of unsanctioned use, at 79%, which matches what we see: the people closest to the tools found the workaround first.
What happens once the review is done?
The policy is written against what is there. An integration nobody has used in months gets a decision: keep it, reassign it, or shut it off. A permission that outlived its purpose gets scoped back down. After that, access is enforced by role through access control, and agent activity runs through Magic MCP with a traced record of what it touched, so the picture does not go stale the way the original list did.
This is not exciting, and the customer sees none of the product yet. Skipping it means governing an inventory that was wrong at the start. Companies that start from an accurate picture have a shorter list of surprises later. Companies that skip the step, or skim it, spend the next few months finding the same gaps, at a worse time: an access request nobody expected, or a workflow that breaks because a permission it still used got cleaned up. The finding itself is rarely one dramatic thing. It is several smaller ones, most often an integration or a grant still active past the reason it was set up, that add up to a different picture than the paperwork.
What would we tell another team?
Talk to people before you trust the list. A permissions export is a starting point. The gap between the export and the conversation is where the risk is. It is slower than trusting the documentation, and it never shows up in a demo. It is also the part that decides whether everything built on top of it holds.
FAQ
Is the review automated or manual?
Both. Automated checks confirm what is connected and which scopes exist. The conversation is what surfaces the gap between that and what people are doing.
Does this only happen to Metorial customers?
No. PagerDuty's 2026 survey found unapproved AI tools in 98% of organizations, and about 55% cannot name which employees. The pattern is broad.
Why not trust the existing permissions doc?
Existing documentation is usually out of date in specific, non-obvious ways: an integration that outlived its original purpose, a grant nobody revisited, access being used differently than it was scoped. The doc records what was true when it was written, not what is true now.
Sources
- PagerDuty, "Shadow AI Workplace Survey," 2026 (checked 2026-09-20)