AI agents are already running in your environment — Ping just gave IAM teams the controls to govern them the same way they govern people.

Ping Identity announced new AI-first identity capabilities this week, expanding its platform beyond human identities to cover the AI agents proliferating across enterprise environments. The additions target two of the most urgent gaps in modern IAM: who owns your AI agents, and what access are they running with.

WHAT’S NEW IN THE PLATFORM

• Agent Governance — Visibility, ownership, certification, and auditability for AI agents. IGA applied to non-human identities.
• Agent Privilege — Just-in-time access for AI coding agents and developer tools. Least-privilege enforcement where standing access has been the default.
• AI-first headless identity — The Ping platform is now consumable directly by AI agents, letting teams work with Ping through the AI tools they already use.

WHY THE “BUILT-IN, NOT ADD-ON” FRAMING MATTERS

Ping is positioning this as native to the platform — not a separate module. That distinction is operationally significant. Bolt-on AI governance features rarely integrate with existing certification workflows or access request models. If agent identities live in the same governance engine as human identities, IAM teams can enforce consistent policy without managing parallel systems.

Most organizations are deploying agents faster than their security controls can track them. Ping is betting that governance-first is the right posture — and for IAM practitioners, the problem framing is hard to argue with.

Source: Ping Identity Press Release: https://press.pingidentity.com/2026-05-27-Ping-Identity-Redefines-the-Identity-Control-Plane-for-the-Agentic-Enterprise

SMS was never authentication, it was a phone call away from being bypassed. Microsoft just made it official.

Microsoft has confirmed it is phasing out SMS-based authentication and account recovery for all personal Microsoft accounts. The reason, stated plainly in their own advisory: “SMS-based authentication is now a leading source of fraud.” This affects every account tied to Windows, Outlook, Xbox, and OneDrive.

Why SMS authentication was always broken

Text messages were never designed to verify identity. They travel in plain text across cellular networks, making them vulnerable to interception. Worse, SIM-swap attacks where an attacker socially engineers your carrier into transferring your number to their device hand over every SMS one-time code instantly and silently.

The security industry has known this for years. NIST deprecated SMS-based OTP in 2016. Microsoft’s move is long overdue, but it sets a meaningful precedent for enterprise environments where SMS MFA is still considered “good enough.”

What replaces it

Microsoft is pushing three phishing-resistant alternatives:

• Passkeys: Device-bound cryptographic authentication using Windows Hello, biometrics, or a PIN. The private key never leaves your hardware, making remote phishing attacks impossible.
• Microsoft Authenticator app: TOTP-based app authentication, significantly harder to intercept than SMS.
• Verified backup email A secondary identity anchor for account recovery when no device is available.

What this means for IAM and security teams

If your organization still relies on SMS as an MFA factor for Microsoft 365, Azure AD, or any workforce identity flow, this is your forcing function to accelerate the move to phishing-resistant MFA. FIDO2 passkeys and authenticator apps are the direction every major identity provider is heading — Microsoft is just the loudest signal yet.

Audit your MFA enrollment policies now. Any user still on SMS-only MFA is one SIM swap away from a full account compromise.

Source: Windows Latest · Windows Central

AI platforms are now enterprise SaaS — and they need to be governed like it. Okta just made that possible for Claude.

Okta announced on May 21, 2026 a new integration between Identity Security Posture Management (ISPM) and Anthropic’s Claude Compliance API. Security and compliance teams can now monitor identity risks and misconfigurations inside Claude Enterprise and Claude Platform environments — the same way they already govern Salesforce, Workday, or GitHub.

What the Okta–Anthropic integration actually does

Okta ISPM connects to Claude through Anthropic’s Compliance API and continuously assesses four identity risk areas that AI platforms have historically left ungoverned:

• Admin API key visibility: Flags keys that are unused or haven’t been rotated, eliminating standing credentials before they become a liability.
• Offboarding gaps: Detects former employees who still hold active access to the corporate Anthropic workspace after leaving.
• Privilege escalation risk : Enforces zero-standing privilege for admin roles across Claude and connected Anthropic products.
• Dormant accounts : Surfaces provisioned accounts no longer in use, reducing the attack surface and reclaiming licenses.

Why IAM teams should care

Claude has been a governance blind spot. Employees onboard, create admin API keys, build integrations, and offboard and most organizations have no visibility into any of it. This integration closes that gap by pulling Claude into the same identity inventory as the rest of your SaaS stack.

The broader signal is architectural. Anthropic built a dedicated Compliance API so identity providers can plug in. That decision reflects a shift: AI vendors are starting to treat identity governance as a product requirement, not a customer problem. Expect this pattern to spread across other AI platforms.

