Reference Architecture
Building identity foundations for AI-Ready Enterprise Environments
Prepared for a real-world environment.
Read our real-world reference architecture developed by Activate IAM’s senior automation architect for our existing customer, within a government environment.
Enterprise identity environments rarely start with a clean slate.
Over time, new platforms, integrations and automation are added, and identity processes become more complex.
In our customer’s government environment, several integrations relied on broadly privileged shared service accounts across HR, directory, ITSM and device management systems. Our immediate challenge was to reduce that risk without rebuilding their existing environment.
The longer-term challenge was just as important: build an identity model that could support new forms of automation, including AI agents, without having to redesign the foundations later. This reference architecture shows the approach we proposed: to move from shared, broadly privileged accounts to dedicated, scoped identities with clear ownership, least-privilege access and auditable workflows.
The problem: Complexity builds up over time.
Large government environments accumulate integrations incrementally, over many years and multiple technology cycles.
It's common to find one Active Directory service account doing several jobs: authenticating connectors into HR platforms, directory services, ITSM tools, and device management systems added at different times. That doesn’t mean the original design was poor. Often, it was the practical way to get important systems working. But as the environment grows, the model creates problems.
One broadly privileged account can increase the impact of a compromise, lockout or configuration error. It also makes audit and compliance harder because the same identity is performing multiple functions across multiple systems. The question becomes:
How do you reduce that risk without replacing the platforms and processes that already work?
But it concentrates risk: a shared, broadly-privileged service account expands the blast radius of any single compromise, lockout, or misconfiguration far beyond the one integration that triggered it. That’s the problem this architecture was designed to solve.
The proposed architecture.
One integration. One dedicated identity. Only the permissions it needs.
Instead of multiple integrations relying on a broadly privileged shared account, each integration receives its own named identity, scoped to its specific purpose. That creates clearer:
ownership
permissions
accountability
audit evidence
revocation
lifecycle management
And importantly, it doesn't require a platform rebuild. The approach progressively moves existing integrations toward a scoped identity model while retaining the existing staff-facing request experience.
Proposed architecture: One integration. One identity. Only the access it needs.
Each integration gets its own dedicated identity, with permissions scoped to its specific job. No broadly shared accounts. No more standing privilege than the integration needs to operate.
Where Activate fits.
Activate's existing privileged account management capabilities support this model by managing privileged secondary accounts, service accounts, connector identities and administrator accounts through:
ownership assignment
approval workflows
time-bound access
credential control
audit trails
These aren't new controls created specifically for AI. They are established identity operating patterns being applied to a more granular account structure.That distinction is important.
AI doesn't change the need for good identity operations. It increases the importance of getting them right.
What counts as a non-human identity in this architecture?
The design covers three areas.
Service accounts
Accounts used by connectors and automation to interact with systems such as Active Directory, Exchange and SharePoint.
Application and API identities
Entra ID app registrations, managed identities and integration credentials used for defined machine-to-machine functions.
Future AI agents
The agency does not currently have AI agents operating in this environment. The architecture is designed so that if agents are introduced later, the organisation already has an identity model capable of supporting tightly scoped access, ownership, approval and auditability. That's the AI-readiness element of the design.1.
Extending the identity model to AI agents.
The agency hasn't deployed AI agents yet. This architecture prepares for that possibility now, so future agents can operate within the same scoped identity model rather than requiring the account structure to be redesigned later.
Extending the pattern to AI agents.
AI agents introduce a new consideration because they may be capable of initiating or completing tasks across enterprise systems. The proposed principle is simple: Where an AI agent requires its own access, give it a dedicated identity with explicitly scoped permissions rather than allowing it to rely on a broad shared account. The same identity principles used elsewhere in the architecture can then apply:
Dedicated identity — identify the agent or agent function clearly.
Least privilege — give it only the access required for its defined task.
Time-bound access — avoid unnecessary standing access.
Human approval — require approval before actions with material impact, such as creating identities or changing access.
Auditability — correlate actions with the request or workflow that initiated them.
Revocation — provide a way to remove the agent's access without disrupting unrelated identities or integrations.
These are not claims that Activate governs AI behaviour. They are identity and operational controls that can help organisations establish safer foundations for automation involving AI.
Why this works with existing identity operations.
Activate already separates a request from its fulfilment. In simple terms:
Something requests a change → rules and approvals are applied → approved work is executed → activity is recorded.
That model is already used for identity operations involving people, applications and service accounts.
If an AI agent is introduced in future, it can participate within that controlled operating model rather than automatically receiving broad, standing access to downstream systems.
For example, an agent might submit a request or perform an automation step within an already-approved workflow.
The objective is not to give AI more access. It's to make sure any access it receives is deliberate, scoped and auditable.
A practical migration path
1
Understand what exists
Catalogue service accounts, app registrations and connectors, and establish what each currently has access to. Start with accounts carrying the broadest permissions.
2
Design and test scoped identities
Create dedicated identities in UAT, configure the relevant connectors and test both successful and unsuccessful scenarios before making production changes.
3
Move to production carefully
Create production identities after UAT sign-off, test in parallel where practical and maintain a defined rollback point.
4
Add stronger privileged-access controls and AI readiness.
Once the scoped model is stable, evaluate Activate's PAM capability or the organisation's existing enterprise PAM tooling, for just-in-time elevation.The same identity principles can then be applied if AI agents are introduced later.
Designed for real enterprise environments.
Each phase needs a defined rollback strategy. If changing a scoped account causes a connector or workflow to fail, the affected integration can return to its previous identity while the issue is investigated.
End-to-end testing should confirm critical processes such as Active Directory provisioning, mailbox creation and group membership before cutover is considered complete.
High availability, failover and disaster recovery also need to be considered as part of the migration rather than treated as separate workstreams.
Security improvements only work operationally if the identity services themselves remain available and recoverable.
Why this pattern matters beyond one government agency.
This architecture was developed for a specific government environment, but the underlying problem is common. Enterprise identity environments grow incrementally. Systems are added. Integrations accumulate. Service accounts gain additional responsibilities. Processes that were once straightforward become interconnected. Eventually, organisations can find themselves with too much identity responsibility concentrated in too few accounts and too much operational work crossing too many systems.
The answer isn't necessarily another platform replacement. Often, it's a more disciplined operating model:
one purpose → one identity → scoped access → controlled workflow → clear audit trail.
That improves today's identity operations while creating a stronger foundation for whatever comes next — including AI-enabled automation.
Working through a similar mix of legacy service accounts, ITSM transition, and AI governance planning? Learn more about enterprise identity operations or explore Activate Identity Operations solution.