Identidad de IA: inicio de sesión humano y acceso del agente

Dejas de tomar identidad prestada y empiezas a emitirla · construido dirigiendo a un agente, una especificación a la vez

Imagina a tu Digital FTE trabajando a las 2 a. m. mientras duermes. Registra un gasto, reserva un proveedor, envía una respuesta. Una pregunta decide si eso es seguro o un desastre esperando ocurrir: ¿de quién era la identidad que usó?

En los cursos Connector-Native Apps y Plugins for AI Agents, tu app simplemente tomaba prestada la identidad de quien ejecutaba el host. Eso está bien mientras hay una persona en la silla. Pero un worker que corre cuando no hay ningún humano en la silla no puede tomar prestado el login de una persona, porque si inicia sesión como tú, es tú: puede hacer todo lo que tú puedes hacer, para siempre, y cada log dice que lo hiciste tú. No hay forma de acotarlo, ponerle vencimiento ni retirarlo.

Este curso es donde la identidad deja de ser prestada. La construyes en dos mitades. Primero posees tu sign-in: en lugar de alquilar un login de terceros, levantas tu propia autenticación production-grade y un servidor OAuth/OIDC que emite tokens reales. Luego le das a un agente identidad propia: una credencial acotada, temporal, revocable y aprobada por una persona, para que un worker pueda hacer trabajo real en nombre de alguien sin hacerse pasar nunca por esa persona.

Al final habrás enviado una app en ejecución (un proyecto real de Next.js en tu propia máquina) que, en orden, será:

• tu propio inicio de sesión con correo electrónico y contraseña, con sesiones reales y un dashboard protegido;
• un emisor OAuth/OIDC que emite tokens firmados y publica sus claves (JWKS) para que cualquiera pueda verificarlas;
• una segunda app separada que inicia sesión de personas mediante tu emisor sin guardar ninguno de tus secretos;
• un servidor de recursos que verifica esos tokens sin conexión y acepta solo pulseras emitidas para él;
• y una credencial beta de agente: una pulsera acotada, temporal, revocable y aprobada por una persona, que un worker de IA lleva con su propio nombre.

Prerrequisito: Spec-Driven Development

Este es un curso de construcción, y asume que ya dominas el loop spec-driven: acuerdas el qué y luego diriges a un agente para producir el cómo. A diferencia del curso SDD, la herramienta principal aquí no es claude.ai. Este curso es repo-based: trabajas en Claude Code u OpenCode sobre una app Next.js real. No escribirás TypeScript a mano; diriges a un agente general y él escribe el código, la misma jugada que en cada curso de construcción del track Manufacturing. Pero este también es un curso de seguridad, así que el código es solo la mitad del trabajo: lo que sigue siendo tuyo es especificar qué se construye y luego inspeccionar, probar y demostrar que cada propiedad de seguridad se cumple. Eso es lo que entrenan los prompts de entender sin especificación a lo largo del curso: decodificar un token, alterar su audience, reproducirlo y ver cómo el servidor lo rechaza.

📚 Ayuda didáctica

Abre la presentación completa

Ver presentación completa — Identidad de IA: inicio de sesión humano y acceso del agente

La pregunta única que responde este curso

Cada sistema que construyas después de esto lo puedes sostener frente a una prueba:

¿De quién es esta identidad y cómo pasa la autoridad de un humano a un agente?

Esa pregunta es la columna vertebral. Las herramientas concretas seguirán cambiando mientras se asientan los estándares de identidad de agentes. La pregunta no.

Una imagen: el local y la pulsera

La identidad suena abstracta hasta que la mapeas a una salida nocturna. Mantén esta sola imagen en la cabeza y cada pieza del curso encaja.

Llegas a un local. En la puerta, alguien revisa tu identificación una vez: eso es iniciar sesión, demostrar quién eres. No te hacen mostrar la identificación otra vez en cada barra dentro. En cambio, una cabina te imprime una pulsera. La pulsera prueba que tienes permiso para entrar; vence cuando cierra el local, y un guardia puede cortarla si te portas mal. Dentro, el bartender solo mira tu pulsera y te atiende. La pulsera tiene un sello que solo la cabina puede hacer, así que el bartender confía en ella a simple vista, sin llamar a la cabina para preguntar.

Ese es todo el stack de identidad, con un término para cada parte de la escena:

Un modelo, usado en todas partes: la puerta es el sign-in, la cabina es el issuer, la pulsera es el token, el bartender es el validator. En la frontera, el agente deja de tomar tu pulsera prestada y obtiene una propia, a veces sellada para actuar por una persona bajo límites estrictos.

