Why Every AI Agent In Your Company Needs An Identity

At 2:14 on a Tuesday morning, an internal agent at a mid-sized logistics firm opened a support ticket, pulled a customer export, and pushed a config change to staging. Every one of those actions was permitted. Nobody could say who permitted them. The token it used belonged to a service account created in 2023 by an engineer who left the company in 2024, and the audit log recorded the actor as "automation-prod-07".

That is not a security failure in the way most boards understand the phrase. Nothing was breached. The system worked exactly as configured. It is an accountability failure, and it is now sitting inside a standards process at NIST rather than inside a vendor pitch deck.

AI agents are getting production access faster than anyone is issuing them identities. NIST opened a formal track on agent identity and authorization in February 2026. Enterprises that cannot name the human behind an agent action will fail their next audit, not their next penetration test.

Why this matters now

The industry already solved machine identity once. Workloads got certificates and CI runners got short-lived tokens, and everyone quietly agreed that a long-lived API key sitting in a repository was embarrassing. That model holds because a workload does one thing forever. An agent does not. It decides. It picks which tool to call and when to escalate. The thing it decides to do at 2am was not in the ticket that authorized it.

So the common advice, which is to give each agent a service account and move on, is wrong. Not slightly wrong. A service account answers "what is running." Agent identity has to answer four questions instead, and NIST wrote them down almost that plainly: what exactly is the agent, who delegated authority to it, what is it allowed to do, and how are its actions logged and constrained. The governance frameworks that decide which enterprises win with agents all assume those four answers exist. Almost nobody has them.

In February 2026 NIST's Center for AI Standards and Innovation announced the AI Agent Standards Initiative, with agent security and identity as one of three named workstreams. Alongside it the National Cybersecurity Center of Excellence published a draft concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," and closed public comment on 2 April 2026. It does not invent a protocol. It stretches the ones already in the building: OAuth 2.1, OpenID Connect, SPIFFE and SPIRE for workload attestation, SCIM for lifecycle, NGAC for attribute-based access, and the Model Context Protocol for tool access. And it is blunt about the part vendors skip, asking how to bind agent identity to human identity for on-behalf-of scenarios, and demanding that agents log their actions and intent in a tamper-proof and verifiable manner. Meanwhile the credential surface underneath all of this keeps expanding, and the certificate rules governing it keep tightening on a schedule that has nothing to do with AI and no interest in waiting for it, which is the same structural pressure driving the post-quantum migration deadlines already running against your encrypted traffic.

Certificate lifetime

200 days

Ceiling since 15 March 2026

Shadow AI breach premium

USD 670,000

Added to average breach cost

Secrets leaked publicly

28.65 million

New on public GitHub in 2025

Machine to human ratio

109 to 1

Identities per employee today

The certificate number is the one that should worry an operations lead, because it is the only figure on that grid that is a hard deadline rather than a trend. The ceiling drops again in March 2027 and lands under seven weeks in March 2029, and at that point the window for reusing domain validation data shrinks to ten days. Manual renewal stops being slow and starts being impossible. Any agent that terminates or initiates TLS on your behalf inherits that clock, and if you cannot enumerate which agents hold which credentials, you cannot rotate them on the schedule the rules now require.

"

You are running more than a hundred non-human actors for every person on payroll, and almost none of them can tell you which human signed off on what they did last night.

What identity for an agent actually means

Strip away the protocol names and agent identity decomposes into six practical obligations. None of them is exotic. All of them are things your existing IAM stack does for humans and mostly fails to do for software that makes choices. The table below is the working checklist, and it is deliberately written as what you have to be able to prove, not what you have to buy.

Category	Detail	Insight
Identification	Model, version, tool set, owning team	A name is not an identity
Authentication	Attested workload credentials, not static keys	Short lived beats secret and shared
Delegation	On-behalf-of chain back to a person	Authority must have a human origin
Authorization	Scope bound to task, not role	Least privilege per job, per run
Audit	Tamper-evident record of action and intent	Non-repudiation is the actual deliverable
Lifecycle	Provisioning, rotation, revocation on exit	Kill it faster than you built it

Read down the Insight column and the pattern is uncomfortable. Five of the six obligations are things you can implement today with protocols that shipped years ago. Only the audit row really needs new work, because logging an agent's intent, meaning why it chose the action, is not something any existing standard captures well. That is where the standards effort will actually spend its time, and it is also the row your regulator will ask about first.

