Non-Human Identity Security: The Credentials Your IdP Never Issued Are Being Created on Laptops

A non-human identity (NHI) is any credential that lets software, not a person, authenticate and act: service accounts, API keys, OAuth tokens, machine certificates, and now the tokens that AI agents and MCP servers use to reach your systems. The non-human identities that matter most in 2026 are not the ones sitting in your vault. They are the ones employees create on their laptops by pasting a key into an AI client or approving an OAuth grant, which never pass through your identity provider at all. dope.security is the practical answer because it sees those identities the first time they are used, at the device egress, and gives you the visibility and control to govern them.

Every identity team has the same slide. Human identities: a few thousand, all in the IdP, all behind MFA. Non-human identities: some multiple of that, scattered across cloud consoles, CI pipelines, SaaS integrations, and a secrets manager that is nobody's full-time job. The industry's answer has been a new category, non-human identity management, that inventories those credentials, rotates them, and scopes them down. That work is necessary. It is also aimed at the wrong end of the growth curve.

The fastest-growing population of non-human identities in most companies is not being created by platform engineers in Terraform. It is being created by ordinary employees, on ordinary Tuesdays, when they connect an AI assistant to something. Our guide to MCP server security and governance walks through the mechanics of one of those connections. This post is about the identity problem underneath all of them.

What is a non-human identity?

A non-human identity is a credential or principal used by a workload, application, or automated process to authenticate to another system. The classic examples are service accounts in Active Directory or Entra, IAM roles and access keys in AWS, service principals in Azure, API keys issued by SaaS vendors, OAuth client credentials, SSH keys, and X.509 certificates on servers and devices. What they share is that no person types a password, no MFA prompt fires, and the credential usually lives far longer than any human session.

Three properties make NHIs hard to govern. They outnumber humans, frequently by an order of magnitude, because every integration and every automated job needs at least one. They are over-permissioned by default, because the person who created the key had a task to finish and granted whatever scope made the error go away. And they are rarely offboarded, because there is no HR event that tells you a script stopped needing its token. Every one of those properties gets worse when the "workload" holding the credential is an AI agent that a user configured five minutes ago.

Why are AI agents and MCP servers changing the NHI problem?

Because they moved credential creation from the platform team to the endpoint. Consider what actually happens when an engineer wants an AI coding assistant to read the company wiki and query a staging database. The assistant supports the Model Context Protocol, so the engineer adds an MCP server to a local config file and pastes in an API token. Which token? The one they had, which is usually scoped far wider than the task needs. Now a program running on a laptop has standing, automated access to internal systems, authenticated by a non-human identity that appears in no vault, no IdP, and no CMDB.

Multiply that by every AI tool trial this quarter. When dope.security scanned 10,000 endpoints, employees were connecting to 56 different MCP server domains that IT had no record of, spanning CRMs, code repositories, financial systems, and meeting recordings. Each of those connections is at least one non-human identity. Most of them were created by pasting a secret into a desktop application, and none of them were created through a process your identity team could observe.

The same pattern shows up in your SaaS tenants. When an employee clicks "Allow" on an OAuth consent screen so an AI note-taker can read their calendar and email, they have just minted a non-human identity with delegated access to Microsoft 365 or Google Workspace. It is durable, it is over-scoped, and it was approved by a person whose job is not security. We unpacked the persistent-access version of this in what is shadow MCP, but the identity framing is the useful one: shadow AI is a user decision, shadow MCP is a configuration decision, and both of them produce credentials you did not issue.

Why can't the IdP or the vault see these identities?

Because they were never asked. Your identity provider governs identities that authenticate through it. A token pasted into an MCP config authenticates directly to the target API using a key the vendor issued. Your secrets manager governs secrets that were checked into it. A key sitting in a JSON file in a user's home directory was never checked in anywhere. Your CASB's API integration governs OAuth apps connected to your sanctioned tenants, which is genuinely valuable and the right tool for that slice, but it says nothing about a token for a third-party MCP server hosted by a startup you have never heard of.

Non-human identity management platforms are built to discover credentials across cloud consoles, code repositories, CI systems, and IdPs. That is the right scope for identities created by engineering. It is the wrong scope for identities created by end users on endpoints, because the credential never lands in any of those places. The only moment it becomes observable is when it is used, and the only place that use is guaranteed to be visible is the network egress of the device where the AI client is running.