Observa la parte que hace funcionar los tokens: el bartender nunca llama a la cabina. El sello de la pulsera basta. En sistemas reales, ese sello es una firma criptográfica; la cabina publica la clave que cualquiera necesita para verificar una firma, pero guarda la clave necesaria para hacer una. Por eso una app extraña puede confiar en tus tokens sin tocar nunca tu base de datos ni tus secretos.

Tokens y sesiones, desde cero

Tres palabras recorren el resto de este curso. Aquí está cada una, en términos simples, sobre la imagen que ya tienes.

Una sesión es la forma en que el servidor recuerda que iniciaste sesión. Después de que la puerta revisa tu identificación, coloca una pequeña marca en tu navegador, una cookie, y la lee en cada solicitud posterior, para que no tengas que iniciar sesión de nuevo en cada página. La sesión es el local sabiendo que entraste esta noche.

Un token es la pulsera misma: una afirmación firmada de quién eres y qué puedes hacer. El tipo común es un JWT (JSON Web Token), tres partes unidas por puntos: header.payload.signature. El payload lleva las claims; la signature es el sello de la cabina.

Esta es la imagen que debes conservar para el resto del curso. La cabina firma una pulsera presionando su propio sello de cera sobre ella. El cuño que hace ese sello, la clave privada de la cabina, se queda encerrado dentro de la cabina y nunca sale, así que nadie más puede copiar la marca. Para que el mundo pueda revisar el sello, la cabina pega una foto clara en la pared junto a la puerta, la clave publicada (pública). Cualquiera puede sostener una pulsera junto a la foto y confirmar que el sello es genuino, pero no puede tallar un cuño funcional a partir de una foto. Ese es todo el truco: la foto deja que un extraño verifique una pulsera sin poder falsificar una, que es exactamente lo que el bartender confía a simple vista.

OAuth (con OIDC encima para llevar quién es la persona) es el protocolo acordado para el apretón de manos donde la cabina imprime una pulsera para otra app: una app envía a una persona a iniciar sesión, tu servidor devuelve un token y la otra app lo lee.

Pruébalo

Toma cualquier JWT (tu propia app emitirá uno en unos minutos, o pega un ejemplo) y pídele a tu agente: "Decode this JWT. Show me the header and payload as plain JSON, explain what each claim means, and tell me which part anyone can verify with a public key and which part proves it was not tampered with." Leer su respuesta es una comprobación intuitiva más rápida que releer esta sección.

Configura tu entorno (una vez)

Todo lo que construyes sucede dentro de una carpeta pequeña: la base del curso. Es deliberadamente ligera: trae la constitución, las specs, los prompts y una skill, y todavía no hay app. Tu primer movimiento es dirigir al agente para que construya una; eso mismo es la primera repetición del loop que usarás durante todo el curso.

Descárgala una vez; la misma carpeta sirve para todo el curso.

Download ai-identity-base.zip

O clona el repo agentfactory-manufacturing y abre su carpeta ai-identity. En ambos casos, abre la carpeta en tu agente:

cd ai-identity
claude

cd ai-identity
opencode

También necesitarás una base de datos Neon Postgres gratuita para los datos de sign-in (sin tarjeta; la base la cablea por ti). Configúrala antes del segundo prompt de abajo.

Lesson 0 viene en dos prompts, para que veas el suelo probado antes de construir cualquier cosa sobre él.

Paso 1, probar el entorno. Pega:

Read specs/00-set-up-the-base/spec.md (Phase 1) and the "Set up the base" section of AGENTS.md. Check my prerequisites (Node, pnpm), install the skills it lists (Better Auth, shadcn, Neon), and confirm the MCP servers in .mcp.json and opencode.json are present and reachable. Don't scaffold anything yet. Just prove the ground and run the Phase 1 acceptance checks.

Vigila: npx skills add puede soltar silenciosamente el nombre de una skill, así que el agente confirma que cada una realmente aterrizó. Terminado cuando: Node y pnpm reportan versiones, las skills better-auth, shadcn y neon-postgres están presentes, y los tres MCP servers responden.

Qué acaba de pasar: contrataste al personal entrenado y conectaste los teléfonos, pero todavía no construiste nada. Las skills son los manuales del operador de la cabina (cómo emitir una pulsera, cómo construir la UI); los MCP servers son las líneas directas del agente al cuarto de control de Neon y a la documentación viva. El suelo está probado; nada está parado encima todavía.

Paso 2, scaffold de la app. Primero provisiona tu base de datos Neon y luego pega:

Now do Phase 2 of specs/00-set-up-the-base/spec.md: scaffold the Next.js + Tailwind + shadcn app here, pin the Better Auth 1.7 stack with the kysely override, add the Neon driver, and create .env from the template. Don't build any auth. Start the dev server and show me the landing page is up, then run the Phase 2 acceptance checks.

Vigila: create-next-app se niega a hacer scaffold en un directorio no vacío, así que la receta de la base scaffold en un directorio temporal y fusiona el resultado de vuelta (los archivos base ganan cualquier conflicto). Terminado cuando: pnpm dev sirve una landing page simple en http://localhost:3000, y pnpm build y tsc corren limpios.

Qué acaba de pasar: ahora el edificio existe. El dev server muestra un local vacío con las luces encendidas, una app real arrancando en tu máquina, pero todavía sin puerta, cabina ni pulseras. Tienes un lugar donde poner el sistema de identidad, que es exactamente lo que Lesson 1 empieza a construir.

Quick Win: estar signed in en tu propia app

Con la base lista, estás a un prompt de una pantalla de sign-in que tú posees, respaldada por una base de datos real. Primero logra el éxito; luego entiéndelo.

Antes de pegar, nombra las cuatro piezas que esto construye, todas en la misma imagen. Email and password sign-in es la puerta revisando una identificación que configuras la primera vez que llegas. Una sesión es el local recordando que entraste esta noche, conservada por esa cookie de antes, para que no muestres identificación en cada página. Una protected route es una sala trasera a la que solo pueden entrar miembros signed-in. Y un password hash es la huella unidireccional que la puerta guarda en lugar de tu contraseña real, para que ni el local pueda leerla de vuelta.

Lesson 1, posee tu sign-in. Pega:

Read specs/01-own-your-sign-in/spec.md and the better-auth-best-practices and email-and-password-best-practices skills. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, including the security ones, before you call it done.

Revisas el plan, el agente construye, y creas una cuenta para aterrizar en un dashboard que prueba quién eres. Esa es tu victoria: sign-up, sign-in, sesiones y una página protegida, todo corriendo en tu propio servidor.

Vigila: los endpoints POST de Better Auth rechazan cualquier request cuyo header Origin no sea confiable, así que la config de la base lista tu origen de desarrollo desde el inicio. Terminado cuando: creas una cuenta y aterrizas en un dashboard que muestra tu nombre y email, y tu contraseña se almacena solo como hash unidireccional, lo que el prompt de understand de abajo prueba.

Ahora hazlo real para ti con un prompt de understand, que no tiene spec; solo te hace ver lo que construiste:

I just signed up. Show me exactly what got stored in the database for my account, and point out what is NOT there. Where is my password, and why can't you show it to me?

La respuesta (tu contraseña está almacenada solo como hash unidireccional, así que ni tu propio servidor puede leerla de vuelta) es la primera pieza de alfabetización en identidad que construye este curso. No la leíste en un párrafo. La viste en tus propios datos.

El build path: de alquilar login a emitirlo

El curso es una columna de siete pasos que mapean uno a uno con las specs de la base. Construyes cada uno pegando un prompt corto; la spec lleva el detalle y la skill lleva la API exacta, así que la prosa se mantiene en la idea. Este es todo el arco, y dónde deja de ser terreno asentado.

La columna de siete pasos, luego el milestone y después la frontera. Cuanto más a la derecha vas, más jóvenes son los estándares; el modelo mental se mantiene igual todo el camino.

0–1. Configura la base y luego posee tu sign-in

Ya los viste en el Quick Win. El paso 0 scaffolds la toolchain (Next.js, shadcn, el stack Better Auth 1.7, Neon). El paso 1 levanta email and password sign-in con sesiones reales del lado servidor y un dashboard protegido. Esta es la puerta: tus usuarios prueban quiénes son, una vez.

2. Convertirte en el issuer (el marquee)

Este es el paso al que apuntaba todo el track. En Connector-Native Apps eras el bartender: tu gateway validaba tokens que alguien más había firmado. Aquí entras detrás del mostrador y te conviertes en la cabina. Cuando otra app envía a una persona a iniciar sesión contigo, tu servidor devuelve un token firmado que la otra app puede verificar por completo por su cuenta, comparándolo con la foto de tu sello que publicas, sin ver nunca una contraseña ni llamar a tu base de datos.

Ese es el cierre del loop: el curso donde solo revisabas pulseras ahora te enseña a imprimirlas.