The NIST agent identity track moved from announcement to closed comment periods in seven weeks during early 2026, and the next milestone is a draft project description rather than a finished standard.

Where this breaks in practice

The first breakage is organisational, not technical. Identity lives with the security team, agents live with the platform or data team, and the person who actually authorized the agent to touch a customer record is a product manager who has never seen an IAM console. Palo Alto Networks' 2026 identity security survey of more than 2,900 security decision-makers found that disconnected identity systems add roughly 12 hours to the average identity-related incident. That gap is not spent fixing anything. It is spent asking who owns this thing.

The second breakage is that agents multiply credentials as a side effect of being useful. Every tool an agent connects to wants a key. Every connector config file becomes a place a key can sit. This is the same failure pattern that made verified caller identity such a fight in telecom, where operators had to be pushed into displaying the KYC name behind a number before anyone could trust who was calling. The lesson transferred badly. We are once again shipping systems that act on our behalf without a verified name attached.

And here is the part I am not sure about, which is worth saying out loud rather than hiding behind a framework. Should an agent hold a first-class identity of its own, or should it only ever borrow a human's? Giving it its own identity makes revocation clean and audit trails honest, but it also creates a permanent non-human principal that outlives the reason it existed. Borrowing keeps accountability tight and makes the agent disappear when the human leaves, but it collapses the moment an agent runs unattended for a week. I lean toward first-class identity with a mandatory delegation link, but I would not call that settled, and anyone selling you certainty on this in 2026 is selling.

Watch-outs before you buy anything:

• Any vendor claiming NIST compliance for agent identity is claiming compliance with a concept paper. There is no standard to comply with yet.
• Inventory before policy. If you cannot list every agent and the credentials it holds, a policy engine just enforces rules against the half you know about.
• Logging the action without logging the delegation is worthless. "Agent X deleted the record" is not an audit trail. "Agent X, acting for Priya, deleted the record under ticket 4471" is.
• Treat agent credentials as in-scope for your certificate automation programme now, not after the next validity cut lands.

Key takeaways

01. Access control, not model quality, is where agent deployments fail. IBM's 2025 breach research found 97% of breached organisations that suffered an AI-related security incident said they lacked proper AI access controls.

02. The credential surface is growing faster than the agents are. Leaked AI-service secrets on public repositories rose 81% year over year in GitGuardian's 2026 count, outpacing the overall secrets growth rate.

03. Start with the delegation link. It is the only obligation on the checklist that no tool can retrofit for you, because the record of who authorized what has to be captured at the moment it happens.

Pick your three highest-privilege agents this week, and for each one write down the human who authorized it, the exact scope it holds, and where its actions are logged. If you cannot complete that sentence for all three, you do not have an agent identity problem to plan for later. You have one now, and it is already in production.

Harvest Now Decrypt Later: Your Encrypted Data Is Already Stolen

A batch of your company's traffic left the building this morning. It was encrypted, so nobody logged it as an incident. And somewhere it may now be sitting on a disk in a facility you will never see, waiting. Not for a stolen password. For a machine that does not exist yet.

Attackers are storing encrypted traffic today to decrypt once quantum hardware matures. NIST has already set the clock: RSA and elliptic curve go deprecated after 2030 and disallowed after 2035. Data with a long confidentiality life is exposed now, not later. Start the inventory this quarter.

Why It Matters

The attack has a name that sounds almost polite. Harvest now, decrypt later. An adversary, usually state-sponsored, quietly copies encrypted traffic and archives it. No malware, no ransom note, no alert. They are not trying to read it this year. They are betting that a cryptographically relevant quantum computer arrives before the value of that data expires, and for a lot of records that bet is a comfortable one.

Here is where most security budgets get it wrong. Teams treat post-quantum work as a 2030 problem because that is the first date on the NIST calendar, and 2030 feels like somebody else's fiscal year. But the exposure window opened the day the traffic was captured, not the day it gets decrypted. If you handle records that must stay confidential for fifteen years, your deadline already passed. I would go further: for anything covered by long-retention regulation, the decision to defer migration is a decision to accept an eventual breach, just one you will not have to explain until after you have left the job. That is a governance failure dressed up as a scheduling call, and it belongs on the same risk register as the accountability gaps in enterprise AI agent deployments that boards spent the first half of this year arguing about.

