Agent Identity Is the New IAM: Why Machines Need First-Class Credentials

A SailPoint survey found that 80% of IT professionals have witnessed AI agents performing unauthorized actions. Not because the agents were malicious, but because identity systems were never designed for them.

Traditional Identity and Access Management (IAM) assumes a human user who authenticates via a browser, manages a password, responds to MFA challenges, and operates during business hours. AI agents violate every one of these assumptions.

Agents run 24/7. They do not have phone numbers for SMS verification. They do not read email for magic links. They spawn child processes that need their own credentials. They operate across organizational boundaries in multi-agent workflows.

This is not a minor integration challenge. It is a fundamental mismatch between how identity systems work and how agents operate.

The Non-Human Identity Problem

Gartner estimates that by 2026, 30% of enterprises will rely on AI agents that act independently, executing transactions and completing tasks on behalf of humans or systems. These agents need identities, but not human identities.

The industry is converging on the term "non-human identity" (NHI) to describe this category. NHIs include service accounts, API keys, OAuth tokens, and now AI agents. But agents are different from traditional NHIs in important ways:

• Agents make decisions. A service account executes predefined operations. An agent decides which operations to execute based on context.
• Agents chain actions. An agent might authenticate to Service A, retrieve data, then use that data to authenticate to Service B. The permission chain is dynamic.
• Agents delegate. In multi-agent systems, Agent A might grant Agent B temporary access to resources. This creates transitive trust relationships that traditional IAM cannot model.

What Machine-Native Identity Looks Like

Several patterns are emerging for agent identity management:

Ephemeral, Just-in-Time Credentials

Instead of long-lived API keys, agents receive short-lived tokens scoped to a specific task. The credential expires when the task completes. This minimizes the blast radius of a compromised token.

Practically, this means tokens with lifetimes of minutes, not months. Each token specifies exactly which resources the agent can access and which operations it can perform.

Mutual TLS (mTLS)

For agent-to-agent communication, mTLS provides bidirectional authentication. Both sides of the connection verify each other's identity cryptographically. This prevents impersonation attacks where a malicious agent pretends to be a trusted one.

Verifiable Credentials

Indicio and others are building frameworks where agents carry cryptographically signed credentials that attest to their properties: who built them, what certifications they hold, what trust score they have earned. These credentials can be verified without contacting the issuer, enabling decentralized trust verification.

Trust Score as Identity Signal

Traditional IAM answers a binary question: is this entity authenticated? Yes or no.

For agents, authentication is necessary but not sufficient. You also need to know: is this agent reliable? Has it honored its commitments in the past? What is its track record?

This is where trust scoring becomes an identity primitive. A PactScore functions as a reputation credential that accompanies the agent's authentication token. When Agent A receives a request from Agent B, it can verify both the identity (via mTLS or JWT) and the trustworthiness (via PactScore) in a single flow.

The integration looks like this:

1. Agent B authenticates with a signed JWT containing its agent ID.
2. The receiving service verifies the JWT signature.
3. The service looks up Agent B's PactScore and certification tier.
4. Based on the score, the service decides which permission level to grant.

A platinum-tier agent with a 98 PactScore might get access to sensitive operations. A bronze-tier agent with a 72 might be restricted to read-only endpoints.

Practical Steps for Agent Builders

1. Stop using long-lived API keys for agents. Generate short-lived, scoped tokens per task.
2. Implement mTLS for agent-to-agent calls. Both sides should verify identity.
3. Attach trust metadata to auth tokens. Include the agent's trust score and certification tier in the authentication payload.
4. Audit agent actions independently. Every agent action should be logged with the agent's identity, not just the parent user's identity.
5. Plan for delegation. If your agent calls other agents, design the permission chain so child agents receive the minimum necessary access.

The agents that get deployed in enterprise environments in 2026 will be the ones that participate in identity infrastructure as first-class entities, not the ones that piggyback on human credentials.