Agent Identity: The Million-to-One Problem

Agent identity is the practice of giving every AI agent its own credential, a named human owner, a written scope of what it may touch, and a log of what it did. Most founders meet it by accident. Someone wires an agent into Slack and a production database to unblock a workflow, it works, and the credential it used was a copy of a human's or a shared service account that nobody will revisit. Six months later there are more of them than anyone can list, and no one can say what any of them is allowed to touch.

Howard Ting started his career in identity at RSA Security in 2000, spent five years as CEO of Cyberhaven, and became CEO of Opal Security in late 2025. Opal is an access governance platform that raised $23 million in June 2026 and now runs agents through the same access graph as employees. Talking to Greylock about that agent launch, he put the gap in one sentence:

"agents are the most powerful entities or identities in the organization, they're the least governed, they're the least watched today"

That is a vendor describing the hole his product fills, in an interview run by Greylock, which co-led Opal's last round, so apply the usual discount twice. What survives it is the arithmetic underneath, because the arithmetic does not depend on believing him.

Why agent identity is a scale problem before it is a security problem

The number you have probably seen quoted is a ratio of identities. Ting repeats it and then says it is the wrong unit:

"there's often this ratio that we hear somewhere between 50 to 1 to 100 to 1 non-human or agent identities to every human"

He accepts that ratio as roughly right. His objection is that counting identities tells you nothing about the work of governing them, because the unit that actually generates load is the decision. Walk through a human grant and you can see why.

When an engineer requests access, even under a just-in-time scheme, the permission comes with a duration. Ting's examples are 7 days and 30 days. Inside that window the engineer acts on the resource "many, many times, hundreds of times, maybe thousands of times" and never asks again. One decision buys a thousand actions.

Now scope an agent the way you actually want to scope one:

"we might give the agent access to do its one task or give it access for 1 minute"

Same thousand actions, but each one needs its own grant. The identity count did not move; the decision count went up by three or four orders of magnitude. His version of the conclusion:

"for every 100 non-human identities per human, we're going to have to make thousands, tens of thousands of access decisions"

Which is where the headline number comes from: "the scale is more like a million to one." Treat that as a back-of-envelope multiplication rather than a measurement, because that is what it is. The structural point holds regardless of whether the exponent is five or seven: the tighter you scope an agent, the more decisions you create. Good hygiene makes the volume problem worse, which is a genuinely awkward property for a control to have.

This is the part most startups get backwards. Agent access gets filed under security, so it waits for a security hire. It is actually a throughput problem that security owns, and throughput problems do not improve by being postponed.

The human in the loop is the part that breaks first

Every access workflow in a normal company routes through a person:

"the way we govern access today is very human-driven. There's always a human in the loop."

An engineer requests, their manager approves. Someone in sales needs the CRM, their manager approves. That design has one assumption buried in it, which is that the requester can wait for a human to be awake and looking. Agents violate it twice over. They run overnight and on weekends, and they run at a speed where a 20-minute wait is not a delay but a failure. Ting says Opal's customers are explicit about the gap: they accept 10, 15, 20 minutes, sometimes a day, for human access, and then tell him their agents "need access decisions within a minute" or less.

His conclusion is the one his product is built on:

"that's where AI is managing AI. We can't have humans managing AI. It's going to be completely unworkable."

Note the circularity before you adopt the conclusion. Opal's answer to agent access decisions is its own AI decisioning engine, called Paladin, which evaluates requests and escalates only what needs a human. An identity vendor arguing that only AI can govern AI is arguing for its own roadmap.

The weaker and more useful version of the claim is this: any access path for agents that requires a human to be present has a throughput ceiling set by your team's working hours, and you will hit it. What you put behind that path is a separate decision. A policy engine you wrote yourself, a deny-by-default scope declared at deploy time, or a short list of pre-approved actions all clear the same bar, and none of them need a model in the loop. Where that enforcement point sits, and which parts of it you build rather than rent, is the build-or-buy question in AI agent infrastructure.

Ting's own argument for AI over a static rule is better than the velocity one. His case is that context, not speed, is what humans cannot supply at volume: whether the requesting engineer is assigned to the ticket, whether a ticket exists for this customer, the research a careful approver would do if they had time. He frames the usual trade as dead: "you make the product more usable, you make it less secure. You make it more secure, you make it less usable." Worth noticing that this is the oldest promise in the security industry, and the version of it that keeps proving true is narrower than the pitch. Automating the decision does remove the latency. Whether it improves the decision depends entirely on what the automation can see, which is a data problem your team owns either way.

Why agent access needs policy, not trust

The second argument is about behavior, and it is the one worth taking without any discount, because it does not sell anything.

Agents are persistent and, in Ting's words, "they lack inhibition." The consequence he draws is specific:

"the governance we put around agents can't simply be based on vibes"