The hardware side is no longer speculative either. Banks and pharmaceutical firms are already buying processing time on commercial systems, a shift covered in more detail in this breakdown of what quantum computing actually means for business leaders. Nobody serious claims a machine can break RSA-2048 today. The point is that the archive does not care about today.

Money makes the scale legible in a way that threat modelling never does. Look at what one government alone expects to spend just to swap its own algorithms.

Final Deadline

2035

Legacy algorithms fully disallowed

Federal Migration Cost

$7.1 billion

Civilian agencies only, excludes defence

Practitioners Surveyed

4,000+

IT and security roles worldwide

Actively Preparing

38%

Down from the prior year

The cost estimate comes from the congressionally mandated OMB and ONCD report to Congress, covering United States federal civilian systems in 2024 dollars (as of 2024). It deliberately leaves out national security systems and the entire commercial sector. Read it as a floor, not a ceiling. What it really measures is not licence fees but archaeology: the labour of finding every place a cryptographic primitive was hardcoded by someone who left in 2014. The preparation rate, drawn from the 2026 Entrust and Ponemon Institute global study, moved the wrong way against the prior year, which tells you budget pressure is beating deadline pressure right now.

“

One government put $7.1 billion against swapping its own algorithms, and that estimate covers civilian systems alone. Whatever your number is, you have not budgeted it yet.

The standards themselves are settled, so the usual excuse about waiting for the technology to mature no longer holds. Here is the state of play.

Category	Detail	Insight
The standards	FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Finalised in 2024, ready to deploy
Deprecation date	RSA, ECDH, ECDSA, DSA and FFDH deprecated after 2030	Continued use needs documented risk justification
Certificate visibility	43% report full insight into their own certificates	Most teams cannot see what breaks
Operational pain	68% call managing cryptographic assets extremely difficult	A tooling gap, not awareness gap
Highest-risk data	Regulated records, intellectual property, health data, identity records	Confidentiality outlives the encryption protecting it
The attack	Collection is passive and leaves no trace on your network	No breach alarm ever fires

Read that table as a sequencing document. Rows three and four are the real project; rows one and two are the easy part everyone talks about instead. So why is the work stalling? The reasons people actually give are boring, and boring reasons are the ones that win.

Budget was cited by 39% of respondents and missing expertise by 38%, both up sharply on the prior year in the same Entrust and Ponemon study.

Friction Points

The migration itself is not the hard part. Swapping a TLS library is a Tuesday. Finding every system that quietly depends on a certificate nobody documented is a two-year archaeological dig, and that discovery work is what the money is really paying for. Every embedded device, every code-signing key, every hardware security module, every vendor integration where the crypto lives on their side of the contract and not yours.

There is one question nobody in this field can answer honestly, and it deserves saying plainly rather than hiding behind a confidence interval. Nobody knows when a cryptographically relevant quantum computer arrives. Estimates run from the early 2030s to never. That uncertainty is not a reason to wait, it is the reason the deadline exists at all: regulators picked 2035 precisely because the honest answer is a shrug, and a shrug is not something you can build a control around. Reasonable, well-informed people disagree about this, and they will keep disagreeing right up until somebody publishes a result.

Practical watch-outs before you scope the work:

• Vendor claims of being quantum-ready usually mean the product supports a hybrid mode, not that your deployment uses it. Ask which algorithm is negotiated in production.
• Certificate lifetimes are shrinking independently of quantum concerns. If your renewal process is manual, that breaks first, and it breaks loudly.
• Long-lived signing keys, especially firmware and code-signing, are worse than transport encryption. You cannot re-sign a device already in a customer's hands.
• Regulatory sequencing bites. Mandated technical standards land on their own timetable regardless of your roadmap, a pattern already visible in fights over mandating universal OBD access across car brands.
• Data you already sent is not covered by anything you do next. Migration protects future traffic only.

Key Takeaways

• Inventory before you migrate. You cannot replace an algorithm you have not located, and the discovery phase dominates the timeline.
• Rank by confidentiality lifetime, not by system importance. A dull archive of health records outranks a busy internal dashboard.
• Build crypto-agility, not a one-time swap. Whatever replaces today's choice will itself need replacing, and the second migration should cost a fraction of the first.
• Put the risk acceptance in writing now. After the deprecation date, that documentation stops being optional, and drafting it late is how audits go badly.

