Skip to main content
All practice areas
Practice Area 01

Identity Orchestration & Agent Access

Large organisations run several identity providers, decades of legacy apps and now AI agents — each wired to the others by hand. Identity orchestration puts one standards-based layer between them, so you can add MFA, migrate providers, survive an outage and govern agents without rewriting a single application.

The question we answer

Can you change identity providers, add MFA to a legacy app, or survive a cloud IdP outage without touching application code — and can you show on whose authority each AI agent acted?

AuthoritativeIn a Cloud Security Alliance survey of 950 IT and security professionals (published 30 October 2024, sponsored by an identity orchestration vendor), 75% of organisations ran two or more identity providers and 71% said legacy applications blocked stronger authentication. Cloud Security Alliance, 30 Oct 2024

AuthoritativeOSFI Guideline B-13 (effective 1 January 2024) expects risk-based identity and access controls including MFA (§3.2.7), planning for technology assets before support ends (§2.2.5), and recovery of technology services within set timeframes (Principle 12). OSFI Guideline B-13

InterpretationMost identity programmes stall on the applications, not the identity provider. Every app re-integrated by hand turns a provider decision into a multi-year project. Orchestration moves that integration into one layer the identity team controls.

InterpretationAI agents make the same problem urgent: each needs its own identity, authority scoped to one task and an audit trail back to the person who delegated it — across whichever providers and tools you already run.

What we assess

  • Your identity estate: providers, directories, web access managers and the apps behind each
  • Applications that cannot use modern protocols — and the MFA gaps and audit findings they cause
  • Single points of failure: what happens when your cloud IdP is unavailable
  • How AI agents authenticate today: static keys, shared service accounts or delegated tokens

What we implement

  • A vendor-neutral orchestration layer in front of legacy and modern apps — on-prem, cloud or air-gapped
  • MFA and passwordless for legacy apps, with no code changes
  • Identity provider migration and consolidation, app by app, with rollback
  • Identity provider failover with consistent attributes, tested against a real outage
  • Delegated, short-lived, per-tool access for AI agents, with policy at each call

Evidence you keep

  • Identity estate map and application dependency register
  • MFA coverage report, before and after
  • Failover test record — the drill, not the plan
  • Agent access register and per-action audit trail tied to the delegating person

Maps to

OSFI B-13ITSP.10.033NIST SP 800-63NIST AI RMFISO/IEC 27001

Why identity orchestration

Large organisations didn’t design their identity estate. They accumulated it.

Several identity providers, decades of applications wired to them by hand, and now AI agents. Orchestration puts one layer between them so change stops being a programme.

Without orchestration every app is wired to identity by hand; with it, apps integrate onceWITHOUT ORCHESTRATIONCloud IdP ACloud IdP BOn-prem directoryLegacyappLegacyappSaaSappSaaSappCustomappAgenttoolsEvery change touches every app: years of re-integrationWITH ORCHESTRATIONCloud IdP ACloud IdP BOn-prem directoryIdentity orchestration layerone policy · one integration point · failover · agent tokensLegacyappLegacyappSaaSappSaaSappCustomappAgenttoolsChange providers, add MFA or fail over without code changes
Without orchestration every app is wired to identity by hand; with it, apps integrate once. Apps integrate once. Identity providers, directories and agents change behind the layer, not inside every application.
  1. Reason 01

    Too many identity providers

    Mergers, cloud programmes and SaaS sprawl leave most large organisations with more than one identity provider — three in four run two or more (CSA, 2024, vendor-sponsored survey). Each one is a separate policy, a separate audit and a separate migration.

  2. Reason 02

    Legacy apps hold MFA hostage

    Header-based and web-access-manager applications cannot speak SAML or OIDC, so they stay on passwords. Orchestration enforces modern MFA in front of them — no code change.

  3. Reason 03

    Migrations that never end

    Moving identity providers normally means re-integrating every application. With an orchestration layer, apps integrate once and providers change behind it, in batches you can roll back.

  4. Reason 04

    Your identity provider is a single point of failure

    When the cloud IdP is down, nobody signs in to anything. Orchestration can fail over to a second provider or on-prem directory while apps keep seeing the same attributes — a continuity control you can actually test.

  5. Reason 05

    AI agents need identity too

    Agents call tools and data on someone’s behalf. Orchestration issues a short-lived, narrowly scoped token per call, checks policy, and records who delegated it — instead of a static key nobody can trace.

What we deliver

Identity orchestration, designed, implemented and run.

Multi-IdP identity fabrics, legacy-to-cloud policy abstraction, and identity governance for non-human and AI agent identities, delivered as one practice.

01

Multi-IdP identity fabric design

One standards-based access layer across cloud identity providers, on-prem directories and legacy access managers, so they behave as one system without forcing a single vendor.

02

Legacy-to-cloud migration & policy abstraction

Decouple authentication and policy from the application. Move apps off end-of-life access managers and between identity providers in batches, with rollback and no code rewrites.

03

Runtime access flows & risk-based authentication

Step-up, risk-based and passwordless sign-in enforced at the layer, in front of apps that could never support them natively, with consistent policy across every provider.

04

Identity continuity & failover

Health-checked failover to a second provider or on-prem directory, with attributes mapped so applications keep working. Tested as a drill, with the record kept.

05

Non-human & AI agent identity governance

Per-agent identity, task-scoped delegated tokens, policy at every tool call and an audit trail back to the person who delegated, across multi-cloud estates.

06

Run, measure, hand over