The integration will be available in beta to customers running Okta ISPM alongside Claude Enterprise or Claude Platform.

Source: Okta Newsroom

Most authentication happens once, at login. Step-up authentication challenges users again only when context demands it. It’s the shift from a yes/no access gate to a continuous risk signal.

What it is

Step-up authentication (SUA) is a pattern where a second — or stronger — authentication factor is required mid-session, triggered by a specific action or condition. The user already has a valid session. They just need to prove they’re still the right person to do this specific thing.

Think of it as authentication on demand. Not at the door, but at the vault. Logging in gets you into the building. Transferring $50,000 gets you another challenge.

How it differs from MFA

Multi-factor authentication (MFA) enforces a second factor at login. Step-up authentication enforces an additional factor at a defined risk threshold – after login. The session is already established. The step-up is contextual.

A user might authenticate with password + TOTP at 9am to access their corporate portal. That same session might trigger a FIDO2 challenge at 2pm when they attempt to modify admin group membership. Same session, higher stakes, stronger challenge.

What triggers a step-up

Triggers fall into three buckets: resource sensitivity, behavioral signals, and policy rules.

Personally Identifiable Information lives inside every system your IAM stack touches. Here’s how to classify it, protect it, and govern access to it before a regulator asks you to.

What counts as PII?

PII is any data point or combination of data points that can identify a specific individual, either directly or when linked with other information. The IAM-relevant definition matters: your identity store is a PII database by definition.

Five IAM rules for PII

• Least privilege by default. No user should have broader access to PII than their role requires. Start with no access and grant up; never grant down.
• De-provision on event, not schedule. When an employee changes role or leaves, PII access must be revoked immediately — not at the next certification cycle.
• MFA on every PII-scoped system. Password-only access to systems holding personal data is unacceptable. Enforce phishing-resistant MFA for anything Tier 2 and above.
• Certify access regularly. Run access certification campaigns against PII-tagged entitlements. If a reviewer misses the window — auto-revoke, don’t extend.
• Log everything. Every read, write, and export on PII-holding systems needs an audit trail. Regulators don’t just ask what happened — they ask who had access and when.

PII governance isn’t a compliance project with a finish line — it’s a continuous operational discipline. Every new app onboarded, every role change processed, every service account provisioned is an opportunity to get it right or leave a gap.

The good news: the IAM stack you already have — your IGA platform, your PAM tool, your identity provider — contains the controls you need. The work is connecting those controls to your data classification model and making enforcement automatic, not manual.

Start with your identity store. Classify what you hold, tighten who can access it, and make sure de-provisioning happens the moment a role changes. Everything else builds from there.

From employees to AI agents a unified model for governing all identity types under a single policy fabric.

Modern identity programs no longer govern just people. The attack surface has expanded to include systems, automation pipelines, and now autonomous AI agents — all operating across hybrid and cloud environments. Understanding the five identity categories is the foundation for building a Zero Trust architecture that actually holds.

Workforce users

Employees who perform daily business functions are the baseline identity population. They’re the identity category most IGA platforms were built around — but many programs still have gaps in joiner-mover-leaver automation and access certification coverage.

Privileged users

Users with administrative or root-level access represent the highest-risk human identity class. A single compromised privileged account can enable lateral movement across an entire environment. These identities require a separate governance track from standard workforce users.

Third parties

External users — vendors, partners, contractors, and consultants — are among the most consistently over-provisioned and under-governed identity populations. They rarely have an HR record driving lifecycle events, which means access that was granted for a project often persists indefinitely.

Non-human & machine identities (NHI)

Non-human identities are the fastest-growing and least-governed identity class in most enterprise environments. Service accounts, API keys, certificates, and pipeline credentials typically outnumber human identities by 10:1 or more — and most organizations have limited visibility into where they exist or what they can access.

AI agents (NHI-agent)

AI agents are a new identity class — autonomous or semi-autonomous entities capable of executing tasks, making decisions, and interacting with systems and other agents without direct human instruction on each action. They are machine identities, but their capacity for goal-directed behavior and delegation chains demands a governance model that goes beyond standard NHI controls.

As organizations adopt automation and AI, identity becomes the control plane of security.

If you can’t answer “who (or what) has access and why?” in real time you don’t have control.

Identity categories are the first step toward building a secure, scalable, and AI-ready enterprise.

Traditional identities follow scripts. AI agents improvise. That gap is your next governance blind spot.

The determinism assumption

Every IAM model built over the last two decades assumes the same thing: a known actor will attempt a known action on a known resource at a predictable time. A service account calls the same API at a scheduled time. A user clicks the same menu to access the same report. Identity governance works precisely because behavior is predictable enough to be modeled, attested, and enforced.

