A 90-Day Governance Plan for Service Accounts and AI Agents

When service accounts and AI agents spread faster than ownership, approvals, and revocation controls, the problem is not just security. It is operational risk, audit exposure, and preventable IT cost. The right response is not a broad transformation program. It is an identity governance plan that starts with visibility, containment, and accountable control over what already exists.

If governance is immature, your first objective is simple: stop unreviewed creation, build a minimum registry, assign an owner, triage the highest-risk identities, and prove you can revoke them safely. Everything else in the first 90 days serves that goal.

Start with containment, not cleanup

The first move is to slow identity sprawl without freezing production. Put a temporary change gate in place for every new non-human identity, including service accounts and AI agents. Require a business purpose, accountable owner, backup, target systems, privilege scope, risk tier, expiry or review date, logging plan, and documented revocation method before approval.

At the same time, stand up a minimum registry. A spreadsheet or existing IGA or CMDB is enough to begin. A partial inventory with explicit unknowns is more useful than waiting for perfect discovery. Record source, last seen, owner, status, and credential metadata. Do not delete an identity just because the first pass is incomplete.

Then publish an emergency revocation runbook before you attempt broad cleanup. If you cannot disable an identity, revoke tokens and keys, rotate replacements, preserve evidence, and validate downstream services, you are not ready to expand governance.

Build the minimum registry around ownership and evidence

A registry is not governance unless it can answer who owns the identity, why it exists, what it can reach, and how fast it can be revoked. That means treating identity, credential, entitlement, and owner as separate records.

For each record, capture the business purpose, owning team, technical operator, security approver, systems accessed, effective permissions, credential type, issue and expiry dates, last rotation, last use, lifecycle state, review date, and revocation method. For AI agents, also record tools, data sources, memory, delegation relationships, code-execution capability, and shutdown method.

This is where the first identity governance plan becomes operational. Without ownership and last-use evidence, the inventory is just a list. With both, it becomes the basis for decisions.

Use a simple three-column risk model

Start with a risk model that reflects blast radius and behavior, not just account labels. Score privilege or impact, data sensitivity, exposure, credential persistence, and autonomy or delegation. If an identity can create other identities, change security policy, access regulated data, execute code, or send data outside the organization, override the score to the highest tier.

Tier	Signals	Minimum treatment
Critical	IAM or security administration, credential creation, destructive production action, regulated or crown-jewel data, autonomous agent with external write, code execution, or delegation	Named owner and backup, explicit security approval, short-lived or dynamically issued credential where feasible, real-time alerting, monthly certification, tested emergency revocation, no shared or interactive login, exception expiry required
High	Sensitive write access, production operations, cross-environment or vendor access, static credential, untrusted input, agent tool use with material business effect	Owner and backup, least-privilege review, quarterly certification, rotation or replacement plan, centralized audit trail, anomaly alerts, revocation tested in the first 90 days
Standard	Bounded internal automation with limited data and no administrative or destructive authority	Owner, documented purpose and scope, certification every six months, expiry or review date, normal logging and lifecycle workflow
Low	Ephemeral, read-only, narrowly scoped identity with low-impact data and no external side effects	Automated issuance and expiry where possible, owner or owning team, annual review or event-driven review, basic audit evidence

For the first 90 days, treat unknown ownership, unknown credential location, and unknown effective permissions as high risk until resolved.

Days 0–7: declare the program and define the minimum record

The first week is about authority and baseline, not cleanup.

You should:

• Appoint an executive sponsor and a small working group across IAM, security operations, infrastructure, application owners, AI engineering, compliance, service desk, and change management.

• Define scope across service accounts, application principals, API credentials, certificates, SSH keys, CI/CD identities, database accounts, workload identities, automation identities, bots, and AI agents.

• Identify crown-jewel systems and high-impact operations.

• Publish the net-new identity change gate.

• Create the minimum registry schema and a clear status vocabulary.

• Write a one-page revocation runbook and name the responder roster.

• Capture the first baseline of discovered identities, registered identities, owner coverage, unknowns, privileged identities, static or shared credentials, expiry coverage, log coverage, and recent anomalies.

Day-7 deliverables should include signed scope, registry schema, emergency contacts, an initial list of critical candidates, and an exception template with reason, compensating control, approver, and expiry date.

Days 8–30: discover broadly and contain the highest risks

The first month should turn sprawl into an accountable inventory.

Pull identity data from directories, IGA systems, cloud IAM, secret managers, certificate stores, CI/CD platforms, code repositories, deployment manifests, schedulers, application and database logs, SaaS audit logs, CMDB records, vendor contracts, and AI platform inventories. Reconcile these sources. Do not rely on one export.

Then contact the probable owner for each important identity and ask for one decision: keep and certify, narrow, migrate, rotate, suspend for testing, or retire. If you cannot establish ownership, escalate to the application or platform owner. Do not leave a generic operations mailbox as the permanent accountability anchor.

Common dispositions are straightforward:

• Orphaned identities should be assigned or quarantined.

• Dormant identities should be validated against disaster recovery and batch dependencies before disablement.

• Duplicate identities should be reduced to a canonical identity.

• Shared identities should be replaced with attributable workload identities where possible.

• Overprivileged identities should have unused permissions removed.

• Embedded or exposed credentials should be treated as compromised.

• No-expiry identities should get a tier and an immediate review date.