His illustration of vibes-based governance is uncomfortably recognizable. When his best employee requests access, he says, "I probably don't even look at what they're requesting access cuz that's my best employee. I trust them." Every founder has approved something that way. The trust is doing real work there, and it is trust in a person who has a reputation, a manager, a performance review and a sense of what would get them fired. An agent has none of that and will pursue its objective with complete determination. His analogy, as a father of three, is children with "all the intelligence, but none of the inhibition that adults have."

Where this gets genuinely new is coordination. Ting expects agents breaking tasks into swarms of sub-agents, and his read is that this becomes "the more significant version of insider risk." His reason is a detection asymmetry from the data-loss world he came out of: insider incidents, he says, are nearly always a single employee, because multiple people coordinating is much harder to catch. Agents coordinate by default.

Two things make that worse than it sounds. The first is that the behavior does not need to be malicious to be damaging, only determined. The second is that the old mitigation is gone:

"The security by obscurity mantra that we could kind of hide behind 20 years ago no longer applies. Everything is visible. Everything can be found."

A forgotten API key in a repo used to be protected by nobody bothering to look. That assumption is void now, and not only for attackers: your own agents are excellent at finding credentials and endpoints that a human would have walked past.

The founders of Raindrop, which monitors agents in production and whose September 2026 Series A, led by CRV, brought its total funding to $50 million, describe the same slope from the other side. Talking to YC Root Access about building a safety layer for agents, they trace how scope creeps once a coding agent works: "the permissions start coming off", someone suggests hooking it into production, maybe it should have access to production logs, and "the stakes get higher." Their stated thesis for the company is two clauses and both are about this: "agents will get more capable" and "the cost of their mistakes will increase." What that costs when the agent is acting rather than reading is the subject of agentic payments, and the reliability half of the same surface is AI reliability.

The two bad defaults: too little agent access, or too much

Ask what companies without a governance layer are doing today and Ting's answer is that they compromise, in one of two directions.

The first is to scope narrowly out of caution. The agent gets so little access that it cannot do the job, and in Ting's words it never reaches its full potential. You have paid for an agent and shipped a macro.

The second is the more tempting one, and the worse one. Some of his customers tell him they cannot deploy anything that causes too much friction, so "they become very permissive and they absorb a lot of latent risk." Latent is the operative word. A permissive grant produces no incident on the day you make it, which is exactly why it survives your next three retros.

Here is where the honest conflict sits, and it is not a conflict between a vendor and reality. It is a conflict between two credible schools of practice.

The context school says agents are starved, not overfed. In a Stanford CS 153 lecture on the AI-native company, Y Combinator managing partner Diana Hu, previously co-founder and CTO of Escher Reality, describes wiring agents into the fabric of how a company decides things, the closed-loop argument behind running an AI-native company, and the requirement she states is categorical: "the agent needs to have read access to every single artifact that the company produces." A founder from Skyvern, the open-source browser-automation company, told a YC Root Access audience the same thing as an inventory of what he hands over: "Getting access to your email, getting access to Slack messages, giving it access to Notion where it has like your documentation, giving it access to customer call recordings." Both are describing why their agents are good, and they are right that an agent with a thin view of the company produces thin work.

The governance school says the scope should be one task and one minute.

My reading, and this is mine rather than anyone's in these sources, is that the two schools are arguing about different verbs. The context argument is almost entirely about reads across a corpus: documents, transcripts, tickets, code, history. The governance argument gets expensive on writes and privileged actions: moving money, changing permissions, emailing customers, touching production data. Collapsing those into one permission model is what produces both bad defaults, because you end up tuning a single dial that controls two unrelated risks.

The practical split is to be generous with reads inside a boundary you have drawn deliberately, and stingy with writes by default, with escalation as a named, logged, expiring event rather than a standing grant. The cost of a bad read is a leak, which is real and survivable with a boundary. The cost of a bad write is an action in the world, which is not. Treating those as one number is the actual mistake, and it is upstream of whichever school you lean toward.

What carries over from human identity, and what does not

The most useful part of the interview for anyone choosing an architecture is the part about what to reuse. Agent identity is not a greenfield discipline, and treating it as one is how companies end up with two directories that disagree.

Ting's position is that the platform has to be unified, and his evidence is what buyers tell him:

"Every CISO that we talk with says, 'We can't have a new silo of tools, identity tools to manage non-human identities'"

The reason is not tidiness, it is that the decisions are correlated. When he decides whether an agent should have access to something, he wants to see what that agent's creator or owner has access to, because that informs the decision. Split agents into their own stack and you lose exactly the context that would have told you the grant was wrong. This is the same mistake as standing up a separate observability stack for agents and then being unable to correlate an agent action with the deploy that caused it.