This is the same discovery gap that makes shadow SaaS hard, and the playbook is related. Our shadow IT discovery playbook covers how to build an inventory from what devices actually talk to. NHI discovery in the AI era is that playbook applied to credentials.

What does the endpoint see that identity tooling cannot?

An agent that inspects traffic on the device, with on-device SSL inspection, sees the full encrypted request: the destination domain, the full URL or path, the process that originated the connection, and, for AI workloads, the prompt text and uploaded file contents. That combination answers the questions an NHI program actually needs answered about endpoint-born identities:

• Which systems are being reached by software rather than a browser? A connection to an MCP server or an AI API from a desktop client, IDE, or CLI process is a non-human identity in use, and process attribution names the application that holds the credential.
• Who owns it? The agent knows the logged-in user and the device, so every machine credential in use maps back to a human owner, which is the one thing most NHI inventories struggle to provide.
• What is it touching? Full-URL visibility shows whether a connector is reading a public documentation endpoint or writing to a production data store.
• What data is flowing through it? Dopamine DLP inspects the prompt and upload content moving through AI connections and classifies it with zero-retention AI, so you learn whether the identity is moving customer PII or lunch orders.

None of that replaces rotating your AWS keys. It fills the half of the NHI problem that rotation cannot reach.

How do the control points compare for non-human identities born on the endpoint?

Every architecture governs some slice of the non-human identity population. Here is where each one stops.

DNS filtering

A DNS-layer product sees that a device resolved an AI vendor's domain and nothing else. It cannot see which process made the request, which tenant it authenticated to, or what data moved, because roughly 95 percent of traffic is encrypted and DNS never sees the payload. Cisco's own documentation states that tenant-level control of ChatGPT requires the intelligent proxy, SSL decryption, and a root certificate, which DNS-only tiers do not have. For NHI discovery, DNS produces a list of domains and no identities.

Cloud-proxy SSE

Zscaler, Netskope, Cisco Secure Access, and Forcepoint can decrypt traffic in their clouds and, with the right add-ons, inspect AI prompts. Zscaler's prompt DLP requires the Data Protection add-on, with AI Guard and AI Scanning licensed separately, and Zscaler cannot inspect cert-pinned applications such as Microsoft 365, WebEx, and Dropbox, which land on a bypass list. Netskope's AI Guardrails are strong but ship in a higher tier. More fundamentally, a proxy in a data center sees a flow, not a process, so it has to infer which application on the device holds the credential.

Browser-based controls

Enterprise browsers and browser DLP extensions govern what happens in a tab. Non-human identities born from MCP configs, desktop AI clients, IDE plug-ins, and CLIs never open a tab. Menlo's AI controls are bound to the browser and miss API, IDE, and desktop AI, and its DLP is dictionary and regex based rather than semantic. For this problem, the browser is the wrong vantage point.

API-mode CASB and SSPM

Connecting to your Microsoft 365 or Google tenant by API is the right way to inventory OAuth grants inside sanctioned tenants, and dope.security's AI-Powered SSPM does exactly that, scoring each third-party app on granted scopes, publisher verification, and real usage telemetry with a one-click revoke. What API mode cannot do is see a token issued by a vendor that is not your tenant, which describes nearly every MCP server.

dope.security on the device

dope.security runs an agent on the endpoint and inspects encrypted traffic on the device, so it sees the process, the destination, the full URL, the tenant, and the content for every AI connection, browser or not, and attributes it to a user. Shadow IT discovery surfaces every MCP server domain in use, who is using it, how often, and from which tenants. Cloud Application Control enforces which SaaS and AI tenants may be used. Dopamine DLP inspects what moves. CASB Neural with AI-Powered SSPM covers the OAuth grants inside your sanctioned tenants. That is the complete picture of endpoint-born non-human identities, from a single console, with no data center in the path.

What does a practical NHI program look like in 2026?

Keep the platform half. Inventory cloud and CI credentials with the tooling built for it, rotate on a schedule, enforce least privilege, and delete what is not used. That work is mature and it matters.

Then add the endpoint half, which is where the growth is:

