Reference Architecture
Scoped Identity and Privileged Access Management for AI-Ready Government Environments
A reference design for moving a government agency from broad, shared service accounts to a scoped, least-privilege identity model. Built to extend cleanly to AI agents as non-human identity governance without requiring rework later.
The problem this design addresses:
Large government environments accumulate integrations the way most enterprise environments do: incrementally, over many years, through multiple procurement and platform cycles. It's common to find a single Active Directory service account doing double or triple duty; authenticating connectors into HR platforms, directory services, ITSM tools, and device management systems that were integrated at different points in time.
This pattern is usually the result of pragmatic decisions made under time pressure, not poor practice. It works operationally, often for years. 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. It also complicates audit and compliance, since a single account performing multiple functions across services is harder to explain, scope, and provide clean evidence for than a set of narrowly-defined identities each tied to one purpose.
This reference architecture sets out a design Activate is proposing to a government agency currently mid-transition on its ITSM platform, evaluating how to reduce this risk without a platform rebuild — and how to do it in a way that's ready for AI agent adoption from day one, rather than needing to be redesigned when that adoption happens.
Proposed architecture: Scoped, least-privileged identity model. The core design principle is straightforward: each integration gets its own dedicated, named identity, scoped to only the permissions that integration requires. No shared accounts, no standing privilege beyond what's operationally necessary.
is the mechanism for this: managing privileged secondary accounts, service accounts, connector identities and administrator accounts through ownership assignment, approval workflows, time-bound access, credential control and audit — the same control pattern Activate has run in production since 2014, applied here to a tighter, more granular account structure.
Critically, this is not a platform rebuild. The design proposes reducing reliance on broad shared accounts and migrating toward the scoped, governed identity model Activate is already architected to support — with no material change to the staff-facing self-service request experience.
Activate’s existing PAM capability.
For this design, non-human identity spans three categories, all governed under one consistent model:
Service accounts — static AD, Exchange and SharePoint accounts used by connectors to read and write to target systems
Application and API identities — Entra ID app registrations, managed identities, and integration credentials, which already behave more like scoped identities than a general-purpose AD service account
Future: AI agents — any agent capable of initiating or completing a task inside Activate or a connected system (drafting a ticket, checking a connector, proposing an access change). No agents are in production in this environment today; this reference architecture sets the guardrails to apply before any agent is granted write access to a target system
Non-human identity scope.
Extending the model to identity agents. This is the forward-looking core of the reference architecture. The agency has not deployed AI agents into its environment yet, but the direction across the industry is clear enough that the account model should be built to accommodate agents now, rather than requiring a redesign later.
Core rule:
An agent is a non-human identity. It receives its own named identity — never a shared or borrowed one, and never running under a person's credentials or a generic service account.
Controls to apply before any agent is granted production access:
Distinct identity per agent or agent function — never one identity shared across multiple agents
Scoped permissions matching the exact task the agent performs, following the same least-privilege model applied to service accounts
Time-boxed sessions — an agent's access expires and requires re-authorisation rather than persisting indefinitely
A human approval gate for any action with material impact — creating an account, changing a permission, removing access
A full audit trail correlating each agent action to the request that triggered it, using the same job-log model Activate already applies to human and service-account activity
A kill switch — the ability to immediately revoke a single agent's access without affecting any other identity
Why this fits without rework:
Activate already separates request submission from fulfilment. A request is submitted, checked against approval rules, and only then actioned. An agent slots into this model as a submitter, or as an automation step inside an already-approved workflow — it does not require standing rights to the target system itself. This is the same broker pattern Activate already applies to human requests, extended to a non-human requester.
This reference architecture does not recommend deploying an AI agent into the environment now. It defines the governance model to apply when that decision is made, so the account structure built for service accounts today does not need to be reworked when agents arrive.
Proposed migration approach.
1
Inventory and gap approach
Catalogue every current service account, app registration and connector; confirm exact current permission levels, starting with the shared AD service account carrying the broadest scope
2
Design and build in UAT
Create scoped accounts in the non-production environment, reconfigure connectors to use them, and run functional, negative and regression testing before touching production
3
Controlled production cutover
Create production scoped accounts only after UAT sign-off, run a parallel test period where feasible, and cut over with a clearly defined rollback point
4
PAM and agent readiness
Once scoped accounts are stable in production, evaluate Activate's PAM module (or an enterprise PAM tool) for JIT elevation, and apply the agent governance model above to any planned agent work
Notes on the approach:
A defined rollback strategy accompanies each phase: if a scoped account change causes a connector or workflow failure in production, the affected connector reverts to its previous account or app registration, smoke tests confirm end-to-end execution (AD provisioning, mailbox creation, group membership), the security officer and project lead are notified, and the environment remains on the previous account until the root cause is resolved and a re-cutover can be planned.
High availability, failover, and disaster recovery planning are treated as part of the same workstream as the account separation migration, not a separate activity — since the security benefit of scoped accounts depends on the platform remaining available and recoverable throughout and after the transition.
Why this pattern generalises
This reference architecture responds to a specific engagement, but the underlying pattern — one over-privileged shared account concentrating risk across multiple integrations, discovered mid-way through an ITSM platform transition — is common across large, long-lived identity environments in both New Zealand and Australia, particularly in the public sector, where systems accumulate across long procurement cycles. The fix is rarely a platform replacement. It's disciplined, incremental scoping applied consistently: one integration, one identity, with the same governance model extended forward to cover AI agents before they arrive, rather than retrofitted once they already have standing access.
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.