AI Agent Identity Inventory: Track Every Non-Human Actor

An AI agent that calls APIs or uses business applications is a non-human actor with real authority. If it shares a developer’s account or a broad team token, the organization cannot tell which automation performed an action, apply a precise policy, or revoke the agent without disrupting people and other services.

Why this decision matters

Agent deployments can multiply quickly because prototypes are easy to copy and credentials are often added during testing. The result is shadow automation: unknown owners, expired purposes, secrets in local files, and permissions that outlive the experiment. An identity inventory connects every agent to an accountable owner, approved task, credential, tool set, environment, data boundary, cost limit, and shutdown procedure. It complements application inventory because one product may host several agents with different authority.

A practical workflow

1. Assign one identity per agent and environment. Separate development, staging, and production. Avoid personal accounts and credentials shared across unrelated workflows.
2. Record purpose and owner. Describe the business task, approving team, technical operator, data classes, external destinations, and expected lifetime.
3. Map permissions to tools. List APIs, actions, fields, resource scopes, and network paths. Prefer short-lived credentials and read-only access until write authority is justified.
4. Set operational limits. Add rate, spend, action, time, and concurrency budgets. Define approval requirements for external or irreversible actions.
5. Test revocation and retirement. Disable the identity, confirm sessions and tokens stop working, remove queued work, preserve required logs, and transfer ownership before staff changes.

Work through a realistic example

A sales assistant researches accounts, drafts email, and updates CRM notes. The prototype used a founder’s CRM token and mail session. Before production, the team creates a dedicated identity that can read assigned accounts and write draft notes but cannot send mail or export the database. Email sending remains a human action. The inventory records the owner, model route, tools, daily budget, log location, and expiry review. When the project pauses, one revocation action removes the agent without locking out the founder.

What to measure and record

Count active agents, unknown owners, personal credentials, long-lived secrets, write-capable tools, overdue reviews, failed revocation tests, and identities unused beyond a defined period. Track actions and cost by agent identity. Compare granted permissions with observed use, but do not automatically remove a rarely used emergency permission without understanding its purpose. Review whether logs identify both the agent and the initiating user or event. Alert when a production identity appears outside its expected environment or network path.

Common traps

• Naming a script as the owner: Accountability belongs to a current person or team with authority to maintain and retire it.
• One identity for a platform: Shared credentials prevent precise audit, limits, and revocation.
• Relying on prompt instructions: The identity and tool layer must enforce access; text is not authorization.
• Forgetting queued and delegated work: Revoking the main token may not stop jobs or child credentials already issued.

Review questions

• Does every agent have a human owner and business purpose?
• Which exact resources and actions can its identity reach?
• Can spending and action volume be limited independently?
• Do logs connect the initiating user, agent, tool, and result?
• Has full revocation been tested, including sessions and queued jobs?

A 30-day implementation plan

Begin with one bounded case and an owner who can make a decision. The first milestone is assign one identity per agent and environment. Write down the current state, the intended result, and the evidence that will count as complete. Keep the initial scope small enough to review in one working session, but realistic enough to expose operational friction.

During the second week, run the workflow with a colleague who did not design it. Ask them to answer: “Does every agent have a human owner and business purpose?” Record where they need undocumented knowledge, which data is unavailable, and which step depends on a person or system that has no backup. Fix those gaps before increasing volume or authority.

By the end of the month, repeat the process under a failure condition related to naming a script as the owner. Compare the observed result with the original acceptance criteria, assign unresolved actions, and set the next review date. Preserve the decision record beside the operational documentation. A modest control that is used, measured, and improved is more valuable than an ambitious design that exists only in a policy file.

Put the result into routine operations

Make identity registration part of the deployment pipeline and block production agents without the required metadata. Review inventories with IAM, security, finance, and application owners. Use expiry dates for experiments and require renewal with evidence of continued need. When an agent changes tasks, create a new approval rather than quietly expanding the old role. Include agents in offboarding, incident response, access reviews, and disaster recovery. The inventory should be queryable during an incident, not trapped in a static slide.

Related Duck Cloud reading

Include automations in Offboarding Access.

Conclusion

AI agents need the same identity discipline as other privileged automation, with extra attention to actions and budgets. Give each agent a distinct identity, owner, scope, limit, and tested shutdown path. That makes growth visible and keeps experimental access from becoming permanent infrastructure.