Antes de pegar esto, conoce el handshake que tu cabina está a punto de correr. Cuando un OAuth client (otro local que acepta honrar tus pulseras) envía a una persona a iniciar sesión, no devuelves la pulsera por su navegador. Ejecutas el authorization-code flow: la persona inicia sesión en tu cabina, tú le das a la app un code de vida corta (un talón de reclamación), y la app intercambia silenciosamente ese talón por el token real fuera de la vista, para que la pulsera misma nunca viaje por el navegador. PKCE es la prueba de una línea de que la misma app que inició el handshake es la que lo termina, así que un talón robado no sirve a nadie más. Y antes de imprimir cualquier pulsera, la persona aprueba qué puede ver la app en una pantalla de consent. (La foto de tu sello en la pared, de antes, es lo que permite que esa app verifique la pulsera una vez que la tiene.)

Es el mismo loop de plan-build-check del Quick Win, solo que apuntado a un objetivo mucho más grande. Nada nuevo sobre cómo trabajas; solo algo más pesado de construir. Cuando estés listo, pega:

Read specs/02-become-the-issuer/spec.md and the agent-identity-issuer skill. Plan it, show me the plan, then build it in small steps. Build the token verifier as a separate script so the checks are real, and run all the acceptance criteria, especially the adversarial ones.

No escribirás a mano la configuración OAuth. La skill agent-identity-issuer enviada con la base lleva la config verificada, y la spec lleva los acceptance checks. Tu trabajo es dirigir la construcción y confirmar que pasa, incluidas las compuertas de seguridad que una versión funcional pero insegura fallaría.

Lo construiste; ahora mira que sea seguro de verdad. Ninguno de los prompts de abajo tiene spec. Cada uno hace visible una propiedad de seguridad de tu propio issuer, una a la vez.

Primero, mira la foto en la pared. Tu JWKS endpoint es exactamente esa pared: la foto pública del sello de tu cabina, publicada para que cualquiera revise una pulsera contra ella. El cuño que presiona el sello, tu private signing key, se queda encerrado en la cabina y nunca aparece en esa foto.

Fetch my JWKS endpoint and show me what's there. Is my private signing key in it? Prove it, and explain why a stranger can verify my tokens but can't forge one.

Ese hueco es todo el punto: publica solo la foto, nunca el cuño, y el mundo puede verificar tus pulseras mientras nadie puede falsificar una.

Luego, lee una pulsera que acabas de imprimir y rómpela cambiando un solo carácter:

Take an ID token you just issued, decode it, and walk me through every claim, iss, aud, sub, exp, in plain English. Then change the aud by one character and show me the verifier rejecting it.

Por último, empuja una pulsera más allá de la hora de cierre:

Issue a token, then move the clock past its expiry and try to use it. Show me the exact rejection.

Qué acaba de pasar: caminaste detrás del mostrador. El curso que te enseñó a mirar pulseras ahora te enseña a imprimirlas, selladas para que una app extraña pueda confiar en cada una a simple vista sin llamar jamás a tu cabina, y viste cómo el sello, el sello de audiencia y el vencimiento se sostienen.

3. Scopes y consentimiento

Un token debería decir exactamente qué puede hacer, nada más. El paso 3 agrega un scope (lo que una pulsera tiene permitido hacer, como una pulsera de color sellada drinks only frente a drinks and kitchen) y una pantalla de consent donde la persona ve la lista exacta antes de aprobar. Least privilege hecho real: la pulsera lleva la autoridad más estrecha que hace el trabajo, y un bartender la revisa en cada orden, no solo una vez en la puerta.

Ya corriste este loop dos veces. Aquí va de nuevo, con exactamente una idea nueva, scope, encima del issuer que ya construiste. Pega:

Read specs/03-scopes-and-consent/spec.md and the agent-identity-issuer skill. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

Ahora prueba que el límite es real, no decoración. Cada prompt de abajo te hace ver que el scope se sostiene:

Primero, entrégate una pulsera estrecha e intenta sobrepasarla:

Issue me a token that has only notes.read. Now use it to try the write action and show me the exact refusal. Then explain in plain English why a token that signs fine can still be turned away here.

Luego mira la pantalla de aprobación que la persona realmente ve:

Walk me through the /consent screen for a client asking for notes.read and notes.write. Where do those two lines come from? Prove the screen can only show what the signed request actually asks for, not whatever it likes.

Por último, intenta tomar más autoridad de la que registraste:

Register a client for notes.read only, then have it ask for notes.write anyway. Show me the granted scope in the token it gets back and point out what is missing, and why.

Qué acaba de pasar: tus pulseras ahora vienen en colores. Cada una lleva la autoridad más estrecha que hace el trabajo, y la persona vio la lista exacta antes de que se imprimiera una sola pulsera.

