You've spent years building OAuth flows, SPIFFE identities, and OIDC federation. Now, AI agents are spinning up in production, and your first instinct is to treat them as a new problem needing new standards. That's mistake number one.
The AIMS framework draft, now at version -03 and shaping discussions at IETF 126 in Vienna, argues that agents are workloads. They need identifiers, credentials, authentication, and authorization, issues the identity community solved years ago. Yet teams keep making the same integration mistakes, not because the standards don't fit, but because they're assembling the pieces wrong.
Why These Mistakes Keep Happening
The gap isn't in the standards. It's in the assembly. When you see "AI agent," you might file it under "new technology" instead of "workload with a unique risk profile." This categorization error leads to architectural decisions that ignore mature, deployed specifications in favor of reinvention.
Agents do have dynamic action surfaces, cross-domain operations by default, and high churn. But these differences don't require new protocols; they require careful composition of existing ones.
Mistake 1: Treating Agent Identity as a Greenfield Problem
Why it happens: Every working group at IETF 124 in Montreal viewed agent identity through their own lens. WIMSE focused on workload identity, OAuth teams extended grants, and SPIFFE was already handling service mesh. The instinct to start fresh is strong when faced with something that feels novel.
The consequence: You end up reinventing token formats, credential lifecycles, and basic workload identity concepts that already exist in production at scale. Your team spends months building what OAuth 2.0, SPIFFE, and WIMSE already provide.
The fix: Start with WIMSE identifiers (a superset of SPIFFE IDs) as your foundation. Use WIMSE credentials, X.509 certificates and Workload Identity Tokens, or SPIFFE JWT-SVIDs for cryptographic proof. Provision via SPIFFE for general cases, with platform-specific mechanisms depending on where the agent runs. OpenAI, Anthropic, and Snowflake have all shipped Workload Identity Federation endpoints using OIDC and SPIFFE-style credentials. The pattern works.
Mistake 2: Using Static API Keys for Agent Authentication
Why it happens: API keys are quick to implement. Your LLM provider gives you one, your tool APIs expect one, and suddenly you've got a dozen keys scattered across agent configurations. It's the path of least resistance.
The consequence: An agent with unbound credentials is a privileged insider with no audit trail. Static keys don't rotate, don't expire on agent termination, and create a high-value target that broadcasts your attack surface. When an agent instance spins down after three minutes, that key is still valid.
The fix: Map WIMSE credential mechanisms to your authentication layer. Use mTLS at transport, HTTP Message Signatures, or WIMSE Proof Tokens at the application layer. Avoid pre-shared credentials entirely. The AIMS model explicitly calls this out as an anti-pattern. If your agent needs to authenticate to an LLM, a tool, or another agent, it should present a cryptographically bound credential that proves ownership of its identifier, not a static string copied from a dashboard.
Mistake 3: Skipping Delegated Authorization for User-Acting Agents
Why it happens: Your agent acts on behalf of a user, but implementing OAuth's Authorization Code Flow feels like overkill. You hardcode the user's access token or give the agent a service account with broad permissions instead.
The consequence: You've eliminated the user's ability to control what the agent does. When the agent calls an API, the API sees the agent's identity, not the user's intent. You can't scope access, can't revoke mid-session, and can't audit which user authorized which action.
The fix: Use OAuth for delegated authorization. Authorization Code Flow for user-delegated workflows, client credentials for autonomous agents. Use token exchange for scope management and authorization details. For multi-domain workflows, identity chaining via ID-JAG lets you cross trust boundaries without requiring every authorization server to trust every other one directly. The draft-klrc-aiagent-auth specification maps these existing OAuth specs to specific agent use cases.
Mistake 4: Ignoring Mid-Execution Authorization Changes
Why it happens: You authorize the agent once at startup. The agent runs for hours, making tool calls based on reasoning that happens at inference time. You assume the initial authorization covers everything.
The consequence: Risk evaluation changes. The agent's posture shifts. A user revokes access. But your agent keeps running with stale authorization, calling tools it should no longer reach. By the time you notice, the damage is done.
The fix: Implement continuous access evaluation using Shared Signals Framework (SSF) and Continuous Access Evaluation Protocol (CAEP). When authorization needs to change mid-session, propagate that signal. The WISE (Workload Identity Security Events) draft profiles SSF for workload identity lifecycle events: Vault Rotation, trust revocation, posture changes. For human-in-the-loop approval during execution, the OAuth Transaction Authorization Challenge draft addresses the gap CIBA left: the protected resource issues a signed challenge when an operation requires additional authorization, the agent relays it to a client, which obtains approval and issues a transaction-scoped access token.
Mistake 5: Treating Cross-Domain Agent Workflows as Edge Cases
Why it happens: Your proof-of-concept runs in a single trust domain. The agent calls internal services, everything shares an identity provider, and it works fine. You ship it.
The consequence: The agent's first real task spans internal services, a third-party API, and another agent in a different domain. Suddenly you're doing manual token exchange, trusting foreign authorization servers directly, or worse, passing credentials across boundaries in ways that violate your security model.
The fix: Use Transaction Tokens for cross-domain workflows. The Transaction Token Authorization Grant Profile for OAuth defines how a Transaction Token scoped to one trust domain becomes an authorization grant for crossing a boundary. The Transaction Tokens for Agents draft extends this with agent-specific semantics: an act claim identifying the agent performing the action, and an agentic_ctx claim for operational constraints relevant to authorization and policy evaluation. This makes multi-agent, multi-domain workflows practical without direct trust between every authorization server.
Prevention Checklist
Before you deploy an agent identity system, verify:
- You're using WIMSE or SPIFFE identifiers, not inventing a new URI scheme
- Agent credentials are cryptographically bound (X.509, Workload Identity Tokens, JWT-SVIDs), not static API keys
- Authentication uses mTLS or HTTP Message Signatures, not pre-shared secrets
- Delegated authorization uses OAuth Authorization Code Flow for user-acting agents
- You've implemented SSF/CAEP for continuous access evaluation and mid-session revocation
- Cross-domain workflows use Transaction Tokens with authorization grant profiles
- Audit logs capture which agent acted, on whose behalf, with what authorization
- Policy evaluation can access agent context (
agentic_ctx) for runtime decisions
The standards exist. The protocols are mature. What's been missing is the map showing how they connect. That's what AIMS provides, and where the map shows gaps, the community is filling them with targeted specifications rather than competing stacks. You already have the pieces. Now assemble them correctly.
