An agent books a meeting on Google Calendar. To do it, it authenticates as your marketing team's service account. For the next few seconds it can do whatever that service account can do. Then the task ends, the credential keeps living, and if you're like most organizations, nobody has a clear record of any of it.

Multiply that by every agent your organization has already deployed. Then by every one it's about to.

Non-human identity was already sprawling. Agents made it faster.

Service accounts, API keys, personal access tokens, IAM roles, and OAuth grants have been accumulating in enterprises for years. Most of them get created outside anyone's central view. A developer self-serves a personal access token in GitHub. A team spins up an IAM role in AWS. A service account gets provisioned in Salesforce for a project that shipped last year. Each one gets created independently, in whatever system needed it, and nothing pulls them into a single picture. Agents walked into that picture and started using all of it.

The gap most tools were built to close is inventory. Closing it matters. It also isn't enough.

Inventory tells you what exists. It doesn't tell you what's happening.

A static list of non-human identities answers a question security isn't really asking. "Do these credentials exist?" isn't what keeps a CISO up. What keeps a CISO up is not knowing:

• Which of those credentials is actually being used right now
• Which agent is using it, and for what
• Whether the access it's exercising is anywhere near the access it was granted
• Whether a leaked key from six months ago is quietly still in play
• Whether two agents are quietly sharing the same credential

An inventory pulled from an API connector can't answer any of that. Runtime can.

Live inventory, plus a live picture of what's running

Island pulls the inventory of what exists directly from the systems that issue non-human identities: cloud consoles, source repositories, SaaS platforms, and AI tools. That gives you the full picture of what's been created, wherever it originated.

The picture of what's actually running comes from a different set of control points. Island Desktop already sits on the endpoint. Island Network already sits on the wire. The Island MCP Gateway already sits on the tool-call path. When an agent authenticates as a service account, one of those control points sees the authentication. When a credential leaves the endpoint bound for an external API, Island sees the traffic. When an agent calls a tool through the MCP Gateway, Island sees the call. Every one of those events ties back to the identity used, and the identity ties back, wherever it can, to the human responsible for it.

The result isn't a snapshot pulled from provisioning. It's a picture of what's authenticated and running right now - which identity, doing what, against which resource, on whose behalf.

That vantage point surfaces things a static inventory never would. A hardcoded API key sitting in a repo, active and still valid. An identity that's gone quiet for months but never got decommissioned. An NHI whose granted access has drifted far broader than what it actually uses. A single credential being used by three different agents at the same time, which might be a legitimate service account or might be sprawl. Spotting that last one only becomes possible when granted access gets compared against actual usage, and Island has both data points.

Each finding gets handled differently. Rotate the leaked key. Disable the dormant identity. Scope back the over-privileged one. Untangle the shared credential. All of it before an agent picks it up.

Finding the credentials that were never registered

Not every non-human identity gets created through a proper process. Some sit inside scripts on a developer's laptop. Some live in a local MCP config file no admin has ever seen. Because Island Desktop already runs on the endpoint, it parses local files and configs for embedded credentials, and what surfaces isn't only what's been issued formally, but what's actually sitting on machines, ready for an agent to pick up. That kind of finding is invisible to any tool built only on API connectors, because there's no API to connect to.

Seeing turns into controlling at the gateway

Alongside the inventory sits a separate piece of architecture doing a different job. The Island MCP Gateway sits between every agent and the tools it calls. For any identity routed through it, the raw credential never reaches the agent. The gateway holds it. The agent authenticates to the gateway; the gateway authenticates onward.

That gives you three things a standing credential can't.

• Just-in-time access - Instead of a long-lived credential sitting in a config file, the gateway issues one scoped to a single task, expiring the moment the session ends.
• A cut-off switch that doesn't require rotation - If you need to stop an agent from reaching Salesforce, block it at the gateway. The underlying key stays intact. Nothing else that uses that credential gets disrupted.
• Private access to internal systems, without a custom integration each time - Legacy applications with no public endpoint become reachable to agents through the same gateway that governs everything else.
• Easy access to Enterprise MCPs - seamless access to MCPs that the enterprise has built for internal systems.  

