Table of Contents
Personal AI agents just went mainstream
In a single month, the personal AI agent went mainstream. Meta’s Muse, launched on September 8, hit the top of Apple’s free app chart within 10 days. Instinct, a startup you text or call, just raised $1 billion at a $10 billion valuation.
These aren’t chatbots. They read your email, book, buy and correspond on your behalf. To do that, Instinct users give the agent broad authority to read and store data from any account they connect, and to make purchases and accept agreements in their name.
That’s the consumer version. The enterprise version is already running inside your organization: agents opening tickets, pushing code, pulling customer data and approving workflows. Same pattern, higher stakes. Once an agent acts, it needs access. And access is what attackers are looking for.
Behavior is only half the problem
Most of the security conversation is about agent behavior: guardrails, prompt injection, what the model is allowed to say. That’s real, but it’s half the problem.
Every agent authenticates to something: a database, an API, a SaaS app, another agent. That authentication is a non-human identity (NHI). A key, a token, a service account. Ship an agent, and you’ve also shipped an identity, usually one nobody registered and nobody owns. If that credential leaks, the guardrails don’t matter.
In research we published this month, we analyzed roughly 82,000 public MCP configuration files, the layer that connects agents to enterprise systems. We found secrets and access keys embedded in plain sight, available to grab and exploit. This isn’t a model problem. It’s an identity problem.
Three common questions leave organizations exposed. Here’s what to ask instead.
1. Don’t ask how many agents you have. Ask what identities they run on, who owns them, and how fast you can shut them down.
Picture two teams. A developer connects a coding agent to MySQL, Snowflake and CI. Marketing connects an agent to Drive, Salesforce and a REST API. Two agents, both approved. This is the picture most security teams have.
But to make them work, someone minted a password, a key, an API token, a service account, a personal access token and a certificate. Two agents. Six identities nobody inventoried. They weren’t provisioned as identities. They were created as a side effect of getting something to work, fast.
That’s why counting agents gives you the wrong number. The agents aren’t what touched your systems. Their credentials are. Every one of those identities needs a named owner, a place in a central inventory, and a risk profile: which systems it reaches, what data it can touch, and what happens if it’s compromised. An agent with read access to a wiki and an agent that can move money are not the same problem.
And every agent needs a kill switch. When one misbehaves or its credentials leak, the response can’t be a hunt for scattered keys across repos and config files. When each agent has a single verified identity, revoking it cuts off all access instantly, everywhere, in one action. If you can’t stop an agent in seconds, you don’t control it.
2. Don’t ask if the agent is secure. Ask what it’s allowed to do, and who decided.
The fastest way to connect an agent is to hand it a static key with broad permissions. That key usually carries whatever scope its creator had that day, serves every user the same way, and outlives the project, sometimes the employee. It works until it leaks. Then the attacker gets everything the agent can do, and often more.
The answer isn’t better secret rotation. It’s removing standing secrets altogether. Agents should authenticate as identities, not with shared keys, and receive least agency: only what the task requires, scoped to the user or team they act for, expiring when the task ends.
If an employee can’t delete a database, neither can their agent. That policy already lives in your identity provider. It just needs to extend to agents. Nothing to rotate, because nothing persists.
3. Don’t ask what happened after the incident. Ask what was stopped in the moment.
Plenty of tools produce polished risk dashboards and send alerts. That matters, but agents operate at machine speed. By the time the alert lands, the data is gone. And when you investigate, the log says “API key.” It doesn’t say which agent, which user, or which task.
The difference is between monitoring and enforcement. Real control sits in the path of the action itself: every agent request tied to an identity, checked against policy, allowed or blocked in real time, and recorded with full attribution. That delivers both protection and the ability to show regulators and the board exactly who did what, when and why.
Your new workforce needs identity-first security
What ties these questions together is a shift in how we think about enterprise identity. Your people get an identity, an owner, a lifecycle and offboarding. Your agents get a secret in a vault, or an env file, and a hope that someone remembers it exists.
AI agents are a new workforce: they operate like machines, decide like people, and multiply faster than both. They need to be managed like one.
Leadership doesn’t have to choose between speed and security. It needs to ask different questions: not how many agents, but what identities they run on; not whether they’re secure, but what they’re allowed to do; not what happened, but what was stopped.
Organizations that secure both the agent and the identity it runs on will scale AI with confidence. The rest will discover their shadow identities the hard way.