The most dangerous kind of wrong is 70% right. It activates your confidence without triggering your skepticism.
When a CAIO asks how you govern AI agents, your service account mental model activates immediately. Credential vaulting. Scoped access. Rotation schedules. Privileged access management. The vocabulary fits well enough that you keep talking, and you keep talking until you hit the specific place where the model breaks — usually in the middle of a sentence, in front of someone who already knew it was going to break.
This piece is about finding that break point before Tuesday's call.
Your IDAM intuition is genuinely useful here. The zero trust principles you've been selling and implementing for the past several years map onto agent identity with real fidelity. The service account intuition is more complicated: right vocabulary, structurally insufficient scale model. And the governance workflow assumptions that underpin most enterprise IDAM programs are built on a dependency that agentic systems simply don't satisfy. Each of these zones requires a different posture, and conflating them is where sellers lose credibility with buyers who've already thought this through.
Where the Zero Trust Instinct Holds
Your instincts here are an asset, and it's worth being explicit about why before moving on.
Assume breach. Never trust, always verify. Enforce least privilege continuously. These principles didn't emerge from thinking about human users specifically — they emerged from thinking about what happens when perimeter assumptions fail. Agents are, arguably, the purest test case for zero trust architecture: they're non-human, they operate at machine speed, they traverse multiple systems in a single task, and they're exactly the kind of lateral movement vector that a compromised environment would exploit.
The zero trust requirement that every access request be evaluated against policy regardless of network location? That applies to an agent calling an API from a cloud function just as cleanly as it applies to a contractor logging in from a hotel. The requirement for continuous verification rather than session-based trust? An agent that authenticates once and then operates for hours with accumulated privileges is a liability — the same liability you've been arguing against in human access patterns. Least privilege? An agent that can read, write, and delete across a document repository when its task only requires reading is a misconfigured agent, and the blast radius of a compromised or misbehaving agent scales with its entitlements exactly as it does for a human account.
The zero trust mental model holds here because it was never really about humans. It was about principals and trust relationships. Agents are principals. The principles apply.
Where your zero trust instinct might need a small adjustment: the verification cadence. Human session management operates on timescales measured in hours. Agent tasks can complete in seconds. The policy enforcement point needs to operate at the same timescale as the agent, which has infrastructure implications your buyer may not have thought through yet. But the principle is sound. The implementation is what's being worked out.
Where the Service Account Intuition Misleads
This is where the 70% problem lives.
The vocabulary maps cleanly enough. Credential vaulting, rotation, scoped access, privileged access management — these are the correct categories for agent identity. If a buyer asks whether agents need PAM controls and you say yes, you're correct. The problem is that "yes" implies a scale model that doesn't survive contact with how agents actually behave.
The rotation schedule is the first place this breaks. A service account credential gets rotated quarterly, or monthly if you're disciplined, or on a schedule tied to your PAM policy. That schedule is calibrated to the lifetime of the credential's exposure window. An agent that exists for eleven seconds to complete a document processing task and then terminates has a different exposure window. The rotation schedule is longer than the agent's lifetime by several orders of magnitude. Vaulting a credential for an entity that will be born and die before the vault's next check-in cycle is the right idea applied to the wrong timescale.
The HR record problem is more fundamental. Every PAM workflow I've seen in production — and I spent three years implementing them before I started writing about them — has an authoritative source for "does this principal still exist?" That source is an HR system. Workday, SAP, whatever the agency runs. The lifecycle trigger that fires when an employee leaves fires because there's a record in that system that changes state. Agents don't have HR records. There's no Workday entry for an agent that was spun up by an agentic workflow at 2am to process a batch of procurement documents. The offboarding trigger has no analog. The lifecycle governance that keeps human accounts from persisting after their owners leave the organization simply doesn't fire for agents, because the firing condition doesn't exist.
Then there's velocity. A human user authenticates once per session, maybe twice if they're on multiple devices. An agentic workflow processing a large document corpus might spawn four hundred agents in an hour. Manual governance — approve this request, review that access, certify this entitlement — operates on human timescales. It cannot track agent spawning velocity. The math doesn't work. This isn't a process improvement problem; it's a structural mismatch between the governance model and the thing being governed.
Finally, behavioral analytics. UEBA and anomaly detection work because human behavior is patterned. You log in from the same IP range, at the same hours, and access the same systems. Deviations from that baseline are signal. An agent's access pattern is determined by the task it's given, which changes every invocation. There's no stable behavioral baseline to anomalize against. An agent that reads ten files on Monday and ten thousand files on Wednesday isn't behaving anomalously — it's processing a different workload. The risk signal that behavioral analytics would generate is noise, not intelligence.
The service account intuition correctly identifies that agents need credential management, scoped access, and privileged access controls. The timescale, the lifecycle trigger, the governance velocity, the behavioral baseline — each of those assumptions needs replacing. That's a lot of wrong packed into a correct category.
Where the Governance Workflow Assumptions Collapse
In this zone, the break is structural. Calibration won't fix it.
Most enterprise governance workflows are built on an assumption so foundational that it's never stated explicitly: there is a human on the other end of every access decision. The access review sends an email. The lifecycle trigger fires because an HR record changed. The risk score incorporates login time, geolocation, and device posture. All of these controls assume a human principal, and when that assumption is false, the controls don't degrade gracefully. They disappear.
The access review email makes this concrete. Quarterly access certifications work by asking resource owners: does this account still need access to this system? The resource owner for an agent is unclear. The developer who wrote the workflow? The system owner? The ISSO? The agent itself doesn't have an inbox. The email goes somewhere, but the governance loop is broken at the response end. You can send the email. You cannot get a meaningful answer through the same mechanism that works for human accounts.
Geolocation-based risk scoring produces a similar failure. An agent doesn't log in from a location in any real sense. It authenticates from wherever the compute is running — a cloud function, a container in a government cloud environment, a serverless execution context. The geolocation of the authentication event is the geolocation of the infrastructure, which is irrelevant to the risk question you're trying to answer. A risk score that incorporates geolocation for agent authentication is incorporating noise. Worse, it might suppress the signal you actually need, because the "normal" geolocation for an agent is wherever the cloud provider put the execution environment this time.
Federal agencies are encountering this now, not theoretically. The OMB AI governance requirements that have been accumulating since 2024 require agencies to maintain inventories of AI systems and demonstrate oversight of AI-driven decisions. CAIOs are being asked by oversight bodies to show that they know what their AI systems are doing. The governance workflows they have — built for human users, calibrated for human timescales, dependent on HR system integration — don't answer those questions. The gap between what oversight bodies are asking and what existing governance infrastructure can show is exactly where this conversation is happening.
The Three Questions That Actually Help
Before any product conversation, there are three questions that give a buyer genuine value and give you genuine signal about where they are.
Where are my agents? An inventory question, and it's more fraught than it sounds. In a large organization deploying agentic AI across multiple teams and workflows, the answer is often "we don't fully know." Agents get spun up by developers, by workflow automation, by third-party tools that themselves use agents. Without a centralized registration mechanism, the answer to "where are my agents?" is a spreadsheet that's already out of date. You can't govern what you can't see, and most organizations can't see all of their agents.
What can they access? An entitlement question. Even if you know an agent exists, do you know what it can reach? Which APIs, which data stores, which downstream systems? The least-privilege principle requires knowing the privilege. If the answer to this question is "whatever the service account it's using can access," you've inherited the service account's entitlements without the service account's governance history.
What are they doing? A behavioral monitoring question, and it's where the audit trail becomes operationally important rather than just compliance theater. If an agent behaves unexpectedly — accesses something it shouldn't, makes calls at a volume that suggests compromise or misconfiguration — you need to know, and you need to be able to act. The audit trail that makes revocation meaningful is the same audit trail that makes incident response possible.
These questions aren't a product pitch. They're a diagnostic. A buyer who can answer all three confidently has done serious work. A buyer who can answer one and is vague on the others has told you exactly where the conversation should go.
What's Shipped, What's Not
Okta has built specific capabilities that address these questions, and it's worth being precise about what they are rather than gesturing at "agent identity management" as a category.
On inventory: centralized directory registration for agents and MCP servers, with human owner assignment as the accountability anchor. Every agent in the directory has a human owner — a named person who is responsible for that agent's behavior and access. This is the governance hook that makes the access review email work again, because now there's a human whose name is on the agent and who can be asked whether it still needs what it has.
On entitlements: least-privilege policy enforcement and short-lived credentials. The short-lived credential addresses the rotation schedule problem directly. If the credential's lifetime is measured in minutes rather than months, the exposure window is bounded by design rather than by policy compliance. The agent gets what it needs for the duration of the task, and the credential expires.
On behavioral monitoring: automated governance workflows and kill-switch revocation with a full audit trail. The automated governance workflow addresses the velocity problem — governance that operates at machine speed, so that the spawning of four hundred agents in an hour doesn't require four hundred manual approvals. The kill-switch revocation with audit trail is what makes "what are they doing?" answerable after the fact, and what makes incident response possible when the answer is wrong.
The XAA mechanism that enables cross-system agent authentication, and the OpenID agentic standards landscape that's establishing the protocol foundations for all of this, are covered elsewhere in this issue. The identity infrastructure described here sits on top of those mechanisms.
What's not shipped — by Okta or anyone else — is governance enforcement at thousands of ephemeral agents simultaneously. The inventory, entitlement, and behavioral monitoring capabilities exist. Automated enforcement of governance policy across an agent population that's spinning up and terminating at high velocity, in real time, without human intervention at each decision point: that's the problem the whole industry is working on. It's not solved. A seller who claims it is will be tested by a CAIO who's already asked their current vendors the same question and gotten inconsistent answers.
Knowing that a problem is unsolved is itself a form of fluency. Buyers who've been around long enough to remember the early days of cloud IAM, or the first wave of mobile device management, know that the governance tooling always lags the deployment velocity. They're not expecting a complete solution. They're expecting a vendor who knows where the gaps are and has a credible direction. That's a different conversation than the one where you oversell the current state and get caught.
The buyer who asks "how do you govern agents at scale?" is asking three questions at once: do you know what you have, do you know what it can reach, and do you know what it's doing? The answer to all three, right now, is "better than you could a year ago, and not as well as you'll need in two years." That's honest. It's also, for a buyer navigating the same uncertainty, exactly what trust sounds like.