Pull your certificate inventory this quarter and sort it by how long each dataset has to stay secret, not by how busy the system is. That single sorted list is the whole project plan, and the teams that have one are already ahead of the clear majority who have not started.

Why AI Agent Governance Decides Which Enterprises Win In 2026

Most companies buying autonomous AI agents right now have no clean way to switch one off. They are wiring software that acts on its own into billing systems, customer inboxes, and supply chains, then discovering after the fact that nobody owns the controls. The technology arrived years before the rulebook, and that gap is where the money leaks. AI agent governance is the unglamorous discipline that decides which of these deployments prints returns and which quietly gets pulled.

Enterprises are rushing autonomous AI agents into production while skipping the controls that keep them safe and accountable. The winners this year are not the fastest adopters. They are the ones who paired agents with real oversight, kill switches, and audit trails before scaling anything.

Why It Matters

An AI agent is not a chatbot that answers a question and stops. It takes a goal, breaks it into steps, calls tools and other software, and keeps acting until it decides the job is finished. That autonomy is the whole point, and also the whole problem. A chatbot that hallucinates wastes a few minutes; an agent that hallucinates can send the wrong invoice, cancel the wrong order, or push data to the wrong recipient before a human looks up. That is why AI agent governance has moved from a compliance footnote to a board-level question.

The adoption curve is close to vertical. Gartner projects that by the end of 2026 a large share of enterprise applications will ship with task-specific agents built in, a steep jump from the year before. Low-code builders now let a team stand up a working agent over a lunch break, so the constraint is no longer engineering talent. The real constraint is whether anyone can see what these agents do once they are live, and whether the payoff justifies the exposure.

Low-code build time

15–60 min

Per agent, low-code tools

US production ROI

192%

Median, scaled deployments

Enterprise apps by 2026

40%

Embedding task-specific agents

In production today

1 in 9

Enterprises actually running agents

The build-time figure is the quiet trap. When spinning up an agent takes minutes, teams create dozens of them informally, and the organization loses count of how many are running against production data. That is exactly the condition that turns a helpful tool into an unmonitored liability, and it happens without a single approval meeting. The gap between the number of agents deployed and the number anyone is actually watching is where most of the risk quietly accumulates.

None of this means agents fail to pay off. Disciplined programs post real returns, and the business case for automating repetitive, rules-heavy work is genuine. The difference between a program that scales and one that stalls comes down to a handful of measurable gaps rather than the quality of the underlying model. The current numbers on those gaps are not comforting, and they explain why so many pilots never graduate into trusted production systems.

Category	Detail (2026)	Why It Matters
Adoption intent	74% plan agentic AI within two years (Deloitte)	Demand is racing ahead of control
Governance maturity	Only 21% have a mature agent-governance model	Most run agents without real guardrails
Kill-switch readiness	35% could not stop a rogue agent	No off-switch when things go wrong
Trust maturity	~30% reach advanced governance maturity (McKinsey)	Few have audited, controlled pipelines
2025 baseline	Under 5% of enterprise apps embedded agents in 2025	Shows how steep this curve is

Read those rows together and a pattern appears: intent is nearly universal, control is rare. Closing that distance, not buying more agents, is the actual work of AI agent governance.

A workable sequence for teams starting now: catalog every agent, wrap each one in hard limits and a kill switch, then log and monitor it without gaps. That order is the pattern behind the roughly 171% median return that production-scale programs report globally.

Friction Points

Standing up controls is harder than buying the agents, and the obstacles are practical rather than philosophical. Each one is survivable on its own; the danger is letting several pile up unnoticed until an incident forces the issue.

• Shadow agents: teams deploy agents without telling IT, so no inventory ever reflects what is actually running.
• No clean stop: many systems cannot halt an agent mid-task without taking the whole workflow down with it.
• Ownership vacuum: when an agent errs, security, legal, and the business each assume another team is accountable.
• Audit blindness: agents chain many tool calls, and without logging, reconstructing what happened later is guesswork.

These are fixable, but only if controls are treated as a launch requirement instead of a cleanup project. Bolting oversight onto an agent that already touches customer data is slower, costlier, and far harder to push through politically once something has gone wrong.

Before approving the next agent, ask one question: if this thing goes wrong at 2 a.m., who stops it and how? If nobody in the room can answer, you do not have a deployment plan, you have an incident waiting for a date. Build the controls first, then scale.