What it means to give an AI agent an identity

An AI agent that does real work inside a company needs to log in to things. Email, the CRM, the data warehouse, a calendar API, a payment processor. The question of how it logs in, as whom, and what happens when it goes wrong turns out to be a much bigger problem than it first sounds. NewCore came out of stealth yesterday with $66M to solve it, which is a useful prompt to explain what the problem actually is.

I want to walk through this from the mechanism up, because most coverage of "AI agent identity" treats it as a vague governance worry. It is not vague. It is a specific gap in how authentication protocols were designed, and you can see the gap clearly once you know where to look.

What an identity is, in the technical sense

When a person logs into Salesforce, a chain of things happens. Their browser hits an identity provider — Okta, say, or Microsoft Entra. The identity provider checks their password, pushes a notification to their phone for multi-factor authentication, and then issues a short-lived token. That token is what Salesforce actually trusts. The token says: this is Jane, she works in sales, this proof is good for the next eight hours.

The protocols that run this dance are called OIDC (OpenID Connect) and SAML (Security Assertion Markup Language). They are very good at what they were designed for, which is letting humans prove they are who they say they are, using devices they physically possess, in sessions that map to a working day.

Every assumption in that sentence breaks when the thing logging in is an AI agent.

Where the protocols break

An agent has no browser, no phone, and no working day. It is a process — usually a loop that calls a language model, reads the response, decides what to do next, and calls some tool. It might run for three seconds and disappear. It might run for a week. It might spawn ten copies of itself to parallelise a task. None of these shapes fit into the human authentication flow.

The industry's first move was to treat agents as service accounts — the same primitive used for, say, a cron job that backs up a database at 3am. A service account has a long-lived API key or a client certificate, hard-coded into the script that runs the job. This works fine for a cron job because the cron job does exactly one thing, forever, and a human wrote it.

It works badly for an agent. An agent decides at runtime what to call. Its scope of action is not fixed. And because agents are cheap to spin up, you end up with hundreds or thousands of them — each holding a credential, often with broad permissions, often outliving the task they were created for.

What a "first-class agent identity" actually means

NewCore's pitch — and Microsoft Entra Workload Identities and Okta's machine identity track make adjacent arguments — is that an agent should get its own kind of identity, not a borrowed one. Concretely, that means a few things.

A credential bound to the agent, not the script that launched it. Modern systems use hardware-bound keys — a cryptographic key that lives in a secure chip or enclave and cannot be copied off the machine. When the agent signs a request, the signature proves the request came from that agent instance, not from someone who stole a config file. NewCore mentions split-key signing, where the signing key is mathematically split so no single component can sign alone; this is a hedge against any one part of the system being compromised.

A lifecycle tied to the task, not the calendar. A human identity is provisioned on hire and deprovisioned on departure. An agent identity should be provisioned when the orchestrator spawns the agent, scoped to exactly the tools the task needs, and revoked when the task completes — automatically, not by a human remembering to clean up.

A trust score that can move. This is the most interesting piece and the one that most resembles fraud detection rather than classical IAM. The system watches what the agent is doing: which APIs it calls, how often, with what arguments, against what baseline. If the pattern drifts, the agent that was summarising emails suddenly starts pulling customer records, the trust score drops, and downstream systems can demand re-authentication, narrow the scope, or cut the agent off entirely.

An audit trail per agent. Every call the agent made, every tool it touched, every sub-agent it spawned, attributable. Not to "the service account" — to this agent, born at this time, doing this task.

The shadow-agent problem

There is a concrete failure mode worth naming, because it is the thing security teams will encounter first and probably already are.

A developer builds an agent to triage support tickets. They use an OAuth flow to grant the agent access to the helpdesk and to their company's Slack. The agent runs, does the job, and the developer moves on to the next experiment. The OAuth token does not expire for ninety days. Nobody revokes it. The agent's code is still on a server somewhere, possibly still running, possibly long deleted, but the token is live. Anyone who finds that token, in a log file, a config dump, a compromised laptop, has helpdesk and Slack access for three months, attributable to nobody.

This is shadow IT, but the SaaS is an agent and the data is whatever the agent could reach. It is also exactly the problem an agent-aware identity layer is supposed to catch: an orphaned credential with no live owner and no expected behaviour should fail closed, not stay open.

Why this matters now

The pitch deck number is that machine and agent identities will outnumber human ones by 100x. Take that as a marketing figure, not a measurement — most enterprises today are nowhere near it. But the direction is right. Every team experimenting with agents is adding non-human principals to systems that were not designed to count them, let alone govern them.

The market is now arguing about where that governance sits. Incumbents (Microsoft, Okta, Ping) say it is a feature of the existing identity platform. New entrants (NewCore is the well-funded recent one, but it is not alone) say agents are different enough from humans and from service accounts that they need their own plane. Both sides will be partly right, and the resolution will look like it usually does: incumbents will absorb most of the table-stakes capability, and a few specialists will survive by going deep on the parts the incumbents do badly.

What I would watch is whether the audit trail and the trust score become real. Credentialling agents is the easy part — hardware keys and short-lived tokens are well-understood. Knowing what an agent did, attributing it to that specific agent, and catching the moment one starts behaving wrongly — that is where the actual engineering is, and where you will be able to tell which products are serious.

Footnotes and further reading

Further reading

• OpenID Connect core spec: https://openid.net/specs/openid-connect-core-1_0.html
• Microsoft Entra Workload Identities overview: https://learn.microsoft.com/entra/workload-id/
• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/publications/detail/sp/800-207/final

¶