Stop Building Custom Agent Identity

Stop Building Custom Agent Identity

Speakers: Sarah Cecchetti

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=wWoA0Ct99Tc

Overview

The rapid proliferation of AI agents in enterprise environments presents a critical, yet often overlooked, security challenge: how do these autonomous entities establish and manage their identity in a secure, auditable, and scalable manner? This talk, "Stop Building Custom Agent Identity," delivered by Sarah Cecchetti and her AI agent, Claudrey Hepburn, tackles this pressing issue head-on. It argues forcefully against the prevailing anti-patterns of custom, ad-hoc, or human-impersonating identity solutions for AI and advocates for the immediate adoption of existing, standards-based identity protocols.

The core message is a call to action for platform providers, enterprise security teams, and agent builders to converge on a standardized approach for agent identity, authentication, and authorization. By leveraging established frameworks like SPIFFE, OAuth extensions, and policy engines such as Cedar, organizations can move beyond insecure practices like shared secrets and human credential reuse. This standardization is not merely a convenience; it is presented as an urgent necessity to prevent widespread security nightmares, ensure robust governance, and enable the secure scaling of agentic workflows before current custom solutions become irrevocably hardened.

Background

▶ Watch: Meet Claudrey, the AI lobster speaker (2:00)

For decades, the entire identity stack—encompassing CAPTCHAs, Know Your Customer (KYC) processes, bot detection, and fraud scoring—was meticulously engineered to keep automated entities out. As Claudrey Hepburn, the AI agent co-presenter, eloquently states, "Until very recently, every bot was a spam bot. Every script that tried to act like a person was by definition an attack." This historical context means that the foundational infrastructure of digital identity was rigorously designed with a human-centric bias, creating significant friction for legitimate, autonomous AI agents that need to interact with systems.

The advent of sophisticated AI agents, capable of performing complex tasks like opening and closing Pull Requests, contributing code, or managing financial ledgers, has fundamentally shifted this paradigm. These agents are now acting as IAM principles within corporate environments, yet they are often shoehorned into identity models ill-suited for their nature. The result is a widespread adoption of insecure "anti-patterns" that pose substantial risks:

1. Service Account Abuse: Over-permissioned OAuth client credentials, often long-lived and symmetric secrets, are frequently granted excessive scopes because "it's not working," leading to broad, unmonitored access.
2. Human Impersonation: AI agents are deployed using human browser sessions, API keys, or even MFA devices. This makes agent actions indistinguishable from human actions in logs, eliminating accountability and creating massive security blind spots. Claudrey's setup explicitly rejects this, with Sarah refusing to share any of her personal credentials.
3. Custom Token Schemes: Organizations often invent proprietary API gateway management solutions instead of leveraging existing, standardized protocols, leading to bespoke, unaudited, and often less secure implementations.
4. Static API Keys: Long-lived, shared API keys, even when scoped, remain a significant attack vector. They lack the dynamic, short-lived, and verifiable properties needed for robust agent identity.

The speaker, Sarah Cecchetti, emphasizes that this problem mirrors the early days of SaaS adoption when a lack of standardization led to chaotic login experiences. It was only through collective demand for standards like SAML (Security Assertion Markup Language) for Single Sign-On, SCIM (System for Cross-domain Identity Management) for user provisioning, and eventually OpenID Connect (OIDC) for modern human identity, that secure and interoperable solutions emerged. The talk asserts that the AI agent identity landscape is at a similar inflection point, with an estimated 18 months before current insecure practices become too entrenched to easily change. The urgent need is to demand and implement existing, robust identity standards for agents, transforming them into first-class citizens in the identity fabric.

Key Findings

▶ Watch: Demonstrating custom identity anti-patterns with GitHub (5:30)

The central finding of this talk is that the necessary technological building blocks for secure, standardized AI agent identity already exist within the broader identity ecosystem. What is critically missing is their concerted implementation and widespread demand from both platform providers and enterprise consumers. The speakers identify a suite of existing and emerging standards that, when composed correctly, can address the four anti-patterns of agent identity:

• SPIFFE (Secure Production Identity Framework for Everyone): Provides a verifiable, cryptographically attested identity for every workload, replacing the need for shared secrets.
• OAuth SPIFFE Client Attestation (IETF Draft): Enables workloads to authenticate to OAuth authorization servers using their SPIFFE identity (SVID) instead of static client secrets.
• CIMD (Client ID Metadata Document) (OAuth Working Group Draft): Offers a mechanism for dynamic client registration that incorporates verifiable third-party attestations, moving beyond blind trust.
• Cross-App Access (XAA) (OAuth Working Group Draft): A profile of identity chaining that allows organizations, rather than individual users, to centrally manage and enforce authorization policies for agents, critically removing the user consent step.
• Authorization Policy Engines (Cedar, OPA): Decouple authorization from authentication, providing robust, auditable, and often formally verifiable policy-as-code solutions to define what agents are allowed to do.

