# Capability Lease (concesión de capacidad)

*Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas.*

> **Una Capability Lease** es una autorización para datos concretos y operaciones concretas, con una caducidad explícita y presupuestos. Se emite a **una ejecución** y es la única vía por la que una ejecución toca el NAS. Una concesión hija solo puede ser más estrecha que su padre.

**AN-04** · Nivel de conformidad: L1 Authority · Grupo: Autoridad

## El problema

RBAC y las ACL suponen usuarios estables con permisos amplios y duraderos. Un agente necesita permisos cortados a la medida de la tarea que dejan de valer cuando la tarea termina. Peor aún, las credenciales de larga duración suelen estar al alcance del agente: en el incidente de abril de 2026, el token estaba en un archivo sin relación, creado para gestionar dominios pero capaz de hacerlo todo.

## Cómo funciona

- **Quién tiene la clave.** Las credenciales de larga duración se quedan con el orquestador o con el propietario; una ejecución recibe una concesión, no una clave. El modelo nunca ve una credencial de larga duración.
- **Una concesión es un token de acceso.** Su `authorization_details` ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)) describe las rutas, las acciones y la rama; la solicita el propietario o el orquestador mediante [intercambio de tokens (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693), la declaración `act` registra la cadena de delegación, y el NAS guarda estado para la revocación y el recuento de presupuestos.
- **Solo estrechar.** Una concesión hija debe ser un subconjunto de su padre, y el NAS lo comprueba al emitirla.
- **Presupuestos.** Bytes leídos y escritos, número de solicitudes y, opcionalmente, bytes de salida y un tope de gasto, contados en la pasarela. Son un **cortacircuitos**, no una facturación exacta.
- **Sobre de políticas.** El propietario fija un rango de antemano; las concesiones dentro de él se emiten de forma automática y todo lo que queda fuera pasa a una [Human Gate](https://agentnas.com/es/concepts/human-gate/). El acceso de larga duración se expresa como un sobre, no como una concesión de larga duración.
- **B y C se declaran de forma explícita.** Una concesión indica la sensibilidad más alta que puede leer y si puede escribir en árboles protegidos o enviar datos al exterior. Son entradas de las [Trust Labels](https://agentnas.com/es/concepts/trust-labels/).
- **Revocación.** Un TTL corto (4 horas por defecto, 24 como máximo) más una revocación inmediata, que se propaga en cascada a las concesiones hijas.
- **`purpose` se registra, no se impone:** el texto libre no lo puede comprobar una máquina.

## Empezar en pequeño

- Escribe un comando `nas lease create`: para cada rol, emite un token con un prefijo de ruta, acciones y un TTL, entrégalo al sandbox en una variable de entorno y haz que el NAS imponga el prefijo y las acciones.
- Esto ya detiene la primera mitad de ese tipo de incidente: el token no puede hacer nada fuera de la concesión.
- Los presupuestos, las cadenas de delegación y los sobres de políticas pueden venir después.

## Esbozo de la interfaz

Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3.

*lease.json*

```json
{
  "lease_id": "lse_7Qk3",
  "run": "run_91ab",
  "principal": "agt_cleo",
  "on_behalf_of": "usr_wei",
  "parent": null,
  "purpose": "Draft the Q4 release notes",
  "paths": ["/shared/launch/**", "/agents/cleo/workspace/**"],
  "actions": ["read", "write", "propose"],
  "branch": "cleo/run_91ab",
  "sensitivity_max": "private",
  "egress": false,
  "requires_gate": ["merge", "delete", "share"],
  "budgets": { "bytes_read": 200000000, "bytes_written": 5000000, "requests": 5000 },
  "expires_at": "2026-11-12T16:00:00Z"
}
```

## Lo que pide la especificación

- Una concesión DEBE tener caducidad y NO DEBE renovarse más allá del TTL máximo; la renovación exige una nueva emisión.
- Una concesión hija DEBE ser un subconjunto de su padre, y el NAS DEBE verificarlo al emitirla.
- Revocar una concesión DEBE propagarse en cascada a todas sus concesiones hijas.
- El acceso de larga duración DEBE expresarse como un sobre de políticas y NO DEBE convertirse en una concesión de larga duración.
- Una concesión DEBE declarar su techo de sensibilidad y si permite la salida de datos y las escrituras protegidas.
- Las credenciales de larga duración NO DEBEN exponerse a un modelo ni a una ejecución.

## Lo prestado y lo nuevo

Lo que sigue son todo piezas establecidas. **Lo nuevo:** tomar como unidad la **forma de una ejecución y una tarea** y poner la rama, los presupuestos y las propiedades de la Rule of Two en una sola concesión. Los tokens y los modelos de capacidades en sí no son nuevos.

- [OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693)
- [OAuth Rich Authorization Requests (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396)
- [Biscuit](https://github.com/biscuit-auth/biscuit)
- [UCAN](https://ucan.xyz/specification/)
- [IETF attenuating agent tokens draft](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/)

## Límites honestos

- Solo cubre las operaciones dentro del NAS y no puede gobernar lo que hace un agente en otros sitios.
- `purpose` no se puede imponer, y los presupuestos son aproximados.
- Una concesión no puede evitar el uso indebido **dentro de la autoridad legítima**; de eso se encargan las ramas y las compuertas.

## Preguntas abiertas

- ¿Cómo puede `purpose` pasar de texto libre a una intención estructurada que una máquina pueda comprobar?
- ¿Cómo se contabilizan los presupuestos bajo federación?

## Preguntas

### ¿En qué se diferencia una concesión de una clave de API?

Una clave de API es un secreto compartido de larga duración, y quien la tiene puede hacer lo que pueda hacer la cuenta. Una concesión está ligada a una ejecución, limita rutas, acciones y tiempo, y solo se puede estrechar; deja de funcionar al caducar y se puede revocar en cualquier momento.

### ¿Por qué no usar simplemente OAuth?

Es OAuth: una concesión es un token de acceso, solicitado mediante intercambio de tokens (RFC 8693) y descrito con rich authorization requests (RFC 9396). Agent NAS solo añade lo que OAuth no especifica: la ejecución como unidad, y poner la rama, los presupuestos y las propiedades de la Rule of Two en una sola autorización.

### ¿Qué le pasa a una ejecución cuando caduca su concesión?

El montaje pasa a solo lectura y después se desmonta; las nuevas solicitudes se rechazan y se registran. La rama se conserva hasta que caduca su propio TTL, de modo que el trabajo terminado no se pierde y todavía se puede fusionar tras la revisión.

## Conceptos relacionados

- [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real.
- [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two.
- [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó.

---

URL canónica: https://agentnas.com/es/concepts/capability-lease/
Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0