4. Conecta una app real

Ahora prueba que la cabina funciona para alguien que no eres tú. Una client app es un local separado que inicia sesión de personas a través de ti sin compartir ninguno de tus secretos. Llama a tu issuer AuthCo y a la nueva app Notes. Cuando alguien inicia sesión en Notes, lo envía a la cabina de AuthCo, recibe una pulsera y revisa el sello de la pulsera por completo por su cuenta contra la foto que AuthCo publica en la pared. Notes nunca ve una contraseña y nunca toca tu base de datos.

Mismo ritmo, nuevo actor. Respira: no estás construyendo nada extraño, solo apuntando una segunda app separada a la cabina que ya posees. Pega:

Read specs/04-connect-a-real-app/spec.md and the agent-identity-issuer skill (the register-a-client and verify-a-token sections). Plan the approach against our constitution, show me the plan, then build it in small steps. Keep Notes a fully separate process. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

Ahora convéncete de que la separación es genuina. Cada prompt hace visible una parte:

Primero, prueba que Notes no guarda ninguno de tus secretos:

Show me everything Notes knows about AuthCo. Prove it has no copy of BETTER_AUTH_SECRET and no path into AuthCo's database, then explain how it can still verify my tokens.

La respuesta vuelve a ser la foto: Notes solo necesita la foto pública del sello de AuthCo para revisar una pulsera, nunca el cuño, así que puede verificar cada token sin guardar ningún secreto de AuthCo.

Luego rompe el sello de audiencia por un carácter:

Take a token Notes just verified and change its aud by one character. Show me Notes's verifier rejecting it, and explain why that one character is the whole point.

Por último, corta la pulsera desde la cabina y observa fallar la siguiente llamada:

Sign me in through Notes, then revoke the client at AuthCo. Make Notes's next call and show me it fails. Explain what "revocable" actually buys me here.

Qué acaba de pasar: un local que no controlas inició sesión de alguien a través de tu cabina y confió en la pulsera por su cuenta, sin guardar tus secretos. La cabina funciona para extraños, no solo para ti.

5. Conecta un resource server

Un resource server es una barra que solo revisa pulseras y nunca inicia sesión de nadie. Es exactamente el bartender que interpretaste en Connector-Native Apps, ahora parado en tu propio terreno. Toma un bearer token, lo que significa que quien tiene la pulsera simplemente la presenta y no muestra otra identificación, y lee el sello de audience de la pulsera, good at THIS bar, así que una pulsera emitida para otra barra se rechaza a simple vista. El sello aquí se hace con un signing algorithm específico (RS256), y una pulsera sellada de cualquier otra forma también se rechaza. Revisa cada sello contra la foto publicada de AuthCo y nunca llama a la cabina, que es exactamente lo que significa verificar offline vía JWKS en el prompt de construcción de abajo.

A estas alturas el loop debería sentirse familiar. Un actor más, la barra que solo revisa pulseras y atiende a la persona nombrada dentro. Pega:

Read specs/05-connect-a-resource-server/spec.md and the agent-identity-issuer skill (sections 1 and 3). Plan it, show me the plan, then build it in small steps. Configure AuthCo to sign RS256 tokens audience-bound to my API, stand up a tiny protected resource that verifies offline via JWKS, and run all the acceptance checks including the adversarial ones.

Prueba que la pulsera solo funciona donde debe. Cada prompt convierte una regla en algo visible:

Primero, pon lado a lado los dos tipos de pulsera:

Show me two tokens side by side: the ID token from the login flow (lesson 4) and the access token a resource server gets. Point at the aud on each and explain in plain English why they're different.

Luego presenta una pulsera sellada de la forma incorrecta:

Sign a token with EdDSA and present it to my RS256-only verifier. Show me the exact rejection, then explain why the issuer's signing algorithm has to match what the consumer expects.

Por último, apunta una pulsera válida a la barra incorrecta:

Change the audience on a valid token to a different API's URL and show my resource server refusing it, even though AuthCo's signature is genuine.

Qué acaba de pasar: levantaste el bartender de Connector-Native Apps en tu propio terreno. Revisa cada pulsera, sirve solo a la persona nombrada dentro y rechaza cualquier pulsera emitida para otra barra o sellada de forma incorrecta.

6. Identidad de cliente con CIMD (el edge)