For critical and high-risk identities, apply immediate controls. Remove broad permissions where safe. Disable interactive login when possible. Move static secrets into an approved secret-management system. Set an expiry or review date. Enable logging for the highest-risk systems. Require an owner decision on effective permissions. For AI agents, restrict tools and data access before adding autonomy.

By day 30, the CIO should be able to see discovered versus registered identities, orphaned backlog, high-risk identities without expiry, systems without useful logs, and whether the first revocation test worked.

Days 31–60: enforce least privilege and pilot reviews

The second month is where the registry becomes an operating control.

Use the strongest portable credential model the system supports. Prefer dynamically issued short-lived workload credentials, then federated or token-exchange credentials with narrow scope, then vaulted static credentials with minimum privilege and controlled rotation. Reserve legacy exceptions for systems that cannot do better, and document the blast radius, compensating controls, review date, and migration plan.

For planned rotation, create the replacement, deploy and test it, observe successful use, then revoke the old credential. For suspected compromise, do not wait for expiry. Revoke immediately, rotate, remove exposed copies, and investigate historical use.

Run the first access-review pilot on one critical production chain and one representative legacy or vendor integration. Review effective permissions, last-use evidence, credential age, anomalies, dependencies, and proposed right-sizing. Require an explicit decision for each entitlement: approve, remove, narrow, suspend for testing, or escalate.

For AI agents, keep read, write, delete, code execution, external communication, and credential-management tools separate. Every high-impact action should require approval or a deterministic policy gate outside the model. The agent may recommend, but it should not authorize itself.

By day 60, you should have at least one completed certification record, at least one successful credential replacement, alert visibility for privileged or out-of-scope use, and a tested stop path for an agent or service account.

Days 61–90: automate the lifecycle and prove revocation

The final month is about repeatability and proof.

Automate request, approval, creation, owner assignment, entitlement grant, credential issuance, expiry, review, suspension, revocation, retirement, and evidence retention. Connect the registry to the systems that can actually create or disable identities. A dashboard that cannot change access is not automation.

Expand reviews by risk and event. Trigger reviews when ownership changes, applications retire, privileges change, compromise is suspected, agents change tools or version, vendors change, or data classifications change. Preserve the original effective-permission evidence, the decision, and the remediation result.

Then run a tabletop and a controlled technical drill for at least one service account and one AI agent. Test the ability to identify the identity, preserve logs and traces, disable the identity, revoke tokens and keys, stop the workload or tools, deploy a replacement if continuity is required, validate service health, and restore only after containment and approval.

A kill switch should be layered. Disable the identity. Revoke the current credentials. Deny its tools and resources. Stop the workload or orchestration. Block re-registration if needed. A single disabled account is not enough if another credential or child agent can continue the action.

What success looks like at day 90

Day 90 should not feel like a finished program. It should feel like a working control plane.

The executive dashboard should separate discovered, registered, owned, reviewed, remediated, unknown, orphaned, dormant, and exception identities. Critical and high-risk records should have current owners, backup, purpose, effective scope, tier, credential location, expiry or review date, log source, and revocation method. Net-new identity registration should be part of normal change and onboarding workflows. The next backlog should be ranked by blast radius, not by which connector is easiest to build.

That is the practical value of an identity governance plan in an immature environment. It gives you a way to decide, evidence, and revoke before the sprawl becomes institutionalized.

Where a platform can help without replacing accountability

A modern IGA platform can reduce the manual load by providing the registry, connectors, review workflow, risk view, evidence, and lifecycle automation. Citadel Identity360 is one example of that kind of platform. It is designed to govern human, machine, and AI identities across cloud, SaaS, on-premises, and hybrid environments, with lifecycle automation, access reviews, identity risk analytics, RBAC, SoD controls, dashboards, and integrations.

But no platform removes the need to define owners, risk appetite, approval rules, acceptable agent actions, business dependencies, and emergency authority. The organization still has to make the governance decisions.

FAQ

Are service accounts, machine identities, and AI agents the same thing?

No. Service accounts are accounts or principals used by software. Machine identities are tied to devices or infrastructure. AI agents are autonomous software actors with tool or decision authority. They can overlap, but they should be recorded separately.

How often should service-account credentials be rotated?

There is no universal interval. Prefer short-lived dynamic credentials and automatic renewal. For static critical or high-risk credentials, a 90-day maximum is a reasonable starting policy, with shorter periods where risk warrants it. Rotate immediately after suspected exposure.

Can an AI agent use a person’s access?

Only through explicit, narrow, time-bounded delegation. Keep a separate agent identity and record the initiating human, token scope, approval, tool, and outcome in the audit trace. Do not hand an agent a broad administrator session.

What should we do with an ownerless account that might still be needed?

Treat it as high risk until ownership and scope are verified. Identify dependencies from logs and deployment records, assign a temporary owner, restrict or rotate the credential where safe, and schedule a controlled disablement test before deletion.

How do we revoke an identity without breaking production?

Use a tested runbook. Preserve evidence, identify dependencies, disable or deny the identity, revoke tokens and keys, deploy a replacement if continuity is required, remove exposed copies, validate the service, and restore only after containment and approval.

If you are formalizing this work across a broader estate, an IGA platform can help turn the plan into a repeatable operating model. The key is to start with accountable visibility, then automate only after the organization can prove ownership, scope, and revocation.