AI agents break this assumption at the foundation.

The Core Problem

Agentic systems don’t execute scripts — they plan. The sequence of permissions an agent needs to accomplish a goal is determined at runtime, not design time. You cannot fully enumerate what an agent will request before it runs.

What “non-deterministic” actually means in IAM

Non-determinism in the identity context doesn’t mean random. It means the access path from goal to completion is resolved dynamically, shaped by context, intermediate results, and reasoning and not a fixed workflow.

The four failure modes unique to agentic identity

Privilege accumulation

An agent acquires permissions incrementally across a long-running task. Each individual grant looks like the least privilege. The combined effective access does not.

Context poisoning

External content ingested mid-task (emails, web pages, documents) can alter agent reasoning and redirect which resources it accesses next, prompting injection as an IAM vector.

Ghost delegation

Orchestrator agents create sub-agents and pass along credential context without an explicit governance event. The downstream identity has no auditable entitlement record.

Identity ambiguity

When an agent acts, is it acting as itself, as the user who invoked it, or as the application that deployed it? Most platforms have no answer. Enforcement defaults to whichever identity has the least friction.

What makes this structurally different from service accounts

The instinct is to treat AI agents like privileged service accounts — provision them with a fixed set of permissions and monitor usage. This misses the structural difference.

A service account calls a specific endpoint on a defined schedule. Its behavior is determined by code, which is auditable and static across deployments. An AI agent’s behavior is determined by a language model interacting with runtime inputs. The same agent invoked with a different context produces different access sequences — even with identical starting permissions.

Governance principles that hold for non-deterministic identities

Just-enough access, just-in-time
Grant permissions at task invocation, not at provisioning time. Revoke when the task completes. Agents should not carry standing entitlements between runs.

Explicit delegation boundaries
Every agent-to-agent credential pass must produce an auditable governance event. Sub-agents cannot inherit scope implicitly — scope must be explicitly constrained at each delegation hop.

Runtime behavioral monitoring
Entitlement reviews cannot replace real-time behavioral detection. Monitor for anomalous tool call sequences, unexpected resource access, and scope drift mid-task.

Immutable task context binding
Bind agent sessions to a declared task scope at invocation. Access requests outside that declared scope require a new authorization event, not an implicit extension.

Tri-party identity attribution
Every agentic action must include three identity attributes: the human who invokes it, the agent that orchestrates it, and the sub-agent or tool that executes it. All three must appear in the audit record.

Deny by default on ambiguity
When the agent’s declared scope doesn’t clearly cover a resource request, default to deny and surface the decision for human review — not silent approval.

Your IAM stack is ready for agentic identity when you can answer three questions about any in-flight agent session: what is its current effective access, what human authorized this scope, and what happens to the credentials when the task ends. If any of these are unanswerable in real time, the governance gap is open.

A new organizational model is quietly taking hold in enterprise software. It isn’t about chatbots answering questions; it’s about autonomous agents that act, decide, and collaborate across the entire business stack.

There is a meaningful difference between a company that uses AI and one that is organized around it. The first deploys machine learning models to speed up individual tasks; a support chatbot here, a document summarizer there. The second has undergone a more structural change: its core business processes are owned, executed, and continuously improved by autonomous software agents.

That second category (the AI agent–based company) is still rare. But the architectural building blocks are now available to any organization willing to assemble them. Understanding what they are and why they represent a genuine inflection point is essential for anyone thinking about where enterprise technology is heading.

The Four Pillars of an Agent-Based Organization

• Process Ownership
  • Agents run business workflows end-to-end, not just individual steps
• System Integration
  • Agents act natively inside enterprise platforms and APIs
• Agent Collaboration
  • Specialized agents delegate and coordinate with one another
• Human Oversight
  • People set policy, approve high-risk actions, and review outcomes

Pillar One: Agents That Own Business Processes

The canonical tell of an agent-based company is that consequential business processes — not just queries or lookups — run inside agents without continuous human steering. The agent is responsible for a workflow from trigger to resolution.

Customer Support

In a traditional setup, a support ticket arrives, a human reads it, triages it, escalates it or resolves it. In an agent-based company, an AI agent receives the ticket, determines urgency and category, consults policy and knowledge bases, routes to the right resolution path, attempts resolution autonomously, escalates to a human only when confidence thresholds are not met, and closes the ticket with a documented audit trail. The agent owns the entire workflow.

Pillar Two: Native System Integration

An agent that can reason but cannot act is merely an advisor. The second pillar is what gives agents real leverage: the ability to read from and write to enterprise systems of record.

In practice, this means agents are credentialed actors inside the same platforms that human employees use — not just calling REST APIs, but operating within the permission structures, audit trails, and workflow engines of those platforms.