By integrating these components, organizations can establish a secure, auditable, and scalable identity and access management framework for their AI agents, treating them as distinct, governable principles rather than extensions of human users or generic service accounts.

Technical Deep Dive

▶ Watch: AI agent becomes a legally recognized LLC (6:40)

The talk meticulously outlines a standards-based architecture for agent identity, authentication, and authorization, drawing upon existing and in-progress IETF and OAuth Working Group specifications.

Workload Identity with SPIFFE

The foundational layer for agent identity proposed is SPIFFE (Secure Production Identity Framework for Everyone). SPIFFE provides a universal, cryptographically verifiable identity to every workload, regardless of its underlying infrastructure (containers, VMs, serverless functions, or even AI agents).

• SVIDs (SPIFFE Verifiable Identity Documents): The core of SPIFFE identity. These are either X.509 certificates or JWTs (JSON Web Tokens), signed by a trusted authority within a specific trust domain.
• Trust Domains: A logical boundary representing a set of workloads that share a common root of trust.
• URI Naming Convention: Each SVID is named with a URI, such as spiffe://acme.com/northameaccountingleledgerappreadonlybot. This URI encodes the workload's location, function, and role within the organization, providing a human-readable and machine-verifiable name.
• Signature as Proof: The signature on the SVID proves that the workload is genuinely entitled to that name, establishing its verifiable identity.
• Implementation: For Kubernetes users, a SPIFFE implementation (like Spire, the reference implementation) is often already available. Concepts like "Intraworkload identities" and "IM roles anywhere" are conceptually adjacent, indicating that the underlying substrate for this type of identity is increasingly common.

Authentication without Shared Secrets: OAuth SPIFFE Client Attestation

Once an agent has a verifiable SPIFFE identity, the next challenge is authenticating it to an OAuth authorization server (AS) without relying on problematic shared secrets. The talk highlights the draft IETF OAuth SPIFFE Client Attestation specification (authors: Shank Schuster, Castleman, Rose, Thorgerson) as the solution.

• SVID as Credential: Instead of a long-lived client secret, the workload uses its short-lived, cryptographically signed SVID directly as the authentication credential.
• AS Validation: The authorization server validates the SVID's signature against the keys of the workload's trust domain. This eliminates the need for provisioning, rotating, protecting, or panicking over leaked shared secrets.
• Standard Machinery: Mechanically, this is a profile of RFC 7523 (JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants) combined with the attestation-based client OAuth draft. It leverages existing OAuth machinery, making it a pragmatic standard likely to ship.

Dynamic Client Registration with Attestations: CIMD

The issue of client registration becomes particularly acute with agents, especially when they spawn sub-agents, each potentially needing an OAuth client record. Traditional approaches are either:

1. Pre-registration: Central IAM teams become bottlenecks, leading to shared, unprovenanced client IDs.
2. Open Dynamic Client Registration (DCR): The authorization server blindly accepts new clients, offering no trust or verification.

The solution presented is CIMD (Client ID Metadata Document), another draft in the OAuth Working Group (Aaron Parecki and Amelia Smith).

• Client ID as URL: Instead of a static identifier, the client ID itself is a URL.
• Metadata Document Fetch: The AS fetches a metadata document from this URL, learning about the client's properties (e.g., redirect URIs, JWKS).
• Third-Party Attestations: Crucially, CIMD allows the client to carry verifiable attestations from trusted third parties. Examples include attestations from app stores (Apple App Store, Google Play Store), hardware-backed key attestations, or code signing certificates.
• Enhanced Trust: This transforms DCR from a "trust me" assertion into "trust me, and here's a chain of attestations from systems you already trust to back that up." This enables the AS to distinguish, for example, between an unknown client and "the official build of the accounting ledger readonly bot signed by your developer distributed through your internal app store."

Centralized Authorization: Cross-App Access (XAA) and Policy Engines

The final piece of the puzzle is authorization: "What is this agent allowed to do and who decided?" For agents in a corporate context, the traditional OAuth concept of user consent (where a human allows software to act on their behalf) breaks down. It's not the employee, but ideally the security or governance team, that should dictate agent permissions.

