Most companies have a reasonable idea of who their employees are. They have an HR system, an IdP, an org chart, and some process for onboarding and offboarding people.
They usually have a much weaker understanding of what else can act inside their environment.
That is where shadow API keys and service accounts become a problem. They are not always tied to a human user. They often do not show up cleanly in the IdP. They may have been created for a project, integration, workflow, migration, script, or vendor connection that no one fully remembers. And unlike employees, they do not resign, change departments, or appear on an offboarding list.
So when teams ask, “How do we find shadow API keys and service accounts?” they are really asking a broader question: what non-human identities exist in our environment, what can they access, and who is responsible for them?
The uncomfortable answer is that there is rarely one place to look. These identities are scattered across cloud platforms, SaaS apps, developer tools, OAuth grants, automation systems, and local admin consoles. Finding them usually requires pulling together multiple signals and accepting that discovery is not a one-time project.
The easiest place to start is with systems that treat non-human identities as first-class objects. Cloud platforms are usually the clearest example.
In AWS, that may mean reviewing IAM users, roles, access keys, and workloads with programmatic access. In Google Cloud, it may mean reviewing service accounts, keys, and permissions. In Azure, it may mean reviewing managed identities, app registrations, enterprise applications, and secrets.
This is usually where teams find the most structured data. You can see when some credentials were created, when they were last used, what permissions they have, and sometimes what systems depend on them. That makes cloud a good starting point, especially for security and infrastructure teams.
But even here, the work is not always clean. Many service accounts have vague names, unclear ownership, broad permissions, or no obvious business context. You may find accounts created years ago for migrations, reporting jobs, data pipelines, or scripts that still run somewhere in the background. The technical object exists, but the human context around it is missing.
That is the first big lesson: finding the account is not the same as understanding the account.
The next place to look is wherever code, infrastructure, and automation live. API keys are often created to make something work quickly, and that means they frequently show up in developer workflows before they ever make it into a formal inventory.
That can include Git repositories, CI/CD systems, environment variables, build tools, deployment scripts, infrastructure-as-code files, secrets managers, and internal automation platforms. Experienced teams often use secret scanning here because it catches a very real pattern: credentials that were created for a legitimate reason, stored somewhere convenient, and then forgotten.
This is not just about hardcoded secrets in code. Many keys are technically stored in the “right” place, but still lack ownership, rotation, scope, or review. A key in a secrets manager can still be overprivileged. A token in a CI/CD system can still belong to a former employee. A credential used by a deployment job can still have access far beyond what the job requires.
Developer systems tell you how non-human access is actually being used. That makes them valuable, but also messy. They often expose the gap between what security policy says should happen and what teams had to do to ship something.
A lot of shadow non-human access lives inside SaaS applications themselves. Many apps allow admins or users to create API tokens, webhooks, integration users, personal access tokens, or app-specific credentials directly inside the product.
This is where discovery becomes frustrating because every app has its own model. One app may have clear token ownership and expiration. Another may show only a token name and creation date. Another may bury API access in a developer settings page. Another may not make it easy to export anything at all.
Practitioners often end up going app by app, starting with the systems that hold the most sensitive data or run the most important workflows. That usually means CRM, support, finance, HR, engineering, data, and collaboration tools.
The goal is to answer a few basic questions. What tokens or service accounts exist? Who created them? When were they last used? What permissions do they have? Are they still needed? Can they be tied back to a team, system, or business process?
This work is tedious, but it matters. A SaaS API token can sometimes do more damage than a normal user account, especially if it has admin permissions, broad read access, or the ability to export data.
OAuth is one of the most common ways shadow access enters the environment. An employee connects a third-party app to Google Workspace or Microsoft 365, approves a set of scopes, and suddenly that app can read files, send email, access calendars, or act on behalf of the user.
From the user’s perspective, they clicked “Allow” to make a tool work. From a security perspective, a new delegated access path now exists.
This is especially important because OAuth access often bypasses the traditional IdP mental model. The app may not be in Okta. It may not be part of an approved software list. It may not have gone through procurement. But it can still have meaningful access to company data through Google or Microsoft.
Teams should review OAuth applications, consent grants, scopes, publishers, user counts, and high-risk permissions. The practical question is not just “is this app approved?” It is “what can this app do, and on whose behalf?”
This is also where AI agents and automation tools make the problem more urgent. As more tools act on behalf of users, OAuth grants become part of the effective access picture, not just an app discovery problem.
Activity logs are useful because they show what is actually being used. Cloud audit logs, SaaS audit logs, API gateway logs, SIEM data, and network telemetry can all help identify active keys, service accounts, and integrations.
This matters because not every discovered credential carries the same urgency. A key that has not been used in two years may be a cleanup candidate. A service account making thousands of API calls a day may be business-critical. A token used from an unexpected location may require immediate investigation.
But activity is only one signal. Logs can tell you what is being used, not everything that exists. Dormant credentials may be invisible until they are abused. And active credentials may still be overprivileged, even if their usage looks normal.
The best teams use activity to prioritize. They do not treat it as complete discovery.
The hardest part of this work is not always technical. It is organizational.
You find an API key or service account and ask who owns it. The answer is often unclear. Maybe it belonged to a former engineer. Maybe it was created during an implementation. Maybe it powers a dashboard no one wants to break. Maybe the team is afraid to delete it because no one knows what will happen.
That uncertainty is the risk.
Every non-human identity should have an owner. Not just a creator, and not just a vague team name. Someone needs to be accountable for why it exists, what it can access, and whether it is still needed.
Ownership is what turns discovery into control. Without it, you are just building a list of scary things.
The goal is not to run one big cleanup and declare victory. Shadow API keys and service accounts will keep appearing because the business keeps adding tools, integrations, automations, and now AI agents.
A healthier process looks more continuous. New non-human identities should be created through an approved path. Owners should be assigned at creation. Permissions should be scoped to the actual job. Credentials should expire or rotate. Usage should be monitored. Access should be reviewed periodically. Unknown or ownerless identities should be treated as risk.
This does not need to be perfect on day one. But it does need to become a normal part of access management.
API keys and service accounts are not edge cases anymore. They are part of how modern work happens. SaaS apps talk to each other. Workflows run automatically. Data moves through integrations. AI agents act on behalf of users and teams.
That means identity is no longer just about employees logging into applications. It is about every human and non-human actor that can touch company systems or data.
Your IdP may tell you who can log in. It probably will not tell you every API key, OAuth grant, service account, integration, bot, or agent that can act inside your environment.
That is why this problem feels hard. Access no longer lives in one place.
To find shadow API keys and service accounts, start with the systems where they are easiest to see: cloud platforms, SaaS admin consoles, developer tools, OAuth grants, secrets managers, and activity logs. Expect the first pass to be incomplete. The point is not to find everything perfectly. The point is to create a repeatable process that makes unknown access harder to hide over time.
The real goal is not just discovery. It is accountability.
For every non-human identity, you should be able to answer: what is it, what can it access, who owns it, when was it last used, and is it still appropriate?
If you cannot answer those questions, you do not have a visibility problem. You have an access control problem.
