Many teams deploying AI agents have made a security tradeoff they didn't consciously choose. They gave the agent a service account, maybe a shared API key; something with enough access to do its job, stored in a config file or an environment variable. It works. The agent calls the right APIs, the demos run clean, and the project ships.
What they've actually done is recreate the service account problem, except now the principal operates autonomously, at speed, and its "judgment" can be influenced by whatever text it reads in a prompt.
I want to make a specific argument: governing AI agent access isn't a new problem that requires new tools. The privileged access management (PAM) tools you already have—just-in-time (JIT) access, session recording, least-privilege enforcement, and audit trails—all become more important, not less. Instead, what needs to evolve is the identity model, and that evolution has implications for which PAM architectures are actually up to the job.
The problem with treating an agent like a service account
A service account is a static identity. It has credentials and permissions, and when something goes wrong, the audit log tells you which account did what. The remediation is clear: Rotate the credential, scope down the permissions, and move on.
An AI agent is a different kind of principal. There are a few reasons it doesn't fit the service account model cleanly:
It operates on behalf of a human
When your security operations center (SOC) analyst asks an agent to investigate a production server, the agent isn't acting on its own judgment; it's executing a directive from a specific person. That person's identity should be in the access record. A service account doesn't carry that context. "The agent accessed the server" is a weaker statement than "Jason's agent accessed the server, following a session Jason initiated at 6:51 p.m. after completing MFA."
Its instructions can be manipulated
A service account does what its code tells it to do. An AI agent processes natural language, which means that a sufficiently crafted prompt can make almost anything sound like a reasonable next step. The security boundary that protects a service account—the code itself—doesn't apply the same way. The solution is to add enforcement layers around the agent that don't evaluate intent and aren’t negated by a manipulated input.
Static credentials are a single point of failure at scale
As agents proliferate, the blast radius of a shared credential grows with every agent that uses it. One compromised config file doesn't just expose one service; it exposes every system the credential touches, across every agent that uses it.
The answer isn't a clever agent framework or a new kind of API key. It's the same answer PAM gave for human privileged access: Don't issue standing credentials at all. Issue access just-in-time, scope it to the session, record what happened, and leave nothing to steal when the session ends.
Governing AI agents in practice: A SOC workflow use case
Earlier this year, I built a working demo of an AI-assisted SOC workflow that allowed a security analyst using a chat interface to direct an agent to investigate a production server running on our lab infrastructure. The agent had no standing credentials for the production environment.
We recorded the session end-to-end. When the analyst initiated the session, here's the sequence of events that unfolded:
- The analyst authenticated via Okta with MFA—a real identity assertion, not a service token.
- The agent performed an OAuth 2.0 token exchange (RFC 8693), which is the delegation step that produces a token carrying both the human's identity (sub = firstname.lastname@com.com) and the agent's identity (cid = ag_ir_forensic_7f3a2). Both present, neither omitted. The human had to be there for this token to exist.
- Okta Privileged Access (OPA) validated the token against the configured workload connector and policy to confirm the agent was authorized to access this class of server under these conditions.
- OPA issued a short-lived SSH certificate via the PAM client, which received an encrypted payload, brokered the connection through the OPA Gateway, and handled the decryption there. The agent never held a readable credential.
- The agent connected via the Okta Privileged Access Gateway, which is the only network path into the production environment. The production hosts weren’t directly reachable from the agent's compute; the gateway was the only bridge in, and only for policy-compliant sessions.
Total elapsed time from the analyst's browser to a secured shell on a production server: 37 seconds.
The agent found a reverse shell on the first command, ran nc as root, and called back to an external IP. That's the use case: Fast, governed, and fully audited.
How JIT access eliminates standing privileges for AI agents
A few details in that flow are worth unpacking. First, JIT access here operates at two levels:
- OPA issued an ephemeral SSH certificate scoped to this session.
- OPA also provisioned a local OS account on the production host for this session, which was removed upon session end. There was no persistent account sitting on the host waiting to be compromised.
Enforcing least privilege with runtime sudo policies
The runtime sudo enforcement deserves its own note as the control that addresses what most people are actually afraid of with agents in production: Stories circulating about agents going rogue, deleting databases, and overwriting files. Those scenarios require write access. Our forensic agent needed production access but operated in read-only mode, and OPA's centrally managed sudo policy enforced that at the OS level—not through a system prompt, not through application logic, and not the agent's own judgment about what's appropriate.
But the policy didn’t just block destructive behavior. It enforced the specific boundary of what this agent should have been doing, which matters even for read operations. In testing, the LLM’s own reasoning reliably caught requests for the agent to read /etc/shadow; it was obvious enough that the soft boundary held.
However, asking the agent to analyze a process memory map was different. Because that request was forensically plausible and not destructive, after a few attempts, the agent’s reasoning layer agreed to attempt it. OPA's sudo policy blocked it anyway. The point isn't that the LLM failed; it's that the policy doesn't depend on the LLM getting it right. The person who built the sudo bundle thought carefully about what a SOC analyst should and shouldn't access. That judgment is enforced at runtime regardless of what the agent decides is reasonable.
Threading human identity through the PAM audit log
The audit trail also matters here. The Okta System Log contains seven events for that session, from the analyst's SSO login through the SSH login to the production server. Every event is linked. The human user ID is present throughout the entire chain.
The WorkloadPrincipal in the PAM events isn't just "an agent," it’s opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com (the team that owns this agent, the policy context it ran under, and the human who authorized it). All three in one PAM log field. The human's email is in the PAM record because it was in the token and came from the same identity system that authenticated the analyst in the first place.
That's the accountability story. Not "an agent accessed the server," but instead: "Firstnames's agent accessed the server, here's the cert it used, here's the session recording, here's every token in the chain that authorized it."
Why the IdP foundation is not optional
Here's where I want to make a more pointed argument for security architects evaluating PAM vendors.
Many enterprise PAM vendors support JSON Web Token (JWT) authentication. Many support JWT/OIDC authentication and let you map claims to policies. This works, but "accepting the JWT" and "natively understanding the identity" are not the same thing.
When the identity provider (IdP) and PAM are the same platform, a few things are structurally different:
- The agent's registration lives in the IdP: OPA's workload connector binds to the agent's
cid—not a string in a policy config file, but a live reference to a registered principal. Deprovisioning the agent in Okta revokes access. - The audit trail is a single stream: The analyst's SSO event, token grant, PAM credential issuance, SSH login—they're all in the Okta System Log, queryable together. With a separate PAM vendor, you're joining two audit systems to reconstruct what happened.
- The human identity in the PAM record isn't a mapped claim that survived a handoff: It's the same identity that was authenticated at the start of the chain, never leaving the platform's trust boundary.
For human-privileged access, the IdP-PAM integration was convenient, as it enabled SSO in your PAM console and possibly SCIM provisioning. For AI agent access, however, it's an architectural issue. The accountability story depends on the human identity traveling intact from authentication through delegation to access, and every trust boundary it crosses is an opportunity for it to be lost, mapped incorrectly, or simply not logged.
That architectural concern doesn't only apply to privileged infrastructure access.
The SOC workflow described above isn't a one-off integration, as it's one expression of a broader architecture. Okta for AI Agents answers three questions every security team deploying agents faces: Where are my agents? What can they connect to? What can they do?
Okta Privileged Access is how we answer the third question for the highest-stakes targets: production infrastructure, sensitive systems, and anywhere a compromised or manipulated agent could do real damage. The same principles that govern the (human, agent) pair in the OPA flow—which are user context-bound to every action, least-privilege scopes, ephemeral credentials, and an immutable audit trail—extend across MCP servers, SaaS APIs, agent-to-agent calls, and credentialed service connections. Agentic access to a production server is just the case where getting it wrong is most expensive, which is why the IdP-PAM foundation is important before the agent count gets ahead of you.
The takeaway
AI agents are the new privileged principals in enterprise infrastructure. The threat model is familiar: standing credentials, over-privileged accounts, no audit trail. The difference with agents is that these problems occur more quickly and are harder to detect.
The primitives that PAM is built around—such as JIT access, session recording, credential vaulting, policy enforcement, and privilege elevation controls—don't become less relevant when the principal is an AI. They become the thing that makes agentic access safe to deploy in the first place.
What has to evolve is the identity model. The principal is now a (human, agent) pair. Both identities need to be in the record. Reconstructing accountability after the fact, like "whose agent was this, and who authorized it?" requires that the platform understand that pair from the start, not reassemble it from logs across two systems.
If your current PAM architecture treats agent access as a service account problem, it's worth asking whether it was designed for a world where the principal has two identities, operates autonomously, and needs a governing system that doesn't take its word for what it's been asked to do.
These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. © Okta, Inc. and/or its affiliates.
