Governing agents alongside Okta or Entra

What do Okta and Entra already cover?

Both major workforce identity providers extended their products to AI agents in 2026. It is worth knowing exactly what they cover before buying anything else.

Okta for AI Agents became generally available on 29 April 2026. It registers agents in Universal Directory and can import them from Agentforce, Bedrock AgentCore and ServiceNow. You can assign human owners and include agents in access requests and certifications. Agent SSO followed in core Okta SSO on 24 August 2026. At general availability, Okta listed Agent Gateway and human-in-the-loop controls as coming later.

Microsoft Entra Agent ID is available to all Entra customers. Each agent has a sponsor. Conditional Access can apply to agents, and Identity Governance extends to agents acting on behalf of users. Microsoft Agent 365 became generally available on 1 May 2026 at $15 per user per month. Per-action human approval was not found in the Microsoft material we read.

That is a solid foundation. Identity, owners, sign-in policy and periodic certification are all in place for agents.

What does a governance layer add?

Identity providers decide who an agent is and what it may reach. They mostly act at sign-in or token issue. A governance layer acts at each action, after access is granted.

Four capabilities are the usual reason to add one.

• Per-action policy: checking each tool call against the agent, the person, the tool and the data (GOV-06).
• Human approval: pausing high-risk actions for a named approver, with no self-approval (GOV-07, GOV-08).
• Audit tied to a person: logging each action with the agent and the person it acted for (GOV-13).
• Fast revocation: cutting one agent off from tools in minutes, independent of token lifetimes (GOV-11).

Some layers also add discovery that does not depend on registration, so shadow agents created outside the identity provider are found (GOV-16).

Why alongside, and never instead of?

A governance layer runs alongside your identity provider, never instead of it. The identity provider remains the system of record for people and for employee sign-in. Replacing it would mean rebuilding everything that already works for the workforce, which no agent governance product in the register sets out to do.

Several vendors state this directly. NewCore says your current identity platform keeps handling employee sign-in, and its first deployment path is "Start alongside your identity platform". Aembit states that it does not replace the workforce identity provider. Silverfort discovers agents across identity providers such as Entra ID and Okta through read-only APIs.

How do you avoid two sources of truth?

Running two systems that both hold agents, owners and policies invites drift. Decide early which system owns each record.

• Agent identity: usually the identity provider, where it exists. The governance layer reads it.
• Owner or sponsor: pick one source. If Entra holds sponsors, sync them into the governance layer, or the reverse, but not both ways.
• Sign-in and token policy: the identity provider, through Conditional Access or Okta policies.
• Per-action policy and approvals: the governance layer.
• Access certification: either can run it, but only one should. Many teams keep it in the identity governance tool they already use.
• Audit: both produce logs. Send both to the SIEM and join them on agent ID.

Write these decisions down in your agent governance policy. They save hours in every audit.

How should the two connect technically?

The common pattern has three links. The governance layer reads agent and user identities from the identity provider, often through SAML, OIDC or read-only APIs. Agent tool calls pass through a gateway or proxy that the governance layer controls, frequently using MCP. And both systems export events to the SIEM.

NewCore names SAML, OIDC and MCP, and routes every agent tool call through its gateway. Silverfort's MCP Gateway receives every tool call first. Aembit's MCP Identity Gateway enforces policy on every MCP request. Idira's Identity Broker sits as a proxy between agent and tools.

Delegation needs special care. When an agent acts for a person, the governance layer should check the action against that person's permissions from the identity provider (GOV-18). If the person loses a role in Entra or Okta, the agent should lose it too, at the next call.

What should you check before buying?

Ask each vendor five questions and ask to see the answer working.

• Which identity providers do you read from, and how?
• Where does your policy check happen, and does every tool call pass through it?
• Can an approver be a named person, and can an agent approve its own action?
• Does your audit log name the person each action was for?
• How fast can you revoke one agent, and do cached tokens stop working?

Compare the answers with the register's control coverage for each platform. Where the register says not found in public material, the vendor may still do it. A live demonstration settles it.

When do you not need a governance layer yet?

If you run a handful of agents with read-only access and no high-risk actions, the identity provider's agent features may be enough for now. Register the agents, assign owners or sponsors, and include them in certifications.

The case for a governance layer grows with three things. They are agents that write or delete, agents acting for many people, and audits that ask for per-action evidence. When any of those arrives, per-action policy and approval stop being optional.

What mistakes should you avoid?

Three mistakes recur. Teams buy a governance layer and then try to move employee sign-in into it, which creates risk with no benefit. They keep owners in two places that drift apart. And they assume a sign-in policy also controls each tool call, which it usually does not. Keep the identity provider for people and sign-in, and keep per-action decisions in the governance layer.

Where to go next

Read the Okta for AI Agents and Microsoft Agent 365 pages for what each covers, with sources. The register compares ten governance layers on the same 24 controls. The guide on designing approval rules covers the part identity providers do not yet document.