• Discover from egress. Turn on device-level Shadow IT and AI usage discovery and build the list of AI applications, MCP server domains, and AI APIs your fleet actually talks to. This list is your inventory of endpoint-born NHIs, and it comes with owners attached.
• Classify the destinations. Decide which AI vendors, agent frameworks, and MCP servers are sanctioned. Our agentic AI security guide covers the approval questions for connectors: what data they expose, what credential scope they use, who publishes them, and where their traffic goes.
• Enforce at the tenant level. Use Cloud Application Control to allow the corporate ChatGPT, Claude, Microsoft 365, and Google tenants and block personal ones, so the credentials employees create at least belong to identities you administer.
• Inspect the content. Run Dopamine DLP in monitor mode first, then block mode, so a connector that starts moving PII, PHI, PCI, or source code trips a policy instead of a breach report.
• Review OAuth grants in your tenants. Use AI-Powered SSPM to find over-scoped and stale third-party apps and revoke or downscope them in one click.

Companies that have done this describe the outcome in identity terms without meaning to. An oil and gas operator that replaced Cisco Umbrella with dope.security for AI governance finally had an answer to which AI tools its field engineers were connecting to and what data was reaching them, which is another way of saying it could see its non-human identities in use for the first time.

Where NHI security is heading

Agent-to-agent protocols, autonomous workflows, and MCP marketplaces will push the count of non-human identities up faster than any identity team can inventory by hand. The vendors building NHI management platforms are right that the population is exploding. The nuance is that the explosion is happening on the endpoint, in configuration files and consent screens, not in the cloud consoles those platforms watch. The organizations that get ahead of it will be the ones that treat device egress as the source of truth for identities their IdP never issued.

That is the case for dope.security in one sentence: the non-human identities you did not create are only visible where they are used, and dope.security is already watching that spot. See how dope.security manages AI across browsers, desktop apps, and command-line tools, or book a 20-minute demo.

Frequently Asked Questions

What is the difference between a non-human identity and a service account?

A service account is one type of non-human identity, specifically a directory or cloud account created for an application to run under. Non-human identity is the broader category that also includes API keys, OAuth tokens and client credentials, SSH keys, machine certificates, and the tokens AI agents and MCP servers use. dope.security focuses on the NHIs created on endpoints when employees connect AI tools, which service-account governance does not cover.

How many non-human identities does a typical company have?

Industry estimates commonly put non-human identities at many times the number of human users, and the ratio rises with cloud and automation maturity. The count is hard to pin down precisely because a growing share of NHIs are created on endpoints by end users connecting AI clients and approving OAuth grants, which never appear in a vault or IdP. Device-level discovery, which dope.security provides through Shadow IT and AI usage visibility, is how those uncounted identities get into the inventory.

Is an MCP server a non-human identity?

The MCP server itself is a service, but the credential an AI client uses to authenticate to it, and the credential the server uses to reach your data, are both non-human identities. Because those tokens are typically pasted into a local configuration file, they bypass identity and secrets tooling entirely. dope.security surfaces every MCP server domain a device connects to, which is the first step to inventorying those identities.

Can a CASB discover non-human identities?

An API-mode CASB or SSPM can discover OAuth applications connected to your sanctioned Microsoft 365 or Google tenant, which is an important slice of the NHI population, and dope.security's CASB Neural with AI-Powered SSPM does this with risk scoring and one-click revocation. A CASB cannot see credentials issued by third-party vendors outside your tenant, such as MCP servers and AI APIs, which is why dope.security pairs SSPM with on-device traffic inspection.

Do I need a separate non-human identity management platform?

If your engineering organization has a large cloud and CI footprint, a dedicated NHI management tool for discovering and rotating cloud credentials is reasonable. It will not see the identities employees create on laptops by connecting AI tools, so pair it with endpoint-level visibility. dope.security covers that endpoint half, along with tenant control and DLP, from a single console.

Does DNS filtering help with non-human identity security?

Only marginally. DNS filtering can show that a device resolved an AI vendor's domain, but it cannot identify the process, the tenant, or the data involved, because it never sees the encrypted payload. Cisco's own documentation confirms that tenant-level AI control requires a proxy with SSL decryption and a root certificate, not DNS alone. dope.security performs that inspection on the device, so it sees the identity in use rather than just the domain.