Omada Buys EmpowerID to Add Runtime Authorization for AI Agents
The announcement went out through PR Newswire and Omada's pressroom. Omada A/S described itself as "a global leader in Identity Governance and Administration (IGA)" and said it "today announced it has acquired EmpowerID, a pioneer in AI agent governance." The company says the acquisition brings EmpowerID's runtime agent governance capabilities into Omada, strengthening its ability to provide security controls for human, non-human and agent identities. VMblog carried the same release on September 25. That is republication of the release, so it doesn't count as independent confirmation.
The trade publication ID Tech gave its own summary of the deal. It described the goal as incorporating real-time runtime authorization for AI agents into its enterprise identity lifecycle management platform. In its reading, the combined architecture bridges scheduled governance reviews with in-line policy enforcement, evaluating access requests against live risk metrics the moment an autonomous software agent attempts to query enterprise tools, databases, or workloads rather than relying solely on delayed audit cycles.
The leadership change is concrete. EmpowerID CEO and co-founder Patrick Parker will join Omada as chief innovation officer to drive innovation and development of next-generation identity security capabilities and support the integration of EmpowerID's agent governance technology into Omada's platform. Omada's release also says the investment firm Stephens advised Omada and its shareholders on the deal. The release gives no price, no closing conditions and no word on what happens to EmpowerID's existing product line or its customers' contracts.
Both companies were already in the same market. On Gartner Peer Insights' IGA comparison, EmpowerID has a rating of 4 stars with 33 reviews. Omada has a rating of 4.6 stars with 221 reviews. In effect, a larger IGA vendor has absorbed a smaller rival whose recent work centered on controlling agents while they run.
Runtime Authorization Moves the Decision From the Review Cycle to the Request
The strategic idea is simple once the jargon is removed. Traditional IGA answers the question of who is entitled to what. Accounts get provisioned, reviewers certify access every quarter or so, and changes reach target systems through scheduled synchronization. That model works for employees whose jobs change slowly. It is a weak fit for software agents that might make thousands of tool calls a day. Omada argues that the access controls built for human employees simply weren't designed for something that moves, and can go wrong, at machine speed.
Omada says the combined company will deliver five things:
- Humans, applications, workloads and AI agents will go through the same lifecycle, access and certification services, giving each identity one record and one access decision.
- A continuously maintained view of identities, entitlements and relationships across connected systems will feed governance, authorization and risk evaluation from one source instead of separate copies.
- Runtime authorization will decide access when each request arrives, using live risk and governance context. A change made during an access review would then apply on the agent's next call instead of after the next sync.
- Agent governance will cover the full span from discovery (finding agents, their identities, tools and reach) through ownership, lifecycle management, certification and runtime control.
- Every grant, decision and review will be recorded as compliance evidence when it happens, so evidence isn't assembled just before an audit.
The runtime authorization item is the one that changes day-to-day operations. Under the sync-based model, revoking an agent's access in a review leaves a gap until the change reaches the target system. Omada says the next request would be evaluated against the new state instead. CEO Jakob H. Kraglund framed it this way: "This acquisition means we can tell customers not just what their agents have access to, but we can also stop those agents the moment they step outside the lines – in real time, not after the fact. That's the difference between governing AI and just monitoring it."
Martin Kuppinger, co-founder of KuppingerCole, gave the analyst view in the release. He said that with EmpowerID, Omada adds runtime authorization and security for AI agents to its IGA foundation. He described that as extending governance from who is entitled to access to what agents are actually permitted to do while they do it. His comment summarizes the vendor's plan; it is not an assessment of a working combined product.
Omada says it "will deliver" all five capabilities. The release does not separate what customers can use today from what is on the roadmap.
EmpowerID's Agent Governance & Execution Is Still Largely Early Access
To see what "stop the agent in real time" means in practice, look at EmpowerID's own product pages. They are more careful than the acquisition release. EmpowerID's Agent Governance & Execution product carries an Early Access label. The company states that capabilities, credential modes and evidence coverage vary by execution path, integration and release.
EmpowerID describes the mechanism as authorizing the exact action, not just the agent, the session or the tool. Each agent is tied to an accountable owner, an "approved mission" (the limited job it is authorized to do), a chain of delegated authority and the current policy. When the agent is about to act, EmpowerID evaluates the specific operation, resource, parameters and destination against current identity, delegation and risk context. It returns one of three outcomes: allow, deny, or require extra assurance such as human approval. The authorization is single-use and is consumed before the request is sent to the target. If authority has changed since the action was prepared, the request never reaches the target system through that path.
EmpowerID's worked example is a procurement agent creating a purchase order in an ERP system. An operations manager revokes the agent's delegation partway through a run. The next proposed action is re-evaluated and denied, no request is sent, and the denial is recorded as evidence. The underlying point is that an active token does not mean the agent still has authority to act. Each consequential action gets checked again.
EmpowerID also stresses credential handling. On supported vault-backed paths, the agent asks EmpowerID to perform an authorized action. The credential for the destination system stays inside EmpowerID's governed boundary, is applied only after authorization, and is never returned to the agent. That addresses a common risk in agent deployments: a reusable API key or service credential ending up in the agent's context, where it could leak or be misused. EmpowerID says this protection applies only to declared vault-backed modes, and that other integration modes have to state how credentials are obtained and exposed.
The maturity labels by control path are the most useful detail for anyone evaluating the acquisition:
| Control path | Where control happens | Maturity per EmpowerID | Stated limitation |
|---|---|---|---|
| LLM Gateway | Before model access | Early Access | Features follow the release contract |
| MCP Gateway | Before tool invocation | Early Access | Coverage varies by connector |
| Native runtime and agent-to-agent | From start/stop controls up to per-action checks, where a callback exists | Preview | The runtime sets the ceiling |
| Custom applications and workflows | At a declared API, workflow or backend boundary | Early Access | Requires a declared enforcement point |
MCP here is the Model Context Protocol, the standard many agent frameworks use to call tools. The MCP Gateway sits in front of those tool calls. According to EmpowerID's comparison table, it is the path with the strongest exact-action binding (tool, operation, resource and parameters) and vault-backed credentials.
EmpowerID Only Controls Actions That Pass Through Its Enforcement Points
EmpowerID's pages set out limits in plain terms. The company says it does not claim control over actions that bypass its declared enforcement points. If an agent can reach a system directly without going through the gateway or a wrapped API, runtime authorization never sees that action. EmpowerID also says revocation stops new governed actions but does not undo actions already completed. Proving that a business outcome actually happened in an external system depends on trustworthy evidence from, or participation by, the destination system.
Discovery has the same kind of limit. EmpowerID's AI Agent Discovery page says coverage depends on the connected sources and the metadata each one exposes. Its FAQ is blunt on one point: discovery does not automatically block an agent. Containment or runtime enforcement needs a supported control path plus an explicit policy or operator action. The coverage matrix shows the gaps. Credential-path visibility for LLM gateways is marked "not currently available," and custom applications and APIs need configuration before agents can be inventoried or controlled.
Kraglund's line about stopping agents "the moment they step outside the lines" should be read with that in mind. The mechanism exists and is well described, but it works per path. An agent is governed at runtime only where its traffic goes through a governed gateway or a declared enforcement point. Everywhere else, the combined product offers visibility, ownership records and review workflows, which is the "monitoring" Kraglund contrasted with governing.
EmpowerID's page also draws a line between an agent and a service account. A service account is usually a non-human identity used by an application. An agent is a system that picks and carries out actions toward a goal, and it may use several service accounts, tokens or delegated credentials. EmpowerID recommends keeping agent records and credential records connected but separate, and that is sound inventory practice whichever vendor a team uses.
Omada Agent Governance Needed a Runtime Layer
The acquisition builds on a product Omada announced three months earlier. On June 15, 2026, Omada introduced Omada Agent Governance and showed it at Identiverse 2026 in Las Vegas. The June release framed the problem as visibility and accountability. Kraglund said most organizations could not answer four questions: what AI agents they have, who is accountable for them, what they can reach, and what the risk is.
The June product focused on posture. It aimed to improve visibility into agents and non-human identities across cloud platforms, assign owners to reduce orphaned agents, compare granted access against actual use to cut over-privilege, and produce audit evidence. Omada said it aligned the product with the EU AI Act, NIST AI RMF, ISO 42001, OWASP and MITRE ATLAS. That describes alignment only, not certification. Omada also said the product was deliberately agnostic to customers' existing IGA and IAM investments. That matters to organizations that don't run Omada as their main governance platform.
Nothing in the June release described blocking an agent's action as it happens. EmpowerID's gateways and single-use authorizations fill that gap. Omada's earlier work on the Model Context Protocol, which it described in a late-2025 blog post as an early milestone in the evolution from AI for IGA toward IGA for AI, points the same way. The acquisition turns that direction into a purchase instead of a roadmap item.
What this means for you
Security and identity teams that are piloting or running AI agents should treat this as a reason to ask their governance vendor specific questions. It is not yet a reason to change platforms. Existing Omada customers will get a combined roadmap, but nothing announced so far says when EmpowerID's runtime controls will appear in Omada's product, how they will be licensed, or whether they will need separate deployment. EmpowerID customers should ask about product continuity and migration, since the release is silent on both.
If you are evaluating runtime agent governance from these vendors or others, EmpowerID's own documentation supplies a good checklist. Ask which agent platforms and execution paths are supported today and at what maturity level. Ask whether the path that matters most to you, such as a production deployment API, an ERP write or a ticketing system, can be put behind an enforcement point. Ask what happens if an agent can reach that system without going through the gateway.
- Omada completed its acquisition of EmpowerID on September 24, 2026. Financial terms were not disclosed, and Patrick Parker becomes Omada's chief innovation officer.
- Omada's five promised capabilities are forward-looking statements, and the release gives no general-availability dates, pricing or supported integrations.
- EmpowerID labels its LLM Gateway, MCP Gateway and custom-workflow enforcement as Early Access, and native runtime and agent-to-agent control as Preview.
- Runtime blocking covers only actions that go through a declared enforcement point, and revocation does not reverse actions that have already completed.
- Agent discovery gives inventory and context but does not block anything on its own, and discovery coverage depends on which sources are connected.
- Keeping destination credentials out of the agent's runtime, which EmpowerID does on vault-backed paths, is worth asking for from any vendor, because a reusable credential in an agent's context is a common exposure.
With this purchase, Omada has bought the missing piece of its agent-governance pitch. EmpowerID gives it a working design for checking each agent action before it is sent and for keeping credentials away from the agent. It also comes with honest documentation of where that design stops. Whether the deal pays off for customers depends on how quickly Omada moves those Early Access and Preview paths to general availability and publishes connector-by-connector coverage. Until that happens, the practical value for most enterprises is an inventory and ownership record for their agents, plus runtime control on the few high-impact paths they choose to route through a gateway.