AI Agent Identity: A Manageable Risk

We are entering an era where software is no longer just code that executes instructions; it is code that observes, decides, and acts. AI agents are evolving from simple conversational assistants to operational entities capable of querying data, calling APIs, creating tickets, changing configurations, executing playbooks, and interacting with internal applications. In many cases, they perform these tasks without continuous human intervention.

When an agent can act, it possesses power. With power comes the need for a defined identity.

Why CISOs and CTOs Should Care

Traditionally, Identity and Access Management (IAM) has been designed for humans. However, Non-Human Identities (such as services, workloads, bots, integrations, and now agents) are rapidly increasing in volume and privilege. Industry research shows that machine identities now often outnumber human identities, primarily driven by cloud adoption and automation.

This shift changes the landscape for three key reasons:

1. Scale: Manual management becomes unfeasible as these identities proliferate.
2. Persistence: Agents and integrations operate around the clock—mistakes or compromises do not rest.
3. Default Superpowers: To maintain speed, we often grant broad permissions and long-lived tokens, which we may forget about.

The fundamental risk question remains: when an agent acts, can we unequivocally prove its identity, the permissions it used, the context in which it operated, and the approvals it received?

The Thesis

AI agent identity must be viewed as a controllable, manageable, auditable risk, akin to privileged users, service accounts, and critical workloads. This is not a distant concept; it represents basic governance applied to a new category of actor.

What “Agent Identity” Means in Practice

An enterprise AI agent typically comprises four components:

1. A “brain” (model and instructions)
2. Memory and data (history, context, knowledge bases)
3. Tools (APIs, RPA, scripts, cloud consoles, ITSM, SOAR, CI/CD)
4. Credentials (tokens, keys, certificates, delegated sessions)

Risk arises when credentials and access lack a clear owner, established boundaries, short validity periods, and comprehensive audit trails.

Failures in Treating Agents Like Applications

Many organizations have encountered issues with service accounts, such as:

• Embedded credentials in code or pipelines.
• Shared keys across multiple automations.
• Accumulation of permissions over time, often adding “just one more permission” as a quick fix.
• No inventory or lifecycle management.
• Logs that lack sufficient detail for proper attribution.

Now, consider the addition of autonomy and decision-making—this expands the attack surface and often renders it invisible.

The Starting Point: Zero Trust for Agents

Zero Trust is based on a simple principle: never trust implicitly, always verify, enforce the least privilege, and continuously evaluate context. Agentic AI compels us to take this seriously and respond to three fundamental questions that any auditor or regulator would pose:

1. Who is the agent? (It should have a unique, non-shared, verifiable identity)
2. What can it do? (It should operate under least privilege and within explicit boundaries)
3. How do we prove what it did? (We must have end-to-end telemetry and auditability)

If you cannot provide evidence-based answers, you lack proper governance—you’re relying on hope.

Practical Control: What an “Auditable Identity” Looks Like for Agents

Here’s a control framework that distinguishes between a mere “interesting pilot” and a “secure, scalable capability”:

• Inventory and Ownership: Each agent should be registered as a non-human identity, with both a technical and business owner. Classify them based on criticality, the systems they can access, the data they can read, and the actions they can execute.
• Strong Authentication and Short-Lived Credentials: Prefer workload identity patterns (certificates, OIDC, mTLS) and short-lived tokens over static keys. Implement automated rotation, vaulting, and mitigate secrets in code.
• Policy-Based Authorization: Avoid ad hoc permissions. Apply real least privilege—agents should only be able to execute what is strictly necessary. Ensure that separation of duties is maintained; reading access should not imply permission to make changes. Adopt attribute or policy-based controls when relevant, where access depends on context (e.g., environment, risk, time).
• Operational Boundaries and Guardrails: Create an allowlist of tools and endpoints that agents can access. Set action limits (such as rate limits and maximum values) and require human approval for irreversible or high-impact actions.
• Audit and Traceability: Ensure logs connect requests, agent decisions, tool calls, and outcomes. Implement correlation identifiers for each run and maintain evidence preservation. Set up alerts for abnormal behavior (like unusual access patterns, new tool usage, or privilege escalation).
• Lifecycle Hygiene: Establish formal processes for provisioning and deprovisioning agents. Conduct periodic access reviews similar to those for privileged accounts. Define procedures for quickly revoking sessions and tokens during emergencies.
•  

A Key Point: GenAI App security does not replace IAM

There are specific risks associated with GenAI, such as prompt injection and data exfiltration through tools. However, even with strong prompt-level security, if an agent holds excessive privileges and long-lived credentials, the potential damage is significant.

How to start without a twelve-month program

If I had to suggest a practical starting plan for Chief Information Security Officers (CISOs) and Chief Technology Officers (CTOs), it would be as follows:

Week 1: Inventory all agents and automations that have access to critical systems.

Week 2: Map out credentials, identify where static secrets exist, and assign ownership for each.

Week 3: Reduce privileges and replace long-lived credentials with short-lived authentication methods.

Week 4: Enable end-to-end auditability and establish approval controls for critical actions.

This approach is straightforward enough to initiate and significant enough to mitigate real risks.

Conclusion

AI agents will proliferate, and trying to combat that tendency is futile. What truly matters is preventing them from becoming invisible privileged users.

By treating agent identity as a controllable, manageable, and auditable risk, you can confidently scale automation, pass audits, and protect your business without hindering innovation.

If your organization already has agents in production or is close to implementing them, the question is not whether you need identity governance, but rather when you will implement it.