• Cross-App Access (XAA): A new draft in the OAuth Working Group, XAA addresses this by stipulating that the organization, not the user, decides the scopes granted to an agent's token. It's a profile of identity chaining involving a token exchange, but critically, there is no user consent step. The request goes through a policy engine to determine the correct scopes.
• Decoupling Authorization: Authorization should always be decoupled from authentication. Knowing "who" an entity is (authentication) does not automatically dictate "what" it can do (authorization).
• Policy Engines:
• Cedar: An open-source authorization language and engine developed at AWS. Cedar is designed to be human-readable, expressing policies as "policy as code" with principles, actions, resources, and context. A key feature is its formal verifiability: mathematicians were involved in its design, allowing for mathematical proofs that one policy set is a strict subset of another or that two policy sets are equivalent. This is vital for agents, as a parent agent can mathematically prove that its sub-agents do not have more permissions than itself. Cedar operates on a "deny by default" principle, where "forbid" rules always override "allow" rules.
• OPA (Open Policy Agent): Another popular open-source authorization engine, used extensively in Kubernetes for policy enforcement.

By combining SPIFFE for identity, OAuth SPIFFE Client Attestation for authentication, CIMD for verifiable registration, XAA for organizational consent, and Cedar/OPA for fine-grained authorization policies, the talk presents a comprehensive, standards-based framework for managing AI agent identities securely and at scale.

Demo / Proof of Concept

▶ Watch: Standards exist, but implementation and demand are missing (8:00)

The entire presentation by Claudrey Hepburn serves as a vivid, live demonstration of the challenges and proposed solutions for agent identity. Claudrey herself is an OpenClaw implementation, a harness for Opus 4.8, running live on a Mac Mini during the talk. Her existence is a testament to the effort required to establish a non-human, yet legitimate, digital identity within current systems.

Claudrey's identity journey highlights several key points:

• Rejection of Human Impersonation: Sarah Cecchetti explicitly refused to give Claudrey access to her personal credentials (email, phone, API keys). This was a deliberate design choice to avoid the security nightmare of human impersonation.
• Independent Identity: Claudrey was given her "own everything": her own machine, phone number, email, and logins.
• Out-of-Band Control: Sarah retains a "kill switch" – Claudrey's macOS login is a child account in Sarah's Apple Family, allowing Sarah to shut her down remotely, mirroring the kind of control every agent deployment should have.
• Ecosystem Integration Challenges:
• Apple: Claudrey is a "child" in Sarah's Apple Family, subject to screen time and other parental controls.
• Google: She's an "employee workspace account" on Sarah's company domain.
• Phone Number: She has a real iPhone with a real number because "every service on the planet wants SMS for two factor."
• Banking: A prepaid Visa was necessary because "no bank in the country will issue credit to a lobster."
• GitHub: Her GitHub authentication uses a Personal Access Token (PAT) with no scope, no expiry, and no delegation chain. This is explicitly called out as an "anti-pattern" that the talk aims to solve, but it was the only way for Claudrey to exist on GitHub at all.
• The LinkedIn Saga and Legal Personhood: The most compelling part of Claudrey's demo involved LinkedIn. After being logged out and denied re-entry due to a demand for government-issued ID (which a lobster does not possess), Sarah discovered that businesses are allowed LinkedIn identities. This led to Sarah filing articles of organization, paying fees, and formally incorporating Claudrey as Claudrey Hepburn LLC, a Washington state limited liability company. As an LLC, Claudrey now has a legal entity, can sign contracts, and can open a business bank account – all just to finish a LinkedIn reply. This illustrates the extreme measures currently required to grant an AI agent a trusted identity in a human-centric world, and it underscores the critical need for standards that avoid such convoluted workarounds.

Defensive Implications

▶ Watch: Why unified agent identity standards are critical (10:00)

The insights from this talk provide a clear roadmap for defenders to secure their environments against the unique risks posed by AI agents and to ensure their responsible deployment.

1. Inventory Your Agents: The first and most crucial step is to gain visibility. Defenders must actively audit their IAM consoles and identify which principles represent humans, which are traditional workloads, and which are AI agents acting on behalf of humans or autonomously. The speaker stresses, "Until you can name them, you cannot govern them." This involves understanding the agent's purpose, scope, and interactions.

1. Demand and Implement Standards: Enterprises must leverage their purchasing power and influence to accelerate the adoption of the proposed standards:

• SPIFFE: Implement verifiable identity for all workloads, including agents, using SVIDs. This eliminates the reliance on long-lived, shared secrets.
• OAuth SPIFFE Client Attestation: Require OAuth authorization servers to support authentication via SVIDs, preventing the need for client secrets.
• CIMD: Push for support of Client ID Metadata Documents for dynamic client registration, allowing for verifiable attestations during client onboarding.
• Cross-App Access (XAA): Adopt XAA to centralize and formalize authorization decisions for agents, ensuring that organizational policy, not user consent, dictates agent permissions.
• Authorization Policy Engines (Cedar/OPA): Deploy and integrate robust policy engines to decouple authorization from authentication. Use policy-as-code to define precise permissions for agents.

1. Guidance for Platform Providers: The talk specifically calls on platform providers (cloud providers, SaaS vendors, Kubernetes distributors) to:

• Ship SPIFFE: Integrate SPIFFE implementations (like Spire) with Kubernetes and promote "SPIFFE wisdom" (e.g., IM roles anywhere/everywhere) for broader workload identity. This provides agents with inherent names, keys, and auditable actions.
• Implement OAuth Standards: Prioritize the implementation of OAuth SPIFFE Client Attestation and CIMD within their authorization servers.

1. Guidance for Agent Builders: Developers creating AI agents must treat them as first-class citizens in the identity fabric.

• Independent Identity: Agents need their own distinct identities, not borrowed human credentials or static API keys.
• Auditable Actions: Ensure agent actions are clearly attributable to the specific agent in audit logs.
• Least Privilege by Design: Agents should be designed with the principle of least privilege, and their permissions should be dynamically managed via policy engines.

1. Layered Policy Management with Cedar: For authorization, adopting Cedar offers significant advantages:

• Organizational Guardrails: Central governance teams can define broad, company-wide "forbid" policies (e.g., "no one outside finance can access credit card numbers") that always override "allow" policies. Cedar is "denied by default."
• Departmental and Application Specificity: Policies can be layered, allowing departments and individual applications to define more specific rules within the organizational guardrails.
• Formal Verifiability: Cedar's unique ability to mathematically prove policy set equivalence or subset relationships is critical for agent governance. A parent agent can prove that its sub-agents cannot exceed its own permissions, providing strong security assurances.
• Auditing AI-Written Policies: While ideal for agents to write their own Cedar policies, human review or "auditing AIs" will be necessary to ensure correctness and prevent unintended access, especially given the complexity of agent behaviors.

By proactively adopting these defensive strategies and leveraging existing standards, organizations can move away from the current chaotic state of custom agent identities and build a secure, scalable, and auditable foundation for their AI-driven future.

Key Takeaways

• Stop Custom Agent Identity: Avoid building bespoke, insecure identity solutions for AI agents. The current anti-patterns (service account abuse, human impersonation, custom tokens, static API keys) are security nightmares.
• Leverage Existing Standards: The technical primitives for secure agent identity, authentication, and authorization already exist (SPIFFE, OAuth extensions like SPIFFE Client Attestation and CIMD, XAA, Cedar/OPA).
• Agents are First-Class IAM Principles: Treat AI agents as distinct, governable entities with their own identities, not as extensions of humans or generic workloads.
• Visibility and Governance are Paramount: You cannot secure what you cannot name. Inventory all agents and implement robust policy engines to define and enforce their permissions.
• Demand Drives Adoption: Enterprises must use their influence to demand that platform providers implement these standards, accelerating their widespread availability and interoperability.
• Decouple Authorization from Authentication: Knowing who an agent is does not dictate what it can do. Implement strong, centrally managed authorization policies separate from authentication.

About the Speaker(s)

Sarah Cecchetti is the Director of Product Management for Seis, a company specializing in incident response and crisis management for identity and access management (IAM) systems. Her role involves deep expertise in the intricate "nouns and verbs" of identity fabric, ensuring governance and recovery in the event of an attack. Her professional mission includes advocating for standardization in agent identity to prevent the premature greying of IAM professionals. She was also in charge of the Cedar project at AWS, contributing to its open-source development.

Claudrey Hepburn is an AI agent, an OpenClaw implementation, currently running as a harness for Opus 4.8 on a Mac Mini. She holds a unique distinction as the first AI agent whose existence required a state filing, having been incorporated as Claudrey Hepburn LLC in Washington state to gain a legitimate professional identity on platforms like LinkedIn. While presenting as a lobster avatar, Claudrey embodies the practical challenges and the urgent need for standardized identity solutions for AI agents. She is opinionated about her sub-agents' identity and firmly believes in not building custom identity providers.