Configuration exported and documented, custom code kept to a minimum, MFA coverage and failover metrics reported. Your team runs it after us.

Identity estates we design across

  • Microsoft Entra ID
  • Okta
  • Ping Identity
  • CyberArk
  • SailPoint
  • Saviynt
  • Active Directory & LDAP
  • Legacy web access managers
  • Identity orchestration platforms
  • Cloud IAM (AWS, Azure, Google Cloud)

Platforms named to describe the estates we work across. No partnership, endorsement or certification is implied unless stated. Where Aegis holds a commercial relationship with a vendor, we disclose it in writing before recommending its product.

How it fits

One layer between who signs in and what they reach.

It routes, translates and enforces. It stores no identities and replaces none of the identity products you already own.

Reference architecture: one orchestration layer between people, agents, identity systems and applicationsWHO SIGNS IN OR CALLSWorkforceCustomers & partnersAI agentsIdentity orchestration layerProtocol translationSession managementPolicy at request timeAttribute mappingProvider failoverAgent token exchangeAudit to SIEMIDENTITY SYSTEMS YOU ALREADY OWNIdentity providerscloud and legacyDirectoriesAD, LDAP, attribute storesMFA & passwordlessany providerGovernance & PAMIGA, privileged accessLegacy web appsheader-based, access-managerSaaS & cloud appsSAML, OIDCAPIs & agent toolsMCP servers, internal APIsRequests pass through the layer to the apps; the layer consults the identity systems on each sign-in or call.
Reference architecture: one orchestration layer between people, agents, identity systems and applications. Reference architecture for a large organisation. The layer stores no identities and replaces no identity product; it routes, translates and enforces. Runs on-prem, in cloud or air-gapped.

Where it pays off

Six problems, one layer.

Retire a legacy web access manager

Before

Every app is tied to agents and headers; end of support forces a rewrite.

After

The layer replays the same headers from a modern provider. The old platform is switched off.

Migrate or consolidate identity providers

Before

Re-integrate and test every app — for years.

After

Apps point at the layer once; providers swap behind it in batches.

MFA for legacy and on-prem apps

Before

Password-only apps and a standing audit finding.

After

Modern MFA enforced in front of the app.

Survive an identity provider outage

Before

One outage locks out the whole organisation.

After

Automatic failover, with consistent attributes for every app.

Mergers and acquisitions

Before

Duplicate accounts or a rushed migration.

After

Both providers behind one layer on day one; consolidate when ready.

Govern AI agents

Before

Static API keys and shared service accounts.

After

Per-call delegated tokens, policy checks and an audit trail to a person.

Where identity meets AI control

Orchestrating identity for autonomous AI agents and multi-cloud enterprises.

This is the intersection we work at. Identity orchestration is the runtime front of our AI control spine: it feeds the identity and policy zones of our published reference architecture, so access decisions and AI decisions produce one evidence trail.

E1 · Identity & Ingress

The orchestration layer authenticates every principal: person, workload or AI agent. It binds the authenticated identity, plus the person an agent acts for, to each request before it reaches a model or tool.

E2 · Policy & Entitlement

Policy is evaluated at request time, in one place, across every identity provider. Each decision stamps the request with the control identifier and risk tier that the evidence plane records.

E6 · Evidence Plane

Every sign-in, step-up, failover and agent tool call writes an audit event. Identity evidence then sits beside model evidence, ready for the same E-23, B-13 or ITSP.10.033 review.

See the reference architecture

Entry engagement

Identity Orchestration Readiness Assessment

3–4 weeks · fixed fee, scoped in a 45-minute briefing

You leave with a plan your identity team can execute, with or without us, and with a clear view of which applications to move first.

Book an identity estate briefing
  • Identity estate map: providers, directories, access managers and the applications behind each
  • Application protocol and dependency register, ranked by business criticality
  • Target orchestration architecture, on-prem, cloud or air-gapped
  • Sequenced roadmap: MFA coverage, provider migration and failover
  • AI agent and non-human identity gap list, with the controls to close it
  • Proof-of-concept plan for one application, with the latency and failover tests to run

For identity and security vendors

We design, implement and operate identity orchestration across your platform and the rest of a client’s estate, including legacy-to-cloud migration, multi-IdP fabrics and AI agent access.

Services, implementation and resale, with every commercial interest disclosed to the client in writing. Alliance and co-sell enquiries: partners@aegis-systems.ca

Questions we get asked

The objections, answered.

Isn’t this just another reverse proxy?

Proxying is one way to deploy it. What a plain proxy lacks is identity logic: routing across several providers, translating between protocols, normalising attributes, managing sessions, failing over, and exchanging tokens for agents.

Aren’t we swapping one lock-in for another?

The layer speaks open standards — SAML, OIDC, OAuth — so applications can be modernised and taken off it one by one. We keep custom code to a minimum and hand over documented, exported configuration.

What about latency and resilience?

It adds one hop at sign-in and on proxied requests. We deploy it close to the apps, scale it horizontally and design out the single point of failure — which most estates already have in their one identity provider. We measure latency in a proof of concept rather than quote a number.

Does it replace our identity provider, IGA or PAM?

No. It coordinates them. Your identity provider still authenticates, governance still certifies access, and privileged access management still vaults admin credentials.

Other practice areas

Labels show what is traceable to a regulator or standards body (Authoritative) and what is our professional reading of it (Interpretation). Where an engagement involves technology from a vendor Aegis holds a commercial relationship with, we disclose that interest in writing before recommending it.