Un permiso para un agente de IA debe indicar **quién hace la llamada, qué conexión utiliza, a qué recurso puede acceder, qué cambia la acción y quién confirma el cambio definitivo**. Un catálogo de herramientas le dice al agente qué comandos existen. El servidor aún tiene que decidir si esa persona puede ejecutar ese comando sobre ese objeto en ese momento, y la respuesta debe explicar qué ha ocurrido realmente.

La distinción importa cuando una sola interfaz permite descubrir miles de operaciones. El 28 de septiembre, Cloudflare presentó [`cf`, una CLI orientada a agentes](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) para su API. El anuncio facilita encontrar comandos; encontrarlos no da permiso para ejecutarlos. El [debate en Hacker News](https://news.ycombinator.com/item?id=49879577) muestra por qué el lanzamiento llamó la atención de los administradores de sistemas, pero sus comentarios son preguntas y opiniones, no una evaluación de seguridad de la CLI.

Para un producto SaaS, la respuesta útil es definir un contrato para cada acción con consecuencias. Las herramientas de Kit para Contratación, respuesta de seguridad y gestión de equipos ofrecen ejemplos concretos: sus verbos pueden parecerse, pero sus efectos son muy distintos. Se puede redactar una respuesta a un candidato sin enviarla. Se puede proponer una recompensa sin concederla. Otras llamadas autorizadas cambian el estado de inmediato. Son decisiones de producto que puedes inspeccionar y probar.

## ¿Qué cambió con el lanzamiento de `cf` de Cloudflare?

Según Cloudflare, su CLI `cf`, en beta abierta, ofrece comandos derivados de una API con **más de 3 000 operaciones**, frente a unas 280 rutas de comandos de Wrangler. Devuelve JSON de forma predeterminada y ofrece `cf cli search`, de modo que un agente puede encontrar el comando pertinente a partir de una descripción en lenguaje natural sin tener que cargar todo el catálogo en su contexto. Son cambios en el **descubrimiento y el diseño de la interfaz**, descritos en el [anuncio de Cloudflare](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) y en el [repositorio de `cf`](https://github.com/cloudflare/cf).

Cloudflare también afirma que los agentes representaron el 48 % del uso de Wrangler durante la semana anterior al anuncio, frente al 25 % de marzo de 2026. Es una medición de Cloudflare sobre el uso de Wrangler; el anuncio no publica el denominador ni el método. No es una tasa de adopción entre clientes.

Un agente puede buscar desde una consulta de lectura hasta un despliegue, un cambio en el WAF o la compra de un dominio desde una misma interfaz de comandos. Eso no le proporciona credenciales para todas esas acciones. La [documentación de tokens de API de Cloudflare](https://developers.cloudflare.com/fundamentals/api/how-to/create-via-api/) define políticas por recursos y grupos de permisos; su [referencia de permisos](https://developers.cloudflare.com/fundamentals/api/reference/permissions/) separa los permisos de lectura y escritura para recursos de usuario, cuenta y zona. Estos documentos explican los controles disponibles en la API. El anuncio no establece cómo funcionan la autenticación o la aprobación en cada llamada a `cf`.

Esta diferencia es fundamental para quien ofrece un catálogo amplio de herramientas: **que un comando se pueda encontrar no significa que esté autorizado**. Su descripción puede indicar al agente cómo solicitar una acción. Solo el sistema que ejecuta el comando puede decidir si quien llama tiene permiso para actuar sobre un objeto concreto en su estado actual. Cuanto más fácil sea encontrar comandos, más valioso será documentar esa decisión para cada uno.

## ¿Qué debe especificar un permiso para un agente de IA?

Un permiso eficaz para un agente de IA es un **contrato de recurso y acción**, no una simple etiqueta de «lectura» o «escritura». Antes de ofrecer una herramienta, documenta el permiso de la conexión, la identidad actual, cómo se localiza el objeto, las comprobaciones de estado, el efecto, quién confirma el cambio, quién recibe algo fuera del sistema, qué puede ver quien llama en la respuesta y cómo se deniega la operación.

Imagina una petición para «enviar una respuesta a este candidato». La conexión puede tener `hiring_write`, pero quizá el miembro del equipo solo tenga acceso a una oferta de empleo. La candidatura podría pertenecer a otra oferta, el plazo para responder podría haber terminado y la herramienta podría limitarse a crear un borrador. Cada cuestión cambia la respuesta a «¿puede hacerlo el agente?». En este caso hace falta un permiso amplio, pero no basta con él.

Empieza por estas seis preguntas:

1. **¿Quién actúa?** Identifica a la persona o identidad de servicio vinculada a la conexión. Comprueba su pertenencia y función actuales en la cuenta, no solo las que tenía cuando se creó la conexión.
2. **¿Qué se ha delegado?** Indica el ámbito de permisos de la conexión y la cuenta o módulo que abarca. Un token con permiso de escritura para un módulo no debe alcanzar otro módulo por sorpresa.
3. **¿A qué objeto se dirige?** Resuelve el identificador dentro de los objetos que esa persona puede ver. Una consulta a toda la cuenta puede seguir siendo demasiado amplia para una oferta restringida o un informe privado.
4. **¿Qué estado permite la acción?** Quien puede actualizar la ficha de un candidato quizá ya no pueda responderle cuando se cierra el flujo. Comprueba el estado en el momento de ejecutar la acción.
5. **¿Qué cambio se confirma?** Distingue entre una sugerencia, un borrador interno, un cambio directo en la base de datos, un mensaje a otra persona y un pago. El nombre de la herramienta no basta para expresar esa diferencia.
6. **¿Qué puede ver quien llama después?** La respuesta puede revelar recuentos, nombres o registros privados aunque la escritura estuviera permitida. Aplica también al resultado los límites de lectura de esa persona.

Estas preguntas permiten comprobar qué significa «requiere aprobación humana»: quién aprueba, en qué canal y qué endpoint exige esa aprobación.

## ¿Por qué el ámbito de la conexión es solo la primera comprobación?

El ámbito de una conexión limita las operaciones que un cliente puede solicitar. No determina si un miembro del equipo puede trabajar con **este registro concreto**. El servidor debe cruzar el permiso de la conexión con la pertenencia actual, la cuenta, la visibilidad del registro, las políticas y el estado del flujo.

La conexión MCP externa de Kit usa ámbitos OAuth como `hiring_read`, `hiring_write`, `csirt_read`, `csirt_write` y `team_write`. Su flujo de consentimiento limita los ámbitos solicitados a los que puede conceder el miembro actual de la cuenta. El ámbito básico `mcp`, por sí solo, no da acceso a ningún módulo del producto. En cada llamada, Kit vuelve a comprobar el ámbito del token y el acceso actual al módulo; ocultar una herramienta en la lista de descubrimiento solo facilita el uso de la interfaz. Un cliente aún puede enviar el nombre de una herramienta que nunca haya visto en esa lista. La [guía de Kit para conectar asistentes de IA](/docs/connecting-ai-assistants) explica el flujo de conexión para los usuarios.

En el caso de una candidatura, Kit busca entre las ofertas visibles para ese miembro y después aplica la política de la candidatura. Si el miembro no tiene acceso a una oferta restringida, la candidatura aparece como no encontrada; si puede ver el registro, la política puede denegarle la acción solicitada. Los informes de seguridad tienen una búsqueda comparable entre los informes visibles para el miembro, aunque cada acción tiene comprobaciones distintas de función y política. El contexto de la cuenta delimita el tenant; la búsqueda del objeto delimita el destino.

Esto permite una prueba negativa útil. Conecta como un miembro que no sea administrador y tenga `hiring_write` para todo el módulo. Pide a la herramienta que actualice una candidatura de una oferta restringida a la que ese miembro no tiene acceso. El resultado esperado es «no encontrado», sin revelar si la candidatura existe. Reduce después el acceso de ese miembro al módulo y repite la llamada con la misma conexión. Kit comprueba el acceso en cada llamada y respeta la función actual. Eso no borra información que el cliente ya haya recibido ni deshace acciones confirmadas antes.

Las [restricciones de tokens de API de Cloudflare](https://developers.cloudflare.com/fundamentals/api/how-to/restrict-tokens/) ilustran otra capa: los tokens pueden tener límites temporales y por dirección IP del cliente. Reducen el periodo o los lugares desde los que puede utilizarse una credencial. No sustituyen la política sobre recursos concretos de una aplicación SaaS situada detrás de la llamada a una herramienta.

## ¿Qué ocurre cuando un agente redacta una respuesta a un candidato?

El nombre `hiring_send_message` de Kit sugiere una acción hacia fuera. Su efecto real es más limitado: una llamada permitida **prepara un borrador de respuesta pendiente**, que un compañero revisa y envía desde el hilo de correo de la candidatura. La respuesta de la herramienta lo indica. El estado de borrador impuesto por el servidor, y no una instrucción que pida al modelo confirmar el texto, establece ese límite.

La llamada requiere un miembro vinculado a la cuenta con `hiring_write`, localiza la candidatura entre las ofertas visibles para ese miembro, comprueba que pueda actualizarla y verifica que el estado actual del hilo permita preparar una respuesta. Si se acepta, crea un borrador interno y devuelve un enlace al hilo. La acción de confirmación en la interfaz web es el momento en que se envía el correo al candidato.

Ese borrador sigue siendo importante. Puede incluir lenguaje sensible o engañoso e influir en quien pulse «Enviar» más tarde. Pero el resultado inmediato es **«borrador pendiente», no «candidato avisado»**. Una respuesta que dijera solo «Hecho» ocultaría el dato más importante del flujo.

Define el contrato como dos acciones: *preparar la respuesta* y *enviar la respuesta*. En la primera, el agente puede confirmar el cambio una vez superadas las comprobaciones del registro; el destinatario sigue siendo interno. En la segunda, el compañero confirma el envío en la interfaz web y el candidato pasa a ser el destinatario. Si eliges otro diseño de producto, descríbelo con la misma precisión. El ámbito de la conexión no indica por sí solo qué acción se ha producido.

La distinción también se aplica a una herramienta de CRM llamada `send_quote`: podría guardar un presupuesto para revisión, poner un correo en cola o enviarlo inmediatamente. Comprueba qué se ha guardado y qué se ha entregado antes de describir el efecto.

## ¿En qué se diferencia proponer una recompensa de concederla?

Las herramientas de respuesta de seguridad de Kit muestran por qué «escritura» es una categoría demasiado amplia. `csirt_propose_bounty` crea un **importe propuesto interno** en un informe visible para el miembro. No crea una recompensa concedida, un asiento en el libro mayor, una notificación al investigador ni un pago. Una propuesta posterior puede sustituir a la propuesta abierta y hacer que los votos anteriores caduquen. Es una escritura real, pero con un público y unas consecuencias limitados.

Los miembros del equipo pueden usar `csirt_vote_bounty_proposal` para registrar una postura consultiva. En el modo de votación a ciegas, la respuesta no debe filtrar el recuento oculto en su texto mientras lo esconde en los datos estructurados. También hay que comprobar la **visibilidad de la respuesta**: poder votar no da acceso automáticamente a los votos de todos.

`csirt_approve_bounty` exige acceso de administrador del módulo CSIRT y una conexión con `csirt_write`. Una llamada autorizada registra directamente en Kit la decisión de conceder la recompensa, sujeta a las reglas del informe. La descripción de la herramienta pide al asistente que confirme con el usuario el importe y el tipo, pero ese texto orienta al cliente; no es una segunda barrera aplicada por el servidor. La aprobación **no transfiere fondos**: el pago se realiza fuera de Kit.

Por eso, «una persona interviene en el proceso» necesita un significado preciso. En una propuesta, la decisión humana aún está pendiente. En la herramienta de aprobación, la llamada del administrador autorizado confirma la decisión definitiva en Kit. Si tu política exige una segunda aprobación para conceder una recompensa, impleméntala como una transición distinta en el servidor. Un «sí» en la conversación no puede sustituirla.

Compara el efecto que anuncia la descripción de la herramienta con el resultado. «Recompensa aprobada en Kit» deja aparte el estado del pago. La respuesta a una propuesta nunca debe dar a entender que se ha prometido dinero al investigador.

## ¿Cuándo debe gestionarse el acceso del equipo fuera del chat?

Cambiar el acceso de un compañero tiene consecuencias más allá de un solo flujo. Kit lo trata de forma distinta según el canal. En su **chat de IA integrado**, el adaptador bloquea las invitaciones al equipo, los cambios de acceso, la edición y revocación de invitaciones y la eliminación de miembros. En su lugar, dirige al usuario a los ajustes autenticados. Un «sí, lo apruebo» visible para el modelo en el chat no convierte el chat en un canal fiable para conceder acceso, especialmente si el modelo ha leído documentos aportados por candidatos.

La **vía MCP externa con OAuth tiene otro contrato**. Un administrador de la cuenta puede obtener `team_write` y usar `team_update_member_access` para cambiar directamente la función o los niveles de acceso a módulos de un miembro. La herramienta busca al miembro dentro de la cuenta e impide cambiar de función o rebajar el acceso del propietario. Según los datos recibidos, `team_invite_member` puede enviar una invitación o añadir a un usuario existente a una oferta, tras sus propias comprobaciones de administración y cuenta. Son acciones directas, no redirecciones a los ajustes.

Esta diferencia debe figurar en cualquier revisión de permisos. «El chat de Kit no puede cambiar el acceso del equipo» es correcto para el adaptador integrado. «Ningún agente puede cambiar el acceso del equipo» no lo es. Los clientes externos con un permiso autorizado pueden llegar a otra vía que confirma el cambio. Si tu producto tiene un asistente web, una API y un servidor remoto de herramientas, dedica una fila a cada canal que pueda ejecutar una acción con el mismo nombre.

El endpoint importa más que la promesa del modelo de preguntar primero. Una redirección a los ajustes impone un límite entre canales. Una herramienta externa de administración aplica un límite de función mediante su ámbito y sus comprobaciones de administrador. Ambos necesitan nombres más precisos que «aprobación».

## ¿Qué debe incluir tu lista de recursos y acciones?

Usa una fila por **efecto real**, aunque el producto reúna varios efectos bajo un verbo sencillo. Rellénala a partir del código y las pruebas, y compruébala con una llamada permitida y otra denegada. Esta es la versión resumida para seis acciones de Kit:

| Acción | Permiso e identidad | Límite de recurso y estado | Efecto y quién confirma el cambio | Límite que debe quedar claro |
| --- | --- | --- | --- | --- |
| Leer el resumen de una candidatura | `hiring_read`; miembro vinculado | Candidatura de una oferta visible | Devuelve datos y notas del candidato; no escribe nada | El resultado contiene datos sensibles de contratación. |
| Redactar una respuesta al candidato | `hiring_write`; miembro con permiso para actualizar la candidatura | Candidatura de una oferta visible; el estado permite preparar una respuesta | Borrador interno pendiente; un compañero lo envía desde la interfaz web | El candidato no ha recibido ningún correo. |
| Avanzar una candidatura | `hiring_write`; miembro con permiso para avanzar | Candidatura visible; etapa siguiente o elegida válida | La etapa cambia directamente; el flujo gestiona las notificaciones | Esta herramienta no exige otra aprobación. |
| Proponer una recompensa | `csirt_write`; miembro con acceso a CSIRT | Informe visible para el miembro; reglas del programa y del importe | La herramienta registra una propuesta interna | No hay recompensa concedida, notificación ni pago. |
| Aprobar una recompensa | `csirt_write`; administrador del módulo CSIRT | Informe del programa de la cuenta; reglas de concesión | La llamada autorizada registra la recompensa en Kit | No transfiere fondos; el texto de confirmación del modelo no añade una barrera en el servidor. |
| Cambiar el acceso del equipo | `team_write`; administrador de cuenta por MCP externo | Miembro de la cuenta; protección del propietario | MCP externo cambia directamente el acceso del miembro | El chat integrado dirige al usuario a los ajustes. |

Para cada fila de tu sistema, añade tres columnas que quizá no quepan en un resumen para usuarios: **destinatario externo**, **visibilidad del resultado** y **constancia de la decisión**. Un correo tiene destinatario. Un resumen de un informe privado tiene lectores autorizados. Una llamada fallida necesita un motivo de denegación que ayude al usuario autorizado sin revelar un registro al que no tiene acceso. Estos detalles suelen dejar al descubierto límites que una tabla de ámbitos de permisos pasa por alto.

Después, realiza cuatro comprobaciones sobre la implementación:

1. **Sáltate el descubrimiento.** Llama directamente a una herramienta aunque no aparezca en el catálogo. El servidor debe seguir aplicando sus comprobaciones de ámbito y función.
2. **Cruza el límite del objeto.** Usa un identificador verosímil de otra cuenta o de un objeto restringido de la misma cuenta. Ambos casos deben fallar sin revelar su existencia ni su contenido privado.
3. **Cambia el acceso con la conexión abierta.** Reduce la función del miembro y repite la llamada. La siguiente debe usar sus permisos actuales. Trata los datos descargados anteriormente, los resultados en caché y las URL firmadas como cuestiones de revocación distintas.
4. **Lee la respuesta al pie de la letra.** Comprueba que «borrador», «propuesta», «concesión», «enviado» y «pagado» coincidan con lo guardado y con los efectos externos. El resumen del resultado forma parte del contrato de seguridad porque otras personas pueden actuar basándose en él.

Dejar constancia de la decisión también exige precisión. Kit marca algunas herramientas como destructivas o dirigidas al exterior para los clientes MCP y emite eventos estructurados para **llamadas a herramientas «open-world»**. Esas anotaciones ayudan al cliente a presentarlas; no añaden una aprobación en el servidor. Los eventos tampoco constituyen un registro de auditoría inmutable de todas las llamadas. Kit, además, contabiliza las llamadas a herramientas MCP externas dentro de un presupuesto por cuenta, incluidas las que forman parte de un lote. Ese límite restringe el uso, pero no autoriza el acceso a un objeto. Define qué exige tu auditoría y comprueba después que el endpoint que confirma el cambio deje constancia suficiente.

La revocación también tiene límites. Una comprobación de la función actual puede impedir una llamada futura desde una conexión existente. No puede retirar un correo ya enviado, revertir un cambio de acceso confirmado, recuperar datos copiados al contexto de un agente ni hacer desaparecer una URL firmada ya emitida. Enumera cada uno de esos elementos si tu flujo los crea y define su vigencia o su vía de revocación.

## ¿Cómo aplica Kit este contrato?

El patrón útil de Kit consiste en dejar claros **el objeto y el efecto definitivo**. Un ámbito MCP delegado abre el acceso a un módulo; las comprobaciones del miembro actual y de la cuenta delimitan quién llama; y la búsqueda del registro por la herramienta delimita el objeto. A partir de ahí, la acción puede preparar un borrador, crear una propuesta, redirigir al usuario o confirmar un cambio directamente. Puedes consultar el flujo de conexión en la [guía de Kit para asistentes de IA](/docs/connecting-ai-assistants) y un caso de uso de contratación más amplio en [MCP para contratación](/blog/mcp-for-hiring).

Elige una herramienta con consecuencias, completa la lista y prueba la denegación de un objeto, el cambio de función y la respuesta final. Si conectas un asistente a Kit, revisa los flujos concretos que necesita tu equipo antes de conceder permisos de escritura. El objetivo es que el agente pueda decirte qué cambió, con qué autoridad y qué acción sigue pendiente de una persona.