Pillar Three: Agent-to-Agent Collaboration

The most architecturally interesting property of agent-based companies is what happens when agents work together. Rather than a single monolithic agent attempting to handle every domain, sophisticated systems decompose complex workflows across specialized agents that communicate through structured interfaces.

This mirrors how large organizations already work: a hiring manager doesn’t personally provision laptop access ; they trigger a chain of handoffs through HR, IT, and security. Agent-based architectures make those handoffs programmable, auditable, and dramatically faster.

Pillar Four: Humans as Supervisors, Not Operators

Perhaps the most counterintuitive aspect of the agent-based model is the role it assigns to humans; not elimination, but elevation. Humans in these organizations stop being the people who do the work and become the people who define what the work should accomplish.

This shift plays out across three distinct functions. First, policy definition: humans specify the rules, constraints, and goals that govern agent behavior. An agent doesn’t decide on its own what “approved vendor” means ;a human defines that policy, and the agent enforces it at scale. Second, high-stakes approval: agents are designed to escalate decisions that exceed confidence thresholds or cross defined risk levels

Not all agents are the same—but today, we treat them as if they are.

Traditional IAM models group everything into:

• Human users
• Service accounts

This is no longer sufficient.

To properly secure, govern, and scale AI, we need a formal classification model for Non-Human Identities (NHI); specifically NHI-Agents.

What Is an NHI-Agent?

An NHI-Agent is: A non-human identity that can act autonomously or semi-autonomously to perform tasks, make decisions, and interact with systems or other agents.

Key Characteristics:

• Has intent (task-driven execution)
• Operates with context awareness
• Can initiate actions, not just respond
• May delegate to other agents
• Requires identity lifecycle governance

Why NHI-Agent Classification Is Critical

Without classification, organizations face:

• Overprivileged AI agents
• No ownership or accountability
• Inability to trace decisions
• Compliance gaps (SOX, ISO, NIST)
• Security blind spots in automation

NHI-Agents are no longer theoretical; they are already operating inside modern enterprises, driving automation, decisions, and interactions at scale. But with that power comes a fundamental requirement:

They must be treated as first-class identities; not as traditional service accounts. Enterprises adopting AI today must immediately integrate NHI-Agent governance into their IAM strategy.

Without proper classification, organizations expose themselves to significant risk—overprivileged access, lack of accountability, and limited visibility into autonomous actions. These are not just technical gaps; they are security, compliance, and operational risks that can scale rapidly with AI adoption.

Not all identities are created equal. Before you can govern access effectively, you need to know who or what is requesting it. IAM programs that only think about employees are leaving half the picture ungoverned.

The two identity categories

Every identity in your environment falls into one of two buckets: human or machine. The distinction isn’t just semantic; it determines how an identity authenticates, how long it should live, how you detect anomalies, and how you de-provision it when it’s no longer needed.

• Human identities
  People-centric, behavior-based risk
• Machine identities
  Non-human, credential-based risk
  

Examples at a glance

Why human identities require behavioral context

Human identities are inherently unpredictable; a legitimate user can act in ways that may look risky (signing in from a new country, accessing systems outside working hours). Effective governance here relies on behavioral baselines, contextual policies, and MFA enforcement.

• Employees, developers, and QA staff form the core identity population. Role-based access controls, regular access reviews, and separation of duties keep privilege creep in check.
• Contractors, vendors, and partners are the highest-risk segment. They arrive with entitlements negotiated outside IAM workflows and often linger after the engagement ends. Time-bound access and auto-deprovisioning are non-negotiable.
• Executives are high-value targets. FIDO2 phishing-resistant MFA and enhanced monitoring should be standard, not optional.

Why machine identities are the bigger blind spot

Most organizations have a handle on human identities — they live in Active Directory, Okta, or a similar directory. Machine identities are scattered: service accounts, API keys, certificates, tokens, and secrets spread across CI/CD pipelines, cloud workloads, IoT firmware, and AI agents. They often have no owner, no expiry, and no audit trail.

• Cloud service principals and IAM roles are the fastest-growing NHI category. Overly permissive roles are the root cause of most cloud breaches.
• AI agents are the emerging frontier — they act on behalf of humans, can spawn sub-agents, and need scoped, short-lived identities. See our post on identity agentic for a deep dive.
• Certificates and PKI entities are the silent risk — an expired cert can take down a production service instantly. Certificate lifecycle management belongs in every NHI program.

Key takeaways

1. Build a unified identity inventory
2. Separate the risk models
3. Expire everything by default
4. Classify AI agents as machine identities
5. Apply least privilege to both categories
6. Automate de-provisioning, do not rely on reviews