Los pasos 0 a 5 son terreno asentado y production-grade. El paso 6 se sale de él. Hasta ahora una app probaba quién era mediante client registration: ganaba un lugar en tu lista preaprobada de partners, avalada de antemano. Con CIMD (Client ID Metadata Document), la app salta la lista. Cuelga un letrero público en una URL que la describe, y tu cabina lee ese letrero bajo demanda la primera vez que aparece la app, sin preregistro. Hacia allí se mueve el mundo MCP, pero corre sobre un plugin prerelease de Better Auth y un estándar draft de IETF, así que el curso te hace confirmar la API viva antes de construir.

Este es el único lugar donde consultas antes de construir, porque el suelo es más nuevo. Ve despacio; el prompt mismo pide al agente revisar primero la documentación viva, que es exactamente el instinto correcto ante un estándar en movimiento. Pega:

Read specs/06-client-identity-with-cimd/spec.md and section 2 of the agent-identity-issuer skill. Before writing anything, query the live Better Auth docs MCP at https://mcp.better-auth.com/mcp and show me the current @better-auth/cimd API, whether I add cimd() or pass cimdClientDiscovery() to oauthProvider, and the exact discovery key. Then plan it, show me the plan, move us to the Better Auth 1.7 pre-release channel, and build it in small steps. Run the acceptance checks including the adversarial ones.

Luego mira qué activó realmente ese cambio. Cada prompt hace visible el nuevo comportamiento:

Primero, mira aparecer la nueva línea en tu letrero público:

Show me my discovery document before and after this change, and point at the one new line that tells a client "you can identify yourself by URL." Explain in plain English what that flips on.

Luego observa a la cabina leer un letrero en lugar de una lista:

Walk me through what happens when a client hands you an HTTPS URL as its client_id: what do you fetch, what do you read in that document, and how is that different from looking up a row in my database?

Por último, dale un letrero malo y observa el rechazo:

Hand my issuer a client_id that is a plain http:// URL, and one with a #fragment on the end. Show me each one being refused, and explain why the draft insists on a clean HTTPS URL.

Qué acaba de pasar: una app se presentó colgando un letrero público en vez de esperar en tu lista de invitados. Hacia allí se mueve el mundo de agentes, y lo construiste sobre un suelo que puedes ver moverse.

El milestone de ~50%: tu primer proyecto dirigido por ti

Después de la columna, el curso deja de darte pasos totalmente especificados y verificados en vivo, y empieza a darte proyectos que diriges tú mismo. El primero es la marca de mitad de camino, y se mantiene en terreno firme.

🔐Project 12-3 hoursEndurece tu sign-inEl login funciona. Ahora hazlo difícil de robar y fácil de usar.

Ya posees un sign-in funcional. Un sign-in funcional también es un objetivo: una contraseña filtrada y alguien entra. Así que subes la exigencia desde ambos lados, con las specs estables 2fa y social-login de la base.

Dos ideas nuevas sostienen esto. Un segundo factor es una segunda prueba además de la contraseña: tu portero también revisa un código que solo tu teléfono puede mostrar, así que una identificación copiada ya no basta para entrar. Un social login es solo una segunda puerta, una entrada Continue with Google que aterriza en la misma membresía dentro.

Read specs/projects/2fa/spec.md and specs/projects/social-login/spec.md. Plan both, show me the plan, then build them in small steps. Harden the sign-in you already own with a second factor, and add a "Continue with Google" door. Run every acceptance check, including the adversarial security ones.

Terminado cuando una contraseña correcta con un segundo factor incorrecto se rechaza, un backup code funciona exactamente una vez, "Continue with Google" aterriza en el mismo dashboard que un usuario de email y contraseña, y ningún secreto aparece jamás en el cuerpo de una respuesta o en un log.

Qué acaba de pasar: tu puerta ahora pide dos pruebas y abre desde dos lados, y una contraseña robada por sí sola ya no deja entrar a nadie.

La frontera: identidad para agentes

Ahora la segunda mitad, y la razón de existir del curso. Hasta ahora cada token representó a un humano: iniciaste sesión, recibiste una pulsera, apps y gateways confiaron en ella. Pero el camino de Manufacturing trata sobre agentes que actúan por su cuenta. Entonces la pregunta cambia: cuando un agente hace algo, ¿de quién es la pulsera que lleva? Si solo reutiliza tu login, los logs dicen que tú lo hiciste, puede hacer todo lo que tú puedes hacer, y no puedes revocar al agente sin dejarte fuera a ti mismo. Esa es la respuesta incorrecta, y corregirla es toda la frontera.

Esta es la misma imagen, contada como problema y solución:

Misma imagen, problema y solución: hoy cada agente usa una copia de tu única pulsera maestra, así que el guardia no puede distinguirlos ni cortar solo una. Con agent auth, cada agente corre bajo un host confiable y usa su propia pulsera; el servidor lee exactamente quién actúa y corta una sin tocar las demás.