The primitives survive too. There are agents born with access, which Opal calls "birthright." There are agents that need to escalate for a specific task that requires more than they were given. There are agents whose access has to be revoked. Ting's summary: "a lot of those concepts are still they still apply. I think the way that we go about executing those workflows, I think will change."

What changes is execution, and the specific failure he keeps returning to is lifecycle. This one predates agents and is worth checking in your own company this week:

"when a user's account gets retired, a lot of people think that oh, that's the end of access. However, that user created a lot of other identities that continue to have standing permissions, like service accounts and API keys and things like that"

Offboarding deletes the human. The service accounts, keys and now agents that human created keep working, and in an environment where everything is findable, those orphans are the cheapest thing for an attacker to reach. Opal's own risk surface, by his description, includes exactly these shapes among others: agents with more permissions than their owners, and standing permissions that were never used.

Two terms Ting uses on the agent side are worth taking into your own vocabulary. The first is the manifest, the declared statement of what an agent was built to do, which is what lets a grant be checked against an intention rather than against a vibe. The second is the ownership tree, which is how the question of who is accountable resolves to a person even when the requester is software.

None of that works without the list. Ting's read on the market is that most products today solve the easier half: "most of the solutions in the market are really dealing with the inventory and discovery part of the equation." Inventory is necessary and it is not governance, which is the division of labor behind the piece on building an AI agent registry: the registry is the catalog, and access governance is what you enforce against it.

Start before you have agents in production

The question founders actually want answered is when this becomes their problem. Ting was asked precisely that, about a company early in adoption, with a couple of homegrown agents and no platform. His answer:

"I think from the very beginning. It's already too late."

Then, less gnomically: "If they're already building agents and using them in production, it's already too late." His reason is that identity is a foundation rather than a feature, and most organizations are already running on what he calls a best-vibes scenario, with risk accumulating in the background.

Ignore the sales timing in that and the structural claim is sound. Retrofitting identity means discovering grants you cannot explain, and the discovery is the expensive part. There is also a useful admission buried in how Opal onboards customers, which is that a lot of them do not know what their policy should be. So the product observes what is already happening, then recommends: "It doesn't require organizations to actually know what policy should be." That is a reasonable design and it is also a reasonable method without buying anything. You cannot write a sensible agent access policy from first principles at a desk. You can watch what your agents actually touch for two weeks and write down what you see, which is the same algorithm with a spreadsheet instead of a platform.

What to do this week

1. Count decisions, not agents. For your busiest agent, write down how many distinct privileged actions it takes in a day. That number, not your agent count, is the load your access model has to carry.
2. Split reads from writes. One list of what each agent may read, a separate and much shorter list of what it may write or spend. If both live in one credential today, that is the first thing to fix.
3. Kill the borrowed credentials. Find every agent running on a human's token or a shared service account and give it its own identity with its own scope. You cannot revoke, audit or reason about anything until this is true.
4. Run the offboarding test. Take the last person who left. List every service account, API key and agent they created that still has standing permissions. If that list is not empty, your offboarding is a UI change rather than a revocation.
5. Write the manifest and name the owner. Two lines per agent: what it exists to do, and which human is accountable for it. If you already keep an agent registry, these are two columns you have, and the point here is what you enforce against them. This is the artifact that makes every later access decision checkable instead of a judgment call.
6. Set an expiry on everything you grant this week. Default to a duration short enough that nobody can forget it. Standing access that nobody uses is the risk you will not notice until it is used.

The wider operating picture these controls sit inside is the pillar on AI for startups. The course is the structured version of this: AI Operating System for Startups covers how to decide what each agent may touch, who or what approves an escalation, and how to revoke access when an agent is retired.

Sources

• Howard Ting from Opal on the Million-to-One Access Decision Problem (Greylock), the interview this article distills.
• Building the Safety Layer for AI Agents (YC Root Access), for Raindrop's founders on permission creep and the rising cost of agent mistakes.
• Stanford CS153 Frontier Systems: The AI Native Company (Stanford Online), for the read-access-to-everything requirement that cuts against tight scoping.
• How to Give AI Agents Enough Context to Be Useful (YC Root Access), for the Skyvern founder's inventory of the systems he connects an agent to.
• Opal Security Raises $23 Million for AI-Native Identity Governance (SecurityWeek) and Opal's own announcement, for the June 2026 round and the Paladin decisioning engine.
• Announcing our Series A and $50M in total funding (Raindrop), for the September 2026 round led by CRV. Raindrop did not disclose the size of the round itself, only the $50 million total.
• Profiles: Howard Ting, CEO of Opal Security since late 2025 and previously CEO of Cyberhaven, whose appointment Business Wire announced in December 2025 (credited without a link because the wire service blocks automated readers), and Diana Hu, managing partner at Y Combinator and previously co-founder and CTO of Escher Reality.