It’s three distinct concepts. The non-human identity is the credential itself. The agent is the actor using it. The gateway is the control mechanism sitting between them. Treating those as one thing is a common source of confusion, and it's what leads to the assumption that governing the identity is the same as governing the agent's action. It isn't.

Boundaries on what an agent can do, not just what data it can see

The gateway also enforces what an agent is allowed to do once it has access. For example you can full permission authentication via Gmail OAuth for the user, but reduced permission set for the agents. Read-only on a specific MCP server. Blocked from calling delete on a Salesforce record. Permitted to pull customer records but not write them back. Customers are starting to call this Action Runtime Management. Whatever the label, the point is that data-level policy alone isn't enough for agents, because agents don't just read data. They take actions on it.

Ownership without paperwork

Every non-human identity Island discovers gets tied, wherever it can, back to a human. Some of that inference is rule-based today. Some is behavioral, still developing. The goal is that accountability shouldn't stop the moment a credential gets minted.

When something goes wrong, and eventually something will, the question isn't whether a credential was compromised. The question is who owns it. Whose team deployed the agent that used it. Which human decision sits on the other end of the machine action. Those answers should exist before the incident, not get reconstructed after it.

The identities are already there. The picture hasn't been.

Your organization has already issued more non-human identities than it has humans. Agents are about to accelerate that curve, not start it. The question isn't whether to inventory them. The question is whether inventory alone answers what the board, the auditor, and the CISO are actually asking.

A live picture of every identity. A gateway that gives out only what's needed, only for as long as it's needed. Boundaries on what agents can do once they're in. Ownership that traces back to a human. All of it running on the same substrate that already governs how your people work.

FAQs

What kinds of non-human identities does Island discover, and where?

Every non-human identity created across the environment: API keys, service accounts, personal access tokens, IAM roles, OAuth grants, and other machine credentials. Island pulls the inventory from cloud providers, source repositories, SaaS platforms, and AI tools through direct API integration, covering systems like AWS, GitHub, Salesforce, Copilot-type platforms, and vendor compliance APIs. Island Desktop also parses local files and configs on the endpoint, so credentials hardcoded into scripts or MCP configs surface alongside the ones issued through official channels.

Which control points does Island use for non-human identity (NHI)?

Island Desktop on the endpoint, Island Network on the wire, the Island MCP Gateway on the tool-call path, LLM Gateway integrations for organizations that already run one, direct API integrations with the cloud, source, and SaaS systems where identities get created, and vendor compliance API integrations for usage telemetry. Together they give both the inventory picture (what exists) and the runtime picture (what's running).

How does runtime usage mapping actually work?

Runtime usage is inferred from telemetry at Island's existing control points. For example, a specific API key seen in a network request through Island Network gets correlated back to the identity record in the inventory. That correlation is what turns "the identity exists" into "the identity is doing this, right now, on behalf of this agent." An inventory pulled through an API connector alone can't produce it, because the usage happens somewhere the connector doesn't see.

Can Island compare granted access with actual usage?

Yes. Once an identity is in the inventory and its runtime activity is being observed, Island compares the access it was granted against the access it actually exercises, and flags identities whose granted scope has drifted far wider than their real usage. Over-privileged identities are one of the largest sources of blast radius when an agent is compromised or misdirected, and the gap is invisible without both data points.

Does Island revoke or rotate credentials automatically?

Island integrates with identity providers like Okta and Microsoft Entra, and with application systems like Salesforce and GitHub, to surface recommended revocation and rotation steps from a single point of control instead of requiring a per-system cleanup. Whether a given action is executed directly or handed off to an admin depends on what the source system supports. The Island MCP Gateway also offers a distinct kind of remediation by cutting an agent off from a resource by blocking it at the gateway, without touching the underlying credential.

What about credentials stored in a Vault?

The goal of Island’s Vault integration is to surface where each discovered credential actually lives, whether that's a secrets manager, a local file, or a notebook, so exposure risk from poor storage becomes visible. 

How does this work alongside existing NHI, PAM, or identity governance tools?

Complementary, not overlapping. Classic NHI and PAM tools govern the access path. Namely, which identity may reach which resource, with what credential, for how long. Island governs what an identity is actually doing at runtime, drawn from control points those tools don't have. Customers commonly run Island alongside their existing identity infrastructure rather than replacing it.

‍