Ese es el porqué. El cómo es un flujo corto que cada agente ejecuta para obtener su pulsera y usarla:

Estos tres pasos corren sobre el plugin @better-auth/agent-auth de Better Auth, que está en beta, una implementación del Agent Auth Protocol. El encuadre honesto, mantenido al frente: trata la API específica como una instancia intercambiable de primitivas duraderas y fija la versión sobre la que aterrices. Lo que no se mueve es la imagen, así que consérvala: el agente está a punto de recibir su propia pulsera.

No empiezas desde cero. La base trae un worked example verificado para los tres pasos de abajo (la clave de respuestas en worked-examples/ai-identity/), y cada paso es una spec que tú diriges, el mismo loop que ya corriste seis veces.

El agente obtiene una pulsera propia

Hasta ahora tú fuiste el invitado. Aquí entra un nuevo invitado: un agente de IA. El primer instinto es sujetarlo a tu pulsera, pero ese es exactamente el problema de impersonation. En cambio, el agente obtiene su propia pulsera, a su propio nombre, la pulsera agent #7 de la imagen.

Tres cosas lo hacen distinto de un sign-in humano, y son toda la idea. Primero, el agente no llega solo; corre dentro de un host, un runtime o dispositivo que el local ya confía, y el host avala al agente. Segundo, la pulsera es self-sealed y short-lived: el agente firma su propia pulsera con su propia clave, y la pulsera vale aproximadamente un minuto, así que una pulsera copiada se vuelve vieja casi en cuanto se filtra (muy distinta de un bearer token largo sentado en un archivo de configuración). Tercero, lo que la pulsera deja hacer al agente es una lista de capabilities nombradas, la versión de scope del agente. Ya corriste este loop antes; aquí va de nuevo, apuntado a una nueva clase de invitado:

Read specs/projects/agent-credential/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable autonomous agent identity, register an agent under a host, have it self-sign its own short-lived credential, and execute a granted capability. Run every acceptance check, including replay and revocation.

Ahora haz visible la idea nueva. Primero, mira de quién es el nombre en la pulsera:

Register an autonomous agent and show me the credential it gets. Whose identity is the sub, a person's or the agent's own? Explain in plain English why the agent having its own band is different from it reusing my login.

Luego prueba que la pulsera short-lived y self-sealed resiste el robo:

Take my agent's credential and replay the exact same signed band twice. Show me the second call being refused. Explain what the one-time marker is doing and why a band good for only a minute is safer than a long-lived token.

Qué acaba de pasar: el agente dejó de tomar prestada tu pulsera y obtuvo una propia. Los logs ahora dicen que el agente lo hizo, la pulsera está a nombre del agente y solo lleva las capabilities que se le otorgaron.

On-behalf-of: una pulsera sellada

Esta es la credencial que más vale la pena acertar. Un agente rara vez actúa solo por sí mismo; normalmente actúa por una persona, y el atajo peligroso es dejar que se convierta en esa persona. On-behalf-of es la versión honesta: la pulsera nombra a ambas partes, agent #7, acting for Alice, así que la acción siempre se atribuye al par agent-for-Alice, nunca solo a Alice. Esa es la pulsera sellada de la imagen: for Alice, drinks only, void at midnight.

La parte que la hace segura es human approval in the loop. El agente no puede mint esa pulsera para sí mismo. La pide, y Alice recibe un prompt (un device-code flow, el mismo patrón que iniciar sesión en una TV con tu cuenta de streaming) y dice sí antes de que exista cualquier autoridad. Sin aprobación, no hay pulsera. Y como Alice es la fuente de la autoridad, puede retirarla: revocas, y la siguiente llamada del agente falla. Pega:

Read specs/projects/on-behalf-of/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable delegated mode, have an agent request a scoped capability, gate it behind human device-code approval, and only then let it act. Run every acceptance check, including no-approval-no-grant and revocation.

Luego observa que la compuerta humana realmente sostiene. Primero, detente antes de aprobar:

Have my agent request the right to act for me, then stop before I approve. Show me that it has nothing yet, no band, no access. Explain why "human in the loop" means the approval is the thing that mints the authority, not a formality after it.

Luego prueba que es delegación, no impersonation:

Approve the grant, then show me the band. Point out where it says both the agent and that it is acting on behalf of me. Explain why that pairing matters for an audit trail.

Qué acaba de pasar: el agente ahora puede actuar por ti, pero solo después de que dijiste sí, solo dentro de lo que aprobaste y solo hasta que lo revoques. Usa una pulsera sellada, nunca tu pulsera.

Aprieta la pulsera: scope, valor y huella para lo peligroso

La pulsera sellada ya dice drinks only. Este paso hace que los límites sean tan estrechos como merece la acción, con tres ideas que van más allá de lo que puede decir un simple string de scope.

Una capability es la acción nombrada (el agente puede share a note). Una value-constraint la estrecha a valores permitidos, no solo encendido o apagado: no "may share notes", sino "may share notes only with @acme.com." Un string de scope no puede expresar eso; una constraint sí, y el servidor la revisa en el momento en que el agente actúa, así que un share a @evil.com se rechaza aunque la capability esté encendida. Y step-up approval escala la compuerta humana al radio de daño: una lectura se auto-grants, un share necesita un humano con sesión iniciada, y una acción irreversible (delete everything) necesita presencia física, una huella o passkey, para que un agente de IA que casualmente tiene navegador no pueda hacer clic en approve para su propia destrucción. Es el over $50 needs Alice de la imagen, salvo que la acción realmente peligrosa necesita la huella de Alice, no solo su sí. Pega:

Read specs/projects/step-up-approval/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: three capabilities across the approval ladder (auto, session, physical-presence), one with a required value-constraint, and a single-use grant. Run every acceptance check, including the adversarial ones.

Ahora prueba que cada límite muerde. Primero, la value-constraint:

Give my agent the right to share notes, but only with @acme.com. Then have it try to share with @evil.com and show me exactly where the server refuses it. Explain why a value-constraint is stronger than an on-or-off scope.

Luego la compuerta step-up sobre la acción peligrosa:

Try to approve the "delete everything" capability for my agent with just my logged-in session. Show me the server demanding physical presence instead of granting it, and explain what that step-up protects against when the agent itself has a browser.

Qué acaba de pasar: la pulsera del agente ahora es tan estrecha como el trabajo: acotada a una capability, fijada a valores permitidos y con una compuerta más dura cuanto más peligrosa es la acción, con las irreversibles encerradas detrás de la huella de una persona.

Una nota sobre madurez: por qué esto es honesto, no hype

El curso te enseña a anclarte en las primitivas duraderas, las partes que se mantienen ciertas mientras las herramientas cambian: sign-in verificado, credencial propia del agente, delegación on-behalf-of, scope de privilegio mínimo y aprobación humana. Luego habla claramente de qué tan asentada está cada capa:

• La stable spine es production-grade hoy. Sign-in, issuer, scopes and consent, conectar una app real y el resource server corren sobre el stack maduro y open source Better Auth. Toda la spine, más CIMD, fue verificada en vivo sobre la línea 1.7, y el gateway de Connector-Native Apps aceptó tokens firmados por este mismo issuer. La primera mitad es algo que puedes ship.
• CIMD es el edge. Funciona, está fijado y probado, pero vive sobre un prerelease de Better Auth y un estándar draft de IETF. Espera movimiento; vuelve a confirmar la API antes de construir.
• La identidad de agentes es la frontera. Darle a un agente autoridad propia, limitada, revocable y on-behalf-of es la dirección de la industria. Anthropic lo señaló con human-agent teams, y Better Auth tiene un plugin temprano de Agent Auth, pero los estándares son jóvenes y siguen asentándose.

Ese corte es el punto de anclarte en primitivas. Cuando lleguen los estándares, el modelo mental ya encajará: una credencial sigue siendo una pulsera, scope sigue siendo lo que la pulsera te deja hacer, expiry sigue siendo la hora de cierre y human approval sigue siendo la persona en la cabina diciendo sí.

A dónde lleva esto

Ahora tienes el hilo conductor de toda la capa de identidad. Sostén cualquier sistema frente a una pregunta, de quién es esta identidad y cómo pasa la autoridad de un humano a un agente, y puedes leerlo: encuentra la puerta, la cabina, la pulsera y el bartender; luego pregunta si el agente está tomando prestada la pulsera de un humano o cargando una propia.

Esta es la capa de credenciales bajo el resto del camino de Manufacturing. A continuación, Build AI Agents le da a ese agente su loop, el razonamiento y las herramientas que deciden qué hacer con la autoridad que acabas de aprender a otorgar. Y en Human-Agent Teams pones esa identidad a trabajar, ejecutando un roster de agentes junto a personas, cada uno con una pulsera propia y solo la autoridad que recibió.

Dejaste de tomar identidad prestada. De aquí en adelante, la emites.

Ayuda de estudio con flashcards

---

Pon a prueba tu comprensión

Checking access...